วิธีปรับปรุง Core Web Vitals ที่มีประสิทธิภาพสูงสุด

ตลอดหลายปีที่ผ่านมา ชุมชนเว็บได้รวบรวมความรู้มากมายเกี่ยวกับการเพิ่มประสิทธิภาพของเว็บ แม้ว่าการเพิ่มประสิทธิภาพรายการใดรายการหนึ่งอาจช่วยปรับปรุงประสิทธิภาพของเว็บไซต์หลายแห่งได้ แต่การเพิ่มประสิทธิภาพทั้งหมดพร้อมกันอาจทําให้สับสน และในทางปฏิบัติแล้ว มีเพียงบางรายการเท่านั้นที่ใช้กับเว็บไซต์หนึ่งๆ ได้

การเพิ่มประสิทธิภาพใดที่ส่งผลต่อเว็บไซต์มากที่สุดอาจไม่ชัดเจน เว้นแต่คุณจะทํางานด้านประสิทธิภาพเว็บเป็นอาชีพ คุณอาจไม่มีเวลาทำทั้งหมด ดังนั้นจึงควรถามตัวเองว่าการปรับปรุงใดที่ส่งผลมากที่สุดซึ่งคุณเลือกได้เพื่อปรับปรุงประสิทธิภาพให้กับผู้ใช้

ความจริงเกี่ยวกับการเพิ่มประสิทธิภาพคือ คุณไม่สามารถตัดสินประสิทธิภาพจากข้อดีทางเทคนิคเพียงอย่างเดียว นอกจากนี้ คุณยังต้องพิจารณาปัจจัยด้านบุคคลและองค์กรที่ส่งผลต่อโอกาสในการนำการเพิ่มประสิทธิภาพหนึ่งๆ ไปใช้ ในทางทฤษฎีแล้ว การปรับปรุงประสิทธิภาพบางอย่างอาจส่งผลอย่างมาก แต่ในทางปฏิบัติ มีนักพัฒนาแอปเพียงไม่กี่รายที่มีเวลาหรือทรัพยากรในการใช้งาน ในทางกลับกัน อาจมีแนวทางปฏิบัติแนะนำด้านประสิทธิภาพที่ส่งผลอย่างมากซึ่งเกือบทุกคนก็ทําตามอยู่แล้ว คู่มือนี้จะระบุการเพิ่มประสิทธิภาพเว็บที่มีลักษณะดังนี้

  • สร้างผลกระทบในชีวิตจริงมากที่สุด
  • เกี่ยวข้องและใช้ได้กับเว็บไซต์ส่วนใหญ่
  • เป็นแนวทางที่นักพัฒนาแอปส่วนใหญ่นำไปใช้ได้จริง

ทั้งหมดนี้ถือเป็นวิธีที่เป็นไปได้จริงและมีประสิทธิภาพมากที่สุดในการปรับปรุงเมตริก Core Web Vitals หากคุณเพิ่งเริ่มศึกษาเรื่องประสิทธิภาพของเว็บ หรือยังตัดสินใจไม่ได้ว่าจะทําสิ่งใดเพื่อให้ได้ผลตอบแทนจากการลงทุนมากที่สุด บทความนี้เหมาะสําหรับคุณ

การโต้ตอบกับ Next Paint (INP)

Interaction to Next Paint (INP) เป็นเมตริก Core Web Vitals ใหม่ล่าสุดที่มีโอกาสในการปรับปรุงมากที่สุด อย่างไรก็ตาม เนื่องจากมีเว็บไซต์เพียงไม่กี่แห่งที่ผ่านเกณฑ์ประสบการณ์การใช้งาน "ดี" เมื่อเทียบกับเวอร์ชันก่อนหน้าที่เลิกใช้งานแล้ว คุณจึงอาจเป็นหนึ่งในนักพัฒนาซอฟต์แวร์จํานวนมากที่กำลังเรียนรู้วิธีเพิ่มประสิทธิภาพการตอบสนองของการโต้ตอบเป็นครั้งแรก เริ่มต้นด้วยเทคนิคที่ควรทราบเหล่านี้เพื่อหาวิธีที่มีประสิทธิภาพสูงสุดในการปรับปรุง INP

1. หยุดพักบ่อยๆ เพื่อแบ่งงานยาวๆ

งานคืองานใดก็ตามที่เบราว์เซอร์ทำ ซึ่งรวมถึงการแสดงผล เลย์เอาต์ การแยกวิเคราะห์ การคอมไพล์ หรือการดำเนินการสคริปต์ เมื่องานมีระยะเวลานานกว่า 50 มิลลิวินาที ก็จะกลายเป็นงานที่มีระยะเวลานาน งานที่มีระยะเวลานานเป็นปัญหาเนื่องจากอาจบล็อกเธรดหลักไม่ให้ตอบสนองต่อการโต้ตอบของผู้ใช้ได้อย่างรวดเร็ว

