Какво всъщност прави lazy loading с вашия Largest Contentful Paint

Lazy loading е решение за планиране, не магия за скорост

Lazy loading често се описва като подобрение на производителността, което е вярно по същия начин, по който неопаковането на куфар намалява теглото. Помага, защото браузърът върши по-малко работа в началото.

Това разграничение е важно за Largest Contentful Paint, обикновено съкращаван до LCP. LCP измерва кога се визуализира най-големият смислен елемент във viewport-а. На много страници този елемент е hero изображение. На други е голямо заглавие, poster image, продуктова снимка или съдържателен блок.

Lazy loading променя момента, в който се заявяват ресурсите. Той не кара изображението да се декодира по-бързо, сървъра да отговори по-бързо или шрифта да се изобрази по-рано. Ако приложите lazy loading върху грешното нещо, особено върху елемента, който става LCP, казвате на браузъра да изчака, преди да изтегли точно това, което трябва да покаже, за да премине Core Web Vitals.

Затова lazy loading едновременно се използва прекомерно и се разбира недостатъчно.

Какво прави браузърът, когато използвате lazy loading за изображение

Нативният lazy loading за изображения обикновено се добавя така:

<img src='hero.jpg' loading='lazy' alt='...'>

С loading='lazy' браузърът има право да отложи изтеглянето на изображението, докато прецени, че то вероятно ще бъде нужно. На практика браузърите използват разстояние от viewport-а, мрежови условия, размери на изображението и други евристики. Точните правила са детайли на имплементацията и могат да се променят.

С loading='eager', или без lazy атрибут в повечето случаи, браузърът третира изображението като част от нормалния процес на зареждане. Той все още трябва да приоритизира между CSS, JavaScript, шрифтове, изображения и други заявки, но изображението е откриваемо веднага.

Това означава, че lazy loading засяга основно три фази:

• Откриване: кога браузърът забелязва ресурса.
• Начало на заявката: кога започва мрежовото изтегляне.
• Момент на рендериране: кога ресурсът най-накрая може да бъде декодиран и изрисуван.

За LCP опасната фаза е началото на заявката. Ако заявката за LCP изображението започне късно, всичко след нея също се измества късно.

Простото правило: никога не използвайте lazy loading за LCP кандидата

Ако дадено изображение е видимо в началния viewport и вероятно ще бъде най-големият contentful елемент, не го зареждайте с lazy loading.

Това включва:

• hero изображения
• основни продуктови снимки над сгъвката
• големи водещи изображения в статии
• големи изображения, подобни на фон, имплементирани като <img>
• video poster изображения, когато poster-ът е основният визуален елемент

Браузърът не може да рендерира LCP изображението, докато то не бъде заявено, прехвърлено, декодирано и изрисувано. Lazy loading внася несигурност преди първата стъпка. Дори малко забавяне може да е достатъчно, за да премести LCP от приемлив към лош при по-бавна връзка.

Често срещан модел на проблем изглежда така:

1. Сървърът изпраща HTML.
2. Браузърът парсва изображение над сгъвката.
3. Изображението има loading='lazy'.
4. Браузърът изчаква, защото евристиката за lazy loading казва, че може.
5. CSS и JavaScript продължават да се зареждат.
6. Заявката за изображението започва по-късно, отколкото трябва.
7. LCP закъснява, въпреки че самият файл на изображението е разумно оптимизиран.

Това е неприятно, защото страницата може да изглежда подредена при code review. Проблемът не е само в размера на файла. Проблемът е в приоритета.

Ако четете резултати от лабораторен инструмент и се опитвате да разберете дали LCP наистина е проблемът, нашето ръководство за четене на Lighthouse отчет без паника е нарочно практично: разделете field data, лабораторните подсказки и поправките, преди да започнете да променяте код. (Бележка: ако routing-ът ви е case-sensitive, използвайте точния URL от вашата CMS.)

Корекция: използвайте действителния вътрешен URL

Правилният URL на статията в Wux е Как да четете Lighthouse отчет без паника. Изводът остава: идентифицирайте LCP елемента, преди да променяте поведението на зареждане.

Кога lazy loading може да подобри LCP

Lazy loading може да подобри LCP косвено, когато държи некритичните ресурси извън пътя на браузъра.

Представете си продуктова страница с hero продуктово изображение най-горе и carousel с дванадесет препоръчани изображения под сгъвката. Ако всички тринадесет изображения се зареждат eager, браузърът може да изразходва bandwidth и connection slots за изображения, които потребителят още не може да види. При ограничена мрежа това може да се конкурира с hero изображението, CSS или файловете с шрифтове.

Lazy loading на изображенията в carousel-а под сгъвката може да помогне на LCP изображението да се зареди по-рано, защото по-малко некритични заявки се конкурират по време на първоначалното зареждане на страницата.

Това е легитимният performance случай за lazy loading:

• зареждайте eager LCP кандидата над сгъвката
• зареждайте с lazy loading изображенията под началния viewport
• избягвайте тежки скриптове, които инжектират важни изображения късно
• дръжте размерите на изображенията в HTML, за да избегнете layout shifts

Lazy loading сам по себе си не е LCP оптимизация. Той е инструмент за приоритизация на ресурси. Помага, когато защитава критичния път.

По-добрият модел за LCP изображения

За LCP изображение над сгъвката целта е браузърът да го открие рано, да го заяви рано и да го рендерира без layout instability.

Солидна базова версия изглежда така:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

Важните части не са декоративни:

• loading='eager' предотвратява забавянето от lazy loading.
• fetchpriority='high' казва на браузъра, че това изображение е важно.
• width и height резервират място и намаляват layout shift.
• srcset и sizes предотвратяват изтеглянето на прекалено големи файлове.
• Модерен формат може да намали времето за прехвърляне, когато се използва внимателно.

Ако все още сервирате един голям JPEG към всеки екран, форматът на изображението и responsive оразмеряването може да са по-важни от атрибута за lazy loading. За практично дърво на решения вижте кога AVIF побеждава WebP и кога не.

Background изображенията изискват допълнително внимание

CSS background изображенията не се откриват толкова рано, колкото нормалните HTML изображения. Браузърът трябва да изтегли и парсне CSS, преди да разбере за тях. Ако вашият LCP елемент е CSS background image, вече сте направили откриването по-трудно.

Това не означава, че background изображенията са забранени. Означава, че трябва да сте целенасочени.

За декоративни изображения CSS backgrounds са напълно подходящи. За смислена hero визия елемент <img> или <picture> обикновено е по-добър, защото е видим за HTML parser-а, поддържа alt текст и работи добре с атрибути за responsive images.

Ако трябва да използвате CSS background за LCP изображение, помислете за preload:

<link rel='preload' as='image' href='/images/hero.avif'>

Preload също не е магическа пръчка. Preload на твърде много изображения създава същия проблем с приоритета в различна премяна. Използвайте го за едното изображение, което наистина има значение, не за всяко изображение в design system-а.

JavaScript lazy loading често влошава нещата

Преди нативният lazy loading да бъде широко поддържан, много сайтове използваха JavaScript библиотеки, които заменяха data-src със src след зареждане на страницата или след задействане на intersection observer. Някои все още го правят.

Това може да е разумно за дълги статии или галерии с много изображения. Това е лош избор за съдържание над сгъвката.

Browser preload scanner-ът е бърз, но не може да заяви изображение, чийто URL е скрит в custom attribute, докато JavaScript не се изпълни. Ако вашето hero изображение започва като data-src='hero.jpg', сте забавили откриването зад изтегляне на скрипт, парсване, изпълнение и framework hydration.

Това е лош компромис за LCP. Поставяйте критичните URL адреси на изображения в реален HTML. Оставете браузъра да си свърши работата.

LCP не винаги е проблем с изображения

На някои страници LCP елементът е текст. В такъв случай lazy loading на изображения може да има малък директен ефект. Тясното място може да е render-blocking CSS, бавен отговор от сървъра, client-side rendering или web fonts.

Шрифтовете си струва да се споменат, защото често са скрита причина за късно рендериране на текст. Голямо заглавие може да стане LCP, а поведението при зареждане на шрифтове може да забави или промени момента, в който това заглавие се изрисува. Ако работата по изображенията не променя метриката, инспектирайте директно LCP елемента, вместо да предполагате. Нашата статия за web fonts като печалба за производителността покрива скучните поправки, които често работят: по-малко начертания, модерни формати, разумни fallback-и.

Как да тествате промени в lazy loading, без да се самозаблуждавате

Не тествайте, като просто гледате страницата си през офисния Wi-Fi. Трябва да видите timing-а на заявките.

Използвайте този workflow:

1. Отворете Chrome DevTools и запишете Performance trace.
2. Активирайте network throttling, например Fast 4G или Slow 4G.
3. Презаредете страницата с изключен cache.
4. Намерете LCP marker-а.
5. Идентифицирайте LCP елемента.
6. В Network панела проверете кога този ресурс е започнал да се зарежда.

Ако LCP ресурсът започва късно, попитайте защо:

• Беше ли зареден с lazy loading?
• Беше ли инжектиран от JavaScript?
• Беше ли скрит в CSS?
• Беше ли deprioritized зад други изображения?
• Сървърът отговори ли бавно?

След това направете една промяна и тествайте отново. Работата по производителността става хаотична, когато екипите променят формат на изображения, lazy loading, preloading, JavaScript bundles и CDN настройки в едно и също deployment. Може да подобрите страницата, но няма да знаете коя промяна е имала значение.

Field data също има значение. Lab tools са полезни за диагностика, но LCP варира според устройство, мрежа, viewport, cache state и география. Използвайте real-user monitoring или данни от Chrome User Experience Report, когато можете.

<!-- tool-cta:start -->

💡 Опитайте това: Поддържайте LCP изображението си малко и заредено с приоритет, като го обработите чрез Image Compressor, за да се визуализира бързо, без да е необходимо отложено зареждане.

<!-- tool-cta:end -->

Практична политика за повечето уебсайтове

За повечето marketing сайтове, ecommerce страници, documentation сайтове и publisher страници тази политика е достатъчна:

• Основно изображение над сгъвката: eager load, обмислете high fetch priority.
• Content изображения под сгъвката: lazy load.
• Икони и малки UI assets: обикновено не си струва да се мислят поотделно.
• CSS background hero: преосмислете като HTML image или preload-нете внимателно.
• JavaScript-injected hero image: поправете rendering architecture, ако е възможно.
• Carousels: eager load само на първия видим slide; lazy load за останалите.

Има edge cases. Евристиките на браузърите се подобряват. Framework-ите добавят автоматични image components. Някои платформи вече избягват lazy loading за изображения, засечени близо до viewport-а. И все пак принципът не се променя: критичните ресурси трябва да са ранни и очевидни; некритичните ресурси трябва да чакат.

Lazy loading е ценен, когато изразява това разграничение. Вреден е, когато скрива най-важното съдържание от браузъра, докато страницата вече е започнала да губи състезанието за LCP.