ผลด้านประสิทธิภาพของการโหลดแบบ Lazy Loading ที่มากเกินไป

คำแนะนำโดยอิงตามข้อมูลสำหรับรูปภาพที่โหลดแบบ Lazy Loading โดยคำนึงถึง Core Web Vitals

การโหลดแบบ Lazy Loading เป็นเทคนิคในการยืดเวลาดาวน์โหลดทรัพยากรจนกว่าจะจำเป็นต้องใช้ ซึ่งจะประหยัดข้อมูลและลดการช่วงชิงเครือข่ายสำหรับเนื้อหาที่สำคัญ ซึ่งกลายเป็นมาตรฐานเว็บในปี 2019 และปัจจุบัน loading="lazy" สำหรับรูปภาพได้รับการรองรับโดยเบราว์เซอร์หลักส่วนใหญ่ ฟังดูเข้าท่าดีนะ แต่มีบางอย่างโหลดแบบ Lazy Loading มากเกินไปไหม

โพสต์นี้สรุปวิธีที่เราวิเคราะห์ข้อมูลความโปร่งใสของเว็บที่เปิดเผยต่อสาธารณะและการทดสอบ A/B เฉพาะกิจเพื่อทำความเข้าใจการใช้งานและลักษณะประสิทธิภาพของการโหลดแบบ Lazy Loading ของรูปภาพแบบเนทีฟ เราพบว่าการโหลดแบบ Lazy Loading เป็นเครื่องมือที่มีประสิทธิภาพสูงในการลดไบต์ของรูปภาพที่ไม่จำเป็น แต่การใช้งานมากเกินไปอาจส่งผลเสียต่อประสิทธิภาพ การวิเคราะห์ของเราชี้ชัดว่าการโหลดรูปภาพภายในวิวพอร์ตเริ่มต้นอย่างกระตือรือร้นมากขึ้น ขณะเดียวกันก็การโหลดส่วนที่เหลือได้อย่างอิสระ ทำให้เราได้สิ่งที่ดีที่สุดของทั้ง 2 โลก ซึ่งก็คือจำนวนไบต์ที่โหลดน้อยลง และ Core Web Vitals ที่ได้รับการปรับปรุง

การนำไปใช้

ข้อมูลล่าสุดใน HTTPที่เก็บถาวร พบว่าการโหลดแบบ Lazy Loading ของรูปภาพเนทีฟใช้ในเว็บไซต์ 17% และการรับไปใช้งานก็เพิ่มขึ้นอย่างรวดเร็ว ฐานที่มั่นในระบบนิเวศนี้ถือว่าน่าทึ่งสำหรับ API ที่ค่อนข้างใหม่

แผนภูมิวงกลมแสดง WordPress คิดเป็น 84.1% ของการใช้งานการโหลดแบบ Lazy Loading, CMS อื่นๆ 2.3% และไม่ใช่ CMS 13.5%
รายละเอียดประเภทเว็บไซต์ที่ใช้ประโยชน์จากการโหลดแบบ Lazy Loading ของรูปภาพดั้งเดิม (แหล่งที่มา)

การค้นหา ข้อมูลดิบในโปรเจ็กต์ HTTP Archive ช่วยให้เราเข้าใจได้ชัดเจนยิ่งขึ้นว่าเว็บไซต์ประเภทใดบ้างที่ผลักดันให้เกิดการใช้งาน ผลลัพธ์เหล่านี้ให้ความชัดเจนว่า WordPress เป็นผู้นำในการเรียกเก็บเงินอย่างไร

แผนภูมิอนุกรมเวลาของการใช้งานการโหลดแบบ Lazy Loading โดย WordPress เป็นโปรแกรมเล่นที่โดดเด่นเมื่อเทียบกับ CMS และไม่ใช่ CMS อื่นๆ โดยมีสัดส่วนใกล้เคียงกับแผนภูมิก่อนหน้า เราพบว่าการใช้งานโดยรวมเพิ่มขึ้นอย่างรวดเร็วจาก 1% เป็น 17% ตั้งแต่เดือนกรกฎาคม 2020 ถึงมิถุนายน 2021
รายละเอียดประเภทเว็บไซต์ที่ใช้ประโยชน์จากการโหลดแบบ Lazy Loading ของรูปภาพดั้งเดิม (แหล่งที่มา)