แม้ว่าคุณควรพยายามทำงานใน JavaScript ให้น้อยที่สุดเสมอ แต่คุณก็ช่วยเทรดหลักได้โดยแบ่งงานที่มีระยะเวลานานออกเป็นหลายงาน ซึ่งทำได้โดยให้สิทธิ์เธรดหลักบ่อยๆ เพื่อให้การอัปเดตการแสดงผลและการโต้ตอบอื่นๆ ของผู้ใช้เกิดขึ้นได้เร็วขึ้น

Browser Support

  • Chrome: 129.
  • Edge: 129.
  • Firefox: not supported.
  • Safari: not supported.

Source

Scheduler API ช่วยให้คุณจัดคิวงานโดยใช้ระบบลําดับความสําคัญได้ กล่าวโดยละเอียดคือ API scheduler.yield() จะแบ่งงานที่มีระยะเวลานานออกเป็นหลายงาน ขณะเดียวกันก็จัดการการโต้ตอบได้โดยไม่ต้องเสียลำดับในคิวงาน

การแบ่งงานที่มีระยะเวลานานออกเป็นหลายงานจะช่วยให้เบราว์เซอร์มีเวลามากขึ้นในการดําเนินการที่สำคัญซึ่งบล็อกผู้ใช้

2. หลีกเลี่ยง JavaScript ที่ไม่จําเป็น

เว็บไซต์ใช้ JavaScript มากกว่าที่เคย และดูเหมือนว่าแนวโน้มนี้จะยังคงเดิม เมื่อคุณจัดส่ง JavaScript มากเกินไป เท่ากับว่าคุณกำลังสร้างสภาพแวดล้อมที่งานต่างๆ แย่งกันใช้ทรัพยากรของชุดข้อความหลัก ซึ่งอาจส่งผลต่อเวลาในการตอบสนองของเว็บไซต์ โดยเฉพาะในช่วงเริ่มต้นที่สำคัญ

แต่ปัญหานี้แก้ไขได้และคุณมีตัวเลือกดังนี้

  • ใช้ฟีเจอร์แพลตฟอร์มเว็บที่พร้อมใช้งานอย่างแพร่หลายใน Baseline แทนการติดตั้งใช้งาน JavaScript ที่ซ้ำซ้อน
  • ใช้เครื่องมือการครอบคลุมในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome เพื่อค้นหาโค้ดที่ไม่ได้ใช้ในสคริปต์ การลดขนาดทรัพยากรที่จําเป็นในระหว่างการเริ่มต้นช่วยให้หน้าเว็บใช้เวลาในการแยกวิเคราะห์และคอมไพล์โค้ดน้อยลง ซึ่งจะช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ราบรื่นยิ่งขึ้นตั้งแต่เริ่มต้น
  • ใช้การแยกโค้ดเพื่อสร้างกลุ่มแยกต่างหากสําหรับโค้ดที่ไม่จําเป็นสําหรับการแสดงผลครั้งแรก แต่จะใช้ในภายหลัง
  • หากคุณใช้เครื่องมือจัดการแท็ก ให้เพิ่มประสิทธิภาพแท็กเป็นระยะ คุณนําแท็กเก่าที่มีโค้ดที่ไม่ได้ใช้ออกได้เพื่อลดร่องรอย JavaScript ของเครื่องจัดการแท็ก

3. หลีกเลี่ยงการอัปเดตการแสดงผลขนาดใหญ่

การดำเนินการของ JavaScript เป็นเพียงปัจจัยหนึ่งซึ่งส่งผลต่อเวลาในการตอบสนองของเว็บไซต์ การแสดงผลเป็นงานประเภทหนึ่งที่ต้องใช้ทรัพยากรมากอยู่แล้ว และในระหว่างการอัปเดตการแสดงผลครั้งใหญ่ เว็บไซต์อาจตอบสนองต่อการโต้ตอบของผู้ใช้ช้าลงอีก

การเพิ่มประสิทธิภาพการเรนเดอร์ไม่ใช่กระบวนการที่ตรงไปตรงมา และขึ้นอยู่กับสิ่งที่คุณพยายามบรรลุ อย่างไรก็ตาม ต่อไปนี้คือสิ่งที่คุณทำได้เพื่อให้งานแสดงผลไม่กลายเป็นงานที่ใช้เวลานาน

  • จัดระเบียบการอ่านและเขียน DOM ใหม่ในโค้ด JavaScript เพื่อหลีกเลี่ยงการจัดวางแบบบังคับและการจัดวางที่ทำงานหนักเกินไป
  • ทำให้ DOM มีขนาดเล็ก ขนาด DOM และความรุนแรงของงานเลย์เอาต์มีความเกี่ยวข้องกัน เมื่อโปรแกรมแสดงผลต้องอัปเดตเลย์เอาต์สําหรับ DOM ขนาดใหญ่มาก งานที่จําเป็นในการคํานวณเลย์เอาต์อีกครั้งอาจเพิ่มขึ้นอย่างมาก
  • ใช้การจำกัด CSS เพื่อแสดงผลเนื้อหา DOM ที่อยู่นอกหน้าจอแบบล่าช้า การดำเนินการนี้อาจไม่ตรงไปตรงมาเสมอไป แต่การแยกพื้นที่ที่มีเลย์เอาต์ที่ซับซ้อนจะช่วยให้คุณหลีกเลี่ยงงานด้านเลย์เอาต์และการเรนเดอร์ที่ไม่จำเป็นได้

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) คือ Core Web Vitals ที่นักพัฒนาแอปมักพบปัญหามากที่สุด โดยเว็บไซต์40% ในรายงาน UX ของ Chrome ไม่เป็นไปตามเกณฑ์ LCP ที่แนะนําสําหรับประสบการณ์ของผู้ใช้ที่ดี ทีม Chrome แนะนำเทคนิคต่อไปนี้เป็นวิธีที่มีประสิทธิภาพมากที่สุดในการปรับปรุง LCP

