Lazy load: как измерить и улучшить производительность сайта

Представьте интернет-магазин с длинной карточкой товара: главное фото, характеристики, десять фотографий галереи, отзывы, видео, похожие товары и карта пункта выдачи. Посетитель открывает страницу и пока видит только верхнюю часть. Если браузер сразу бросится загружать вообще всё, получится цифровой вариант официанта, который приносит одновременно салат, суп, десерт и счёт.

Lazy load решает более простую задачу: откладывает загрузку того, что пока не нужно. Фотографии, iframe и другие тяжёлые элементы ниже экрана могут подождать, а ресурсы первого экрана получают меньше конкурентов за сеть и обработку.

Но есть важная оговорка: lazy load — это техника загрузки, а не показатель производительности. Её нельзя оценивать по принципу «включили — значит сайт стал быстрее».

Что именно делает lazy load

В простом случае браузеру достаточно указать, что изображение можно загрузить лениво:

<img
  src="product-gallery-08.webp"
  loading="lazy"
  width="800"
  height="600"
  alt="Деталь товара крупным планом"
>

Современные браузеры умеют обрабатывать такую загрузку самостоятельно. Для изображений вне начальной области просмотра web.dev рекомендует использовать lazy loading, а изображения, которые пользователь видит сразу после открытия страницы, загружать без него.

То есть правило лучше формулировать не как «lazy load нужен картинкам», а так:

ресурс важен сейчас — загружаем сейчас; понадобится позже — можем отложить.

Это принципиальная разница.

Главная ошибка: включить lazy load на всём сайте одним рубильником

Самая неприятная ситуация возникает, когда отложенную загрузку получает главное изображение первого экрана.

Допустим, карточка дивана открывается с крупной фотографией товара. Именно она оказывается самым большим видимым элементом страницы. Если пометить её loading="lazy", браузер сначала должен разобраться с расположением элемента и только затем начать загрузку. В результате технология, которую установили «для ускорения», способна задержать LCP.

Google в рекомендациях по оптимизации LCP прямо советует не применять lazy loading к LCP-изображению: такой ресурс должен обнаруживаться как можно раньше. Для важного изображения также может использоваться высокий приоритет загрузки.

Для владельца сайта отсюда следует простое правило:

Элемент страницы	Lazy load
Главное фото или баннер первого экрана	Обычно нет
Основная фотография товара	Обычно нет, если видна сразу
Галерея ниже первого экрана	Да
Изображения в длинной статье	Да, если находятся ниже
Карта или видео в конце страницы	Обычно да
Логотип в шапке	Нет смысла откладывать
Большой фон первого экрана	Требует отдельной проверки

Lazy load и SEO: проблема не в самом механизме

Lazy load иногда описывают почти как отдельный SEO-фактор. Это слишком смелое упрощение.

Google действительно использует Core Web Vitals в системах ранжирования, а LCP относится к основным метрикам пользовательского опыта. При этом сама Google отдельно подчёркивает: хорошие показатели Core Web Vitals не гарантируют высоких позиций, а удобство страницы нельзя свести к одному числу.

Поэтому логика такая:

lazy load → может изменить загрузку страницы → это может изменить пользовательские метрики → но из этого не следует автоматическое «включили lazy load — выросли позиции».

Подробнее границу между подтверждённым фактором, наблюдением и гипотезой полезно учитывать при оценке факторов ранжирования сайта.

Есть и другая SEO-сторона — доступность содержимого поисковому роботу.

Google предупреждает, что основной контент не должен появляться только после действий вроде клика, свайпа или другого взаимодействия. Для lazy-loaded элементов рекомендуются механизмы, которые автоматически загружают содержимое, когда оно приближается к области просмотра. Search Console позволяет проверить, появилось ли такое содержимое в отрендеренном HTML.

Если проблема уже касается того, какие URL и содержимое реально попадают в поиск, полезно отдельно проверить страницы в индексе, а не пытаться лечить всю индексацию одним атрибутом loading.

Как проверить lazy load без профессии фронтенд-разработчика

Владельцу бизнеса необязательно начинать с чтения JavaScript.

Сначала возьмите несколько реальных типов страниц, а не одну удобную главную:

• карточку товара;
• категорию с большим количеством изображений;
• статью;
• страницу услуги;
• длинный лендинг.

Проверьте их в PageSpeed Insights или Lighthouse. Нас интересует не только итоговый балл, а то, какой элемент стал LCP и не загружается ли он лениво. Lighthouse отдельно умеет указывать ситуацию, когда LCP-изображение получило lazy loading.

