ในโลกของการพัฒนาเว็บ มีกฎด้านประสิทธิภาพบางอย่างที่กลายเป็นเหมือนคำสอนสากลมาหลายปี นักพัฒนาถูกสอนมาว่าการใช้ CSS transform และ opacity จะรับประกันการเคลื่อนไหวที่ลื่นไหล ในขณะที่คุณสมบัติเช่น top และ left จะทำให้เกิดการรีโฟลว์ที่ใช้ทรัพยากรสูงและทำให้การแสดงผลกระตุก แต่จะเป็นอย่างไรหากความรู้ทั่วไปนี้ไม่เป็นความจริงทั้งหมดอีกต่อไป? บทความทางเทคนิคล่าสุดและการอภิปรายในชุมชนตามมาได้เปิดเผยว่าเบราว์เซอร์สมัยใหม่นั้นฉลาดกว่าที่เราให้เครดิตกับมันมาก และความเป็นจริงของการปรับปรุงประสิทธิภาพนั้นมีความละเอียดอ่อนกว่าที่กฎง่ายๆ บอกเรา
คำสัญญาด้านประสิทธิภาพ กับ ความเป็นจริง
บทความเดิมได้นำเสนอความแตกต่างที่ชัดเจนสองแบบ: รุ่นที่ไม่ได้ปรับแต่งโดยใช้คุณสมบัติ top และ left ซึ่งคาดเดาว่าก่อให้เกิดการรีโฟลว์ กับอีกรุ่นที่ปรับแต่งแล้วโดยใช้ transform ซึ่งใช้ประโยชน์จากการเร่งความเร็วโดย GPU ผลลัพธ์ที่สัญญาไว้คือความแตกต่างอย่างมาก – รุ่นที่ไม่ได้ปรับแต่งแสดงผลได้เพียง 21 FPS ในขณะที่รุ่นที่ปรับแต่งแล้วยังคงรักษาไว้ที่ 60 FPS อย่างลื่นไหล อย่างไรก็ตาม เมื่อนักพัฒนาในส่วนความคิดเห็นได้ทำการโปรไฟล์การทำงานของทั้งสองเวอร์ชันจริงๆ พวกเขากลับค้นพบสิ่งที่น่าประหลาดใจ ผู้แสดงความคิดเห็นหลายคนรายงานว่าไม่มีเวอร์ชันใดที่พลาดเฟรมอย่างต่อเนื่องในเบราว์เซอร์สมัยใหม่ และความแตกต่างของประสิทธิภาพนั้นน้อยกว่าที่อ้างไว้มาก นักพัฒนาคนหนึ่งระบุหลังจากทำการโปรไฟล์ว่า: ไม่มีเบราว์เซอร์ใดทำการรีโฟลว์เลย หรือการรีโฟลว์ทั้งหมดเกิดขึ้นเร็วพอจนไม่มีตัวอย่างใดๆ ในโปรไฟล์เลอร์ที่เกี่ยวข้องกับการนี้ การเปิดเผยครั้งนี้ท้าทายสมมติฐานพื้นฐานที่ว่าคุณสมบัติ CSS บางอย่างจะกระตุ้นการทำงานของเบราว์เซอร์ที่ใช้ทรัพยากรสูงโดยอัตโนมัติ
การคำนวณงบประมาณเฟรม:
- เป้าหมาย: 60 FPS (เฟรมต่อวินาที)
- งบประมาณต่อเฟรม: 1000ms ÷ 60 = 16.67 มิลลิวินาที
- จอแสดงผลระดับไฮเอนด์: 120 Hz = 8.33ms ต่อเฟรม
การปรับแต่งเบราว์เซอร์ได้เปลี่ยนเกมไปแล้ว
การตรวจสอบโดยชุมชนเปิดเผยว่าเครื่องมือของเบราว์เซอร์ได้พัฒนากลยุทธ์การปรับแต่งที่ซับซ้อนซึ่งมักจะหลีกเลี่ยงสิ่งที่นักพัฒนาเชื่อว่าจะเป็นจุดบกพร่องด้านประสิทธิภาพ เมื่อใช้ position: absolute เบราว์เซอร์มักจะสามารถปรับแต่งการเคลื่อนย้ายได้อย่างมีประสิทธิภาพจนการรีโฟลว์ที่น่ากลัวนั้นไม่เกิดขึ้น หรือเกิดขึ้นเร็วมากจนไม่นับว่ามีนัยสำคัญ ดังที่ผู้แสดงความคิดเห็นหนึ่งคนชี้ให้เห็น: การย้ายองค์ประกอบที่กำหนดตำแหน่งแบบ absolute ไม่เคยทำให้เกิดการรีโฟลว์ โดยการออกแบบ นี่อธิบายได้ว่าทำไมนักพัฒนาหลายคนพบความแตกต่างของประสิทธิภาพเพียงเล็กน้อยระหว่างการใช้งานสองแบบในการทดสอบของพวกเขา ความเป็นจริงคือเบราว์เซอร์มีสิ่งที่ผู้แสดงความคิดเห็นหนึ่งคนอธิบายว่าเป็น กองการปรับแต่งโดยใช้การคาดเดาขนาดใหญ่ ซึ่งขัดแย้งกับคำอธิบายง่ายๆ ทำให้กฎประสิทธิภาพแบบเหมาทั้งหมดไม่น่าเชื่อถือมากขึ้นเรื่อยๆ
ขั้นตอนหลักของ Browser Rendering Pipeline:
- Scripting: การประมวลผล JavaScript บนเธรดหลัก
- Style Calculation: การกำหนดว่ากฎ CSS ใดที่ใช้กับแต่ละองค์ประกอบ
- Reflow/Layout: การคำนวณขนาดและตำแหน่งขององค์ประกอบ
- Repaint/Paint: การวาดพิกเซลเพื่อแสดงผลภาพ
- Composite: การรวมเลเยอร์ต่างๆ เพื่อแสดงผลขั้นสุดท้ายบนหน้าจอ
ตัวการที่แท้จริงของปัญหาประสิทธิภาพปรากฏขึ้น
เมื่อนักพัฒนาลงลึกไปในโค้ดตัวอย่างจริง พวกเขาค้นพบว่าความแตกต่างของประสิทธิภาพที่สำคัญนั้นไม่ได้เกิดจากการเลือกระหว่าง transform กับ top/left เป็นหลัก แต่เกิดจากปัจจัยที่แตกต่างไปโดยสิ้นเชิง นั่นคือเอฟเฟกต์ box-shadow นักพัฒนาคนหนึ่งที่ตรวจสอบโค้ดที่ทำงานจริงระบุว่า การลบเงาออกไปทำให้ประสิทธิภาพของทั้งสองวิธีใกล้เคียงกันมากขึ้นอย่างมาก สิ่งนี้เน้นย้ำให้เห็นว่าเอฟเฟกต์ภาพเช่น เงา การไล่ระดับสี และเส้นขอบที่ซับซ้อน มักจะมีผลกระทบต่อประสิทธิภาพมากกว่าคุณสมบัติการจัดเลย์out ฉันทามติของชุมชนได้เปลี่ยนไปสู่ความเข้าใจที่ว่าการดำเนินการวาดภาพ (การวาดเอฟเฟกต์ภาพ) มากกว่าการดำเนินการจัดเลย์out (การกำหนดตำแหน่งองค์ประกอบ) มักจะเป็นจุดคอขวดด้านประสิทธิภาพที่แท้จริงในแอปพลิเคชันเว็บสมัยใหม่
ลักษณะประสิทธิภาพของ CSS Property:
- Layout-triggering:
top,left,width,height,margin - Paint-only:
background-color,box-shadow,border-color - Composite-only:
transform,opacity(โดยทั่วไปจะใช้ GPU-accelerated)
ความสำคัญของการโปรไฟล์จริง มากกว่าการใช้กฎทั่วๆ ไป
การอภิปรายสรุปได้ที่ความเข้าใจที่สำคัญ: คุณไม่สามารถพึ่งพากฎประสิทธิภาพทั่วๆ ไปในการพัฒนาเว็บสมัยใหม่ได้ ดังที่ผู้แสดงความคิดเห็นหนึ่งคนกล่าวอย่างรวบรัดว่า: ความจริงก็คือเบราว์เซอร์มีกองการปรับแต่งโดยใช้การคาดเดาขนาดใหญ่ซึ่งขัดแย้งกับคำอธิบายง่ายๆ คุณต้องทำการโปรไฟล์และทดลอง ทุกครั้ง แยกกัน ความรู้สึกนี้สะท้อนโดยนักพัฒนาหลายคนที่พบว่าผลการโปรไฟล์ของพวกเขาขัดแย้งกับข้อกล่าวอ้างในบทความ ชุมชนเน้นย้ำว่าการปรับปรุงประสิทธิภาพต้องขับเคลื่อนด้วยข้อมูลมากกว่าที่จะอิงตามข้อสันนิษฐาน โดยการวัดผลจริงในเบราว์เซอร์เป้าหมายเป็นวิธีการที่เชื่อถือได้เพียงวิธีเดียว
ความจริงก็คือเบราว์เซอร์มีกองการปรับแต่งโดยใช้การคาดเดาขนาดใหญ่ซึ่งขัดแย้งกับคำอธิบายง่ายๆ คุณต้องทำการโปรไฟล์และทดลอง ทุกครั้ง แยกกัน
กว่าเบราว์เซอร์: การพิจารณาด้านสถาปัตยกรรม
บทสนทนาได้ขยายออกไปเกินกว่าการปรับแต่ง CSS ไปสู่คำถามทางสถาปัตยกรรมที่กว้างขึ้นเกี่ยวกับว่าควรจัดการการเรนเดอร์อย่างไร นักพัฒนาบางคนแย้งว่าปัญหาพื้นฐานอยู่ในสถาปัตยกรรมของเบราว์เซอร์เอง โดยเสนอแนะว่า 'user' code ทั้งหมดต้องทำงานในเธรดเฉพาะ โดยแยกออกจากการวนรอบการเรนเดอร์โดยสิ้นเชิง คนอื่นๆ โต้แย้งว่าการแยกออกจากกันโดยสมบูรณ์ก็สร้างปัญหาของมันเอง นำไปสู่ปุ่มที่ไม่มีฟังก์ชันการทำงานเมื่อคลิก การเลื่อนไปยังพื้นที่ที่ยังไม่ได้โหลด ภาพเคลื่อนไหวการโหลดที่ไม่สิ้นสุด และสิ่งผิดปกติอื่นๆ การอภิปรายเชิงปรัชญานี้เน้นให้เห็นถึงความตึงเครียดอย่างต่อเนื่องระหว่างภาพเคลื่อนไหวที่ลื่นไหลและปฏิสัมพันธ์ผู้ใช้ที่ตอบสนองซึ่งนักพัฒนาต้องสร้างสมดุล
วิวัฒนาการของการปรับแต่งประสิทธิภาพเบราว์เซอร์สะท้อนให้เห็นถึงแนวโน้มที่ใหญ่กว่าในเทคโนโลยี: เมื่อระบบมีความซับซ้อนมากขึ้น กฎง่ายๆ ก็ใช้การไม่ได้ คำแนะนำด้านประสิทธิภาพที่ใช้งานได้เมื่อห้าปีที่แล้วอาจไม่ใช้กับวันนี้อีกต่อไป และสิ่งที่ใช้งานได้ใน Chrome อาจทำงานแตกต่างออกไปใน Firefox ประเด็นสำคัญจากการอภิปรายของชุมชนครั้งนี้คือประสิทธิภาพเว็บไม่สามารถลดเหลือเพียงแค่รายการตรวจสอบง่ายๆ ของคุณสมบัติ CSS ที่ดีและไม่ดีได้อีกต่อไป แต่แทนที่นักพัฒนาจำเป็นต้องยอมรับแนวทางที่ละเอียดอ่อนมากขึ้นซึ่งรวมความเข้าใจในกระบวนการพื้นฐานของเบราว์เซอร์เข้ากับการวัดผลที่เข้มงวดและต่อเนื่องในกรณีการใช้งานเฉพาะของพวกเขา ทักษะที่มีค่าที่สุดในการพัฒนาเว็บสมัยใหม่อาจไม่ใช่การจดจำกฎประสิทธิภาพ แต่เป็นการรู้วิธีโปรไฟล์และตีความผลลัพธ์อย่างมีประสิทธิภาพ
อ้างอิง: Inside a 16.67 Millisecond Frame