1. ตรวจสอบว่าแหล่งข้อมูล LCP ค้นพบได้จากแหล่งที่มาของ HTML และได้รับการจัดลําดับความสําคัญ

ทีม Chrome สังเกตเห็นสิ่งต่อไปนี้เกี่ยวกับ LCP บนเว็บ

  • ตามสารานุกรมเว็บปี 2024 ของ HTTP Archive หน้าเว็บในอุปกรณ์เคลื่อนที่73% มีรูปภาพเป็นองค์ประกอบ LCP
  • การวิเคราะห์ข้อมูลผู้ใช้จริงจาก Chrome แสดงให้เห็นว่าต้นทางส่วนใหญ่ที่มี LCP ไม่ดีใช้เวลาน้อยกว่า 10% ของเวลา LCP p75 ในการดาวน์โหลดรูปภาพ LCP
  • ในหน้าเว็บที่มี LCP ไม่ดี รูปภาพ LCP ของหน้าเว็บจะโหลดล่าช้าในไคลเอ็นต์ 1,290 มิลลิวินาทีที่เปอร์เซ็นไทล์ที่ 75 ซึ่งมากกว่าครึ่งหนึ่งของงบประมาณสําหรับประสบการณ์การใช้งานที่รวดเร็ว
  • ในหน้าเว็บที่มีองค์ประกอบ LCP เป็นรูปภาพ รูปภาพเหล่านั้น 35% มี URL แหล่งที่มาที่ตรวจไม่พบในการตอบกลับ HTML ครั้งแรก (เช่น <img src="..."> หรือ <link rel="preload" href="...">) ซึ่งจะทำให้เครื่องมือสแกนการโหลดล่วงหน้าของเบราว์เซอร์ค้นพบรูปภาพเหล่านั้นได้เร็วที่สุด
  • ตามข้อมูลใน Web Almanac หน้าเว็บที่มีสิทธิ์ 15% ใช้ประโยชน์จากแอตทริบิวต์ fetchpriority HTML เพื่อให้ความสำคัญกับทรัพยากรมากกว่า ซึ่งรวมถึงทรัพยากรที่อาจปรับปรุง LCP ของหน้าเว็บได้โดยไม่ต้องทำอะไรมากนัก

สถิติเหล่านี้แสดงให้เห็นว่านักพัฒนาแอปมีโอกาสอย่างมากในการลดทั้งความล่าช้าในการโหลดทรัพยากรและระยะเวลาในการโหลดทรัพยากรสําหรับรูปภาพ LCP

Browser Support

  • Chrome: 102.
  • Edge: 102.
  • Firefox: 132.
  • Safari: 17.2.

Source

เมื่อปัญหาคือความล่าช้าในการโหลดทรัพยากร โปรดทราบว่าอาจสายเกินไปที่จะได้ LCP ที่ดีหากหน้าเว็บต้องรอให้ CSS หรือ JavaScript โหลดจนเสร็จสมบูรณ์ก่อนที่จะเริ่มโหลดรูปภาพได้ นอกจากนี้ คุณยังลดระยะเวลาในการโหลดทรัพยากรของรูปภาพ LCP ได้โดยการจัดลําดับความสําคัญใหม่เพื่อให้รูปภาพได้รับแบนด์วิดท์มากขึ้นและโหลดได้เร็วขึ้นโดยใช้fetchpriorityแอตทริบิวต์ HTML

หากองค์ประกอบ LCP เป็นรูปภาพ คุณควรค้นพบ URL ของรูปภาพในการตอบกลับ HTML เพื่อลดเวลาในการโหลดทรัพยากร เคล็ดลับในการทำให้เนื้อหาของคุณเข้าถึงได้ง่ายมีดังนี้

  • โหลดรูปภาพโดยใช้องค์ประกอบ <img> ที่มีแอตทริบิวต์ src หรือ srcset อย่าใช้แอตทริบิวต์ที่ไม่ใช่มาตรฐาน เช่น data-src ที่ต้องอาศัย JavaScript ในการเรนเดอร์ เนื่องจากจะทำงานช้ากว่าเสมอ หน้าเว็บ 7% บดบังรูปภาพ LCP ไว้ด้านหลัง data-src
  • ใช้การแสดงผลฝั่งเซิร์ฟเวอร์ (SSR) แทนการแสดงผลฝั่งไคลเอ็นต์ (CSR) เนื่องจาก SSR บ่งบอกว่ามาร์กอัปทั้งหน้า (รวมถึงรูปภาพ) อยู่ในซอร์ส HTML โซลูชัน CSR กำหนดให้ JavaScript ต้องทำงานก่อนจึงจะค้นพบรูปภาพได้
  • หากต้องอ้างอิงรูปภาพจากไฟล์ CSS หรือ JS ภายนอก คุณยังคงใส่รูปภาพนั้นในซอร์ส HTML ได้โดยใช้แท็ก <link rel="preload"> โปรดทราบว่าเครื่องมือสแกนแบบโหลดล่วงหน้าของเบราว์เซอร์จะตรวจไม่พบรูปภาพที่อ้างอิงโดยสไตล์อินไลน์ ดังนั้นแม้ว่าจะพบรูปภาพเหล่านั้นในซอร์ส HTML แต่ระบบอาจยังคงบล็อกไม่ให้มีการค้นพบรูปภาพเหล่านั้นเมื่อโหลดทรัพยากรอื่นๆ ดังนั้นการโหลดล่วงหน้าจึงช่วยได้ในกรณีเหล่านี้

