Cumulative Layout Shift (CLS) เป็น 1 ใน 3 ของเมตริก Core Web Vitals โดยจะวัดความไม่แน่นอนของเนื้อหาโดยรวมปริมาณเนื้อหาที่มองเห็นได้ที่เปลี่ยนไปในวิวพอร์ตกับระยะทางที่องค์ประกอบที่ได้รับผลกระทบเคลื่อนที่
การเปลี่ยนเลย์เอาต์อาจทำให้ผู้ใช้เสียสมาธิ ลองนึกภาพว่าคุณเริ่มอ่านบทความหนึ่งเมื่อจู่ๆ องค์ประกอบทั้งหมดเปลี่ยนไปเรื่อยๆ ในหน้านั้น ส่งผลให้คุณต้องหาที่ที่ต้องการอีกครั้ง กรณีนี้พบได้บ่อยในเว็บ ซึ่งรวมถึงเวลาอ่านข่าวหรือพยายามคลิกปุ่ม "ค้นหา" หรือ "เพิ่มในรถเข็น" ประสบการณ์ดังกล่าวชวนให้รู้สึกสะเทือนใจและน่าหงุดหงิด ซึ่งมักจะเกิดขึ้นเมื่อองค์ประกอบที่มองเห็นได้ถูกบังคับให้ย้าย เนื่องจากองค์ประกอบอื่นถูกเพิ่มในหน้าหรือปรับขนาดอย่างกะทันหัน
เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดี เว็บไซต์ต้องมี CLS ไม่เกิน 0.1 สำหรับการเข้าชมหน้าเว็บอย่างน้อย 75%
คะแนน CLS เป็นค่าที่ไม่มีหน่วยจากการคำนวณปริมาณการเปลี่ยนแปลงและเนื้อหาตามระยะทาง ซึ่งต่างจาก Core Web Vitals อื่นๆ ซึ่งเป็นค่าที่อิงตามเวลาในหน่วยวินาทีหรือมิลลิวินาที
ในคู่มือนี้ เราจะกล่าวถึงการเพิ่มประสิทธิภาพสาเหตุที่พบบ่อยของการเปลี่ยนเลย์เอาต์
สาเหตุที่พบบ่อยที่สุดของ CLS ที่ไม่ดีมีดังนี้
- รูปภาพที่ไม่มีขนาด
- โฆษณา การฝัง และ iframe ที่ไม่มีมิติข้อมูล
- เนื้อหาที่แทรกแบบไดนามิก เช่น โฆษณา การฝัง และ iframe ที่ไม่มีมิติข้อมูล
- แบบอักษรสำหรับเว็บ
ทำความเข้าใจสาเหตุของการเปลี่ยนเลย์เอาต์
ก่อนที่จะเริ่มดูวิธีแก้ไขปัญหา CLS ที่พบได้ทั่วไป คุณต้องทำความเข้าใจคะแนน CLS และที่มาของการเปลี่ยนแปลงก่อน
CLS ในเครื่องมือในห้องทดลองเทียบกับงานภาคสนาม
นักพัฒนาซอฟต์แวร์มักคิดว่า CLS ที่วัดในรายงาน UX ของ Chrome (CrUX) ไม่ถูกต้อง เพราะไม่ตรงกับ CLS ที่วัดโดยใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome หรือเครื่องมือในห้องทดลองอื่นๆ เครื่องมือห้องทดลองประสิทธิภาพของเว็บ เช่น Lighthouse อาจไม่แสดง CLS แบบเต็มของหน้าเว็บ เนื่องจากโดยปกติแล้วเพียงแค่โหลดหน้าเว็บเพื่อวัดเมตริกประสิทธิภาพเว็บบางรายการและให้คำแนะนำบางส่วน แต่ขั้นตอนของผู้ใช้ Lighthouse ช่วยให้คุณวัดผลได้นอกเหนือจากการตรวจสอบการโหลดหน้าเว็บเริ่มต้น)
CrUX คือชุดข้อมูลอย่างเป็นทางการของโปรแกรม Web Vitals โดยจะวัด CLS ตลอดอายุของหน้าเว็บ ไม่ใช่เฉพาะช่วงการโหลดหน้าเว็บเริ่มต้นที่เครื่องมือในห้องทดลองมักวัด
การเปลี่ยนเลย์เอาต์เกิดขึ้นบ่อยมากในช่วงการโหลดหน้าเว็บ เพราะนั่นเป็นตอนที่ระบบดึงทรัพยากรทั้งหมดที่จำเป็นต่อการแสดงผลหน้าเว็บ แต่การเปลี่ยนเลย์เอาต์ก็อาจเกิดขึ้นหลังการโหลดครั้งแรกได้เช่นกัน การเปลี่ยนแปลงหลังการโหลดหลายครั้งเกิดขึ้นอันเป็นผลมาจากการโต้ตอบของผู้ใช้ จึงไม่รวมอยู่ในคะแนน CLS ตราบใดที่เกิดขึ้นภายใน 500 มิลลิวินาทีนับจากการโต้ตอบนั้น ระบบจะนับเป็นการเปลี่ยนแปลงที่คาดไว้
อย่างไรก็ตาม อาจมีการเปลี่ยนแปลงหลังการโหลดที่ไม่คาดคิดในกรณีที่ไม่มีการโต้ตอบที่เข้าเกณฑ์ เช่น หากเนื้อหาที่โหลดแบบ Lazy Loading โหลดจนเสร็จสมบูรณ์ขณะที่ผู้ใช้เลื่อนดูหน้าเว็บ สาเหตุอื่นๆ ที่พบบ่อยของ CLS หลังการโหลดมาจากการโต้ตอบระหว่างการเปลี่ยน เช่น ในแอปหน้าเดียว ซึ่งใช้เวลานานกว่าระยะเวลาผ่อนผัน 500 มิลลิวินาที
PageSpeed Insights แสดงทั้ง CLS ที่ผู้ใช้รับรู้จาก URL ในส่วน "ดูสิ่งที่ผู้ใช้จริงพบ" และ CLS การโหลดตามห้องทดลองในส่วน "วิเคราะห์ปัญหาด้านประสิทธิภาพ" ความแตกต่างระหว่างค่าเหล่านี้มักเป็นผลมาจาก CLS หลังการโหลด
ระบุปัญหา CLS ในการโหลด
เมื่อคะแนน CrUX และ Lighthouse CLS ใน PageSpeed Insights ใกล้เคียงกัน โดยทั่วไปจะหมายความว่า Lighthouse ตรวจพบปัญหา CLS ในการโหลด ในกรณีนี้ Lighthouse จะมีการตรวจสอบ 2 รายการสำหรับข้อมูลเพิ่มเติม ได้แก่ รายการหนึ่งสำหรับรูปภาพที่ทำให้เกิด CLS เนื่องจากความกว้างและความสูงหายไป และอีกชุดหนึ่งสำหรับองค์ประกอบทั้งหมดที่เปลี่ยนแปลงระหว่างการโหลดหน้าเว็บพร้อมกับการมีส่วนร่วม CLS หากต้องการดูการตรวจสอบเหล่านี้ ให้กรองหาการตรวจสอบในภาพต่อไปนี้
แผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บจะไฮไลต์การเปลี่ยนแปลงเลย์เอาต์ในส่วนประสบการณ์ด้วย มุมมองสรุปสำหรับระเบียน Layout Shift จะรวมคะแนน CLS และการแสดงข้อมูลเป็นสี่เหลี่ยมผืนผ้าที่แสดงภูมิภาคที่ได้รับผลกระทบ ซึ่งมีประโยชน์อย่างยิ่งในการระบุปัญหา CLS ในการโหลดเนื่องจากช่วยให้คุณจำลองประสบการณ์ของผู้ใช้ด้วยโปรไฟล์ประสิทธิภาพแบบโหลดซ้ำได้
Layout Shift เมื่อคลิกที่ระเบียน คุณจะสามารถเจาะลึกองค์ประกอบที่ได้รับผลกระทบได้โดยการแสดงรายละเอียด เช่น รายการ "ย้ายจาก" และ "ย้ายไปที่" ในรูปภาพนี้ระบุปัญหา CLS หลังการโหลด
ความแตกต่างระหว่างคะแนน CrUX กับ Lighthouse CLS มักจะบ่งบอกถึง CLS หลังการโหลด การเปลี่ยนแปลงเหล่านี้อาจเป็นเรื่องยากที่จะติดตามหากไม่มีข้อมูลภาคสนาม สำหรับข้อมูลเกี่ยวกับการรวบรวมข้อมูลภาคสนาม โปรดดูวัดองค์ประกอบ CLS ในช่อง
ส่วนขยาย Web Vitals ใน Chrome คุณใช้เพื่อตรวจสอบ CLS ขณะโต้ตอบกับหน้าเว็บได้ทั้งในจอแสดงผลล่วงหน้าหรือในคอนโซลควบคู่ไปกับรายละเอียดเกี่ยวกับองค์ประกอบที่มีการเปลี่ยนแปลง
นอกจากการใช้ส่วนขยายแล้ว คุณยังสามารถเรียกดูหน้าเว็บขณะที่บันทึกการเปลี่ยนแปลงเลย์เอาต์โดยใช้ Performance Observer ที่วางลงในคอนโซลได้
หลังจากตั้งค่าการตรวจสอบกะแล้ว คุณสามารถลองจำลองปัญหา CLS หลังการโหลดได้ CLS มักเกิดขึ้นขณะที่ผู้ใช้เลื่อนดูหน้าเว็บ เมื่อเนื้อหาที่โหลดแบบ Lazy Loading โหลดจนเต็มโดยไม่มีพื้นที่สำรองไว้ การเปลี่ยนแปลงเนื้อหาเมื่อผู้ใช้ถือตัวชี้เหนือเนื้อหาเป็นอีกสาเหตุหนึ่งที่พบบ่อยของ CLS หลังการโหลด การเปลี่ยนแปลงเนื้อหาในระหว่างการโต้ตอบใดๆ เหล่านี้จะนับเป็นที่ไม่คาดคิด แม้ว่าจะเกิดขึ้นภายใน 500 มิลลิวินาที
ดูข้อมูลเพิ่มเติมได้ที่แก้ไขข้อบกพร่องการเปลี่ยนเลย์เอาต์
หลังจากระบุสาเหตุที่พบบ่อยของ CLS แล้ว คุณยังใช้โหมดการไหลเวียนของผู้ใช้แบบช่วงเวลาของ Lighthouse เพื่อให้มั่นใจว่าการเปลี่ยนเลย์เอาต์จะไม่ไม่เป็นไปตามขั้นตอนของผู้ใช้ทั่วไปได้ด้วย
วัดองค์ประกอบ CLS ในฟิลด์
การตรวจสอบ CLS ในช่องมีประโยชน์อย่างมากในการพิจารณาว่าสถานการณ์ใดของ CLS เกิดขึ้นและจำกัดสาเหตุที่เป็นไปได้ให้แคบลง เช่นเดียวกับเครื่องมือในห้องทดลองส่วนใหญ่ เครื่องมือภาคสนามจะวัดเฉพาะองค์ประกอบที่เปลี่ยนไป แต่มักจะให้ข้อมูลที่เพียงพอในการระบุสาเหตุ นอกจากนี้ คุณยังสามารถใช้การวัดค่าฟิลด์ CLS เพื่อระบุว่าปัญหาใดมีความสำคัญสูงสุดที่ต้องแก้ไข
ไลบรารี web-vitals มีฟังก์ชันการระบุแหล่งที่มา
ที่ช่วยให้คุณรวบรวมข้อมูลเพิ่มเติมนี้ได้ ดูข้อมูลเพิ่มเติมได้ที่การแก้ไขข้อบกพร่องในช่อง
ผู้ให้บริการ RUM รายอื่นก็เริ่มรวบรวมและนำเสนอข้อมูลนี้ในทำนองเดียวกันแล้ว
สาเหตุที่พบบ่อยของ CLS
ส่วนนี้จะพูดถึงสาเหตุที่พบบ่อยของ CLS และกลยุทธ์ในการเลี่ยง
รูปภาพที่ไม่มีขนาด
ใส่แอตทริบิวต์ขนาด width และ height ในองค์ประกอบรูปภาพและวิดีโอเสมอ หรือสงวนพื้นที่ที่ต้องใช้โดยใช้ CSS aspect-ratio
วิธีนี้ช่วยให้เบราว์เซอร์จัดสรรพื้นที่ในเอกสารได้ในจำนวนที่ถูกต้องขณะที่รูปภาพโหลด
width, height และ aspect-ratio
ในช่วงแรกๆ ของเว็บ นักพัฒนาซอฟต์แวร์ได้เพิ่มแอตทริบิวต์ width และ height ในแท็ก <img> เพื่อให้มั่นใจว่าจัดสรรพื้นที่ในหน้าเว็บอย่างเพียงพอก่อนที่เบราว์เซอร์จะเริ่มดึงข้อมูลรูปภาพ วิธีนี้จะลดการจัดเรียงและการจัดเรียงใหม่ให้เหลือน้อยที่สุด
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
width และ height ในตัวอย่างนี้ไม่รวมหน่วย มิติข้อมูล "พิกเซล" เหล่านี้
ช่วยให้เบราว์เซอร์สงวนพื้นที่ไว้ 640x360 รูปภาพจะขยายออกให้พอดีกับพื้นที่นี้ไม่ว่าขนาดที่แท้จริงจะตรงกับส่วนนั้นหรือไม่ก็ตาม
เมื่อเปิดตัวการออกแบบเว็บที่ตอบสนองตามอุปกรณ์ นักพัฒนาแอปเริ่มใช้ CSS เพื่อปรับขนาดรูปภาพแทน width และ height
img {
width: 100%; /* or max-width: 100%; */
height: auto;
}
แต่เนื่องจากไม่ได้ระบุขนาดรูปภาพ ระบบจึงไม่สามารถจัดสรรพื้นที่ให้รูปภาพได้จนกว่าเบราว์เซอร์จะเริ่มดาวน์โหลดและสามารถระบุขนาดได้ ขณะที่รูปภาพโหลดขึ้นมา ข้อความจะเลื่อนตามหน้าเว็บเพื่อให้มีพื้นที่ว่าง ทำให้ผู้ใช้ได้รับประสบการณ์ที่น่าสับสนและน่าหงุดหงิด
แนวทางปฏิบัติแนะนำสำหรับการกำหนดขนาดรูปภาพ
เนื่องจากเบราว์เซอร์สมัยใหม่กำหนดสัดส่วนภาพเริ่มต้นตามแอตทริบิวต์ width และ height ของรูปภาพ คุณจึงป้องกันไม่ให้เลย์เอาต์เปลี่ยนแปลงได้โดยการตั้งค่าแอตทริบิวต์เหล่านั้นในรูปภาพและรวม CSS ที่อยู่ก่อนหน้าในสไตล์ชีทของคุณ
<!-- set a 16:9 aspect ratio as 640x360 pixels -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
จากนั้นเบราว์เซอร์จะเพิ่มสัดส่วนภาพเริ่มต้นตามแอตทริบิวต์ width และ height ที่มีอยู่ขององค์ประกอบ เพื่อให้กำหนดขนาดพื้นที่ที่จะสำรองไว้สำหรับรูปภาพเมื่อเริ่มต้นการคำนวณเลย์เอาต์ได้
เนื่องจากเบราว์เซอร์หลักๆ จะคำนวณสัดส่วนภาพเริ่มต้นขณะประมวลผล HTML แต่ละเบราว์เซอร์จึงแสดงค่าที่ต่างกันเล็กน้อย (สำหรับรายละเอียดเกี่ยวกับสาเหตุ โปรดดูคำแนะนำการนำเสนอความกว้างและความสูง)
ตัวอย่างเช่น Chrome จะแสดงสัดส่วนภาพในส่วนรูปแบบของแผงองค์ประกอบ ดังนี้
img[Attributes Style] {
aspect-ratio: auto 640 / 360;
}
Safari ทำงานคล้ายๆ กัน โดยใช้แหล่งที่มาของรูปแบบแอตทริบิวต์ HTML Firefox ไม่แสดง aspect-ratio ที่คำนวณแล้วนี้ในแผง เครื่องมือตรวจสอบ เลย แต่ใช้สำหรับเลย์เอาต์
ส่วน auto ของโค้ดก่อนหน้ามีความสำคัญ เนื่องจากจะทำให้ขนาดรูปภาพลบล้างสัดส่วนภาพเริ่มต้นหลังจากดาวน์โหลดรูปภาพ หากขนาดรูปภาพแตกต่างกัน ก็ยังคงทำให้เลย์เอาต์เปลี่ยนแปลงไปบ้างหลังจากที่โหลดรูปภาพแล้ว แต่ก็จะทำให้ระบบยังคงใช้สัดส่วนภาพเดิมเมื่อพร้อมใช้งานในกรณีที่ HTML ไม่ถูกต้อง แม้ว่าสัดส่วนภาพจริงจะแตกต่างจากค่าเริ่มต้น แต่ก็ยังมีการเปลี่ยนเลย์เอาต์น้อยกว่าขนาดเริ่มต้น 0x0 ของรูปภาพที่ไม่ได้ระบุขนาด
ดูรายละเอียดแบบเจาะลึกเกี่ยวกับสัดส่วนภาพและปรัชญาเกี่ยวกับรูปภาพที่ตอบสนองตามอุปกรณ์ได้ที่หัวข้อการโหลดหน้าเว็บที่ปลอดเนื้อหาด้วยสัดส่วนภาพของสื่อ
หากรูปภาพอยู่ในคอนเทนเนอร์ คุณสามารถใช้ CSS เพื่อปรับขนาดรูปภาพตามความกว้างของคอนเทนเนอร์ได้ เราตั้งค่า height: auto; เพื่อหลีกเลี่ยงการใช้ค่าคงที่สำหรับความสูงของรูปภาพ
img {
height: auto;
width: 100%;
}
แล้วรูปภาพที่ตอบสนองตามอุปกรณ์จะเป็นอย่างไร
เมื่อใช้รูปภาพที่ปรับเปลี่ยนตามอุปกรณ์
srcset จะกำหนดรูปภาพที่คุณอนุญาตให้เบราว์เซอร์เลือกระหว่างและ
ขนาดรูปภาพแต่ละรูป หากต้องการตรวจสอบว่าตั้งค่าแอตทริบิวต์ความกว้างและความสูง <img> ได้ ให้ใช้สัดส่วนภาพเดียวกันสำหรับแต่ละรูปภาพ
<img
width="1000"
height="1000"
src="puppy-1000.jpg"
srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
alt="Puppy with balloons"
/>
นอกจากนี้ สัดส่วนภาพยังอาจเปลี่ยนแปลงตามทิศทางศิลปะด้วย เช่น คุณอาจต้องการรวมรูปภาพแบบครอบตัดสำหรับวิวพอร์ตแคบและแสดงรูปภาพขนาดเต็มในเดสก์ท็อป
<picture>
<source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
<source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
<img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>
ตอนนี้ Chrome, Firefox และ Safari รองรับการตั้งค่า width และ height ในองค์ประกอบย่อย source ขององค์ประกอบ picture แล้ว
<picture>
<source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width=480 height=400/>
<source media="(min-width: 800px)" srcset="puppy-800w.jpg" width=800 height=400/>
<img src="puppy-800w.jpg" alt="Puppy with balloons" width=800 height=400/>
</picture>
โฆษณา การฝัง และเนื้อหาอื่นๆ ที่โหลดช้า
รูปภาพไม่ใช่เนื้อหาประเภทเดียวที่อาจทำให้เกิดการเปลี่ยนเลย์เอาต์ โฆษณา, การฝัง, iframe และเนื้อหาที่แทรกแบบไดนามิกอื่นๆ ล้วนทำให้เนื้อหาปรากฏขึ้นหลังจากที่โฆษณาลดลง ซึ่งจะช่วยเพิ่ม CLS ของคุณ
โฆษณาเป็นปัจจัยที่ส่งผลต่อการเปลี่ยนเลย์เอาต์ในเว็บมากที่สุด เครือข่ายโฆษณาและผู้เผยแพร่โฆษณามักจะรองรับขนาดโฆษณาแบบไดนามิก และโฆษณาขนาดใหญ่ก็มักจะสร้างรายได้มากกว่าโฆษณาขนาดเล็ก อย่างไรก็ตาม โฆษณาที่โหลดอย่างกะทันหันและดันเนื้อหาที่มองเห็นได้ลงมาในหน้านั้นส่งผลเสียต่อประสบการณ์ของผู้ใช้
วิดเจ็ตแบบฝังได้ช่วยให้คุณใส่เนื้อหาเว็บแบบพกพาไว้ในหน้าเว็บได้ เช่น วิดีโอจาก YouTube, แผนที่จาก Google Maps และโพสต์บนโซเชียลมีเดีย อย่างไรก็ตาม วิดเจ็ตเหล่านี้มักไม่ทราบขนาดเนื้อหาก่อนที่จะโหลด ด้วยเหตุนี้ แพลตฟอร์มที่เสนอการฝังจึงไม่ได้มีการสงวนพื้นที่ไว้สําหรับวิดเจ็ตเสมอไป ซึ่งทําให้เลย์เอาต์เปลี่ยนไปเมื่อโหลดในท้ายที่สุด
เทคนิคในการจัดการกับสิ่งเหล่านี้ต่างก็คล้ายกัน ความแตกต่างที่สำคัญคือ คุณสามารถควบคุมเนื้อหาที่แทรกได้มากน้อยเพียงใด บุคคลที่สามอย่างพาร์ทเนอร์โฆษณามักไม่ให้ข้อมูลที่เป็นประโยชน์เกี่ยวกับเนื้อหาที่แทรก หรือการควบคุมการเปลี่ยนเลย์เอาต์ซึ่งทำให้การฝังเหล่านี้เปลี่ยนแปลง
จองพื้นที่สำหรับเนื้อหาที่โหลดล่าช้า
เมื่อวางเนื้อหาที่โหลดช้าในโฟลว์เนื้อหา คุณหลีกเลี่ยงการเปลี่ยนเลย์เอาต์ได้โดยจองพื้นที่สำหรับเนื้อหาในเลย์เอาต์เริ่มต้น
ขั้นตอนนี้ทำได้ง่ายๆ ด้วยการเพิ่มการจัดรูปแบบ min-height เพื่อจองพื้นที่ หรือการใช้พร็อพเพอร์ตี้ CSS ใหม่ของ aspect-ratio สำหรับเนื้อหาที่ปรับเปลี่ยนตามอุปกรณ์ เช่น การใช้พร็อพเพอร์ตี้ CSS ใหม่ในลักษณะเดียวกับที่เบราว์เซอร์ใช้ฟีเจอร์ดังกล่าวสำหรับรูปภาพโดยอัตโนมัติ
คุณอาจต้องพิจารณาความแตกต่างเล็กๆ น้อยๆ ในขนาดโฆษณาหรือตัวยึดตำแหน่งของโฆษณาต่างๆ ในรูปแบบของอุปกรณ์ต่างๆ โดยใช้คิวรี่สื่อ
สำหรับเนื้อหาที่อาจมีความสูงไม่คงที่ เช่น โฆษณา คุณอาจไม่สามารถจองพื้นที่ที่ต้องใช้ในจำนวนที่แน่นอนเพื่อกำจัดการเปลี่ยนแปลงของเลย์เอาต์ทั้งหมด หากมีการแสดงโฆษณาที่เล็กกว่า ผู้เผยแพร่โฆษณาสามารถจัดรูปแบบคอนเทนเนอร์ที่ใหญ่กว่าเพื่อหลีกเลี่ยงการเปลี่ยนเลย์เอาต์ หรือเลือกขนาดที่เป็นไปได้มากที่สุดสำหรับช่องโฆษณาโดยอิงตามข้อมูลประวัติ ข้อเสียของวิธีนี้คือช่วยเพิ่มพื้นที่ว่างในหน้าเว็บ
คุณสามารถกำหนดขนาดเริ่มต้นเป็นขนาดเล็กที่สุดที่จะใช้ และยอมรับการเปลี่ยนแปลงในระดับหนึ่งสำหรับเนื้อหาที่ใหญ่ขึ้นได้ การใช้ min-height ตามที่ได้แนะนำไปก่อนหน้านี้จะช่วยให้องค์ประกอบระดับบนสุดขยายได้ตามต้องการ พร้อมกับลดผลกระทบของการเปลี่ยนเลย์เอาต์เมื่อเทียบกับขนาดเริ่มต้น 0px ขององค์ประกอบที่ว่างเปล่า
พยายามหลีกเลี่ยงการยุบพื้นที่ที่จองไว้โดยการแสดงตัวยึดตำแหน่งในกรณีที่ไม่มีการแสดงโฆษณา การนำช่องว่างออกสำหรับองค์ประกอบอาจทำให้ CLS มากเท่ากับการแทรกเนื้อหา
วางเนื้อหาที่โหลดล่าช้าให้ต่ำลงในวิวพอร์ต
เนื้อหาที่แทรกแบบไดนามิกใกล้กับด้านบนของวิวพอร์ตมักจะทำให้เลย์เอาต์เปลี่ยนแปลงมากกว่าเนื้อหาที่แทรกอยู่ต่ำกว่าในวิวพอร์ต อย่างไรก็ตาม การแทรกเนื้อหาไว้ที่ใดก็ได้ในวิวพอร์ตยังคงทำให้เกิดการเปลี่ยนแปลงอยู่บ้าง หากไม่สามารถจองพื้นที่สำหรับเนื้อหาที่แทรกได้ เราขอแนะนำให้วางไว้ภายหลังในหน้าเว็บเพื่อลดผลกระทบ
เนื้อหาของแบนเนอร์ซ้อนทับ
แบนเนอร์และแบบฟอร์มที่ปรากฏในหน้าเว็บโดยไม่คาดคิดเป็นสาเหตุที่พบบ่อยอีกประการหนึ่งที่ทำให้เกิดการเปลี่ยนแปลงที่ไม่คาดคิด
ถ้าคุณไม่สามารถจองพื้นที่สำหรับเนื้อหาประเภทนี้ คุณสามารถซ้อนทับเนื้อหาที่มีอยู่แทน เพื่อไม่ให้เป็นส่วนหนึ่งของการทำงานของเอกสาร หากต้องการคำแนะนำว่าควรใช้วิธีการนี้เมื่อใด โปรดดูแนวทางปฏิบัติแนะนำสำหรับประกาศคุกกี้
ให้การโต้ตอบของผู้ใช้ทริกเกอร์การเปลี่ยนแปลงเลย์เอาต์ที่คาดไว้
ในบางกรณี การเพิ่มเนื้อหาแบบไดนามิกเป็นส่วนสำคัญของประสบการณ์ผู้ใช้ เช่น เมื่อโหลดผลิตภัณฑ์เพิ่มเติมลงในรายการหรือการอัปเดตเนื้อหาฟีดสด มีหลายวิธีที่คุณสามารถหลีกเลี่ยงการเปลี่ยนเลย์เอาต์ที่ไม่คาดคิดในกรณีเหล่านั้น
- แทนที่เนื้อหาเก่าด้วยเนื้อหาใหม่ในคอนเทนเนอร์ขนาดคงที่ หรือใช้ภาพสไลด์และนำเนื้อหาเก่าออกหลังการเปลี่ยน อย่าลืมปิดใช้ลิงก์และการควบคุมใดๆ จนกว่าการเปลี่ยนผ่านจะเสร็จสิ้น เพื่อป้องกันการคลิกหรือแตะโดยไม่ตั้งใจขณะกำลังโหลดเนื้อหาใหม่
- ให้ผู้ใช้เริ่มโหลดเนื้อหาใหม่ เช่น ด้วยปุ่มโหลดเพิ่มเติมหรือปุ่มรีเฟรช การเปลี่ยนแปลงนี้จึงไม่น่าแปลกใจ เราขอแนะนำให้ดึงข้อมูลเนื้อหาใหม่ล่วงหน้าก่อนการโต้ตอบของผู้ใช้เพื่อให้เนื้อหาแสดงขึ้นทันที โปรดทราบว่าการเปลี่ยนแปลงของเลย์เอาต์ภายใน 500 มิลลิวินาทีของอินพุตของผู้ใช้จะไม่นับรวมใน CLS
- โหลดเนื้อหานอกหน้าจออย่างราบรื่นและวางซ้อนข้อความแจ้งให้ผู้ใช้ทราบว่าเนื้อหานั้นใช้งานได้ (เช่น ด้วยปุ่มเลื่อนขึ้นไปด้านบน)
ภาพเคลื่อนไหว
การเปลี่ยนแปลงค่าพร็อพเพอร์ตี้ CSS อาจทำให้เบราว์เซอร์ตอบสนองต่อการเปลี่ยนแปลงเหล่านี้ ค่าบางค่า เช่น box-shadow และ box-sizing ทริกเกอร์รีเลย์ สี และผสม การเปลี่ยนพร็อพเพอร์ตี้ top และ left ก็จะทำให้เลย์เอาต์เปลี่ยนแปลงเช่นกัน แม้ว่าองค์ประกอบที่จะย้ายจะอยู่ในเลเยอร์ของตนเองก็ตาม หลีกเลี่ยงภาพเคลื่อนไหว
โดยใช้คุณสมบัติเหล่านี้
คุณเปลี่ยนคุณสมบัติ CSS อื่นๆ ได้โดยไม่ต้องเรียกใช้เลย์เอาต์ซ้ำ ซึ่งรวมถึงการใช้ภาพเคลื่อนไหว transform เพื่อแปล ปรับขนาด หมุน หรือเอียงองค์ประกอบ
ภาพเคลื่อนไหวที่ประกอบขึ้นโดยใช้ translate จะไม่ส่งผลต่อองค์ประกอบอื่นๆ จึงไม่นับรวมใน CLS ภาพเคลื่อนไหวที่ไม่ได้ทำการ Composite ก็ไม่ทำให้เกิดการจัดเรียงใหม่เช่นกัน ดูข้อมูลเพิ่มเติมเกี่ยวกับคุณสมบัติ CSS ที่ทำให้เกิดการเปลี่ยนแปลงเลย์เอาต์ได้ที่หัวข้อภาพเคลื่อนไหวประสิทธิภาพสูง
แบบอักษรสำหรับเว็บ
โดยทั่วไปแล้ว ระบบจะจัดการการดาวน์โหลดและการแสดงผลแบบอักษรของเว็บด้วยวิธีใดวิธีหนึ่งจาก 2 วิธีต่อไปนี้ก่อนที่จะดาวน์โหลดแบบอักษรของเว็บ
- แบบอักษรสำรองจะสลับกับแบบอักษรของเว็บโดยใช้ Flash ของข้อความ Unstyled Text (FOUT)
- ข้อความ "ซ่อนตัว" จะแสดงโดยใช้แบบอักษรสำรองจนกว่าแบบอักษรเว็บจะพร้อมใช้งานและแสดงข้อความโดยใช้ Flash สำหรับข้อความมองไม่เห็น (FOIT)
ทั้ง 2 วิธีอาจทำให้เกิดการเปลี่ยนแปลงเลย์เอาต์ได้ แม้ว่าข้อความจะมองไม่เห็น แต่ข้อความก็ยังคงจัดวางอยู่โดยใช้แบบอักษรสำรอง ดังนั้นเมื่อโหลดแบบอักษรเว็บ บล็อกข้อความและเนื้อหาโดยรอบจะเปลี่ยนไปในแบบเดียวกับแบบอักษรที่มองเห็นได้
เครื่องมือต่อไปนี้สามารถช่วยลดการเปลี่ยนแปลงของข้อความได้:
font-display: optionalจะทำให้ใช้แบบอักษรเว็บก็ต่อเมื่อพร้อมใช้งานในช่วงเวลาที่เลย์เอาต์ครั้งแรกเท่านั้น- ใช้แบบอักษรสำรองที่คล้ายกับแบบอักษรของเว็บ ตัวอย่างเช่น การใช้
font-family: "Google Sans", sans-serif;จะทำให้เบราว์เซอร์ใช้แบบอักษรสำรองของsans-serifขณะที่"Google Sans"โหลด การไม่ระบุแบบอักษรสำรอง (โดยใช้เพียงfont-family: "Google Sans") จะทำให้ Chrome ใช้แบบอักษร Serif เริ่มต้น ซึ่งถือว่าแย่กว่า - ลดความแตกต่างด้านขนาดระหว่างแบบอักษรสำรองและแบบอักษรเว็บโดยใช้ API ใหม่
size-adjust,ascent-override,descent-overrideและline-gap-overrideโปรดดูรายละเอียดที่หัวข้อแบบอักษรสำรองที่ปรับปรุงแล้ว - Font Loading API จะช่วยลดเวลาที่ใช้ในการโหลดแบบอักษรได้
- โหลดแบบอักษรเว็บที่สำคัญโดยเร็วที่สุดโดยใช้
<link rel=preload>แบบอักษรที่โหลดไว้ล่วงหน้ามักจะพร้อมสําหรับสีแรกมากกว่าและทําให้ไม่มีการเปลี่ยนแปลงของเลย์เอาต์
โปรดดูข้อมูลเพิ่มเติมในแนวทางปฏิบัติแนะนำสำหรับแบบอักษร
ทำให้หน้าเว็บมีสิทธิ์ใช้ bfcache
เทคนิคที่มีประสิทธิภาพสูงในการรักษาคะแนน CLS ให้อยู่ในระดับต่ำคือตรวจสอบว่าหน้าเว็บมีสิทธิ์ใช้Back-Forward Cache (bfcache)
bfcache จะเก็บหน้าต่างๆ ไว้ในหน่วยความจำของเบราว์เซอร์เป็นเวลาสั้นๆ หลังจากที่คุณออกจากหน้าไปแล้ว ดังนั้นหากคุณกลับมาที่หน้าเหล่านั้น หน้าจะได้รับการคืนค่าเหมือนกับที่คุณออกจากหน้าไปทุกประการ ซึ่งหมายความว่าหน้าเว็บที่โหลดเสร็จแล้วจะพร้อมใช้งานทันที โดยไม่มีการเปลี่ยนแปลงใดๆ ที่อาจเกิดขึ้นขณะโหลดหน้าเว็บ
แม้ว่าปัญหาแบบนี้จะหมายความว่าการโหลดหน้าเว็บในช่วงแรกมีการเปลี่ยนเลย์เอาต์ แต่ก็ช่วยให้ผู้ใช้ไม่ต้องเห็นการเปลี่ยนเลย์เอาต์เดิมซ้ำๆ ซึ่งช่วยลดผลกระทบจากการเปลี่ยนเลย์เอาต์ที่อาจมีปัญหาแก้ไขด้วยวิธีอื่นๆ
การนำทางย้อนกลับและไปข้างหน้าเป็นเรื่องปกติในเว็บไซต์หลายแห่ง เช่น เมื่อย้อนกลับไปที่หน้าเนื้อหา หน้าหมวดหมู่ หรือผลการค้นหา
ทุกเบราว์เซอร์จะใช้ bfcache โดยค่าเริ่มต้น แต่บางเว็บไซต์จะไม่มีสิทธิ์ใช้ bfcache ด้วยสาเหตุหลายประการ ดูรายละเอียดเพิ่มเติมเกี่ยวกับวิธีทดสอบและระบุปัญหาที่ทําให้ไม่สามารถใช้ bfcache ได้ในบทความ bfcache