Ленивая загрузка

Определение опирается на Google Search Central: руководство описывает отсрочку загрузки некритичного или невидимого содержимого. Для встроенного браузерного механизма HTML Living Standard определяет состояние lazy как ожидание определённых условий перед получением ресурса. ^{[1, 2]}

Кратко

Смысл подхода — изменить время загрузки, сохранив доступ к содержимому. ^[1]
Встроенное loading="lazy" и программная подгрузка — разные способы реализации. ^[3]
Главное изображение первого экрана обычно не следует откладывать. ^[3]
Меньше начальных запросов ещё не означает лучшего отображения страницы: скорость появления содержимого и устойчивость макета проверяют отдельно. ^{[8, 9]}

Происхождение и история термина

До встроенной поддержки в браузерах отложенную загрузку изображений реализовывали программно: обработчиками прокрутки, изменения размеров окна или через Intersection Observer — механизм наблюдения за пересечением элемента с заданной областью. Эти способы описаны в историческом обзоре web.dev; поверх них создавались библиотеки, чтобы разработчикам не приходилось заново писать одинаковую логику. ^[3]

В сентябре 2019 года официальный обзор Chrome уже описывал встроенную загрузку по атрибуту loading, не требующую отдельной библиотеки. ^[6] В марте 2022 года WebKit сообщил о добавлении поддержки loading для изображений в Safari 15.4. ^[7] Это этапы распространения браузерного механизма, а не даты изобретения общей идеи отсрочки.

Изменился способ распределения работы: раньше приложение само решало, когда начать запрос, а в нативном варианте — то есть встроенном в браузер — разработчик задаёт атрибут и передаёт решение браузеру. Современный HTML Living Standard описывает этот механизм через состояния lazy и eager. ^[2] История подхода поэтому шире истории одного плагина или одной версии браузера.

Суть и механизм

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

В HTML — разметке страницы — атрибут loading управляет отсрочкой. Значение lazy разрешает отложить получение, eager задаёт обычное получение без такой отсрочки; при отсутствии или неверном значении действует eager. ^[2] При этом eager не означает повышенного сетевого приоритета: web.dev отдельно различает loading и fetchpriority, подсказку о важности запроса. ^[3]

Браузер может начать запрос до попадания изображения на экран. Стандарт оставляет запас расстояния на усмотрение реализации и предлагает учитывать соединение, прокрутку и устройство. ^[2] Поэтому правило «lazy всегда начинает загрузку строго у границы экрана» неверно. Отсутствие ручной настройки порога в атрибуте также не означает, что порог одинаков во всех браузерах.

Виды и классификации

В руководстве Google выделены встроенная загрузка изображений и iframe, Intersection Observer и библиотеки JavaScript, реагирующие на попадание содержимого в область просмотра. ^[1] Iframe — встроенная в страницу область с другим документом. Для диагностики редакция предлагает дополнительно различать задачи:

Задача	Что откладывается	Что проверить
Галерея после текста	Получение изображений	Появляются ли они вовремя, сохранено ли место
Встроенный документ	Загрузка iframe	Доступен ли блок, когда читатель до него дошёл
Длинный список материалов	Получение следующей порции	Можно ли открыть её отдельно и не потерять элементы

Последний сценарий может использовать бесконечную прокрутку: новые части добавляются по мере движения вниз. Это устройство интерфейса, а ленивая загрузка описывает момент получения данных. Для индексируемого бесконечного списка Google рекомендует отдельные постоянные адреса частей и последовательные ссылки между ними. ^[1] Один атрибут изображения эту навигационную задачу не решает.

Как применяется на практике

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

Под снимки заранее резервируют место, например атрибутами width и height. Они сообщают размеры изображения; без них появление файла может сдвинуть соседний текст. web.dev также разбирает крайний случай: если пустые изображения занимают нулевую площадь, браузер может решить, что вся галерея помещается в видимой области, и запросить её сразу. ^[3]

Для поиска важно, чтобы получение содержимого не зависело от обязательного действия робота. Документация Google прямо говорит, что поиск не нажимает кнопки и не прокручивает страницу как посетитель. ^[1] Российский контекст требует отдельной проверки:

Google	Яндекс
Рекомендует загрузку нужного содержимого при его нахождении в видимой области и проверку итогового HTML. ^[1]	Сообщает о выполнении JavaScript на исходных адресах AJAX-страниц, то есть страниц с динамическим обновлением содержимого. ^[5]
Для проверки изображений указывает наличие URL в src в отрендеренном документе. ^[1]	Для обнаружения адресов в HTML-ссылках учитывает href и рекомендует обычные адреса вместо маршрутов с решёткой. ^[5]

Эти сведения решают разные части задачи. Выполнение JavaScript само по себе не доказывает, что любая кнопка, галерея или бесконечная лента будет обработана одинаково двумя поисковиками.

Как измерить или проверить

Предлагаемая проверка начинается с сетевого журнала. В Chrome DevTools открывают Network и перезагружают страницу: журнал записывает запросы только при открытой панели. Для ресурса видны статус ответа, размер, время и инициатор — причина запроса. Очистка кеша с принудительной перезагрузкой помогает исследовать получение файлов заново, а ограничение скорости — работу при медленном соединении. ^[4]

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