นอกจากนี้ คุณยังลดระยะเวลาในการโหลดทรัพยากรได้โดยตรวจสอบว่าทรัพยากร LCP โหลดตั้งแต่เนิ่นๆ และมีลําดับความสําคัญสูง ดังนี้

  • เพิ่มแอตทริบิวต์ fetchpriority="high" ลงในแท็ก <img> หรือ <link rel="preload"> ของรูปภาพ LCP ซึ่งจะเพิ่มลำดับความสำคัญของทรัพยากรรูปภาพเพื่อให้เริ่มโหลดได้เร็วขึ้น
  • นําแอตทริบิวต์ loading="lazy" ออกจากแท็ก <img> ของรูปภาพ LCP วิธีนี้จะช่วยหลีกเลี่ยงการหน่วงเวลาในการโหลดที่เกิดจากการยืนยันว่ารูปภาพปรากฏในหรือใกล้กับวิวพอร์ต
  • เลื่อนทรัพยากรที่ไม่สําคัญออกไปหากเป็นไปได้ การย้ายทรัพยากรเหล่านี้ไปไว้ที่ท้ายเอกสาร การโหลดรูปภาพแบบ Lazy Loading หรือ iframe หรือโหลดแบบไม่พร้อมกันโดยใช้ JavaScript จะช่วยให้ทรัพยากรที่สําคัญกว่า เช่น รูปภาพ LCP โหลดได้เร็วขึ้น

2. มุ่งเน้นการนําทางทันที

ประสบการณ์การใช้งานที่ยอดเยี่ยมที่สุดคือไม่ต้องรอให้หน้าเว็บโหลด การเพิ่มประสิทธิภาพ LCP เช่น การค้นพบทรัพยากรและการจัดลําดับความสําคัญของทรัพยากรจะช่วยลดระยะเวลาที่ผู้ใช้ต้องรอให้องค์ประกอบ LCP โหลดและแสดงผล แต่ความเร็วในการโหลดไบต์เหล่านั้นผ่านเครือข่ายและแสดงผลในหน้าเว็บนั้นมีข้อจํากัดทางกายภาพ ก่อนที่คุณจะถึงขีดจำกัดนั้น คุณจะต้องทุ่มเททำงานอย่างหนักเพื่อประหยัดเวลาอีกเพียงไม่กี่มิลลิวินาที ดังนั้น เราจึงต้องใช้แนวทางที่แตกต่างออกไปอย่างสิ้นเชิงเพื่อให้การไปยังส่วนต่างๆ ทำได้ทันที

การนําทางทันทีจะพยายามโหลดและแสดงผลหน้าเว็บก่อนที่ผู้ใช้จะเริ่มไปยังส่วนนั้น วิธีนี้จะช่วยให้หน้าเว็บที่แสดงผลล่วงหน้าแสดงได้ทันทีโดยมี LCP เกือบเป็น 0 การบูรณะและการคาดเดาเป็น 2 วิธีในการดำเนินการนี้ เมื่อผู้ใช้ไปยังหน้าเว็บที่เคยเข้าชมก่อนหน้านี้ ระบบจะกู้คืนหน้าเว็บนั้นจากแคชในหน่วยความจําได้อย่างรวดเร็ว ซึ่งจะปรากฏขึ้นตามที่ผู้ใช้เคยดูไว้ หรือเว็บแอปพลิเคชันอาจลองคาดเดาว่าผู้ใช้จะไปที่ใดต่อ และหากคาดเดาถูก หน้าถัดไปจะโหลดและแสดงผลแล้วเมื่อผู้ใช้ไปยังหน้านั้น

Back-Forward Cache (bfcache) ช่วยในการกู้คืนหน้าที่เข้าชมก่อนหน้านี้ หากต้องการใช้ฟีเจอร์นี้ คุณต้องตรวจสอบว่าหน้าเว็บเป็นไปตามเกณฑ์การมีสิทธิ์ของ bfcache สาเหตุที่พบบ่อยที่ทำให้หน้าเว็บไม่มีสิทธิ์ใช้ bfcache คือหน้าเว็บแสดงพร้อมกับคำสั่งแคช no-store หรือมี unload Listener เหตุการณ์