Затем откройте DevTools → Network и перезагрузите страницу. Если всё настроено разумно, не должно происходить двух крайностей:

1. браузер сразу скачивает каждую фотографию из огромной нижней галереи;
2. главное изображение перед глазами пользователя почему-то ждёт своей очереди.

Это намного полезнее, чем радоваться зелёному баллу на одной странице и считать оптимизацию законченной.

Что происходит в WordPress

Для WordPress установка отдельного «lazy load плагина» давно не является обязательным первым шагом.

Нативная поддержка loading="lazy" появилась в WordPress 5.5. Позже ядро получило более аккуратную логику: WordPress старается не назначать lazy loading изображениям, которые предположительно находятся в области первого экрана, а для важного изображения может использовать fetchpriority="high". Текущая документация также подчёркивает, что сочетать loading="lazy" и fetchpriority="high" на одном изображении не следует.

Но слово «автоматически» здесь не означает «проверять больше нечего».

Тема, конструктор страниц, галерея, CDN или оптимизационный плагин могут вмешаться в HTML. Особенно подозрительно выглядит ситуация, когда сразу несколько средств оптимизации пытаются управлять одной картинкой. Это примерно как поставить двух диспетчеров на один перекрёсток и удивиться, почему движение стало интереснее, но не быстрее.

Поэтому на WordPress сначала проверяют фактический HTML и загрузку страницы, а уже потом добавляют очередной плагин.

Отдельная история — фоновые изображения

Для обычного <img> существует нативный атрибут loading. С CSS-фонами всё не так просто.

Если большое изображение задано как background-image, браузеру приходится сначала получить и обработать CSS, прежде чем он обнаружит этот ресурс. Для важного изображения первого экрана это способно создавать дополнительную задержку. web.dev рекомендует по возможности использовать обычный <img> для LCP-кандидата либо отдельно обеспечивать его раннее обнаружение.

А вот декоративный фон блока, который находится далеко внизу страницы, наоборот, может быть хорошим кандидатом на отложенную загрузку.

То есть вопрос снова не «фон это или картинка», а когда ресурс действительно понадобится человеку.

Пример: интернет-магазин после «ускорения» стал загружать главный товар позже

Представим карточку товара.

На первом экране находятся название, цена, кнопка покупки и большая фотография товара. Ниже — шесть дополнительных изображений, видеообзор, отзывы и карта магазинов.

Разработчик включает lazy load сразу для всех картинок. Формально задача выполнена: атрибут есть, аудит показывает меньше ранних запросов. Но главное фото теперь начинает загружаться позднее. Для покупателя страница выглядит странно: цена уже появилась, кнопка есть, а сам товар ещё «едет».

Правильнее разделить ресурсы:

• главное фото — загружать сразу;
• дополнительные фотографии — отложить;
• видео ниже страницы — отложить;
• карту — отложить до приближения пользователя;
• размеры изображений оставить в HTML, чтобы браузер заранее резервировал место.

После изменения нужно снова проверить LCP, сетевую последовательность и страницу на мобильном устройстве. Если картинки снизу перестали мешать начальной загрузке, а главный визуальный элемент не стал появляться позже, настройка движется в правильную сторону.

Если же сайт тормозит даже после нормальной работы с изображениями, причина может быть вообще в другом месте: сервере, PHP, базе данных, тяжёлом JavaScript или сторонних сервисах. В таком случае стоит диагностировать, что именно тормозит сайт и хостинг, вместо бесконечной перестановки атрибута lazy.

Что считать хорошим результатом

У lazy load нет правильного количества картинок, универсального процента экономии или магической оценки PageSpeed.

Хороший результат выглядит прозаичнее:

первый экран получает важные ресурсы вовремя, тяжёлое содержимое ниже страницы не создаёт лишней конкуренции, макет не прыгает, а поисковый робот способен увидеть релевантный контент.

Именно поэтому оптимизацию стоит оценивать на реальных страницах сайта и по нескольким данным сразу. Lazy load — полезный инструмент, пока он управляет очередью. Когда его превращают в правило «отложить всё», он начинает решать проблему, которую сам же и создал.

Если скорость уже влияет на несколько типов посадочных страниц и приходится разбирать не только картинки, но и сервер, шаблоны, JavaScript, индексацию и Core Web Vitals, это уже задача комплексного SEO-продвижения сайта, а не установки очередной галочки в плагине.