อ่านประมาณ 8 นาที
ระดับกลาง
หมวด: เว็บ
อ้างอิง: GitHub Blog
เว็บที่สร้างด้วย React หลายแห่งเขียนสไตล์ไว้ในโค้ด JavaScript ซึ่งสะดวกตอนพัฒนา แต่ทำให้หน้าเว็บต้องรอคำนวณสไตล์ตอนโหลด GitHub ใช้เวลาราวสามปี ย้ายระบบออกแบบ Primer ทั้งหมดไปใช้ไฟล์ CSS ธรรมดาแบบ CSS Modules จนเวลาเรนเดอร์หน้าฝั่งเซิร์ฟเวอร์ลดลง 55% บทความนี้สรุปว่าทำไมการ ship CSS เป็นไฟล์จริงถึงเร็วกว่า และวิธีที่ GitHub ย้ายโดยไม่ทำให้หน้าเว็บที่คนใช้อยู่พัง
CSS-in-JS ช้าตรงไหน
CSS-in-JS คือการเขียนสไตล์เป็นโค้ด JavaScript ผูกกับคอมโพเนนต์ เช่น ไลบรารี styled-components ข้อดีคือสไตล์อยู่ติดกับคอมโพเนนต์และเปลี่ยนตามค่าได้สะดวก แต่สไตล์ถูกสร้างขณะโปรแกรมทำงาน (runtime) ทั้งบนเซิร์ฟเวอร์ที่ต้องเก็บสไตล์ระหว่างเรนเดอร์ และบนเบราว์เซอร์ที่ต้องเตรียมสไตล์ก่อนแสดงผล GitHub พบว่ายิ่งหน้าหนึ่งมีคอมโพเนนต์มาก ต้นทุนส่วนนี้ยิ่งโตตาม และกลายเป็นคอขวดของการโหลดหน้าแรก
CSS Modules แก้ปัญหาอย่างไร
CSS Modules คือไฟล์ CSS ปกติที่วางคู่กับคอมโพเนนต์ แล้วเครื่องมือ build จะตั้งชื่อคลาสให้ไม่ชนกันอัตโนมัติ ผลลัพธ์เป็นไฟล์ stylesheet ธรรมดาที่เบราว์เซอร์อ่านได้ทันทีและแคชได้ จึงได้ข้อดีเรื่องวางสไตล์ไว้ใกล้คอมโพเนนต์เหมือนเดิม แต่ไม่มีงานคำนวณสไตล์ตอน runtime ค่าที่ต้องเปลี่ยนตามธีม เช่น สีของโหมดมืด GitHub ใช้ CSS variables ที่มีอยู่แล้วแทน
ตารางเวลาเรนเดอร์ฝั่งเซิร์ฟเวอร์ที่ลดลงในบริการต่าง ๆ ของ GitHub หลังย้ายสไตล์ออกจาก CSS-in-JS ลดลงตั้งแต่ราว 3% ถึง 22% (ภาพจาก GitHub Blog)
ผลที่วัดได้
ผลจากการย้ายระบบสไตล์ของ GitHub| ช่วง | สิ่งที่ย้าย | ผลที่วัดได้ |
|---|
| ถึงธันวาคม 2024 | คอมโพเนนต์หลักของ Primer | เวลาเรนเดอร์หน้าฝั่งเซิร์ฟเวอร์ลดลง 55% · คอมโพเนนต์บนหน้าพร้อมใช้งานเร็วขึ้น 25% |
| เมษายน 2025 ถึงพฤษภาคม 2026 | prop sx ที่เขียนสไตล์ในโค้ด 6,419 จุด | เรนเดอร์ฝั่งเซิร์ฟเวอร์เร็วขึ้นตั้งแต่ 1% ถึง 22% แล้วแต่หน้า |
| เมษายน 2026 | prop sx 895 จุดสุดท้าย | เหลือ 0 ภายในสามสัปดาห์ ด้วยวิศวกรสองคนร่วมกับเอเจนต์เขียนโค้ด |
วิธีย้ายระบบใหญ่โดยไม่ให้ผู้ใช้เห็นรอยต่อ
GitHub ไม่ได้รื้อทีเดียว แต่เพิ่มไฟล์ CSS Module ข้างสไตล์เดิมของแต่ละคอมโพเนนต์ แล้วสลับด้วย feature flag หรือสวิตช์เปิดปิดฟีเจอร์ ใช้การทดสอบเทียบภาพหน้าจอ (visual regression test) ยืนยันว่าหน้าตาเหมือนเดิมทุกพิกเซล แล้วค่อยเปิดให้ทีมภายใน พนักงานทั้งบริษัท และผู้ใช้ทั้งหมดตามลำดับ ระหว่างทางทำแพ็กเกจตัวกลางให้โค้ดเก่าเรียกใช้ต่อได้ ทำเครื่องมือแปลงโค้ดอัตโนมัติ (codemod) และช่วงท้ายใช้เอเจนต์เขียนโค้ดเก็บงานที่เหลือ
บทเรียนสำหรับทีมที่ทำเว็บ React
- วัดก่อนเลือกเทคนิค ความสะดวกของนักพัฒนาอาจมีต้นทุนที่ผู้ใช้จ่ายทุกครั้งที่โหลดหน้า
- โปรเจกต์ใหม่เริ่มจากไฟล์ CSS จริง เช่น CSS Modules หรือเครื่องมือที่สร้าง CSS ตอน build ดีกว่าย้ายทีหลัง
- ย้ายทีละคอมโพเนนต์ด้วย feature flag และทดสอบเทียบภาพหน้าจอ ลดความเสี่ยงได้มากกว่าการรื้อครั้งเดียว
- ให้เครื่องมือทำงานซ้ำ ๆ codemod และเอเจนต์เขียนโค้ดเหมาะกับงานแปลงรูปแบบเดิมจำนวนมาก แต่ยังต้องมีชุดทดสอบเป็นตัวตัดสิน
เว็บไซต์บริษัทและระบบหลังบ้านในไทยจำนวนมากสร้างด้วย React หรือ Next.js และเจอปัญหาหน้าแรกโหลดช้าบนมือถือราคาประหยัด ซึ่งส่งผลทั้งยอดขายและอันดับใน Google ทีมงาน Smart Cyber Tech รับทำเว็บ React และ Next.js ที่วางโครงสร้างสไตล์และการโหลดให้เร็วตั้งแต่เริ่ม และตรวจความเร็วจากผู้ใช้จริงได้ตามแนวทางในบทความ BEACON ปรึกษาได้ที่ แบบฟอร์มติดต่อ
สรุปสาระสำคัญ
- CSS-in-JS ช้าตรงไหน
- CSS Modules แก้ปัญหาอย่างไร
- ผลที่วัดได้
แหล่งอ้างอิงเรียบเรียงจาก GitHub Blog —
อ่านบทความต้นฉบับภาพปกและแผนภาพ: GitHub Blog · ลิขสิทธิ์ภาพเป็นของเจ้าของต้นฉบับ ใช้ประกอบการรายงานพร้อมอ้างอิงแหล่งที่มา
มีคำถามเพิ่มเติมเกี่ยวกับบทความนี้? เขียนหาเราได้ที่
info@smart-cyber-tech.com
บริการที่เกี่ยวข้องจากทีมงาน Smart Cyber Tech
แบ่งปันบทความนี้:
LINE
Facebook
X
ปรึกษาทีมของเรา