การกู้คืนหน้าที่แสดงผลอย่างสมบูรณ์ไม่เพียงช่วยปรับปรุงประสิทธิภาพการโหลด แต่ยังช่วยเพิ่มความเสถียรของเลย์เอาต์ด้วย ดูข้อมูลเพิ่มเติมเกี่ยวกับ bfcache และประสิทธิภาพในการปรับปรุง CLS ได้ที่ส่วนตรวจสอบว่าหน้าเว็บมีสิทธิ์ใช้ bfcache

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox: not supported.
  • Safari: not supported.

การแสดงผลหน้าถัดไปที่ผู้ใช้เข้าชมล่วงหน้าเป็นอีกวิธีหนึ่งที่มีประสิทธิภาพในการปรับปรุงประสิทธิภาพ LCP อย่างมาก ซึ่งทำได้ด้วย Speculation Rules API แต่หากต้องการรับประโยชน์เหล่านี้ โปรดตรวจสอบว่าระบบแสดงผลหน้าเว็บที่ถูกต้องล่วงหน้าแล้ว การคาดเดาที่ไม่ถูกต้องจะทำให้ทรัพยากรทั้งบนเซิร์ฟเวอร์และไคลเอ็นต์สิ้นเปลือง ซึ่งอาจส่งผลเสียต่อประสิทธิภาพ ดังนั้นยิ่งคุณไม่แน่ใจว่าหน้าถัดไปจะเป็นอย่างไร คุณก็ควรใช้การแสดงผลล่วงหน้าน้อยลง หากมีข้อสงสัย ข้อมูลวิเคราะห์จะช่วยให้คุณมั่นใจมากขึ้นในการแสดงผลหน้าเว็บล่วงหน้าอย่างกระตือรือร้นมากขึ้นซึ่งมีแนวโน้มสูงที่สุดที่จะได้รับการเข้าชมในลำดับถัดไป

3. ใช้ CDN เพื่อเพิ่มประสิทธิภาพ TTFB

คําแนะนําก่อนหน้านี้มุ่งเน้นที่การนําทางทันที ซึ่งมอบประสบการณ์การใช้งานที่ดีที่สุดให้แก่ผู้ใช้ แต่อาจมีบางกรณีที่เทคนิค bfcache และโหลดโดยประมาณใช้ไม่ได้ พิจารณากรณีที่ผู้ใช้ติดตามลิงก์ข้ามแหล่งที่มาไปยังเว็บไซต์ของคุณ ซึ่งการตอบสนองของเอกสาร HTML เริ่มต้นบล็อก LCP ได้อย่างมีประสิทธิภาพ เบราว์เซอร์จะเริ่มต้นโหลดทรัพยากรย่อยไม่ได้จนกว่าจะได้รับการตอบกลับไบต์แรก ยิ่งดำเนินการเร็วเท่าใด ทุกอย่างก็จะเริ่มเร็วขึ้นเท่านั้น

เวลานี้เรียกว่า Time To First Byte (TTFB) วิธีที่ดีที่สุดในการลด TTFB มีดังนี้

  • แสดงเนื้อหาให้ใกล้กับผู้ใช้ทางภูมิศาสตร์มากที่สุด
  • แคชเนื้อหานั้นเพื่อให้แสดงได้อย่างรวดเร็วหากมีการขออีกครั้งในอนาคตอันใกล้

วิธีที่ดีที่สุดในการดำเนินการทั้ง 2 อย่างนี้คือใช้ CDN CDN จะกระจายทรัพยากรไปยังเซิร์ฟเวอร์ที่ขอบทั่วโลก ซึ่งจะจำกัดระยะทางที่ทรัพยากรเหล่านั้นต้องส่งผ่านสายไปยังผู้ใช้ นอกจากนี้ CDN มักจะมีการควบคุมการแคชแบบละเอียดที่สามารถปรับแต่งตามความต้องการของเว็บไซต์ได้

CDN ยังแสดงและแคชเอกสาร HTML ได้ด้วย แต่ตามข้อมูลใน Web Almanac มีเพียง33% ของคำขอเอกสาร HTML ที่แสดงจาก CDN ซึ่งหมายความว่าเว็บไซต์มีโอกาสประหยัดค่าใช้จ่ายเพิ่มเติมได้

เคล็ดลับในการกําหนดค่า CDN มีดังนี้

  • แคชเอกสาร HTML แบบคงที่แม้เพียงระยะเวลาสั้นๆ เช่น เนื้อหาต้องมีความใหม่อยู่เสมอหรือไม่ หรือข้อมูลอาจล้าสมัยไป 2-3 นาที
  • ตรวจสอบว่าคุณย้ายตรรกะแบบไดนามิกที่ทำงานบนเซิร์ฟเวอร์ต้นทางไปยัง Edge ได้หรือไม่ ซึ่งเป็นฟีเจอร์ของ CDN สมัยใหม่ส่วนใหญ่

