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

Представьте интернет-магазин с 48 карточками товаров. На экране покупателя сейчас помещается восемь. Заставлять его телефон немедленно скачивать фотографии остальных сорока — примерно как выкатывать к кассе весь склад, когда человек пришёл купить одну пару обуви.

Для этого и нужна ленивая загрузка. Браузер откладывает получение части изображений, iframe и других некритичных ресурсов до момента, когда они приближаются к видимой области страницы.

Но здесь есть важная оговорка: lazy loading ускоряет сайт не тогда, когда его «включили везде», а когда правильно разделили ресурсы на нужные сейчас и нужные потом.

Что именно даёт ленивая загрузка бизнес-сайту

Главная выгода довольно приземлённая: при открытии страницы не нужно немедленно передавать всё её содержимое.

Возьмём страницу агентства недвижимости. Сверху находится фотография квартиры, цена и кнопка связи, а ниже — ещё 24 фотографии, карта и встроенное видео. Посетителю сначала нужны первые сведения об объекте. Нет смысла одновременно с ними загружать всю фотосессию, карту и видеоплеер, если половина людей до них вообще не доскроллит.

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

Это особенно заметно на:

• каталогах товаров;
• портфолио с большим количеством фотографий;
• страницах объектов недвижимости;
• длинных статьях с иллюстрациями;
• страницах с картами, видео и внешними виджетами.

Если же страница тяжёлая вообще по другой причине — например, сервер долго формирует HTML или блокирующие скрипты съедают время до отрисовки, — одна ленивая загрузка проблему не вылечит. Тогда полезнее начинать с общего разбора скорости сайта, а серверную задержку отдельно сопоставлять с TTFB на практике.

Главная ошибка: сделать ленивым то, что посетитель должен увидеть сразу

Вот здесь оптимизация чаще всего превращается в анекдот.

Компания продаёт кухни. На первом экране красивый интерьер, предложение и форма расчёта стоимости. Кто-то включает lazy loading для всех изображений без исключения. В итоге HTML уже пришёл, заголовок появился, а главное фото кухни ещё ждёт разрешения начать загрузку.

Получается парадокс: механизм, установленный «для ускорения сайта», задержал самый заметный элемент страницы.

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

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

Элемент	Обычно разумная стратегия
Главная фотография/hero первого экрана	загружать сразу
Логотип и важные изображения в шапке	не откладывать без причины
Фотографии значительно ниже первого экрана	lazy loading
Галерея из десятков дополнительных фото	lazy loading для последующих изображений
Карта или видео далеко внизу страницы	часто можно отложить
Изображение, которое является LCP	не использовать lazy loading

Для обычного изображения ниже первого экрана нативная разметка может выглядеть так:

<img
  src="/images/project-12.webp"
  loading="lazy"
  width="800"
  height="600"
  alt="Готовый проект кухни"
>

А главный визуал страницы логичнее оставить доступным браузеру сразу:

<img
  src="/images/hero-kitchen.webp"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="Кухня на заказ"
>

width и height здесь не косметика. Размеры помогают браузеру заранее оставить изображению место, чтобы после загрузки фотографии текст и кнопки не прыгнули вниз.

Как проверить ленивую загрузку, а не просто поверить настройке плагина

Надпись «Lazy Load: ON» в панели управления доказывает примерно столько же, сколько наклейка «Turbo» на багажнике автомобиля.

Проверять нужно поведение страницы.

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

Затем прокрутите страницу. Нужные изображения должны начинать подгружаться немного заранее или при приближении к области просмотра — конкретный порог браузер может определять самостоятельно.

После этого сравните страницу до и после изменения в PageSpeed Insights или Lighthouse. Смотрите не на красивую общую оценку, а прежде всего на то, не ухудшился ли LCP первого экрана и не появились ли скачки макета.

И обязательно проверяйте реального посетителя. Если после «ускорения» у человека сначала появляется пустое место вместо баннера, а фотография приезжает через секунду, спор с лабораторным баллом уже бессмысленен.

Внешние ресурсы могут создавать отдельные задержки. Например, если первый экран зависит от шрифтов или файлов с другого домена, это уже другая задача; её стоит разбирать отдельно, например через preconnect на практике, а не пытаться лечить всё одним lazy loading.

Что ленивая загрузка меняет для SEO

Отдельной медали «использует lazy loading» поисковая система сайту не выдаёт.

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

Связь здесь практическая.

Правильно отложенные второстепенные изображения могут уменьшить ненужную работу при первоначальной загрузке. Ошибочно отложенное главное изображение способно ухудшить LCP. А неправильно реализованный JavaScript lazy loader может создать ещё более неприятную проблему — поисковая система не увидит часть содержимого.

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

Если изображения или другой значимый контент появляются только после пользовательского действия, необходимо проверить отрисованную версию URL в Search Console. Для изображений безопаснее сохранять нормальную понятную разметку, а не превращать реальный адрес файла в секрет, который JavaScript раскроет только после нескольких событий.

Поэтому lazy load — это не отдельная SEO-магия, а один из инструментов управления ресурсами страницы.

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

Три примера, где решение будет разным

Интернет-магазин

На странице категории 48 товаров. Покупатель при открытии видит только первые карточки.

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

Сайт застройщика

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

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

Карточка квартиры с большой галереей

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

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

Во всех трёх случаях технология одна, но правило «поставить lazy на каждую картинку» дало бы разные, а иногда противоположные результаты.

Не превращайте lazy loading в коллекцию плагинов

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

Поэтому установка ещё одного плагина только потому, что в его названии написано Lazy Load, — не первый шаг.

Сначала проверьте текущий HTML. Возможно, нужная механика уже работает. Затем выясните, какие изображения действительно загружаются слишком рано и какое изображение формирует первый экран. После изменения повторите тот же тест.

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

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