นอกจากนี้ อัตราการใช้บริการ เมื่อเดือนกรกฎาคม 2020 เมื่อเดือนกรกฎาคม 2020 เว็บไซต์ WordPress ที่ใช้การโหลดแบบ Lazy Loading ประกอบด้วยเว็บไซต์หลายหมื่นเว็บในคลังข้อมูลประมาณ 6 ล้าน (1% ของทั้งหมด) การใช้การโหลดแบบ Lazy Loading ใน WordPress เพียงอย่างเดียวได้เพิ่มขึ้นเป็นกว่า 1 ล้านเว็บไซต์ (14% จากทั้งหมด)

ประสิทธิภาพความสัมพันธ์

การเจาะลึกเกี่ยวกับที่เก็บถาวรของ HTTP เราสามารถเปรียบเทียบประสิทธิภาพของหน้าเว็บที่มีและไม่มีการโหลดแบบ Lazy Loading เนทีฟด้วยเมตริก Largest Contentful Paint (LCP) ข้อมูล LCP มาจากประสบการณ์ของผู้ใช้จริงจากรายงานประสบการณ์ของผู้ใช้ Chrome (CrUX) ซึ่งตรงข้ามกับการทดสอบสังเคราะห์ในห้องทดลอง แผนภูมิด้านล่างใช้แผนภูมิแบบกล่องและแถบสัญญาณเพื่อแสดงภาพการกระจาย LCP เปอร์เซ็นไทล์ที่ 75 ของแต่ละหน้า เส้นแสดงถึงเปอร์เซ็นไทล์ที่ 10 และ 90 และช่องทำเครื่องหมายแสดงถึงเปอร์เซ็นไทล์ที่ 25 และ 75

แผนภูมิ Box และ Whisker แสดงเปอร์เซ็นไทล์ที่ 10, 25, 75 และ 90 สำหรับหน้าเว็บที่มีและไม่ได้ใช้การโหลดแบบ Lazy Loading เนทีฟ เมื่อเปรียบเทียบกันแล้ว การกระจาย LCP ของหน้าที่ไม่ได้ใช้หน้าดังกล่าวรวดเร็วกว่าการใช้
การกระจายประสบการณ์ LCP เปอร์เซ็นไทล์ที่ 75 ของทุกหน้า โดยแจกแจงว่าหน้าเว็บใช้การโหลดแบบ Lazy Loading ของรูปภาพดั้งเดิม (แหล่งที่มา)

ค่ามัธยฐานของหน้าเว็บที่ไม่มีการโหลดแบบ Lazy Loading มี LCP เปอร์เซ็นไทล์ที่ 75 เท่ากับ 2,922 มิลลิวินาที เมื่อเทียบกับ 3,546 มิลลิวินาทีสำหรับหน้าเว็บที่มีการโหลดแบบ Lazy Loading โดยรวมแล้ว เว็บไซต์ที่ใช้การโหลดแบบ Lazy Loading มีแนวโน้มที่จะมีประสิทธิภาพ LCP แย่ลง

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

แผนภูมิ Box และ Whisker แสดงเปอร์เซ็นไทล์ที่ 10, 25, 75 และ 90 สำหรับหน้า WordPress ที่ใช้และไม่ได้ใช้การโหลดแบบ Lazy Loading เนทีฟ ในเชิงเปรียบเทียบ การกระจาย LCP ของหน้าที่ไม่ได้ใช้หน้าดังกล่าวจะเร็วกว่าการกระจาย LCP ซึ่งคล้ายกับแผนภูมิก่อนหน้า
การกระจายประสบการณ์ LCP เปอร์เซ็นไทล์ที่ 75 ของหน้าเว็บ WordPress โดยแจกแจงว่าหน้าเว็บใช้การโหลดแบบ Lazy Loading ของรูปภาพดั้งเดิม (แหล่งที่มา)

ขออภัย รูปแบบเดียวกันปรากฏขึ้นเมื่อเราเจาะลึกเข้าไปดูหน้า WordPress หน้าที่ใช้การโหลดแบบ Lazy Loading มีแนวโน้มที่จะมีประสิทธิภาพ LCP ช้ากว่า ค่ามัธยฐานของหน้า WordPress โดยไม่มีการโหลดแบบ Lazy Loading มีเปอร์เซ็นไทล์ที่ 75 LCP เท่ากับ 3,495 มิลลิวินาที เมื่อเทียบกับ 3,768 มิลลิวินาทีสำหรับหน้าเว็บที่มีการโหลดแบบ Lazy Loading