ทุกครั้งที่คุณแสดงเนื้อหาจากอุปกรณ์ที่ขอบโดยตรงและหลีกเลี่ยงการไปยังเซิร์ฟเวอร์ต้นทาง ประสิทธิภาพก็จะดีขึ้น แม้ในกรณีที่คุณต้องส่งคำขอไปยังต้นทาง แต่โดยทั่วไป CDN ได้รับการเพิ่มประสิทธิภาพให้ดำเนินการดังกล่าวได้เร็วขึ้น คุณจึงจะได้รับประโยชน์ไม่ว่าในกรณีใดก็ตาม

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS) คือค่าที่วัดความเสถียรขององค์ประกอบที่แสดงบนหน้าเว็บ แม้ว่า CLS จะเป็นเมตริกที่เว็บไซต์ส่วนใหญ่มักจะทำได้ดี แต่เว็บไซต์ประมาณหนึ่งในสี่ยังคงไม่เป็นไปตามเกณฑ์ที่แนะนำ จึงยังมีโอกาสมากมายที่เว็บไซต์จำนวนมากจะปรับปรุงประสบการณ์ของผู้ใช้ได้

1. กำหนดขนาดที่ชัดเจนสำหรับเนื้อหาที่โหลดจากหน้าเว็บ

การเปลี่ยนเลย์เอาต์มักเกิดขึ้นเมื่อเนื้อหาที่มีอยู่ย้ายไปหลังจากที่เนื้อหาอื่นๆ โหลดเสร็จแล้ว วิธีหลักในการปรับปรุง CLS คือการจองพื้นที่ที่จำเป็นล่วงหน้าให้มากที่สุด

วิธีที่ดีที่สุดในการแก้ไขเลย์เอาต์ที่เลื่อนไปมาซึ่งเกิดจากรูปภาพที่ไม่ได้ปรับขนาดคือตั้งค่าแอตทริบิวต์ width และ height อย่างชัดแจ้งหรือพร็อพเพอร์ตี้ CSS ที่เทียบเท่า 66% ของหน้าเว็บมีรูปภาพที่ไม่ได้ปรับขนาดอย่างน้อย 1 รูป หากไม่มีขนาดที่ชัดเจน รูปภาพเหล่านี้จะมีความสูงเริ่มต้น 0px ซึ่งอาจทำให้เลย์เอาต์เปลี่ยนเมื่อรูปภาพเหล่านี้โหลดและเบราว์เซอร์ค้นพบขนาดของรูปภาพ นี่เป็นโอกาสอันยิ่งใหญ่สําหรับเว็บแบบรวม และโอกาสนี้ต้องใช้ความพยายามน้อยกว่าคําแนะนําอื่นๆ บางรายการที่ระบุไว้ในคู่มือนี้

Browser Support

  • Chrome: 88.
  • Edge: 88.
  • Firefox: 89.
  • Safari: 15.

Source

รูปภาพไม่ใช่ปัจจัยเดียวที่ส่งผลต่อ CLS การเปลี่ยนแปลงเลย์เอาต์อาจเกิดจากเนื้อหาอื่นๆ ที่มักจะโหลดหลังจากหน้าเว็บแสดงผลครั้งแรก ซึ่งรวมถึงโฆษณาของบุคคลที่สามหรือวิดีโอที่ฝัง พร็อพเพอร์ตี้ aspect-ratio ช่วยแก้ปัญหานี้ได้ ซึ่งเป็นฟีเจอร์ CSS พื้นฐานที่พร้อมใช้งานในวงกว้างที่ช่วยให้นักพัฒนาแอปสามารถกำหนดสัดส่วนภาพของรูปภาพและองค์ประกอบที่ไม่ใช่รูปภาพได้อย่างชัดเจน ซึ่งจะช่วยให้คุณตั้งค่า width แบบไดนามิกได้ (เช่น ตามขนาดหน้าจอ) และทำให้เบราว์เซอร์คำนวณความสูงที่เหมาะสมโดยอัตโนมัติในลักษณะเดียวกับที่คำนวณสำหรับรูปภาพที่มีมิติข้อมูล

อย่างไรก็ตาม บางครั้งเราอาจไม่ทราบขนาดที่แน่นอนของเนื้อหาแบบไดนามิก แม้ว่าจะไม่ทราบขนาดที่แน่นอน แต่คุณก็ยังคงลดความรุนแรงของการเปลี่ยนเลย์เอาต์ได้ การตั้งค่า min-height ที่สมเหตุสมผลมักจะดีกว่าการอนุญาตให้เบราว์เซอร์ใช้ความสูงเริ่มต้นของ 0px สำหรับองค์ประกอบที่ว่างเปล่า การใช้ min-height มักจะเป็นวิธีแก้ปัญหาที่ตรงไปตรงมา เนื่องจากยังคงอนุญาตให้คอนเทนเนอร์ขยายความสูงตามเนื้อหาสุดท้ายได้หากจำเป็น เพียงแต่จะลดจำนวนการขยายนั้นให้อยู่ในระดับที่ยอมรับได้มากขึ้น

2. ตรวจสอบว่าหน้าเว็บมีสิทธิ์ใช้ bfcache

