เพิ่มประสิทธิภาพ Cumulative Layout Shift

ดูวิธีหลีกเลี่ยงการเปลี่ยนเลย์เอาต์อย่างฉับพลันเพื่อปรับปรุงประสบการณ์ของผู้ใช้

Addy Osmani

Barry Pollard

Cumulative Layout Shift (CLS) เป็นหนึ่งในเมตริก 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 ในการโหลด

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

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

ระบุปัญหา CLS หลังการโหลด

คะแนน CLS ของ CrUX และ Lighthouse ที่ไม่ตรงกันมักบ่งบอกถึง CLS หลังการโหลด การเปลี่ยนแปลงเหล่านี้อาจติดตามได้ยากหากไม่มีข้อมูลภาคสนาม ดูข้อมูลเกี่ยวกับการรวบรวมข้อมูลภาคสนามได้ที่วัดองค์ประกอบ CLS ในพื้นที่

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

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

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

ดูข้อมูลเพิ่มเติมได้ที่แก้ไขข้อบกพร่องการเปลี่ยนเลย์เอาต์

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

วัดองค์ประกอบ CLS ในช่อง

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

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

สาเหตุที่พบบ่อยของ CLS

เมื่อระบุสาเหตุของ CLS แล้ว คุณก็เริ่มแก้ไขปัญหาได้ ส่วนนี้จะแสดงสาเหตุที่พบบ่อยของ CLS และสิ่งที่คุณสามารถทําเพื่อหลีกเลี่ยงปัญหานี้

รูปภาพที่ไม่มีมิติข้อมูล

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

ประวัติของแอตทริบิวต์ width และ height ในรูปภาพ

ในช่วงแรกๆ ของเว็บ นักพัฒนาซอฟต์แวร์จะเพิ่มแอตทริบิวต์ width และ height ลงในแท็ก <img> เพื่อให้แน่ใจว่ามีการจัดสรรพื้นที่ในหน้าเว็บเพียงพอก่อนที่เบราว์เซอร์จะเริ่มดึงข้อมูลรูปภาพ ซึ่งจะช่วยลดการจัดเรียงใหม่และการจัดรูปแบบใหม่

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

width และ height ในตัวอย่างนี้ไม่มีหน่วย ขนาด "พิกเซล" เหล่านี้จะช่วยให้มั่นใจว่าเบราว์เซอร์จะจองพื้นที่ 640x360 ในเลย์เอาต์ของหน้า รูปภาพจะขยายให้พอดีกับพื้นที่นี้ ไม่ว่าขนาดจริงจะตรงกันหรือไม่ก็ตาม

เมื่อมีการเปิดตัวการออกแบบเว็บที่ตอบสนองตามอุปกรณ์ นักพัฒนาซอฟต์แวร์เริ่มละ width และ height และเริ่มใช้ CSS ในการปรับขนาดรูปภาพแทน ดังนี้

img {
  width: 100%; /* or max-width: 100%; */
  height: auto;
}

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

ด้วยเหตุนี้ สัดส่วนภาพจึงเข้ามามีบทบาท สัดส่วนภาพของรูปภาพคืออัตราส่วนความกว้างต่อความสูงของรูปภาพ โดยทั่วไปแล้ว ข้อมูลนี้มักจะแสดงเป็นตัวเลข 2 หลักที่คั่นด้วยโคลอน (เช่น 16:9 หรือ 4:3) สําหรับสัดส่วนภาพ x:y รูปภาพจะมีความกว้าง x หน่วยและความสูง y หน่วย

ซึ่งหมายความว่าหากเราทราบมิติข้อมูลอย่างใดอย่างหนึ่ง ก็จะทราบอีกมิติข้อมูลหนึ่งได้ สำหรับสัดส่วนภาพ 16:9 ให้ทำดังนี้

• หาก puppy.jpg มีความสูง 360px ความกว้างจะเท่ากับ 360 x (16 / 9) = 640px
• หาก puppy.jpg มีความกว้าง 640 พิกเซล ความสูงจะเป็น 640 x (9 / 16) = 360 พิกเซล

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

แนวทางปฏิบัติแนะนำในปัจจุบันสำหรับการตั้งค่าขนาดรูปภาพ

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

<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

จากนั้นเบราว์เซอร์ทั้งหมดจะเพิ่มสัดส่วนการแสดงผลเริ่มต้นตามแอตทริบิวต์ width และ height ที่มีอยู่ขององค์ประกอบ

การดำเนินการนี้จะคำนวณสัดส่วนภาพตามแอตทริบิวต์ width และ height ก่อนที่รูปภาพจะโหลด โดยจะระบุข้อมูลนี้ตั้งแต่เริ่มต้นการคำนวณเลย ทันทีที่รูปภาพระบุความกว้างไว้ (เช่น width: 100%) ระบบจะใช้สัดส่วนภาพเพื่อคำนวณความสูง