การทำเช่นนี้ยังไม่พิสูจน์ว่าการโหลดแบบ Lazy Loading ทำให้หน้าเว็บช้าลง แต่การใช้การโหลดนี้สอดคล้องกับการที่ประสิทธิภาพช้าลง เราได้สร้างการทดสอบ A/B ในห้องทดลองเพื่อพยายามตอบคำถามเกี่ยวกับความสัมพันธ์ระหว่างเหตุและผล

ประสิทธิภาพโดยทั่วไป

เป้าหมายสำหรับการทดสอบ A/B คือการพิสูจน์หรือหักล้างสมมติฐานที่ว่าการโหลดแบบ Lazy Loading ของรูปภาพแบบเนทีฟที่นำมาใช้ในแอปหลักของ WordPress ทำให้ LCP มีประสิทธิภาพช้าลงและไบต์รูปภาพที่น้อยลง วิธีการที่เราใช้คือการทดสอบเว็บไซต์ WordPress สาธิตการใช้ธีม twentytwentyone เราได้ทดสอบทั้งประเภทที่เก็บถาวรและหน้าเดี่ยว เช่น หน้าแรกและหน้าบทความ ในเดสก์ท็อปและอุปกรณ์เคลื่อนที่จำลองโดยใช้ WebPageTest เราได้ทดสอบชุดหน้าเว็บแต่ละชุดทั้งแบบเปิดใช้และไม่ได้เปิดใช้การโหลดแบบ Lazy Loading และทำการทดสอบแต่ละครั้ง 9 ครั้งเพื่อให้ได้ค่ามัธยฐานของ LCP และจำนวนไบต์รูปภาพ

ซีรีส์ ค่าเริ่มต้น ปิดอยู่ ความแตกต่างจากค่าเริ่มต้น
twentytwentyone-archive-desktop 2,029 คน 1,759 ลดลง 13%
twentytwentyone-archive-mobile 1,657 1,403 ตัว ลดลง 15%
twentytwentyone-single-desktop 1,655 1,726 4%
twentytwentyone-single-mobile 1,352 1,384 2%
การเปลี่ยนแปลงของ LCP (มิลลิวินาที) โดยการปิดใช้การโหลดแบบ Lazy Loading ของรูปภาพแบบเนทีฟในหน้า WordPress ตัวอย่าง

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

โปรดทราบว่าผลกระทบของการปิดใช้การโหลดแบบ Lazy Loading นั้นจริงๆ แล้วทำให้หน้าเดี่ยวๆ เร็วขึ้นเล็กน้อย อย่างไรก็ตาม ความแตกต่างใน LCP จะน้อยกว่าค่าเบี่ยงเบนมาตรฐานของทั้งการทดสอบบนเดสก์ท็อปและอุปกรณ์เคลื่อนที่ 1 รายการ เราจึงระบุว่าความแปรปรวนและพิจารณาการเปลี่ยนแปลงโดยรวมเป็นกลาง เมื่อเปรียบเทียบกันแล้ว ความแตกต่างของหน้าที่เก็บถาวรจะเหมือนกับค่าเบี่ยงเบนมาตรฐาน 2-3 มากกว่า

ซีรีส์ ค่าเริ่มต้น ปิดอยู่ ความแตกต่างจากค่าเริ่มต้น
twentytwentyone-archive-desktop 577 1173 103%
twentytwentyone-archive-mobile 172 378 120%
twentytwentyone-single-desktop 301 850 183%
twentytwentyone-single-mobile 114 378 233%
การเปลี่ยนแปลงจำนวนไบต์ของรูปภาพ (KB) ด้วยการปิดใช้การโหลดแบบ Lazy Loading ของรูปภาพดั้งเดิมในหน้า WordPress ตัวอย่าง

ผลลัพธ์ข้างต้นจะเปรียบเทียบค่ามัธยฐานของจำนวนไบต์รูปภาพ (เป็น KB) สำหรับการทดสอบแต่ละครั้ง อย่างที่คาดไว้ การโหลดแบบ Lazy Loading จะส่งผลดีอย่างชัดเจนสำหรับการลดจำนวนไบต์ของรูปภาพ หากผู้ใช้จริงเลื่อนหน้าเว็บลงทั้งหน้า รูปภาพทั้งหมดจะโหลดเมื่อเข้าสู่วิวพอร์ต แต่ผลลัพธ์เหล่านี้จะแสดงประสิทธิภาพที่ดีขึ้นของการโหลดหน้าเว็บเริ่มต้น