ตามที่ระบุไว้ก่อนหน้านี้ในคู่มือนี้ Back-Forward Cache (bfcache) จะโหลดหน้าเว็บจากก่อนหน้านี้หรือหลังจากนั้นในประวัติของเบราว์เซอร์จากสแนปชอตหน่วยความจำทันที แม้ว่า bfcache จะเป็นการเพิ่มประสิทธิภาพระดับเบราว์เซอร์ที่สําคัญซึ่งช่วยปรับปรุง LCP แต่ก็ยังช่วยลดการเปลี่ยนเลย์เอาต์ทั้งหมดด้วย อันที่จริงแล้ว การเปิดตัว bfcache ในปี 2022 ส่งผลให้ CLS มีการปรับปรุงมากที่สุดที่เราเห็นในปีนั้น

อย่างไรก็ตาม เว็บไซต์จํานวนมากไม่มีสิทธิ์ใช้ bfcache จึงพลาดโอกาสที่จะได้ประสิทธิภาพเว็บที่ดีขึ้นแบบไม่มีค่าใช้จ่าย ตรวจสอบว่าหน้าเว็บมีสิทธิ์ใช้ bfcache เว้นแต่ว่าหน้าเว็บจะโหลดข้อมูลที่ละเอียดอ่อนซึ่งคุณไม่ต้องการให้กู้คืนจากหน่วยความจำ

เจ้าของเว็บไซต์ควรตรวจสอบว่าหน้าเว็บมีสิทธิ์ใช้ bfcache หรือไม่ และแก้ไขสาเหตุที่หน้าเว็บไม่มีสิทธิ์ Chrome มีเครื่องมือทดสอบ bfcache ในเครื่องมือสำหรับนักพัฒนาเว็บ และคุณยังใช้ Not Restored Reasons API เพื่อตรวจหาสาเหตุของการไม่มีสิทธิ์ในช่องได้ด้วย

3. หลีกเลี่ยงภาพเคลื่อนไหวและการเปลี่ยนรูปแบบที่ใช้พร็อพเพอร์ตี้ CSS ที่ทำให้เกิดเลย์เอาต์

สาเหตุที่พบบ่อยอีกประการหนึ่งที่ทำให้เลย์เอาต์เปลี่ยนคือเมื่อองค์ประกอบมีภาพเคลื่อนไหว เช่น แบนเนอร์คุกกี้หรือแบนเนอร์การแจ้งเตือนอื่นๆ ที่เลื่อนเข้ามาจากด้านบนหรือด้านล่างมักทำให้เกิด CLS ปัญหานี้เกิดขึ้นได้เมื่อแบนเนอร์เหล่านี้ดันเนื้อหาอื่นๆ ออก แต่แม้ว่าจะไม่ดันออก การแสดงภาพเคลื่อนไหวของแบนเนอร์ก็อาจส่งผลต่อ CLS ได้

แม้ว่าข้อมูลใน HTTP Archive จะไม่สามารถเชื่อมโยงภาพเคลื่อนไหวกับการเปลี่ยนแปลงเลย์เอาต์ได้อย่างแน่ชัด แต่ข้อมูลก็แสดงให้เห็นว่าหน้าเว็บที่มีภาพเคลื่อนไหวของพร็อพเพอร์ตี้ CSS ที่อาจส่งผลต่อเลย์เอาต์มีแนวโน้มที่จะมีค่า CLS "ดี" น้อยกว่าหน้าเว็บโดยรวม 15% พร็อพเพอร์ตี้บางรายการเชื่อมโยงกับ CLS ที่แย่กว่าพร็อพเพอร์ตี้อื่นๆ ตัวอย่างเช่น หน้าเว็บที่มีภาพเคลื่อนไหวที่มีขนาด margin หรือ border มี CLS "แย่" เกือบ 2 เท่าของอัตราที่หน้าเว็บโดยรวมได้รับการประเมินว่าแย่

เรื่องนี้อาจไม่น่าแปลกใจ เนื่องจากทุกครั้งที่คุณเปลี่ยนหรือทำให้คุณสมบัติ CSS ที่ทำให้เกิดเลย์เอาต์ใดๆ เคลื่อนไหว จะทำให้เลย์เอาต์เปลี่ยนตำแหน่ง หากการเปลี่ยนแปลงเลย์เอาต์เหล่านั้นไม่ได้อยู่ในช่วง 500 มิลลิวินาทีหลังจากการโต้ตอบของผู้ใช้ การเปลี่ยนแปลงดังกล่าวจะส่งผลต่อ CLS

สิ่งที่นักพัฒนาแอปบางรายอาจประหลาดใจก็คือ การดำเนินการนี้จะยังคงมีผลแม้ในกรณีที่นำองค์ประกอบออกจากโฟลว์เอกสารปกติ เช่น องค์ประกอบที่วางตำแหน่งแบบสัมบูรณ์ซึ่งแสดงภาพเคลื่อนไหว top หรือ left จะทําให้เลย์เอาต์เปลี่ยนตำแหน่ง แม้ว่าจะไม่ดันเนื้อหาอื่นๆ ก็ตาม อย่างไรก็ตาม หากคุณใช้ transform:translateX() หรือ transform:translateY() แทนที่จะใช้ top หรือ left จะไม่ทําให้เบราว์เซอร์อัปเดตเลย์เอาต์หน้าเว็บ จึงหลีกเลี่ยงการเปลี่ยนแปลงเลย์เอาต์ได้

