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

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

Felix Arntz

Rick Viscomi

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

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

การรับเลี้ยงบุตรบุญธรรม

จากข้อมูลล่าสุดใน HTTP Archive พบว่าเว็บไซต์29% ใช้การโหลดแบบ Lazy Loading ของรูปภาพในตัว และการใช้งานก็เพิ่มขึ้นอย่างรวดเร็ว

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

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

ประสิทธิภาพแบบเชิงสัมพันธ์

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

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

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

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

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

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

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

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

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

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

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

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

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

จากข้อมูลใหม่นี้ เราจึงได้สร้างการแก้ไขเวอร์ชันทดลองที่หลีกเลี่ยงการโหลดแบบเลื่อนลงเมื่อผู้ใช้เลื่อนหน้าเว็บ ซึ่งได้ทดสอบการแก้ไขภายใต้เงื่อนไขเดียวกับการทดสอบ A/B ครั้งแรก

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

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

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

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

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

การใช้งาน

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

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

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 ล่าสุดและบันทึกคําเตือนหากมีการโหลดแบบเลื่อนเวลา

นอกจากนี้ ยังแสดงให้เห็นถึงข้อดีของเทคนิคการโหลดแบบเลื่อนเวลาและโอกาสในการปรับปรุง API ที่ระดับแพลตฟอร์ม เช่น มีปัญหาที่ยังไม่ได้รับการแก้ไขใน Chromium เพื่อทดสอบกับการโหลดรูปภาพ 2-3 รูปแรกอย่างตั้งใจ คล้ายๆ กับการแก้ไข แม้จะมีแอตทริบิวต์ loading ก็ตาม

บทสรุป

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

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

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