ดูวิธีหลีกเลี่ยงการเปลี่ยนเลย์เอาต์อย่างฉับพลันเพื่อปรับปรุงประสบการณ์ของผู้ใช้
เผยแพร่: 5 พฤษภาคม 2020 อัปเดตล่าสุด: 7 ก.พ. 2025
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 มิลลิวินาทีหลังจากการโต้ตอบนั้น
อย่างไรก็ตาม ระบบอาจรวมการเปลี่ยนแปลงอื่นๆ หลังการโหลดที่ผู้ใช้ไม่คาดคิดไว้ด้วยในกรณีที่ไม่มีการโต้ตอบที่ตรงตามเกณฑ์ เช่น หากคุณเลื่อนหน้าเว็บต่อและระบบโหลดเนื้อหาที่โหลดแบบเลื่อนดูทีหลัง ซึ่งทําให้เกิดการเปลี่ยนแปลง สาเหตุอื่นๆ ที่พบได้ทั่วไปของ CLS หลังการโหลดคือการโต้ตอบของการเปลี่ยน เช่น ในแอปแบบหน้าเดียว ซึ่งใช้เวลานานกว่าระยะเวลาผ่อนผัน 500 มิลลิวินาที
PageSpeed Insights จะแสดงทั้ง CLS ที่ผู้ใช้รับรู้จาก URL ในส่วน "ดูประสบการณ์ที่ผู้ใช้งานจริงได้รับ" และ CLS ที่โหลดจากห้องทดลองในส่วน "วินิจฉัยปัญหาด้านประสิทธิภาพ" ความแตกต่างระหว่างค่าเหล่านี้อาจเป็นผลมาจาก CLS หลังการโหลด
![PageSpeed Insights ที่แสดงข้อมูลระดับ URL โดยไฮไลต์ CLS ของผู้ใช้จริงซึ่งสูงกว่า CLS ของ Lighthouse อย่างมาก](https://web.developers.google.cn/static/articles/optimize-cls/image/screenshot-pagespeed-ins-1b9715cccc402.png?hl=th)
ระบุปัญหา CLS ในการโหลด
เมื่อคะแนน CLS ของ CrUX และ Lighthouse ใน PageSpeed Insights สอดคล้องกับคะแนนโดยรวม มักหมายความว่า Lighthouse ตรวจพบปัญหา CLS ในการโหลด ในกรณีนี้ Lighthouse จะช่วยในการตรวจสอบ 2 รายการเพื่อให้ข้อมูลเพิ่มเติมเกี่ยวกับรูปภาพที่ทำให้เกิด CLS เนื่องจากไม่มีความกว้างและความสูง รวมถึงแสดงรายการองค์ประกอบทั้งหมดที่เลื่อนเมื่อโหลดหน้าเว็บพร้อมกับส่วนที่เป็น CLS คุณดูการตรวจสอบเหล่านี้ได้โดยกรองการตรวจสอบ CLS
![ภาพหน้าจอ Lighthouse ที่แสดงการตรวจสอบ CLS ซึ่งให้ข้อมูลเพิ่มเติมเพื่อช่วยคุณระบุและแก้ไขปัญหา CLS](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-screenshot-sho-1c6eeefdc4b1b.png?hl=th)
แผงประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บมีข้อมูลมากมายเกี่ยวกับการเปลี่ยนแปลงเลย์เอาต์ ดังนี้
![ระเบียนการเปลี่ยนเลย์เอาต์ที่แสดงในแผงประสิทธิภาพของเครื่องมือสําหรับนักพัฒนาเว็บใน Chrome](https://web.developers.google.cn/static/articles/optimize-cls/image/devtools-cls-debugging.png?hl=th)
Layout Shift
การคลิกเพชรจะแสดงภาพเคลื่อนไหวของการเปลี่ยนแปลงและรายละเอียดในแผงสรุป
ระบบจะไฮไลต์การเปลี่ยนแปลงเลย์เอาต์ในแทร็กการเปลี่ยนแปลงเลย์เอาต์ เส้นสีม่วงจะจัดกลุ่มเป็นคลัสเตอร์ของการเปลี่ยนแปลง โดยมีเพชรแสดงการเปลี่ยนแปลงแต่ละรายการในคลัสเตอร์นั้น ขนาดของเพชรจะสัมพันธ์กับขนาดของการเปลี่ยนแปลง ซึ่งช่วยให้คุณมุ่งเน้นที่การเปลี่ยนแปลงที่ใหญ่ที่สุดได้
การคลิกที่การเปลี่ยนแปลงจะแสดงป๊อปอัปที่มีภาพเคลื่อนไหวของการเปลี่ยนแปลงและไฮไลต์องค์ประกอบที่เปลี่ยนแปลงเป็นสีม่วง
นอกจากนี้ มุมมองสรุปของระเบียน Layout Shift
ยังมีเวลาเริ่มต้น คะแนนการเปลี่ยนแปลง และองค์ประกอบที่เปลี่ยนแปลง ซึ่งจะเป็นประโยชน์อย่างยิ่งในการดูรายละเอียดเพิ่มเติมเกี่ยวกับปัญหา CLS ที่โหลด เนื่องจากสามารถจําลองปัญหานี้ได้โดยง่ายด้วยโปรไฟล์ประสิทธิภาพการโหลดซ้ำ
ข้อมูลนี้ยังลิงก์กับข้อมูลเชิงลึกสาเหตุของการเปลี่ยนเลย์เอาต์ที่แสดงในแผงข้อมูลเชิงลึกทางด้านซ้าย ซึ่งจะแสดง CLS ทั้งหมดที่ด้านบน รวมถึงสาเหตุที่เป็นไปได้ของการเปลี่ยนเลย์เอาต์
ระบุปัญหา CLS หลังการโหลด
คะแนน CLS ของ CrUX และ Lighthouse ที่ไม่ตรงกันมักบ่งบอกถึง CLS หลังการโหลด การเปลี่ยนแปลงเหล่านี้อาจติดตามได้ยากหากไม่มีข้อมูลภาคสนาม ดูข้อมูลเกี่ยวกับการรวบรวมข้อมูลภาคสนามได้ที่วัดองค์ประกอบ CLS ในพื้นที่
มุมมองเมตริกแบบเรียลไทม์ของแผงประสิทธิภาพช่วยให้คุณโต้ตอบกับหน้าเว็บและตรวจสอบคะแนน CLS เพื่อระบุการโต้ตอบที่ทําให้เกิดการเปลี่ยนแปลงเลย์เอาต์ครั้งใหญ่
![บันทึกการเปลี่ยนเลย์เอาต์ที่แสดงในหน้าจอเมตริกแบบเรียลไทม์ของแผงประสิทธิภาพในเครื่องมือสําหรับนักพัฒนาเว็บใน Chrome](https://web.developers.google.cn/static/articles/optimize-cls/image/live-metrics-cls.png?hl=th)
คุณสามารถเรียกดูหน้าเว็บขณะบันทึกการเปลี่ยนแปลงเลย์เอาต์โดยใช้เครื่องมือตรวจสอบประสิทธิภาพที่วางลงในคอนโซลแทนการใช้เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์
หลังจากตั้งค่าการตรวจสอบการเปลี่ยนแปลงแล้ว ให้ลองจำลองปัญหา CLS หลังการโหลด CLS มักเกิดขึ้นขณะที่ผู้ใช้เลื่อนหน้าเว็บ เมื่อเนื้อหาที่โหลดแบบ Lazy โหลดจนเต็มโดยไม่มีพื้นที่ว่างสำหรับเนื้อหานั้น เนื้อหาที่เลื่อนไปมาเมื่อผู้ใช้วางเคอร์เซอร์ไว้เหนือเนื้อหาเป็นสาเหตุที่พบบ่อยอีกประการหนึ่งของ CLS หลังการโหลด การเปลี่ยนแปลงเนื้อหาระหว่างการโต้ตอบเหล่านี้จะถือว่าไม่คาดคิด แม้ว่าจะเกิดขึ้นภายใน 500 มิลลิวินาทีก็ตาม
ดูข้อมูลเพิ่มเติมได้ที่แก้ไขข้อบกพร่องการเปลี่ยนเลย์เอาต์
หลังจากระบุสาเหตุที่พบบ่อยของ CLS แล้ว คุณยังใช้โหมดขั้นตอนของผู้ใช้ตามช่วงเวลาของ Lighthouse เพื่อตรวจสอบว่าขั้นตอนของผู้ใช้ทั่วไปไม่ได้แย่ลงด้วยการเปลี่ยนเลย์เอาต์
วัดองค์ประกอบ CLS ในช่อง
การตรวจสอบ CLS ในพื้นที่มีประโยชน์อย่างยิ่งในการระบุสถานการณ์ที่ CLS เกิดขึ้นและจำกัดสาเหตุที่เป็นไปได้ให้แคบลง เครื่องมือภาคสนามจะวัดเฉพาะองค์ประกอบที่เปลี่ยนแปลงไปเช่นเดียวกับเครื่องมือส่วนใหญ่ในแล็บ แต่มักจะให้ข้อมูลเพียงพอในการระบุสาเหตุ นอกจากนี้ คุณยังใช้การวัดค่าในช่อง CLS เพื่อพิจารณาว่าปัญหาใดควรได้รับการแก้ไขก่อน
คลัง web-vitals
มีฟังก์ชันการระบุแหล่งที่มาที่ช่วยให้คุณรวบรวมข้อมูลเพิ่มเติมนี้ได้ ดูข้อมูลเพิ่มเติมได้ที่แก้ไขข้อบกพร่องด้านประสิทธิภาพในสนาม ผู้ให้บริการ RUM รายอื่นๆ ก็เริ่มรวบรวมและแสดงข้อมูลนี้ในลักษณะเดียวกันด้วย
สาเหตุที่พบบ่อยของ CLS
เมื่อระบุสาเหตุของ CLS แล้ว คุณสามารถเริ่มแก้ไขปัญหาได้ ส่วนนี้จะแสดงสาเหตุที่พบบ่อยของ CLS และสิ่งที่คุณสามารถทําเพื่อหลีกเลี่ยง
รูปภาพที่ไม่มีมิติข้อมูล
ระบุแอตทริบิวต์ขนาด width
และ height
ขององค์ประกอบรูปภาพและวิดีโอเสมอ หรือจะจองพื้นที่ที่ต้องการด้วย CSS aspect-ratio
หรือที่คล้ายกันก็ได้ วิธีนี้ช่วยให้มั่นใจว่าเบราว์เซอร์จะจัดสรรพื้นที่ในเอกสารได้อย่างถูกต้องขณะที่โหลดรูปภาพ
![รายงาน Lighthouse ที่แสดงผลกระทบก่อน/หลังต่อการเปลี่ยนแปลงเลย์เอาต์แบบสะสมหลังจากตั้งค่ามิติข้อมูลในรูปภาพ](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-report-showing-9556bbb060b37.png?hl=th)
ประวัติของแอตทริบิวต์ 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é](https://web.developers.google.cn/static/articles/optimize-cls/image/examples-dynamic-content-4d11ddda2fa94.png?hl=th)
ภาพเคลื่อนไหว
การเปลี่ยนแปลงค่าพร็อพเพอร์ตี้ 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 ไม่ได้ทั้งหมด แต่การใช้เทคนิคเหล่านี้บางส่วนก็จะช่วยให้คุณลดผลกระทบได้ เราหวังว่าวิธีนี้จะช่วยให้คุณอยู่ภายใต้ขีดจํากัดดังกล่าวได้ ซึ่งจะสร้างประสบการณ์การใช้งานที่ดีขึ้นให้แก่ผู้ใช้เว็บไซต์