การใช้ภาพเคลื่อนไหวของพร็อพเพอร์ตี้ CSS ที่อัปเดตได้ในเธรดคอมโพสิตของเบราว์เซอร์ถือเป็นแนวทางปฏิบัติแนะนำด้านประสิทธิภาพมาอย่างยาวนาน เนื่องจากจะย้ายงานออกจากเธรดหลักไปยัง GPU นอกจากจะเป็นแนวทางปฏิบัติแนะนำด้านประสิทธิภาพทั่วไปแล้ว ยังช่วยปรับปรุง CLS ได้ด้วย

โดยทั่วไปแล้ว คุณไม่ควรใช้ภาพเคลื่อนไหวหรือการเปลี่ยนผ่านกับคุณสมบัติ CSS ที่ต้องใช้เบราว์เซอร์อัปเดตเลย์เอาต์หน้าเว็บ เว้นแต่คุณจะใช้เพื่อตอบสนองต่อการแตะหรือกดแป้นของผู้ใช้ (แต่ไม่ใช่ hover) เมื่อเป็นไปได้ ให้ใช้การเปลี่ยนผ่านและภาพเคลื่อนไหวโดยใช้คุณสมบัติ transform ของ CSS

การตรวจสอบของ Lighthouse หลีกเลี่ยงการใช้ภาพเคลื่อนไหวที่ไม่ได้ทำการ Composite จะเตือนเมื่อหน้าเว็บแสดงภาพเคลื่อนไหวพร็อพเพอร์ตี้ CSS ที่อาจทําให้ช้า

บทสรุป

การปรับปรุงประสิทธิภาพหน้าเว็บอาจดูน่ากลัว โดยเฉพาะอย่างยิ่งเมื่อพิจารณาจากคําแนะนํามากมายบนเว็บ อย่างไรก็ตาม การมุ่งเน้นที่แนวทางปฏิบัติแนะนำที่มีประสิทธิภาพสูงสุดในรายการสั้นๆ นี้จะช่วยให้คุณแก้ไขปัญหาด้วยโฟกัสที่เปลี่ยนไป และหวังว่าจะปรับปรุง Core Web Vitals ของเว็บไซต์ได้

หากต้องการเพิ่มประสิทธิภาพนอกเหนือจากที่ระบุไว้ที่นี่ โปรดอ่านคู่มือต่อไปนี้เพื่อดูข้อมูลเพิ่มเติม

ภาคผนวก: บันทึกการเปลี่ยนแปลง

ระบบจะติดตามการเปลี่ยนแปลงที่สำคัญในเอกสารนี้เพื่อช่วยอธิบายว่าทำไมและเมื่อใดที่คำแนะนำยอดนิยมมีการเปลี่ยนแปลง

ตุลาคม 2024

ข้อมูลอัปเดตปี 2024

  • INP
    • เราเปลี่ยนเมตริกนี้จาก FID เป็น INP ตามการเปิดตัว INP ในฐานะเมตริก Core Web Vitals และทำให้ INP เป็นเมตริกอันดับแรกในรายการ
    • เรายกเลิกคําแนะนําให้ใช้ isInputPending API ในการแบ่งงานที่ใช้เวลานาน ดูข้อมูลเพิ่มเติมเกี่ยวกับเหตุผลของเราได้ในบทความเพิ่มประสิทธิภาพงานระยะยาว
  • LCP
    • เราได้รวมคําแนะนําเกี่ยวกับความสามารถในการค้นพบและการจัดลําดับความสําคัญเข้าด้วยกัน
    • เราได้เพิ่มคําแนะนําใหม่เพื่อมุ่งเน้นการนําทางทันที

มกราคม 2023

รายการคําแนะนําเบื้องต้นมีดังนี้

  • LCP
    • ตรวจสอบว่าทรัพยากร LCP ค้นพบได้จากแหล่งที่มาของ HTML
    • ตรวจสอบว่าทรัพยากร LCP มีลําดับความสําคัญ
    • ใช้ CDN เพื่อเพิ่มประสิทธิภาพ TTFB ของเอกสารและทรัพยากร
  • CLS
    • กำหนดขนาดที่ชัดเจนสำหรับเนื้อหาที่โหลดจากหน้าเว็บ
    • ตรวจสอบว่าหน้าเว็บมีสิทธิ์ใช้ bfcache
    • หลีกเลี่ยงภาพเคลื่อนไหวและการเปลี่ยนรูปแบบที่ใช้พร็อพเพอร์ตี้ CSS ที่ทำให้เกิดเลย์เอาต์
  • FID
    • หลีกเลี่ยงหรือแบ่งงานที่มีระยะเวลานาน
    • หลีกเลี่ยง JavaScript ที่ไม่จําเป็น
    • หลีกเลี่ยงการอัปเดตการแสดงผลขนาดใหญ่

นอกจากนี้ คุณยังดูการนำเสนอของ Google I/O 2023 นี้เพื่อดูสรุปแบบวิดีโอได้ด้วย