คำแนะนำจากข้อมูลสำหรับรูปภาพที่โหลดแบบ Lazy Loading โดยคำนึงถึง Core Web Vitals
การโหลดแบบ Lazy Loading เป็นเทคนิคที่เลื่อนเวลาการดาวน์โหลดทรัพยากรไปจนกว่าจะจำเป็น เพื่อประหยัดข้อมูลและลดการแย่งชิงเครือข่ายสำหรับเนื้อหาที่สำคัญ โดยได้กลายเป็นมาตรฐานเว็บในปี 2019 และปัจจุบันนี้ loading="lazy"
สำหรับรูปภาพได้รับการรองรับในเบราว์เซอร์หลักๆ ส่วนใหญ่
คู่มือนี้จะสรุปวิธีวิเคราะห์ข้อมูลความโปร่งใสของเว็บและการทดสอบ A/B เฉพาะกิจที่เผยแพร่ต่อสาธารณะเพื่อทำความเข้าใจลักษณะการใช้งานและลักษณะประสิทธิภาพของการโหลดรูปภาพแบบ Lazy Loading ระดับเบราว์เซอร์ ผลการศึกษาระบุว่าการโหลดแบบ Lazy Loading จะเป็นเครื่องมือที่มีประสิทธิภาพอย่างมากในการลดจำนวนไบต์รูปภาพที่ไม่จำเป็น แต่การใช้งานมากเกินไปอาจส่งผลเสียต่อประสิทธิภาพ จากการวิเคราะห์นี้ การวิเคราะห์นี้แสดงให้เห็นว่าการโหลดรูปภาพอย่างตั้งใจมากขึ้นภายในวิวพอร์ตเริ่มต้นในขณะที่โหลดส่วนที่เหลือแบบ Lazy Loading นั้นเป็นสิ่งที่ดีที่สุดสำหรับเราทั้ง 2 อย่าง นั่นคือโหลดไบต์น้อยลงและช่วยปรับปรุง Core Web Vitals
การนำไปใช้
ข้อมูลล่าสุดใน HTTP Archive ระบุว่าเว็บไซต์ 29% มีการใช้การโหลดรูปภาพแบบ Lazy Loading และกำลังเพิ่มขึ้นอย่างรวดเร็ว
![แผนภูมิวงกลมแสดงให้เห็นว่า WordPress มีการใช้การโหลดแบบ Lazy Loading 84.1%, CMS อื่นๆ คิดเป็น 2.3% และไม่ใช่ CMS 13.5%](https://web.dev/static/articles/lcp-lazy-loading/image/pie-chart-showing-wordpre-4b9f571267fae.png?authuser=4&hl=th)
การค้นหาข้อมูลดิบในโปรเจ็กต์ HTTP Archive ช่วยให้เราเข้าใจได้ชัดเจนยิ่งขึ้นว่าเว็บไซต์ประเภทใดที่กระตุ้นให้เกิดการใช้งาน โดย 84% ของเว็บไซต์ที่ใช้การโหลดแบบ Lazy Loading ระดับเบราว์เซอร์ใช้ WordPress อีก 2% ใช้ CMS อื่น และอีก 14% ไม่ได้ใช้ CMS ที่รู้จัก ผลลัพธ์เหล่านี้แสดงให้เห็นอย่างชัดเจนว่า WordPress เป็นผู้นำด้านการเรียกเก็บเงิน ในการใช้งานได้อย่างไร
![แผนภูมิอนุกรมเวลาของการโหลดแบบ Lazy Loading โดยมี WordPress เป็นโปรแกรมเล่นหลักเมื่อเทียบกับ CMS อื่นๆ และไม่ใช่ CMS ซึ่งมีสัดส่วนใกล้เคียงกับแผนภูมิก่อนหน้านี้ และจะเห็นว่าการใช้งานทั้งหมดเพิ่มขึ้นอย่างรวดเร็วจาก 1% เป็น 17% จากเดือนกรกฎาคม 2020 ถึงมิถุนายน 2021](https://web.dev/static/articles/lcp-lazy-loading/image/timeseries-chart-lazy-lo-bb9c26a3fb041.png?authuser=4&hl=th)
นอกจากนี้ อัตราการนำไปใช้งานยังควรทราบอีกด้วย ปีที่แล้วในเดือนกรกฎาคม 2020 เว็บไซต์ WordPress ที่ใช้การโหลดแบบ Lazy Loading ประกอบด้วยเว็บไซต์หลายหมื่นเว็บไซต์ในคลังข้อมูลประมาณ 6 ล้านแห่ง (1% จากทั้งหมด) ตั้งแต่การใช้การโหลดแบบ Lazy Loading ใน WordPress เพียงอย่างเดียว ได้เติบโตขึ้นเป็นกว่า 1 ล้านเว็บไซต์ (14% จากทั้งหมด)
ประสิทธิภาพตามความสัมพันธ์
เจาะลึกยิ่งขึ้นเกี่ยวกับที่เก็บ HTTP Archive เปรียบเทียบได้ว่าหน้าที่มีและไม่มีการโหลดรูปภาพแบบ Lazy Loading ระดับเบราว์เซอร์จะทำงานได้ดีเพียงใดด้วยเมตริก Largest Contentful Paint (LCP) ข้อมูล LCP มาจากประสบการณ์ของผู้ใช้จริงจากรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ซึ่งตรงข้ามกับการทดสอบสังเคราะห์ในห้องทดลอง แผนภูมิต่อไปนี้ใช้พล็อตแบบกล่องและเส้นแบ่งครึ่งเพื่อแสดงภาพการกระจายของ LCP เปอร์เซ็นไทล์ที่ 75 ของแต่ละหน้า: เส้นต่างๆ แสดงเปอร์เซ็นไทล์ที่ 10 และ 90 และกล่องเหล่านั้นแสดงสัดส่วนเปอร์เซ็นต์ที่ 25 และ 75
![แผนภูมิทรงกล่องและแผนภูมิหนวดแสดงเปอร์เซ็นไทล์ที่ 10, 25, 75 และ 90 สำหรับหน้าเว็บที่ใช้และไม่ได้ใช้การโหลดแบบ Lazy Loading รูปภาพระดับเบราว์เซอร์ ในเชิงเปรียบเทียบว่าการกระจาย LCP ของหน้าเว็บที่ไม่ได้ใช้นั้นเร็วกว่าหน้าที่ใช้](https://web.dev/static/articles/lcp-lazy-loading/image/box-whisker-chart-showin-fab6befef771c.png?authuser=4&hl=th)
ค่ามัธยฐานของหน้าที่ไม่มีการโหลดแบบ Lazy Loading มี LCP เปอร์เซ็นไทล์ที่ 75 อยู่ที่ 2,922 มิลลิวินาที เมื่อเทียบกับหน้าค่ามัธยฐานที่มีการโหลดแบบ Lazy Loading 3,546 มิลลิวินาที โดยรวมแล้ว เว็บไซต์ที่ใช้การโหลดแบบ Lazy Loading มีแนวโน้มที่จะมีประสิทธิภาพ LCP ต่ำกว่า
คุณต้องชี้ให้เห็นว่าผลการค้นหาเหล่านี้เป็นแบบสหสัมพันธ์ และอาจไม่ได้ชี้ว่าการโหลดแบบ Lazy Loading เป็นสาเหตุของประสิทธิภาพที่ช้าลง ทางสันนิษฐานว่าเว็บไซต์ WordPress มีแนวโน้มที่จะทำงานช้าลงเล็กน้อยและเมื่อพิจารณาจำนวนกลุ่มประชากรตามรุ่นที่ใช้การโหลดแบบ Lazy Loading เท่าไร ก็อาจอธิบายความแตกต่างได้ เพื่อกำจัดความแปรปรวนดังกล่าว คุณสามารถจำกัดขอบเขตให้แคบลงโดยเจาะจงเฉพาะเว็บไซต์ WordPress
![แผนภูมิ Box และ Whisker แสดงเปอร์เซ็นไทล์ที่ 10, 25, 75 และ 90 สำหรับหน้า WordPress ที่ใช้และไม่ใช้การโหลดรูปภาพแบบ Lazy Loading ระดับเบราว์เซอร์ ในการเปรียบเทียบ การกระจาย LCP ของหน้าเว็บที่ไม่ได้ใช้งานจะเร็วกว่าการแสดงหน้าเว็บดังกล่าว ซึ่งคล้ายกับแผนภูมิก่อนหน้านี้](https://web.dev/static/articles/lcp-lazy-loading/image/box-whisker-chart-showin-c37339441feb8.png?authuser=4&hl=th)
น่าเสียดายที่รูปแบบเดียวกันนี้ปรากฏขึ้นเมื่อเจาะลึกลงในหน้า WordPress หน้าเว็บที่ใช้การโหลดแบบ Lazy Loading มีแนวโน้มที่จะมีประสิทธิภาพ LCP ช้ากว่า ค่ามัธยฐานของหน้า WordPress ที่ไม่มีการโหลดแบบ Lazy Loading มี LCP เปอร์เซ็นไทล์ที่ 75 อยู่ที่ 3,495 มิลลิวินาที เมื่อเทียบกับหน้าค่ามัธยฐานที่มีการโหลดแบบ Lazy Loading 3,768 มิลลิวินาที
กรณีนี้ยังไม่ได้พิสูจน์ว่าการโหลดแบบ Lazy Loading จะทำให้หน้าเว็บโหลดช้าลง แต่การใช้งานหน้าเว็บกลับเดียวกับประสิทธิภาพที่ช้าลง โดยเราได้ตั้งการทดสอบ A/B ในห้องทดลองขึ้นเพื่อพยายามตอบคำถามเกี่ยวกับความสัมพันธ์ระหว่างเหตุและผล
ประสิทธิภาพโดยทั่วไป
เป้าหมายของการทดสอบ A/B คือการพิสูจน์หรือหักล้างสมมติฐานที่ว่าการโหลดรูปภาพแบบ Lazy Loading ในตัวที่ใช้การโหลดแบบ Lazy Loading ในตัวของ WordPress ส่งผลให้ประสิทธิภาพ LCP ช้าลงและไบต์รูปภาพน้อยลง ระเบียบวิธีที่ใช้คือการทดสอบเว็บไซต์ WordPress เวอร์ชันเดโมที่มีธีม twentytwentyone ทั้งประเภทที่เก็บถาวรและหน้าเดียวได้รับการทดสอบแล้ว ซึ่งเหมือนกับหน้าแรกและหน้าบทความบนเดสก์ท็อปและอุปกรณ์เคลื่อนที่จำลองโดยใช้ WebPageTest โดยได้ทดสอบชุดค่าผสมของหน้าเว็บแต่ละชุดทั้งที่เปิดใช้และไม่ได้เปิดใช้การโหลดแบบ Lazy Loading และทำการทดสอบแต่ละครั้ง 9 ครั้งเพื่อหาค่ามัธยฐาน LCP และจำนวนไบต์ของรูปภาพ
ซีรีส์ | ค่าเริ่มต้น | ปิดอยู่ | ความแตกต่างจากค่าเริ่มต้น |
---|---|---|---|
twentytwentyone-archive-desktop | 2,029 คน | 1,759 | ลดลง 13% |
Tentytwentyone-archive-mobile | 1,657 คน | 1,403 รายการ | ลดลง 15% |
Tentytwentyone-single-desktop | 1,655 ตัว | 1,726 | 4% |
2018-2019-2021 | 1,352 คน | 1,384 | 2% |
ผลลัพธ์เหล่านี้จะเปรียบเทียบค่ามัธยฐาน LCP ในหน่วยมิลลิวินาทีสำหรับการทดสอบในที่เก็บถาวรและหน้าเดี่ยวสำหรับเดสก์ท็อปและอุปกรณ์เคลื่อนที่ เมื่อปิดการโหลดแบบ Lazy Loading ในหน้าที่เก็บถาวร LCP ก็จะเพิ่มขึ้นอย่างมาก แต่ในหน้าเว็บหน้าเดียว ก็ให้ความแตกต่างน้อยกว่า
ดูเหมือนว่าการปิดใช้การโหลดแบบ Lazy Loading จะทำให้หน้าเดี่ยวเร็วขึ้นเล็กน้อย อย่างไรก็ตาม ความแตกต่างของ LCP นั้นมีค่าเบี่ยงเบนมาตรฐานน้อยกว่า 1 ค่าสำหรับทั้งการทดสอบบนเดสก์ท็อปและอุปกรณ์เคลื่อนที่ ดังนั้นจึงอาจเป็นผลมาจากความแปรปรวนและเมื่อพิจารณาการเปลี่ยนแปลงโดยรวมอย่างเป็นกลาง เมื่อเปรียบเทียบกันแล้ว ความแตกต่างของหน้าที่เก็บถาวรจะมีค่าเบี่ยงเบนมาตรฐานเกือบ 2-3 ค่า
ซีรีส์ | ค่าเริ่มต้น | ปิดอยู่ | ความแตกต่างจากค่าเริ่มต้น |
---|---|---|---|
twentytwentyone-archive-desktop | 577 | 1173 | 103% |
Tentytwentyone-archive-mobile | 172 | 378 | 120% |
Tentytwentyone-single-desktop | 301 | 850 | 183% |
2018-2019-2021 | 114 | 378 | 233% |
ผลลัพธ์เหล่านี้จะเปรียบเทียบค่ามัธยฐานของไบต์รูปภาพ (เป็น KB) สำหรับการทดสอบแต่ละครั้ง ตามที่คาดไว้ การโหลดแบบ Lazy Loading จะส่งผลดีอย่างชัดเจนต่อการลดจำนวนไบต์รูปภาพ หากผู้ใช้จริงเลื่อนดูทั้งหน้า รูปภาพทุกรูปจะโหลดเมื่อข้ามไปยังวิวพอร์ต แต่ผลลัพธ์เหล่านี้จะแสดงประสิทธิภาพที่ดีขึ้นในการโหลดหน้าเว็บเริ่มต้น
ในการสรุปผลการทดสอบ A/B เทคนิคการโหลดแบบ Lazy Loading ที่ WordPress ใช้ช่วยลดไบต์ของรูปภาพได้ชัดเจนหากมี LCP ที่ล่าช้า
ทดสอบการแก้ไข
สิ่งสำคัญที่สุดของการติดตั้งใช้งานการโหลดแบบ Lazy Loading ปัจจุบันของ WordPress คือการโหลดรูปภาพภายในวิวพอร์ต (ครึ่งหน้าบน) บล็อกโพสต์ CMS ได้ยอมรับว่านี่เป็นรูปแบบที่ควรหลีกเลี่ยง แต่ข้อมูลการทดลองในเวลานั้นบ่งชี้ว่าผลที่มีต่อ LCP นั้นเกิดขึ้นน้อยมากและมีความคุ้มค่าที่จะลดความซับซ้อนในการใช้งานใน WordPress Core
ด้วยข้อมูลใหม่นี้ เราได้สร้างการแก้ไขเชิงทดลองที่หลีกเลี่ยงการโหลดรูปภาพที่อยู่ครึ่งหน้าบน และการทดสอบการแก้ไขนั้นได้รับการทดสอบภายใต้เงื่อนไขเดียวกันกับการทดสอบ A/B ครั้งแรก
ซีรีส์ | ค่าเริ่มต้น | ปิดอยู่ | fix | ความแตกต่างจากค่าเริ่มต้น | ความแตกต่างจากการปิดใช้ |
---|---|---|---|---|---|
twentytwentyone-archive-desktop | 2,029 คน | 1,759 | 1,749 | ลดลง 14% | ลดลง 1% |
Tentytwentyone-archive-mobile | 1,657 คน | 1,403 รายการ | 1,352 คน | ลดลง 18% | ลดลง 4% |
Tentytwentyone-single-desktop | 1,655 ตัว | 1,726 | 1,676 คน | 1% | ลดลง 3% |
2018-2019-2021 | 1,352 คน | 1,384 | 1,342 คน | ลดลง 1% | ลดลง 3% |
ผลลัพธ์เหล่านี้มีแนวโน้มมากขึ้น การโหลดแบบ Lazy Loading เฉพาะรูปภาพครึ่งหน้าล่างจะทําให้การถดถอย LCP กลับมาสมบูรณ์และอาจปรับปรุงได้เล็กน้อยเมื่อเทียบกับการปิดใช้การโหลดแบบ Lazy Loading ทั้งหมด แล้วการโหลดแบบ Lazy Loading จะเร็วกว่าการโหลดแบบ Lazy Loading ได้อย่างไร สาเหตุหนึ่งก็คือการไม่โหลดรูปภาพครึ่งหน้าล่าง จะทำให้เกิดการช่วงชิงเครือข่ายกับรูปภาพ LCP น้อยลง ส่งผลให้โหลดได้เร็วขึ้น
ซีรีส์ | ค่าเริ่มต้น | ปิดอยู่ | fix | ความแตกต่างจากค่าเริ่มต้น | ความแตกต่างจากการปิดใช้ |
---|---|---|---|---|---|
twentytwentyone-archive-desktop | 577 | 1173 | 577 | 0% | ลดลง 51% |
Tentytwentyone-archive-mobile | 172 | 378 | 172 | 0% | ลดลง 54% |
Tentytwentyone-single-desktop | 301 | 850 | 301 | 0% | ลดลง 65% |
2018-2019-2021 | 114 | 378 | 114 | 0% | ลดลง 70% |
ในแง่ของไบต์รูปภาพ การแก้ไขนี้จะไม่เปลี่ยนแปลงโดยสิ้นเชิงเมื่อเทียบกับลักษณะการทำงานเริ่มต้น ซึ่งยอดเยี่ยมมากเพราะนั่นเป็นจุดแข็งอย่างหนึ่งของวิธีการปัจจุบัน
การแก้ไขนี้มาพร้อมกับข้อควรระวังบางประการ WordPress กำหนดว่ารูปภาพใดบ้างที่จะโหลดแบบ Lazy Loading ในฝั่งเซิร์ฟเวอร์ ซึ่งหมายความว่า WordPress ไม่มีข้อมูลเกี่ยวกับขนาดวิวพอร์ตของผู้ใช้หรือบอกว่ารูปภาพโหลดขึ้นในตอนแรกหรือไม่ ดังนั้นการแก้ไขจึงใช้การเรียนรู้เกี่ยวกับตำแหน่งสัมพัทธ์ของรูปภาพในมาร์กอัปเพื่อคาดเดาว่ารูปภาพจะโหลดในวิวพอร์ตหรือไม่ กล่าวอย่างเจาะจงคือ หากรูปภาพเป็นรูปเด่นรูปแรกในหน้าเว็บหรือรูปภาพแรกในเนื้อหาหลัก ระบบจะถือว่ารูปอยู่ในครึ่งหน้าบนหรือใกล้เคียงกับรูป และจะไม่โหลดแบบ Lazy Loading
เงื่อนไขระดับหน้าเว็บ เช่น จำนวนคำในส่วนหัวหรือจำนวนข้อความย่อหน้าในช่วงต้นของเนื้อหาหลักอาจส่งผลต่อการที่รูปภาพอยู่ภายในวิวพอร์ต นอกจากนี้ ยังมีเงื่อนไขระดับผู้ใช้ที่อาจส่งผลต่อความแม่นยำของการเรียนรู้ โดยเฉพาะขนาดวิวพอร์ตและการใช้ลิงก์ตำแหน่งเฉพาะที่เปลี่ยนแปลงตำแหน่งการเลื่อนของหน้าเว็บ
ด้วยเหตุผลดังกล่าว คุณจึงต้องรับทราบว่าการแก้ไขได้รับการปรับเทียบมาเพื่อให้ได้ประสิทธิภาพที่ดีในกรณีทั่วไปเท่านั้น และอาจต้องปรับแต่งเพิ่มเติมเพื่อให้ผลลัพธ์เหล่านี้ใช้ได้กับทุกสถานการณ์ในชีวิตจริง
การใช้งาน (:#การติดตั้งใช้งาน)
ตอนนี้เราได้พบวิธีที่ดีขึ้นในการโหลดรูปภาพแบบ Lazy Loading แล้ว ทั้งการประหยัดรูปภาพทั้งหมดและประสิทธิภาพ LCP ที่เร็วขึ้น เว็บไซต์จะเริ่มใช้รูปนี้ได้อย่างไร การเปลี่ยนแปลงที่สำคัญที่สุดคือการส่งแพตช์ไปยัง WordPress Core เพื่อใช้การแก้ไขจากการทดสอบ นอกจากนี้ คำแนะนำในบล็อกโพสต์การโหลดแบบ Lazy Loading ระดับเบราว์เซอร์สำหรับ CMS จะมีการปรับปรุงเพื่อชี้แจงถึงผลกระทบเชิงลบของการโหลดแบบ Lazy Loading ครึ่งหน้าบน และวิธีที่ CMS จะใช้การเรียนรู้เพื่อหลีกเลี่ยงปัญหานี้
เนื่องจากแนวทางปฏิบัติแนะนำเหล่านี้ใช้ได้กับนักพัฒนาเว็บทั้งหมด การปกป้องรูปแบบการโหลดแบบ Lazy Loading ในเครื่องมืออย่าง Lighthouse ก็ควรเป็นเรื่องที่คุ้มค่า โปรดดูคำขอฟีเจอร์ใน GitHub หากสนใจติดตามความคืบหน้าของการตรวจสอบดังกล่าว ในระหว่างนี้ สิ่งหนึ่งที่นักพัฒนาแอปทำได้เพื่อค้นหาอินสแตนซ์ขององค์ประกอบ LCP ที่โหลดแบบ Lazy Loading คือการเพิ่มการบันทึกโดยละเอียดลงในข้อมูลภาคสนาม
new PerformanceObserver((list) => {
const latestEntry = list.getEntries().at(-1);
if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
console.warn('Warning: LCP element was lazy loaded', latestEntry);
}
}).observe({type: 'largest-contentful-paint', buffered: true});
ข้อมูลโค้ด JavaScript ก่อนหน้าจะประเมินองค์ประกอบ LCP ล่าสุดและบันทึกคำเตือนหากเป็นการโหลดแบบ Lazy Loading
การทำเช่นนี้ยังไฮไลต์ข้อดีของเทคนิคการโหลดแบบ Lazy Loading และศักยภาพในการปรับปรุง API ในระดับแพลตฟอร์ม เช่น มีปัญหาที่ยังไม่ได้รับการแก้ไขใน Chromium เพื่อทดสอบกับการโหลดรูปภาพ 2-3 รูปแรกอย่างตั้งใจ คล้ายๆ กับการแก้ไข แม้จะมีแอตทริบิวต์ loading
ก็ตาม
บทสรุป
หากเว็บไซต์ใช้การโหลดรูปภาพแบบ Lazy Loading ระดับเบราว์เซอร์ ให้ตรวจสอบวิธีใช้และทำการทดสอบ A/B เพื่อให้เข้าใจต้นทุนด้านประสิทธิภาพของเว็บไซต์ได้ดีขึ้น อาจได้ประโยชน์จากการโหลดรูปภาพครึ่งหน้าบนอย่างตั้งใจมากขึ้น หากคุณมีเว็บไซต์ WordPress ก็คาดว่าจะมีการอัปเดตแพตช์ในเวอร์ชัน WordPress Core เร็วๆ นี้ และหากคุณใช้ CMS อื่น โปรดตรวจสอบว่า CMS ทราบถึงปัญหาด้านประสิทธิภาพที่อาจเกิดขึ้นตามที่อธิบายไว้ที่นี่
การลองใช้ API แพลตฟอร์มเว็บที่ค่อนข้างใหม่มาพร้อมกับทั้งความเสี่ยงและรางวัล เราจึงเรียกว่าฟีเจอร์สุดล้ำด้วยเหตุผลเดียว เราเริ่มเข้าใจความยุ่งยากของการโหลดรูปภาพแบบ Lazy Loading ระดับเบราว์เซอร์แล้ว เรายังได้เห็นข้อดีของการใช้งานเพื่อให้ได้ประสิทธิภาพที่ดีขึ้นด้วย
รูปภาพโดย Frankie Lopez ใน Unsplash