เพิ่มประสิทธิภาพ 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 มิลลิวินาทีหลังจากการโต้ตอบนั้น

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

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

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

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

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

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

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

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

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 มีความสูง 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 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 ในลักษณะเดียวกับที่เบราว์เซอร์ใช้สิ่งนี้โดยอัตโนมัติสำหรับรูปภาพที่มีขนาดที่ระบุ

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

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