SCT

กำลังเตรียมประสบการณ์ดิจิทัล

GitHub เลิกใช้ CSS-in-JS ย้ายไป CSS Modules: หน้าเว็บเรนเดอร์ฝั่งเซิร์ฟเวอร์เร็วขึ้น 55% และบทเรียนการย้ายระบบใหญ่แบบค่อยเป็นค่อยไป

เว็บที่สร้างด้วย React หลายแห่งเขียนสไตล์ไว้ในโค้ด JavaScript ซึ่งสะดวกตอนพัฒนา แต่ทำให้หน้าเว็บต้องรอคำนวณสไตล์ตอนโหลด GitHub ใช้เวลาราวสามปี ย้ายระบบออกแบบ Primer ทั้งหมดไปใช้ไฟล์ CSS ธรรมดาแบบ CSS Modules จนเวลาเรนเดอร์หน้าฝั่งเซิร์ฟเวอร์ลดลง 55% บทความนี้สรุปว่าทำไมการ ship CSS เป็นไฟล์จริงถึงเร็วกว่า และวิธีที่ GitHub ย้ายโดยไม่ทำให้หน้าเว็บที่คนใช้อยู่พัง

เว็บที่สร้างด้วย 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 หลังย้ายสไตล์ออกจาก CSS-in-JS ลดลงตั้งแต่ราว 3% ถึง 22% (ภาพจาก GitHub Blog)

ผลที่วัดได้

ผลจากการย้ายระบบสไตล์ของ GitHub
ช่วงสิ่งที่ย้ายผลที่วัดได้
ถึงธันวาคม 2024คอมโพเนนต์หลักของ Primerเวลาเรนเดอร์หน้าฝั่งเซิร์ฟเวอร์ลดลง 55% · คอมโพเนนต์บนหน้าพร้อมใช้งานเร็วขึ้น 25%
เมษายน 2025 ถึงพฤษภาคม 2026prop sx ที่เขียนสไตล์ในโค้ด 6,419 จุดเรนเดอร์ฝั่งเซิร์ฟเวอร์เร็วขึ้นตั้งแต่ 1% ถึง 22% แล้วแต่หน้า
เมษายน 2026prop sx 895 จุดสุดท้ายเหลือ 0 ภายในสามสัปดาห์ ด้วยวิศวกรสองคนร่วมกับเอเจนต์เขียนโค้ด

วิธีย้ายระบบใหญ่โดยไม่ให้ผู้ใช้เห็นรอยต่อ

GitHub ไม่ได้รื้อทีเดียว แต่เพิ่มไฟล์ CSS Module ข้างสไตล์เดิมของแต่ละคอมโพเนนต์ แล้วสลับด้วย feature flag หรือสวิตช์เปิดปิดฟีเจอร์ ใช้การทดสอบเทียบภาพหน้าจอ (visual regression test) ยืนยันว่าหน้าตาเหมือนเดิมทุกพิกเซล แล้วค่อยเปิดให้ทีมภายใน พนักงานทั้งบริษัท และผู้ใช้ทั้งหมดตามลำดับ ระหว่างทางทำแพ็กเกจตัวกลางให้โค้ดเก่าเรียกใช้ต่อได้ ทำเครื่องมือแปลงโค้ดอัตโนมัติ (codemod) และช่วงท้ายใช้เอเจนต์เขียนโค้ดเก็บงานที่เหลือ

บทเรียนสำหรับทีมที่ทำเว็บ React

  1. วัดก่อนเลือกเทคนิค ความสะดวกของนักพัฒนาอาจมีต้นทุนที่ผู้ใช้จ่ายทุกครั้งที่โหลดหน้า
  2. โปรเจกต์ใหม่เริ่มจากไฟล์ CSS จริง เช่น CSS Modules หรือเครื่องมือที่สร้าง CSS ตอน build ดีกว่าย้ายทีหลัง
  3. ย้ายทีละคอมโพเนนต์ด้วย feature flag และทดสอบเทียบภาพหน้าจอ ลดความเสี่ยงได้มากกว่าการรื้อครั้งเดียว
  4. ให้เครื่องมือทำงานซ้ำ ๆ 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