Учебный расчёт: до изменения при начальном открытии запрашивались 20 изображений, после — 5. Уменьшение числа первоначальных запросов составляет (20 − 5) / 20 × 100 = 75 %. В знаменателе стоит исходное число запросов изображений, а не количество всех файлов страницы. Это не означает уменьшение байтов на 75 %: файлы могут иметь разные размеры. Если затем читатель просмотрит всю галерею, отложенные изображения тоже будут запрошены; экономия за весь визит из начального сравнения не следует.

Для отображения нужны другие показатели. LCP, Largest Contentful Paint, отражает время появления крупнейшего учитываемого изображения, текстового блока или видео в видимой области относительно начала перехода. Задержка главного фото может ухудшить этот результат. ^[8] CLS, Cumulative Layout Shift, характеризует неожиданные перемещения элементов; показатель учитывает наибольшую сумму оценок в группе близких по времени сдвигов. ^[9] Поздняя картинка без отведённого места может поэтому ухудшить устойчивость макета независимо от числа запросов. ^{[3, 9]}

Проверку браузера дополняют проверкой поиска. Google предлагает исследовать отрендеренный HTML в инструменте проверки URL Search Console. ^[1] Найденный там адрес изображения подтверждает доступность в этом представлении; подсчёт запросов в личном браузере отвечает на другой вопрос.

Ошибки, ограничения и спорные вопросы

Нельзя механически добавлять lazy ко всем изображениям: браузеру сначала нужно определить их положение, и это может задержать важную картинку первого экрана. ^[3] Также не следует считать атрибут гарантией экономии: часть ресурсов окажется достаточно близко для ранней загрузки.

Есть существенная особенность нативного механизма: по алгоритму HTML при отключённых скриптах отсрочка не применяется. Это мера против отслеживания прокрутки по последовательности запросов изображений. ^[2] Она не равна поломке загрузки и не описывает поведение любой сторонней библиотеки. Наличие механизма в стандарте тоже не заменяет проверку поддержки нужного элемента в целевых браузерах.

LCP нельзя использовать как измеритель появления всех нижних фотографий. Описанный в web.dev механизм прекращает выдавать новые записи после взаимодействия пользователя, в том числе прокрутки. ^[8] Для галереи после текста полезно дополнительно наблюдать фактическое время появления снимков и пустые промежутки при просмотре. Учебное уменьшение запросов имеет смысл только вместе с такими наблюдениями.

Частые вопросы

Ленивая загрузка удаляет изображение из поиска?

Сам подход этого не означает. Ошибочная реализация может сделать содержимое недоступным для обработки Google. ^[1]

Нужна ли библиотека для обычных изображений?

Браузерный loading позволяет реализовать отсрочку без отдельной библиотеки; соответствие конкретного решения задаче всё равно проверяют. ^[3]

Почему lazy-изображение загрузилось до прокрутки?

Оно могло оказаться внутри предусмотренного браузером запаса расстояния. Стандарт не задаёт один обязательный порог. ^[2]

Достаточно ли меньшего числа запросов?

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

Решить с помощью сервиса

«SEO-проверка» выполняет проверку одной страницы и включает данные скорости PageSpeed/Lighthouse. Инструмент работает внутри холдинга и готовится к открытию внешним пользователям; эти данные дополняют ручную проверку сценария, но не доказывают индексирование каждого изображения.

Сервисы MEDIATRONE →

Связанные термины

Источники

Google. (2025, December 10). Fix lazy-loaded content. Google Search Central. https://developers.google.com/search/docs/crawling-indexing/javascript/lazy-loading (дата обращения: 30.10.2026). ↑ а б в г д е ж з и
WHATWG. (2026, October 26). HTML Living Standard. § 2.5.7: Lazy loading attributes. https://html.spec.whatwg.org/multipage/urls-and-fetching.html#lazy-loading-attributes (дата обращения: 30.10.2026; дата обновления открытого текста). ↑ а б в г д е
Osmani, A., Djirdeh, H., Bynens, M., & Pollard, B. (n.d.). Browser-level image lazy loading for the web. web.dev. https://web.dev/articles/browser-level-image-lazy-loading (дата обращения: 30.10.2026). ↑ а б в г д е ж з
Basques, K. (2024, October 14). Inspect network activity. Chrome DevTools. https://developer.chrome.com/docs/devtools/network/ (дата обращения: 30.10.2026). ↑
Яндекс. Индексирование AJAX-сайтов // Справка Вебмастера. Б. д. URL: https://yandex.ru/support/webmaster/ru/robot-workings/ajax-indexing (дата обращения: 30.10.2026). ↑ а б
LePage, P. (2019, September 16). New in Chrome 77. Chrome for Developers. https://developer.chrome.com/blog/new-in-chrome-77 (дата обращения: 30.10.2026). Исторический источник, раздел Native lazy loading. ↑
Simmons, J., & Davis, J. (2022, March 14). New WebKit features in Safari 15.4. WebKit. https://webkit.org/blog/12445/new-webkit-features-in-safari-15-4/ (дата обращения: 30.10.2026). Исторический источник, раздел HTML. ↑
Walton, P., & Pollard, B. (2019, August 8; updated 2025, September 4). Largest Contentful Paint (LCP). web.dev. https://web.dev/articles/lcp (дата обращения: 30.10.2026). ↑ а б в
Mihajlija, M., & Walton, P. (n.d.). Cumulative Layout Shift (CLS). web.dev. https://web.dev/articles/cls (дата обращения: 30.10.2026). ↑ а б в