หน้านี้ได้รับการแปลโดย Cloud Translation API

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

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

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

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

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

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

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

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

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

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

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

การรองรับเบราว์เซอร์

แหล่งที่มา

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 บนเว็บ

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

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

การรองรับเบราว์เซอร์

แหล่งที่มา

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

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

โหลดรูปภาพโดยใช้องค์ประกอบ <img> ที่มีแอตทริบิวต์ src หรือ srcset อย่าใช้แอตทริบิวต์ที่ไม่ใช่มาตรฐาน เช่น data-src ที่ต้องอาศัย JavaScript ในการเรนเดอร์ เนื่องจากจะช้ากว่าเสมอ 9% ของหน้าเว็บบดบังรูปภาพ 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

การรองรับเบราว์เซอร์

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

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

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

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

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

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

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

เคล็ดลับบางอย่างสำหรับการกำหนดค่า CDN มีดังนี้

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

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

Cumulative Layout Shift (CLS)

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

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

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

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

การรองรับเบราว์เซอร์

แหล่งที่มา

รูปภาพไม่ใช่ปัจจัยเดียวที่ส่งผลต่อ 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)) หากทำได้ ควรใช้การเปลี่ยนและภาพเคลื่อนไหวโดยใช้พร็อพเพอร์ตี้ CSS transform ทุกครั้งที่ทำได้

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

บทสรุป

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

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

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

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

ตุลาคม 2024

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

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

มกราคม 2023

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

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

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