เจาะลึก
Engineering
ส่ง CSS เยอะขึ้น แต่เว็บเร็วขึ้น? GitHub เล่าเบื้องหลังดีไซน์ซิสเต็มที่ไม่พังทั้งไซต์
เมื่อการรื้อดีไซน์ซิสเต็มทั้งระบบไม่ได้แปลว่าต้องแลกด้วยความเร็วเว็บ GitHub อธิบายวิธีที่พวกเขาเลือก "ส่งโค้ดเยอะขึ้น" แต่กลับได้ performance ดีขึ้น
ทีมข่าว เอไอไทย.com
⏱ อ่าน 5 นาที
คำว่า "optimize" ในวิศวกรรมเว็บไม่ได้แปลว่าต้องลดโค้ดเสมอไป บางทีคำตอบที่ถูกคือการจัดระเบียบมันใหม่ให้ฉลาดกว่าเดิม
ถ้าคุณเคยได้ยินคำแนะนำเรื่อง performance ของเว็บมาบ้าง หนึ่งในนั้นที่วนซ้ำบ่อยสุดคือ "ลด CSS ที่โหลดลง" หรือ "ตัดโค้ดที่ไม่ได้ใช้ทิ้งซะ" ฟังดูสมเหตุสมผลใช่ไหม แต่ทีมวิศวกรรมของ GitHub เพิ่งออกมาเล่าเคสที่ตรงกันข้ามเลย พวกเขาบอกว่าการปรับปรุง performance ของเว็บครั้งใหญ่ครั้งล่าสุด กลับทำได้ด้วยการ "ส่ง CSS มากขึ้น" ไม่ใช่ลดลง และที่สำคัญคือทำได้โดยไม่ทำลายทั้งไซต์
เรื่องนี้เกิดขึ้นตอนที่ GitHub ต้องรื้อและส่งการเปลี่ยนแปลงครั้งใหญ่ของดีไซน์ซิสเต็ม (design system) เข้าไปในระบบ ใครที่เคยทำงานกับดีไซน์ซิสเต็มจะรู้ว่ามันไม่ใช่แค่เปลี่ยนสีปุ่มหรือฟอนต์ แต่คือการเปลี่ยน "ภาษากลาง" ที่ทุกคอมโพเนนต์ทั้งเว็บอ้างอิงถึง ถ้าพลาดนิดเดียว หน้าจอที่ดูปกติเมื่อวานอาจพังทั้งหน้าในเช้าวันรุ่งขึ้น
ประเด็นคือดีไซน์ซิสเต็มเดิมของ GitHub มีวิธีจัดการสไตล์ที่ทำให้การเปลี่ยนแปลงแต่ละครั้งต้องแลกกับอะไรบางอย่าง พอจะอัปเดตระบบให้ทันสมัยขึ้น ทีมก็เจอทางเลือกที่ดูจะขัดกับสัญชาตญาณของวิศวกรทั่วไป นั่นคือแทนที่จะพยายามรวบ CSS ให้เหลือน้อยที่สุด พวกเขากลับเลือกแนวทางที่ "ส่ง CSS ออกไปมากขึ้น" แต่จัดโครงสร้างให้เบราว์เซอร์จัดการได้ฉลาดกว่าเดิม
ฟังดูขัดหู แต่ถ้าคิดตามหลักการทำงานของเบราว์เซอร์จริงๆ มันมีเหตุผลอยู่ เบราว์เซอร์ยุคใหม่เก่งเรื่องการแคช (cache) และการแยกวิเคราะห์สไตล์ที่ใช้ซ้ำได้ ถ้า CSS ถูกจัดกลุ่มให้โหลดพร้อมกันในจังหวะที่เหมาะสม แทนที่จะพยายามยัดทุกอย่างไว้ในไฟล์เดียวหรือตัดออกให้เหลือน้อยที่สุด ประสิทธิภาพโดยรวมกลับดีขึ้นได้ เพราะลดการคำนวณซ้ำซ้อนและลดเวลาที่ต้องรอโหลดสไตล์ที่กระจัดกระจาย
สำหรับคนที่ทำงานสาย frontend หรือดูแลเว็บขนาดใหญ่ เคสนี้ตอกย้ำเรื่องที่หลายคนอาจลืมไปแล้ว นั่นคือ "best practice" ด้าน performance ไม่ใช่กฎตายตัวที่ใช้ได้กับทุกบริบท สิ่งที่เคยจริงเมื่อห้าปีก่อนอาจไม่จริงอีกต่อไป เพราะพฤติกรรมของเบราว์เซอร์ มาตรฐานเว็บ และเครื่องมือ build เปลี่ยนไปเรื่อยๆ การยึดติดกับสูตรสำเร็จแบบ "CSS น้อยกว่าคือดีกว่า" โดยไม่ดูบริบทจริง อาจทำให้เราพลาดทางเลือกที่ดีกว่าไปก็ได้
อีกมุมที่ GitHub เน้นคือเรื่องของ "การส่งการเปลี่ยนแปลงโดยไม่ทำลายทั้งโลก" หรือพูดง่ายๆ คือทำยังไงให้อัปเดตดีไซน์ซิสเต็มครั้งใหญ่ได้โดยที่ผู้ใช้ไม่รู้สึกว่ามีอะไรพัง วิธีที่พวกเขาใช้คือการทยอยส่งการเปลี่ยนแปลงเป็นส่วนๆ และออกแบบโครงสร้าง CSS ให้รองรับการอยู่ร่วมกันของสไตล์เก่าและใหม่ได้ในระยะเปลี่ยนผ่าน แทนที่จะบังคับให้ทุกอย่างต้องเปลี่ยนพร้อมกันในดีพลอยเดียว ซึ่งเสี่ยงเกินไปสำหรับเว็บที่มีผู้ใช้หลายสิบล้านคน
นี่คือประโยคที่ GitHub ใช้เปิดเรื่อง ซึ่งสรุปแก่นของเคสนี้ได้ดีทีเดียว เพราะโจทย์จริงของทีมไม่ใช่แค่ "ทำให้เร็วขึ้น" แต่คือ "เปลี่ยนแปลงครั้งใหญ่โดยที่ไม่มีอะไรพัง" ซึ่งเป็นโจทย์ที่ยากกว่ามากสำหรับระบบที่คนใช้ทั่วโลก
สิ่งที่ผมชอบในเคสนี้คือมันไม่ใช่การอวดว่า "เราทำเว็บเร็วขึ้น 30%" แบบที่หลายบริษัทชอบโปรโมต แต่เป็นการแชร์วิธีคิดและบทเรียนจากกระบวนการทำงานจริง ซึ่งมีค่ากับคนในวงการมากกว่า เพราะมันสอนว่า performance ไม่ใช่แค่ตัวเลขใน Lighthouse แต่คือการตัดสินใจเชิงสถาปัตยกรรมที่ต้องชั่งน้ำหนักระหว่างความเร็ว ความเสถียร และความสามารถในการดูแลรักษาระยะยาว
บทเรียนจากเคสนี้คือ "optimize" ไม่ได้แปลว่า "ลด" เสมอไป บางครั้งคำตอบที่ดีที่สุดคือการจัดระเบียบใหม่ให้ฉลาดกว่าเดิม ใครที่ยังยึดสูตรลดโค้ดแบบเดิมๆ อยู่ ลองเปิดใจดูเคสนี้ก่อนตัดสินใจ ไม่งั้นอาจพลาดทางเลือกที่ตอบโจทย์ระบบจริงมากกว่าโดยไม่รู้ตัว
ที่มา: GitHub Blog — อ่านต้นฉบับ
ความคิดเห็น 3
กำลังโหลดความคิดเห็น...