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

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

Addy Osmani

Barry Pollard

เผยแพร่: 5 พฤษภาคม 2020, อัปเดตล่าสุด: 7 กุมภาพันธ์ 2025

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

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

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

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

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

สาเหตุที่พบบ่อยที่สุดที่ทำให้ CLS ไม่ดีมีดังนี้

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

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

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

CLS ในเครื่องมือในห้องทดลองเทียบกับในฟิลด์

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• font-display: optional จะหลีกเลี่ยงการจัดเลย์เอาต์ใหม่ได้เนื่องจากระบบจะใช้แบบอักษรบนเว็บก็ต่อเมื่อพร้อมใช้งานเมื่อถึงเวลาจัดเลย์เอาต์ครั้งแรก
• ตรวจสอบว่าใช้แบบอักษรสำรองที่เหมาะสม เช่น การใช้ font-family: "Google Sans", sans-serif; จะช่วยให้มั่นใจได้ว่าระบบจะใช้sans-serifแบบอักษรสำรองของเบราว์เซอร์ขณะโหลด "Google Sans" การไม่ระบุแบบอักษรสํารองโดยใช้เพียง font-family: "Google Sans" จะหมายความว่าระบบจะใช้แบบอักษรเริ่มต้น ซึ่งใน Chrome คือ "Times" ซึ่งเป็นแบบอักษรแบบมีเชิงที่จับคู่ได้แย่กว่าแบบอักษร 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 ออกไปโดยสิ้นเชิงไม่ได้ แต่การใช้เทคนิคบางอย่างเหล่านี้จะช่วยลดผลกระทบได้ ซึ่งจะช่วยให้คุณไม่เกินขีดจำกัดดังกล่าว และสร้างประสบการณ์การใช้งานที่ดีขึ้นสำหรับผู้ใช้เว็บไซต์