บทความอื่นที่เกี่ยวข้อง

บทความที่เกี่ยวข้อง

ย้ายเว็บ Next.js ไปรันที่ไหนก็ได้: Vinext 1.0 ของ Cloudflare สร้างแอป Next.js ด้วย Vite และย้าย prerender ไปทำหลัง deploy เว็บ

ย้ายเว็บ Next.js ไปรันที่ไหนก็ได้: Vinext 1.0 ของ Cloudflare สร้างแอป Next.js ด้วย Vite และย้าย prerender ไปทำหลัง deploy

ทีมที่ทำเว็บด้วย Next.js มักเจอคำถามเดียวกันเมื่อเว็บโตขึ้น คือจะย้ายไปรันบนแพลตฟอร์มอื่นได้แค่ไหนโดยไม่ต้องเขียนใหม่ Cloudflare ออก Vinext 1.0 เฟรมเวิร์กโอเพนซอร์สที่สร้างแอป Next.js เดิมด้วย Vite แทนเครื่องมือ build ของ Next.js ทำให้ deploy ได้ทั้ง Cloudflare Workers, Netlify และ AWS Lambda รองรับทั้ง App Router และ Pages Router และผ่านชุดทดสอบของ Next.js ในส่วนที่ลูกค้าใช้จริงเกิน 99%

อ่านบทความ
เว็บทั่วโลกเร็วแค่ไหนจริง ๆ: Cloudflare เปิดข้อมูลความเร็วจากผู้ใช้จริงชุด BEACON ให้ใครก็วิเคราะห์ได้ และสิ่งที่ตัวเลขบอกทีมทำเว็บ เว็บ

เว็บทั่วโลกเร็วแค่ไหนจริง ๆ: Cloudflare เปิดข้อมูลความเร็วจากผู้ใช้จริงชุด BEACON ให้ใครก็วิเคราะห์ได้ และสิ่งที่ตัวเลขบอกทีมทำเว็บ

ทีมทำเว็บส่วนใหญ่วัดความเร็วจากเครื่องของตัวเองหรือจากเครื่องมือทดสอบ ซึ่งไม่เหมือนสิ่งที่ผู้ใช้จริงเจอบนมือถือและเครือข่ายที่หลากหลาย Cloudflare เปิดข้อมูลชุด BEACON ซึ่งรวบรวมการวัดความเร็วจากผู้ใช้จริงนับพันล้านครั้งต่อวันของเว็บไซต์ 10,000 อันดับแรกบนเครือข่ายของตน ให้ทุกคนวิเคราะห์ได้ผ่าน Google BigQuery ข้อมูลชุดแรกบอกว่าหน้าแรกที่ผู้ใช้เข้ามาถึงช้ากว่าการเปลี่ยนหน้าภายในเว็บหลายเท่า และเบราว์เซอร์บน iPhone ช้ากว่าเบราว์เซอร์ตระกูล Chrome ในหลายสิบประเทศ

อ่านบทความ
ช่องโหว่ deserialization ใน React Server Components: เข้าใจโปรโตคอล Flight ก่อนจะถูกโจมตี เว็บ

ช่องโหว่ deserialization ใน React Server Components: เข้าใจโปรโตคอล Flight ก่อนจะถูกโจมตี

React Server Components ส่งข้อมูลด้วยโปรโตคอลสตรีมชื่อ Flight ซึ่งไม่ได้ส่งแค่ HTML หรือ JSON แต่ส่งคำสั่งให้ฝั่งไคลเอนต์ประกอบออบเจ็กต์ที่ทำงานได้ขึ้นมาใหม่ บทความนี้อธิบายว่าจุดใดกลายเป็นช่องโหว่ ทำไม React2Shell ถึงได้คะแนน CVSS 10.0 และแนวทางป้องกันที่ควรทำเรียงตามลำดับความสำคัญ

อ่านบทความ

ติดต่อเพื่อขอรับคำปรึกษาจากทีมงาน

ตั้งแต่ประเมินระบบปัจจุบัน วางแผน จนถึงลงมือพัฒนา — คุยกับเราได้โดยไม่มีค่าใช้จ่าย

ปรึกษาทีมของเรา