ค่า aspect-ratio นี้คำนวณโดยเบราว์เซอร์หลักเมื่อประมวลผล HTML แทนที่จะใช้สไตล์ชีต User Agent เริ่มต้น (ดูโพสต์นี้เพื่อเจาะลึกถึงเหตุผล) ค่าจึงแสดงแตกต่างออกไปเล็กน้อย เช่น 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 เพิ่มขึ้นเท่ากับการแทรกเนื้อหา

วางเนื้อหาที่โหลดช้าให้ต่ำลงในวิวพอร์ต

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

หลีกเลี่ยงการแทรกเนื้อหาใหม่โดยที่ผู้ใช้ไม่ได้โต้ตอบ

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

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

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

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

ภาพเคลื่อนไหว

การเปลี่ยนแปลงค่าพร็อพเพอร์ตี้ CSS อาจทำให้เบราว์เซอร์ต้องตอบสนองต่อการเปลี่ยนแปลงเหล่านี้ ค่าบางค่า เช่น box-shadow และ box-sizing จะทริกเกอร์การจัดวางใหม่ วาด และคอมโพสิต การเปลี่ยนพร็อพเพอร์ตี้ top และ left ยังทําให้เลย์เอาต์เกิดการเปลี่ยนแปลงด้วย แม้ว่าองค์ประกอบที่จะย้ายจะอยู่บนเลเยอร์ของตัวเองก็ตาม หลีกเลี่ยงการใช้พร็อพเพอร์ตี้เหล่านี้ในการทำให้เคลื่อนไหว

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

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

แบบอักษรเว็บ

โดยทั่วไป การดาวน์โหลดและการแสดงผลแบบอักษรของเว็บจะได้รับการจัดการด้วยวิธีใดวิธีหนึ่งใน 2 วิธีก่อนที่จะมีการดาวน์โหลดแบบอักษรของเว็บ ได้แก่

• ระบบจะแทนที่แบบอักษรสํารองด้วยแบบอักษรเว็บ ซึ่งทําให้ข้อความไม่มีการจัดรูปแบบปรากฏขึ้นเป็นระยะเวลาสั้นๆ (FOUT)
• ข้อความ "ซ่อนตัว" จะแสดงโดยใช้แบบอักษรสำรองจนกว่าแบบอักษรเว็บจะใช้ได้ และข้อความนั้นจะแสดงขึ้น (FOIT - แฟลชของข้อความที่มองไม่เห็น)

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

เครื่องมือต่อไปนี้จะช่วยคุณลดการเลื่อนข้อความ

• font-display: optional สามารถหลีกเลี่ยงการจัดเลย์เอาต์ใหม่ได้เนื่องจากแบบอักษรของเว็บจะใช้ได้ก็ต่อเมื่อพร้อมใช้งานในเวลาที่เกิดเลย์เอาต์เริ่มต้นเท่านั้น
• ตรวจสอบว่ามีการใช้แบบอักษรสำรองที่เหมาะสม ตัวอย่างเช่น การใช้ font-family: "Google Sans", sans-serif; จะช่วยให้มั่นใจได้ว่าระบบจะใช้แบบอักษรสำรอง sans-serif ของเบราว์เซอร์ขณะที่โหลด "Google Sans" การไม่ระบุแบบอักษรสํารองโดยใช้เพียง font-family: "Google Sans" จะหมายความว่าระบบจะใช้แบบอักษรเริ่มต้น ซึ่งใน Chrome คือ "Times" ซึ่งเป็นแบบอักษร Serif ที่เข้ากันน้อยกว่าแบบอักษร sans-serif เริ่มต้น
• ลดความแตกต่างของขนาดระหว่างแบบอักษรสำรองกับแบบอักษรเว็บโดยใช้ API size-adjust, ascent-override, descent-override และ line-gap-override ใหม่ตามที่ระบุไว้ในโพสต์แบบอักษรสำรองที่ปรับปรุงแล้ว
• Font Loading API สามารถลดเวลาในการรับแบบอักษรที่จําเป็น
• โหลดแบบอักษรเว็บที่สำคัญโดยเร็วที่สุดโดยใช้ <link rel=preload> แบบอักษรที่โหลดไว้ล่วงหน้าจะมีโอกาสมากขึ้นในการเจอกับสีแรก ซึ่งในกรณีนี้ไม่มีการเปลี่ยนแปลงเลย์เอาต์

อ่านแนวทางปฏิบัติแนะนำสำหรับแบบอักษรเพื่อดูแนวทางปฏิบัติแนะนำอื่นๆ สำหรับแบบอักษร

ลด CLS โดยตรวจสอบว่าหน้าเว็บมีสิทธิ์สำหรับ bfcache

เทคนิคที่มีประสิทธิภาพสูงในการทำให้คะแนน CLS ต่ำอยู่เสมอคือการตรวจสอบว่าหน้าเว็บมีสิทธิ์ใช้แคชย้อนกลับ/ไปข้างหน้า (bfcache)

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

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

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

เมื่อเปิดตัวฟีเจอร์นี้ใน Chrome เราเห็นการปรับปรุงที่สังเกตเห็นได้ใน CLS

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

บทสรุป

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