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

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

Addy Osmani

Barry Pollard

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

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

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

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

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

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

สาเหตุที่พบบ่อยที่สุดของ 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 มิลลิวินาทีของการโต้ตอบดังกล่าว

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

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

วันที่

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

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

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

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

วันที่

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

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

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

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

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

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

รูปภาพที่ไม่มีขนาด

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

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

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

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

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

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

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

width และ height ในตัวอย่างนี้ไม่มีหน่วย "pixel" เหล่านี้ จะช่วยให้แน่ใจว่าเบราว์เซอร์จองพื้นที่ 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 มีความกว้าง 640px ความสูงเท่ากับ 640 x (9 / 16) = 360px

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

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

เนื่องจากเบราว์เซอร์สมัยใหม่ตั้งค่าสัดส่วนภาพเริ่มต้นตาม แอตทริบิวต์ 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 และโพสต์โซเชียลมีเดีย อย่างไรก็ตาม วิดเจ็ตเหล่านี้มักไม่ทราบว่าเนื้อหามีขนาดใหญ่แค่ไหนก่อนที่จะโหลด ด้วยเหตุนี้ แพลตฟอร์มที่นำเสนอการฝังจึงไม่จองพื้นที่สำหรับวิดเจ็ตของตนไว้เสมอไป และทำให้เลย์เอาต์เกิดการเปลี่ยนแปลงเมื่อโหลดในที่สุด

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

สำรองพื้นที่สำหรับเนื้อหาที่โหลดล่าช้า

เมื่อวางเนื้อหาที่โหลดช้าในการรับส่งเนื้อหา สามารถหลีกเลี่ยงการเปลี่ยนแปลงของเลย์เอาต์ได้ด้วยการจองพื้นที่สำหรับเนื้อหาในเลย์เอาต์เริ่มต้น

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

วันที่

การจองพื้นที่สำหรับโฆษณาอาจป้องกันการเปลี่ยนเลย์เอาต์ได้

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

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

โดยคุณสามารถกำหนดขนาดเริ่มต้นให้มีขนาดเล็กที่สุดที่จะใช้แทน และยอมรับการเปลี่ยนแปลงในระดับหนึ่งสำหรับเนื้อหาขนาดใหญ่ การใช้ 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 ภาพเคลื่อนไหวที่ไม่ได้ทำการ Composite ก็ไม่ทำให้เกิดเลย์เอาต์ใหม่เช่นกัน ดูข้อมูลเพิ่มเติมเกี่ยวกับพร็อพเพอร์ตี้ CSS ที่ทริกเกอร์การเปลี่ยนเลย์เอาต์ได้ที่ภาพเคลื่อนไหวประสิทธิภาพสูง

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

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

• แบบอักษรสำรองถูกสลับกับแบบอักษรเว็บ ซึ่งทำให้เกิด Flash ของข้อความ Unstyled Text (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 ตามรายละเอียดในโพสต์แบบอักษรสำรองที่ได้รับการปรับปรุง
• API การโหลดฟอนต์จะช่วยลดเวลาที่ใช้ในการรับแบบอักษรที่จำเป็น
• โหลดแบบอักษรสำหรับเว็บที่สำคัญให้เร็วที่สุดเท่าที่จะทำได้โดยใช้ <link rel=preload> แบบอักษรที่โหลดไว้ล่วงหน้าจะมีโอกาสมากกว่าการลงสีครั้งแรก ซึ่งในกรณีนี้จะไม่มีการเปลี่ยนเลย์เอาต์

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

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

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

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

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

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

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

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

บทสรุป

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