สำหรับการสรุปผลการทดสอบ A/B เทคนิคการโหลดแบบ Lazy Loading ที่ WordPress ใช้นั้นช่วยลดจำนวนไบต์ของรูปภาพได้อย่างชัดเจนมาก แต่จะทำให้ LCP ล่าช้ากว่าเดิม

การทดสอบการแก้ไข

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

ข้อมูลใหม่นี้เราได้สร้างการแก้ไขทดลองที่ช่วยหลีกเลี่ยงการโหลดรูปภาพแบบ Lazy Loading ในครึ่งหน้าบน และทดสอบภายใต้เงื่อนไขเดียวกันกับการทดสอบ A/B ครั้งแรก

ซีรีส์ ค่าเริ่มต้น ปิดอยู่ fix ความแตกต่างจากค่าเริ่มต้น ความแตกต่างจากที่ปิดใช้
twentytwentyone-archive-desktop 2,029 คน 1,759 1,749 ลดลง 14% ลดลง 1%
twentytwentyone-archive-mobile 1,657 1,403 ตัว 1,352 ลดลง 18% ลดลง 4%
twentytwentyone-single-desktop 1,655 1,726 1,676 1% ลดลง 3%
twentytwentyone-single-mobile 1,352 1,384 1,342 ลดลง 1% ลดลง 3%
การเปลี่ยนแปลงใน LCP (มิลลิวินาที) ตามการแก้ไขที่เสนอสำหรับการโหลดแบบ Lazy Loading ของรูปภาพแบบเนทีฟในหน้า WordPress ตัวอย่าง

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

ซีรีส์ ค่าเริ่มต้น ปิดอยู่ fix ความแตกต่างจากค่าเริ่มต้น ความแตกต่างจากที่ปิดใช้
twentytwentyone-archive-desktop 577 1173 577 0% ลดลง 51%
twentytwentyone-archive-mobile 172 378 172 0% ลดลง 54%
twentytwentyone-single-desktop 301 850 301 0% ลดลง 65%
twentytwentyone-single-mobile 114 378 114 0% ลดลง 70%
การเปลี่ยนแปลงจำนวนไบต์ของรูปภาพ (KB) ตามการแก้ไขที่เสนอสำหรับการโหลดแบบ Lazy Loading ของรูปภาพแบบเนทีฟในหน้า WordPress ตัวอย่าง

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

การแก้ไขนี้มีข้อควรระวังบางประการ WordPress กำหนดว่าจะโหลดรูปภาพแบบ Lazy Loading ในฝั่งเซิร์ฟเวอร์หรือไม่ ซึ่งหมายความว่าไม่รู้ข้อมูลใดเกี่ยวกับขนาดวิวพอร์ตของผู้ใช้ หรือไม่ว่ารูปภาพจะโหลดภายในครั้งแรกหรือไม่ ดังนั้นการแก้ไขจึงใช้การเรียนรู้เกี่ยวกับตำแหน่งสัมพัทธ์ของรูปภาพในมาร์กอัปเพื่อคาดเดาว่ารูปภาพจะอยู่ในวิวพอร์ตหรือไม่ กล่าวอย่างเจาะจงคือ หากรูปภาพนั้นเป็นรูปภาพแรกที่แสดงในหน้าเว็บ หรือรูปภาพแรกในเนื้อหาหลัก จะถือว่ารูปภาพอยู่ในครึ่งหน้าบน (หรือใกล้กับภาพ) และจะไม่โหลดแบบ Lazy Loading เงื่อนไขระดับหน้าเว็บ เช่น จำนวนคำในส่วนหัวหรือจำนวนข้อความในย่อหน้าในช่วงต้นของเนื้อหาหลักอาจส่งผลต่อการกำหนดว่ารูปภาพอยู่ภายในวิวพอร์ตหรือไม่ นอกจากนี้ยังมีเงื่อนไขระดับผู้ใช้ที่อาจส่งผลต่อความแม่นยําของการเรียนรู้ด้วย โดยเฉพาะขนาดวิวพอร์ตและการใช้ลิงก์ Anchor ที่เปลี่ยนตำแหน่งการเลื่อนของหน้า ด้วยเหตุผลดังกล่าว คุณจึงควรรับทราบว่าการแก้ไขได้รับการปรับเทียบเพื่อให้ประสิทธิภาพที่ดีในกรณีทั่วไปเท่านั้น และอาจต้องมีการปรับแต่งเพื่อให้ผลลัพธ์เหล่านี้ใช้ได้กับทุกสถานการณ์จริง

การเปิดตัว

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

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

รูปภาพโดย Frankie Lopez ใน Unsplash