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

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

Addy Osmani

Barry Pollard

Cumulative Layout Shift (CLS) เป็นหนึ่งในเมตริก 3 รายการของ Core Web Vitals โดยจะวัดความผันผวนของเนื้อหาโดยรวมปริมาณเนื้อหาที่มองเห็นได้ซึ่งมีการเลื่อนในวิวพอร์ตเข้ากับระยะทางที่องค์ประกอบที่ได้รับผลกระทบเคลื่อนที่

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

เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดี เว็บไซต์ต้องพยายามให้มี CLS ไม่เกิน 0.1 สำหรับการเข้าชมหน้าเว็บอย่างน้อย 75%

ค่า CLS ที่ดีคือ 0.1 หรือน้อยกว่า ค่าที่ไม่ดีจะมากกว่า 0.25

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

ในคู่มือนี้ เราจะพูดถึงการเพิ่มประสิทธิภาพสาเหตุที่พบบ่อยของการเปลี่ยนเลย์เอาต์

สาเหตุที่พบบ่อยที่สุดของ CLS ที่ไม่ดี ได้แก่

• รูปภาพที่ไม่มีมิติข้อมูล
• โฆษณา ชิ้นงานแบบฝัง และ iframe ที่ไม่มีมิติข้อมูล
• เนื้อหาที่แทรกแบบไดนามิก เช่น โฆษณา ชิ้นงาน และ iframe ที่ไม่มีมิติข้อมูล
• แบบอักษรเว็บ

หมายเหตุ: ดูภาพรวมของเนื้อหาบางส่วนที่แสดงในคู่มือนี้ได้จากวิดีโอ "เพิ่มประสิทธิภาพสำหรับ Core Web Vitals" จาก Google I/O 2020

ทําความเข้าใจสาเหตุของการเปลี่ยนแปลงเลย์เอาต์

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

CLS ในเครื่องมือทดสอบเทียบกับภาคสนาม

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

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

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

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

PageSpeed Insights จะแสดงทั้ง CLS ที่ผู้ใช้รับรู้จาก URL ในส่วน "ดูประสบการณ์ที่ผู้ใช้งานจริงได้รับ" และ CLS การโหลดที่อิงตามห้องทดลองในส่วน "วินิจฉัยปัญหาด้านประสิทธิภาพ" ความแตกต่างระหว่างค่าเหล่านี้อาจเป็นผลมาจาก CLS หลังการโหลด

ในตัวอย่างนี้ CrUX จะวัด CLS ที่สูงกว่า Lighthouse มาก

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

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

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

การวินิจฉัย CLS โดยละเอียดของ Lighthouse

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

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

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

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

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

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

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

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

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

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

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

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

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

หมายเหตุ: โซลูชัน RUM ที่วัด CLS ในพื้นที่ทำงาน ซึ่งรวมถึงไลบรารี web-vitals อาจแสดงความแตกต่างกับข้อมูล CrUX ตามที่อธิบายไว้ในโพสต์เหตุใดข้อมูล CrUX จึงแตกต่างจากข้อมูล RUM ของฉัน โดยเฉพาะอย่างยิ่ง CLS ที่เกิดขึ้นใน iframe จะวัดจาก Web API ไม่ได้ แต่ผู้ใช้จะเห็น CLS ดังกล่าว จึงรวมอยู่ใน CrUX ดังนั้น แม้ว่าข้อมูลภาคสนามจะมีประโยชน์อย่างยิ่งในการระบุปัญหา CLS แต่โปรดทราบว่าข้อมูลดังกล่าวอาจไม่สมบูรณ์ในบางสถานการณ์

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

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

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

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

รูปภาพที่ไม่ได้ระบุความกว้างและความสูง

รูปภาพที่มีการระบุความกว้างและความสูง

ผลของการตั้งค่าขนาดรูปภาพใน CLS ของ Lighthouse 6.0

ประวัติของแอตทริบิวต์ 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 มีความสูง 360 พิกเซล ความกว้างคือ 360 x (16 / 9) = 640 พิกเซล
• หาก 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 Attributes 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 ในลักษณะที่คล้ายกับวิธีที่เบราว์เซอร์ใช้พร็อพเพอร์ตี้นี้โดยอัตโนมัติสำหรับรูปภาพที่มีการกำหนดขนาดไว้

การจองพื้นที่สําหรับโฆษณาจะช่วยป้องกันไม่ให้เลย์เอาต์เปลี่ยนรูปแบบ

คุณอาจต้องพิจารณาถึงความแตกต่างเล็กน้อยของขนาดโฆษณาหรือตัวยึดตําแหน่งในอุปกรณ์ต่างๆ โดยใช้ Media Queries

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

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

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

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

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

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

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

เนื้อหาแบบไดนามิกที่ไม่ได้จองพื้นที่ไว้

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

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

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

ตัวอย่างการโหลดเนื้อหาแบบไดนามิกโดยไม่ทําให้เลย์เอาต์เปลี่ยนโดยไม่คาดคิด ซ้าย: การโหลดเนื้อหาฟีดแบบสดบน Twitter ขวา: ตัวอย่าง "โหลดเพิ่มเติม" ในเว็บไซต์ Chloé ดูวิธีที่ทีม YNAP เพิ่มประสิทธิภาพ CLS เมื่อโหลดเนื้อหาเพิ่มเติม

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

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

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

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

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

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

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

• ระบบจะแทนที่แบบอักษรสํารองด้วยแบบอักษรเว็บ ซึ่งทําให้ข้อความไม่มีการจัดรูปแบบปรากฏขึ้นเป็นระยะเวลาสั้นๆ (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 ไม่ได้ทั้งหมด แต่การใช้เทคนิคเหล่านี้บางส่วนก็จะช่วยให้คุณลดผลกระทบได้ เราหวังว่าวิธีนี้จะช่วยให้คุณอยู่ภายใต้ขีดจํากัดดังกล่าวได้ ซึ่งจะสร้างประสบการณ์การใช้งานที่ดีขึ้นให้แก่ผู้ใช้เว็บไซต์