Ленивая загрузка изображений: польза и риски для SEO
Ленивая загрузка — одна из немногих оптимизаций, которую можно внедрить одной строкой в шаблоне и получить измеримый прирост скорости. И одна из немногих, которой так же легко себе навредить: тот же самый атрибут, поставленный на картинку первого экрана, ухудшает LCP на сотни миллисекунд, а неверная реализация через JavaScript способна полностью спрятать изображения от поискового робота. Разница между «сайт стал быстрее» и «половина товарных фото выпала из поиска по картинкам» — это буквально два-три технических решения на этапе вёрстки. В этой статье разбираем механику lazy loading так, как мы применяем её на проектах в рамках SEO-продвижения: где ленивая загрузка даёт выигрыш, где она вредит, как её правильно размечать и как потом проверить, что робот действительно видит все картинки.
Коротко
- Нативный loading="lazy" поддерживается всеми актуальными браузерами и роботами — это база, скриптовые решения нужны только для нестандартных задач.
- Ленивая загрузка не ускоряет LCP сама по себе: она освобождает канал и снижает вес первого экрана, а выигрыш забирают элементы, которые грузятся приоритетно.
- Картинка LCP-элемента никогда не должна быть lazy — это самая частая и самая дорогая ошибка внедрения.
- Опасность для индексации создаёт не сам lazy, а подмена src на data-src без корректного отката: робот видит пустой тег или заглушку.
- Обязательный минимум разметки: width и height (или aspect-ratio), alt, decoding="async", для LCP-картинки — fetchpriority="high".
- Проверять нужно тремя способами: рендер страницы глазами робота, отчёты в Вебмастере и Search Console, поиск по картинкам через оператор site:.
- Ленивую загрузку стоит распространять на iframe, видео и тяжёлые виджеты — там выигрыш обычно больше, чем на самих изображениях.
Что такое ленивая загрузка и как она устроена внутри браузера
Ленивая загрузка (lazy loading) — это откладывание запроса ресурса до момента, когда он реально понадобится пользователю. Применительно к изображениям это значит: браузер не скачивает картинку, находящуюся за пределами видимой области, пока пользователь не приблизится к ней прокруткой. На длинной странице каталога с 60 товарами это разница между 60 сетевыми запросами при загрузке и 8–12.
Исторически задачу решали скриптами: в атрибут src ставили однопиксельную заглушку, реальный адрес прятали в data-src, а JavaScript при прокрутке подменял значения. Такая схема работает, но именно она породила все проблемы с индексацией, о которых пойдёт речь ниже. С 2019–2020 годов появился нативный механизм — атрибут loading у тегов img и iframe, который поддерживают все актуальные версии Chrome, Firefox, Safari и Edge. Сегодня скриптовые библиотеки оправданы только там, где нужна тонкая логика: предзагрузка за N экранов, ленивая подгрузка фоновых изображений из CSS, ленивая инициализация сторонних виджетов.
Три значения атрибута loading
- loading="lazy" — отложить загрузку до приближения к области видимости. Значение по умолчанию для всего, что заведомо ниже сгиба.
- loading="eager" — загружать немедленно, не откладывая. Это поведение браузера по умолчанию, но указывать явно полезно: так вы фиксируете намерение и защищаетесь от плагинов, которые массово навешивают lazy на все теги.
- Отсутствие атрибута — эквивалент eager, но с оговоркой: многие CMS и оптимизирующие плагины автоматически дописывают lazy ко всем картинкам без атрибута. То есть «ничего не указать» ≠ «оставить как есть».
Порог срабатывания: почему картинка появляется заранее
Браузер не ждёт, пока изображение окажется точно в кадре, — он начинает загрузку заранее, за некоторое расстояние до границы вьюпорта. Это расстояние не фиксировано стандартом и зависит от реализации: браузеры используют динамический порог, который увеличивается при медленном соединении и уменьшается при быстром. На практике это сотни, а иногда и больше тысячи пикселей запаса. Именно поэтому при обычной прокрутке пользователь чаще всего не видит «дырок» и подгрузок — если, конечно, вы не поставили свою логику с нулевым порогом через IntersectionObserver.
ЧТО ЛЕНИВАЯ ЗАГРУЗКА НЕ ДЕЛАЕТ
Она не уменьшает вес изображений и не заменяет их сжатие. Картинка весом 1,8 МБ останется картинкой весом 1,8 МБ — просто скачается позже. Ленивая загрузка распределяет трафик во времени, а не сокращает его. Порядок работ всегда такой: сначала правильные форматы и размеры, потом отложенная загрузка. Форматы, размеры и alt-атрибуты подробно разобраны в материале про оптимизацию изображений для сайта.
Как lazy loading влияет на Core Web Vitals
Связь между ленивой загрузкой и Core Web Vitals не линейная, и именно здесь чаще всего ошибаются. Разберём по каждой метрике отдельно.
LCP — Largest Contentful Paint
LCP фиксирует момент отрисовки самого крупного видимого элемента первого экрана. В 70–80% случаев на коммерческих сайтах этим элементом оказывается именно картинка: баннер, фото товара, обложка статьи, фон промо-блока. И вот ключевой момент: если LCP-элемент помечен как lazy, вы гарантированно ухудшаете метрику. Механика простая. Браузер обнаруживает обычные картинки на этапе предварительного сканирования HTML и ставит их в очередь загрузки сразу. Ленивая картинка из этой очереди выпадает: сначала должен быть построен layout, посчитано положение элемента, запущена проверка пересечения с вьюпортом — и только потом уходит сетевой запрос. Задержка складывается из времени парсинга, применения CSS и первого layout-прохода, а на медленных устройствах и тяжёлых шаблонах это уже заметная величина.
Обратная сторона: правильно применённая ленивая загрузка LCP улучшает — косвенно. Когда браузер не тянет одновременно 50 изображений, канал и очередь запросов освобождаются для критичных ресурсов: HTML, CSS, шрифтов и той самой главной картинки. На мобильном соединении с ограниченной пропускной способностью эффект особенно заметен: конкуренция за полосу — реальная причина медленного LCP на страницах каталога.
CLS — Cumulative Layout Shift
Ленивая загрузка сама по себе не вызывает сдвигов макета. Их вызывает отсутствие зарезервированного места. Если у тега img не указаны width и height (или CSS-свойство aspect-ratio), браузер до загрузки файла считает высоту элемента нулевой, а после — раздвигает контент. Пользователь в этот момент читает текст, и текст прыгает вниз. С ленивой загрузкой это происходит прямо во время прокрутки, то есть в самый неудобный момент.
Вывод категоричный: lazy без указанных размеров — это гарантированный рост CLS. Атрибуты width и height обязательны всегда, даже если картинка тянется резиновой вёрсткой — браузер использует их только для вычисления соотношения сторон, а фактический размер задаёт CSS.
INP — Interaction to Next Paint
Прямой связи нет, но косвенная есть: скриптовые библиотеки ленивой загрузки на событии scroll без троттлинга нагружают основной поток и увеличивают задержки отклика. Нативный loading="lazy" обрабатывается движком браузера вне JavaScript и на INP не влияет вообще — это ещё один аргумент в его пользу. Подробнее о том, как метрики отзывчивости связаны с общей производительностью, — в статье про скорость загрузки сайта.
| Метрика | Влияние ленивой загрузки | Условие положительного эффекта | Что портит результат |
|---|---|---|---|
| LCP | Косвенно улучшает: освобождает канал и очередь запросов для критичных ресурсов | LCP-картинка загружается eager, желательно с fetchpriority="high" | Lazy на изображении первого экрана: задержка запроса до первого layout |
| CLS | Нейтрально при правильной разметке, резко ухудшает при неправильной | Заданы width и height либо aspect-ratio у контейнера | Картинка без размеров, подгружаемая во время прокрутки |
| INP | Нативная — нейтрально, скриптовая — может ухудшать | Нативный loading="lazy" без обработчиков scroll | Библиотеки на scroll-событиях без троттлинга, тяжёлые эффекты появления |
| TTFB | Не влияет | — | Метрика зависит от сервера, а не от разметки картинок |
| Общий вес страницы | Снижает вес начальной загрузки в разы на длинных списках | Отложены все изображения ниже сгиба | Плагин, который «оптимизирует» и первый экран тоже |
Главная ошибка: ленивая загрузка на первом экране
Это ошибка номер один по частоте и по ущербу. Возникает она почти всегда не от незнания, а автоматически: SEO-специалист или разработчик ставит галочку «включить lazy loading для изображений» в оптимизирующем плагине, и плагин обрабатывает вообще все теги img в шаблоне — включая логотип, баннер, главное фото товара.
Результат виден в любом инструменте измерения производительности: в диагностике прямо появляется рекомендация не откладывать загрузку изображения, формирующего LCP. Величина ущерба зависит от проекта, но речь идёт о заметных долях секунды — при том что порог «хорошего» LCP составляет 2,5 секунды, а разница между «хорошо» и «требует улучшения» может решаться именно этими долями.
Как определить LCP-элемент
- Откройте страницу в браузере и снимите профиль производительности — панель разработчика показывает LCP-элемент прямо на таймлайне.
- Проверьте несколько типов страниц: главная, категория, карточка товара, статья блога. LCP-элемент у них разный.
- Обязательно проверьте мобильную версию отдельно — на узком экране крупнейшим элементом может оказаться совсем другая картинка или блок текста.
- Помните про адаптивность: если на десктопе LCP — широкий баннер, а на мобильном он скрыт через display:none, значение атрибута должно учитывать оба сценария.
ПРАВИЛО ПЕРВОГО ЭКРАНА
Всё, что попадает в область видимости при загрузке страницы, грузится eager. Всё, что ниже, — lazy. На типовой странице каталога это 2–4 изображения сверху и все остальные внизу. Не пытайтесь угадывать «примерно»: откройте страницу в разрешении 360×640 (самое узкое из массовых мобильных) и посчитайте, сколько картинок реально видно без прокрутки. Именно они и только они — eager.
fetchpriority: усиление для главной картинки
Мало убрать lazy с LCP-изображения — стоит дополнительно поднять ему приоритет. Атрибут fetchpriority="high" сообщает браузеру, что этот ресурс важнее остальных, и он уходит в загрузку раньше конкурирующих запросов. Для баннеров, вставляемых через CSS или подгружаемых скриптом, эквивалент — тег <link rel="preload" as="image"> в head с корректным указанием imagesrcset для адаптивных вариантов. И зеркальный приём: изображениям, которые технически на первом экране, но заведомо второстепенны (иконки платёжных систем, мелкие бейджи), можно поставить fetchpriority="low", чтобы они не отбирали полосу у главного визуала.
Три способа реализации и что выбрать
На практике встречаются три подхода, и они принципиально различаются по риску для индексации.
| Способ | Как устроен | Риск для индексации | Когда применять |
|---|---|---|---|
| Нативный loading="lazy" | Атрибут в HTML, обработка на уровне движка браузера | Минимальный: реальный URL остаётся в src и виден в исходном коде | По умолчанию во всех случаях — это рабочий стандарт |
| IntersectionObserver | Скрипт следит за пересечением элемента с вьюпортом и подставляет src из data-src | Средний: при рендеринге робот увидит картинки, но только если скрипт отработает | Фоновые изображения из CSS, ленивые виджеты, сложные слайдеры |
| Обработчик scroll | Устаревшая схема: пересчёт координат на каждое событие прокрутки | Средний плюс нагрузка на основной поток | Не применять, заменять на IntersectionObserver |
| Плагин CMS «всё сразу» | Автоматически навешивает lazy на все img в выводе | Зависит от плагина: часть меняет src на заглушку | Только с обязательным списком исключений для первого экрана |
| Гибрид native + noscript | Скриптовый lazy плюс дубль тега внутри noscript | Низкий, но добавляет дубли в код | Легаси-проекты, где отказаться от скрипта нельзя |
Рекомендация без вариантов: базой должен быть нативный атрибут. Он не требует JavaScript, не ломается при ошибке в скрипте, не влияет на INP и — что важнее всего для нас — сохраняет настоящий URL картинки в атрибуте src, то есть в статическом HTML, который робот видит без всякого рендеринга.
Риск невидимого контента: что на самом деле видит робот
Вот здесь и находится главная SEO-опасность. Она не в самой ленивой загрузке, а в способе её реализации.
Механика проблемы
Классическая скриптовая схема выглядит так: в src стоит прозрачная заглушка в 1 пиксель или base64-пустышка, а настоящий адрес лежит в data-src. Пока не выполнится JavaScript и не произойдёт прокрутка, в DOM нет ни одного реального URL картинки. Что видит робот в этом случае:
- При обходе без рендеринга (первичный проход, экономия ресурсов, любой сторонний краулер) — в HTML только заглушки. Изображений на странице для него не существует.
- При обходе с рендерингом — робот выполняет JavaScript, но он не прокручивает страницу как человек. Поисковые системы обходят это тем, что рендерят страницу в вьюпорте очень большой высоты, из-за чего значительная часть картинок попадает в область видимости. Но «значительная часть» — не гарантия: на бесконечных лентах и очень длинных каталогах нижние изображения могут не подгрузиться.
- При ошибке в скрипте — а ошибки случаются: конфликт библиотек, блокировка домена со скриптом, ошибка в консоли выше по коду — картинок нет вообще ни для кого, включая пользователей.
Последствия зависят от роли изображений на сайте. Для интернет-магазина одежды, мебели или товаров, где значимая доля трафика приходит из поиска по картинкам, это прямая потеря визитов. Для медиа и блогов страдает попадание в блоки с картинками в выдаче и в рекомендательные ленты. Для карточек товаров теряется участие фото в товарных колдунщиках. При этом обычные текстовые позиции могут не просесть вовсе — из-за чего проблему месяцами не замечают.
Ленивая загрузка не наказывается поисковиками. Наказывается ситуация, когда контент существует только после действия пользователя, которого робот не совершает.
Как сделать скриптовую реализацию безопасной
Если отказаться от скрипта невозможно (например, ленивыми должны быть фоновые изображения из CSS), соблюдайте четыре правила:
- Никогда не используйте пустой или однопиксельный src. Ставьте либо реальный URL (тогда скрипт нужен только для приоритетов), либо низкокачественный превью-плейсхолдер того же изображения — это, по крайней мере, валидный ресурс.
- Дублируйте изображение в
<noscript>с полноценным тегом img и alt. Это страховка на случай, если рендеринг не отработал. - Не завязывайте подгрузку на событие пользователя: клик, наведение, свайп. Робот их не совершает. Единственный допустимый триггер — приближение к вьюпорту.
- Не закрывайте от индексации скрипты и CSS, отвечающие за отображение. Запрет в robots.txt на директорию со скриптами — классический способ сломать рендеринг собственными руками; эта же логика подробно разобрана в материале про JavaScript-SEO.
Отдельный риск: изображения только в sitemap
Иногда пытаются компенсировать невидимые картинки перечислением их в карте сайта. Это полумера. Изображение, указанное в sitemap.xml, робот может найти и загрузить, но без контекста страницы — окружающего текста, подписи, alt — оно ранжируется хуже. Карта сайта помогает обнаружению, но не заменяет корректную разметку в HTML.
Правильная разметка: параметры и пороги
Минимальный набор атрибутов, который должен быть у каждого изображения на коммерческом сайте.
| Атрибут | Значение | Зачем нужен | Что будет без него |
|---|---|---|---|
| src | Реальный URL изображения | Единственный источник картинки для робота без рендеринга | Изображение не индексируется при обходе без выполнения JS |
| alt | Осмысленное описание, 5–12 слов | Текстовый контекст, поиск по картинкам, доступность | Картинка почти не участвует в поиске по изображениям |
| width / height | Натуральные размеры файла в пикселях | Резервирование места, защита от CLS | Скачки макета при прокрутке, рост CLS |
| loading | lazy — ниже сгиба, eager — первый экран | Управление очередью загрузки | Плагин расставит сам, часто неверно |
| decoding | async | Декодирование вне основного потока, меньше блокировок | Микрозадержки отрисовки на слабых устройствах |
| fetchpriority | high для LCP, low для второстепенных | Явное управление приоритетом запросов | Браузер решает сам, часто не в вашу пользу |
| srcset / sizes | Набор вариантов под разрешения | Мобильный не тянет десктопный файл | Перерасход трафика в 3–5 раз на мобильных |
Про srcset стоит сказать отдельно: связка «ленивая загрузка + адаптивные изображения» даёт кратно больший эффект, чем каждый приём по отдельности. Отложенная загрузка убирает лишние запросы, srcset убирает лишние килобайты в оставшихся. На каталоге с крупными фото это самая результативная пара правок в мобильной оптимизации.
Пошаговое внедрение на реальном проекте
Инвентаризация изображений
Просканируйте сайт краулером (Screaming Frog или аналог) и выгрузите все теги img с атрибутами: наличие loading, alt, width/height, вес файла, формат. Сгруппируйте по шаблонам страниц — обычно достаточно 5–7 типовых шаблонов, чтобы покрыть весь сайт.
Определите LCP-элемент каждого шаблона
Отдельно для десктопа и мобильного. Составьте таблицу «шаблон → LCP-элемент → путь к нему в коде». Это ваш список исключений, который дальше пойдёт в настройки плагина или в правки шаблона.
Приведите в порядок сами файлы
До внедрения lazy: перевод в WebP или AVIF с фолбэком, сжатие, генерация вариантов под srcset, удаление изображений в разы крупнее области отображения. Ленивая загрузка тяжёлых файлов лечит симптом, а не причину.
Проставьте атрибуты в шаблонах
Всем изображениям ниже первого экрана — loading="lazy" и decoding="async". LCP-картинке — loading="eager" и fetchpriority="high". Везде — width, height и осмысленный alt. Правьте шаблоны, а не отдельные страницы: ручная расстановка не переживёт первого же обновления контента.
Настройте исключения в плагине
Если ленивую загрузку добавляет модуль CMS, внесите в исключения классы и селекторы первого экрана: логотип, слайдер главной, главное фото карточки, обложку статьи. У большинства плагинов есть поле «Пропускать первые N изображений» — это самый простой рабочий вариант.
Проверьте отрисовку глазами робота
Прогоните ключевые страницы через инструменты проверки рендеринга в Яндекс.Вебмастере и Google Search Console, посмотрите на скриншот и HTML после выполнения скриптов. Все изображения должны присутствовать с реальными URL.
Замерьте до и после
Зафиксируйте LCP, CLS, вес страницы и число запросов при загрузке — до правок и через 2–3 недели после, когда накопятся полевые данные. Синтетика показывает эффект сразу, полевые метрики — правду.
Поставьте проверку на регламент
Раз в квартал перепроверяйте расстановку атрибутов: обновление темы, установка нового плагина или редизайн блока сбрасывают настройки чаще, чем кажется. Включите этот пункт в общий SEO чек-лист проекта.
Как проверить, что картинки индексируются
Проверка обязательна: без неё вы не отличите «всё работает» от «полгода назад скрипт сломался». Используйте четыре независимых метода — они дополняют друг друга.
Исходный код без JavaScript
Отключите JS в браузере или запросите страницу через curl и посмотрите HTML. Если вместо адресов картинок видны заглушки и data-src — робот при обходе без рендеринга видит ровно то же самое.
Инструменты рендеринга панелей
Проверка страницы в Яндекс.Вебмастере и «Проверка URL» в Search Console показывают, как страница выглядит после выполнения скриптов. Сравните скриншот и отрендеренный HTML с тем, что видите вы.
Поиск по картинкам с оператором site:
Задайте в поиске по изображениям запрос вида site:вашдомен.ru и оцените, сколько и каких картинок в индексе. Точного числа оператор не даёт, но отсутствие целых категорий видно сразу.
Логи сервера
Самый честный способ: посмотрите обращения робота изображений к файлам картинок. Если по целому разделу обращений нет — картинки до него не дошли. Методика в статье про анализ логов сервера.
Дополнительные точки контроля: отчёт по индексированию в Яндекс.Вебмастере, где видна статистика загруженных ресурсов; раздел статистики сканирования в Google Search Console с разбивкой по типу файла — доля изображений там показывает, тратит ли робот на них обход вообще; и переходы из поиска по картинкам в Яндекс Метрике — резкое падение этого сегмента после релиза почти всегда означает, что кто-то включил агрессивный lazy.
КОНТРОЛЬНЫЙ ВОПРОС ПЕРЕД РЕЛИЗОМ
Есть ли на странице хоть один реальный URL изображения в статическом HTML — до выполнения любого скрипта? Если ответ «нет», релиз выпускать нельзя, каким бы красивым ни был эффект появления картинок. Это единственная проверка, которую нужно помнить наизусть.
Ленивая загрузка iframe, видео и виджетов
Изображения — не главный источник лишнего веса на современных сайтах. Гораздо тяжелее сторонние встраивания: карты, плееры, чаты, виджеты отзывов и социальных сетей. Каждая встроенная карта или плеер тянет за собой сотни килобайт скриптов и десятки запросов к чужим доменам.
Атрибут loading="lazy" работает и для тега iframe — это первое, что стоит сделать со всеми встраиваниями ниже первого экрана. Второй приём, дающий больший эффект: фасад. Вместо настоящего плеера или карты на странице выводится статичная картинка-превью с кнопкой воспроизведения, а реальный iframe подгружается только по клику. Для видео это снимает со страницы весь вес плеерных скриптов; при этом само видео и его разметку робот получает из микроразметки, о чём подробнее в материале про видео-SEO.
Важное ограничение: фасады допустимы для медиа и виджетов, но не для текстового контента. Если по клику подгружается описание товара, характеристики, отзывы или блок FAQ — это уже риск, что контент не попадёт в индекс. Текст, важный для ранжирования, должен присутствовать в HTML сразу, даже если визуально он свёрнут.
| Тип контента | Можно откладывать | Как именно | Ограничение |
|---|---|---|---|
| Фото ниже сгиба | Да | Нативный loading="lazy" | Обязательны width, height, alt |
| LCP-изображение | Нет | eager + fetchpriority="high" | Проверять отдельно для мобильной версии |
| Карты и плееры | Да | loading="lazy" на iframe или фасад по клику | Разметку Schema.org оставить в HTML |
| Чаты, виджеты отзывов | Да | Инициализация по прокрутке или таймеру | Не прятать сами тексты отзывов |
| Описание товара, характеристики | Нет | Всегда в HTML, при необходимости визуально свернуть | Подгрузка по клику — потеря контента для робота |
| Товары в бесконечной ленте | С оговорками | Обязательна параллельная пагинация ссылками | Без ссылок робот не дойдёт до нижних товаров |
| Фоновые изображения CSS | Да | IntersectionObserver со сменой класса | Фоны и так не индексируются как картинки |
Типичные ошибки: причина и решение
| Проблема | Причина | Решение | Приоритет |
|---|---|---|---|
| LCP вырос после «оптимизации» | Плагин навесил lazy на баннер первого экрана | Исключить первые изображения, добавить fetchpriority="high" | Критический |
| Картинки пропали из поиска по изображениям | src заменён на заглушку, реальный URL только в data-src | Вернуть настоящий URL в src, перейти на нативный lazy | Критический |
| Контент прыгает при прокрутке | У img нет width и height | Проставить размеры в шаблоне, задать aspect-ratio контейнеру | Высокий |
| Скорость почти не изменилась | Изображения не сжаты, вес остался прежним | Конвертация в WebP/AVIF, srcset, ресайз под реальные размеры | Высокий |
| Белые дыры при быстрой прокрутке | Своя реализация с нулевым порогом срабатывания | Увеличить запас до 300–600 px или перейти на нативный lazy | Средний |
| Картинки не грузятся вообще | Ошибка JS выше по коду ломает инициализацию библиотеки | Отказ от скрипта либо дубль в noscript и мониторинг ошибок | Критический |
| Робот не видит товары в ленте | Подгрузка по кнопке «Показать ещё» без ссылок | Добавить обычную пагинацию ссылками параллельно ленте | Высокий |
| Лишние обходы файлов картинок | Робот тянет варианты srcset и превью в больших объёмах | Сократить число вариантов, проверить расход по логам | Низкий |
Особенности популярных CMS
Реализация ленивой загрузки почти всегда упирается в то, чем именно управляется сайт.
WordPress
Начиная с версии 5.5 движок сам добавляет loading="lazy" ко всем изображениям в контенте, а с 5.9 научился пропускать первое изображение как вероятный LCP-элемент. Эвристика работает не всегда: если баннер выводится темой, а не редактором, он в неё не попадает. Кэширующие плагины часто добавляют собственный скриптовый lazy поверх нативного — эту связку нужно разбирать вручную и оставлять один механизм. Настройки и типовые конфликты плагинов разбирали в материале про SEO на WordPress.
1С-Битрикс
Изображения выводятся компонентами и шаблонами компонентов, поэтому расстановка атрибутов делается правкой шаблонов в /local/. Отдельная беда — модуль ресайза, который генерирует превью с нечитаемыми именами файлов в /upload/resize_cache/: имена без ключевых слов, alt часто пустой. Проверьте, что alt заполняется из свойств инфоблока автоматически. Подробности — в статье про SEO на 1С-Битрикс.
Tilda, конструкторы и SPA
В конструкторах ленивая загрузка включена по умолчанию и реализована скриптом. Управлять ею почти невозможно: доступ к шаблонам ограничен. Практический вывод — обязательно проверять рендеринг и не рассчитывать на трафик из поиска по картинкам как на основной канал; ограничения платформы перечислены в разборе SEO на Tilda. На SPA-проектах ситуация сложнее: там картинки часто вставляются React-компонентами, и в статическом HTML их нет вовсе — вопрос решается серверным рендерингом.
Когда ленивая загрузка не нужна
Есть ситуации, где внедрение принесёт больше хлопот, чем пользы:
- Страница с 3–5 изображениями. Экономить нечего: все картинки и так на первом-втором экране. Атрибут не навредит, но и эффекта не даст.
- Лендинг с длинным первым экраном. Если верхняя часть занимает полтора экрана, граница eager/lazy проходит не там, где кажется, — и легко отложить то, что видно сразу.
- Печатные версии и AMP-подобные форматы. При печати отложенные картинки могут не отрисоваться, если пользователь не прокрутил страницу.
- Галереи и слайдеры первого экрана. Первый слайд — eager, остальные можно откладывать, но многие библиотеки грузят все слайды сразу; это правится настройками конкретной библиотеки, а не атрибутом.
И зеркальная ситуация: на каталогах интернет-магазинов с сотнями карточек в листинге ленивая загрузка не обсуждается — это обязательная базовая настройка, без которой страница категории просто не уложится в приемлемые метрики. Общий подход к техническим настройкам таких проектов описан в гиде по SEO для интернет-магазина.
Как измерять эффект и что показывать заказчику
Ленивая загрузка — редкий случай, когда эффект виден в цифрах почти сразу, ещё до изменения позиций. Замеряйте четыре показателя на сопоставимых окнах.
- Вес и число запросов при первой загрузке. Панель разработчика, вкладка Network, с очищенным кэшем. На каталоге типичная картина после правок — сокращение начального веса в разы.
- LCP по полевым данным. Синтетические тесты полезны для отладки, но решение о качестве принимается по данным реальных пользователей. Копите минимум 28 дней после релиза.
- CLS. Контрольная метрика: если он вырос — где-то потеряли размеры изображений.
- Трафик из поиска по картинкам. Отдельный сегмент в системах аналитики. Его падение после релиза — прямой индикатор проблем с индексацией, и заметить это нужно за недели, а не за кварталы.
Важно честно проговаривать с заказчиком причинно-следственную связь: ленивая загрузка сама по себе не поднимает позиции. Скорость — фактор ранжирования, но фактор невысокого веса по сравнению с релевантностью и коммерческими характеристиками. Работает она иначе: быстрая страница улучшает поведенческие факторы, снижает долю отказов на мобильных и повышает конверсию — а это уже влияет и на ранжирование, и на выручку напрямую. Ждать роста позиций от одного атрибута в теге img не стоит; ждать снижения потерь на медленной загрузке — вполне обоснованно. Как эти работы встраиваются в общий план, мы разбираем в статье про внутреннюю оптимизацию сайта, а примеры технических перестроек каталогов есть в портфолио.
Частые вопросы
Да. Нативная ленивая загрузка не мешает индексации: реальный URL картинки остаётся в атрибуте src, то есть присутствует в статическом HTML и доступен роботу без выполнения JavaScript. Проблемы возникают не с самим атрибутом, а со скриптовыми реализациями, где src подменяется заглушкой. Если вы используете только нативный механизм и не прячете адреса в data-атрибуты, специальных мер не требуется — достаточно обычной проверки рендеринга после релиза.
Почти наверняка ленивая загрузка попала на изображение первого экрана. Браузер обнаруживает обычные картинки на этапе предсканирования HTML и запрашивает их сразу; ленивая картинка ждёт построения layout и проверки пересечения с вьюпортом, и запрос уходит позже. Решение: определить LCP-элемент отдельно для десктопа и мобильной версии, поставить ему loading="eager" и fetchpriority="high", а в плагине оптимизации внести его в исключения.
При нативной ленивой загрузке — нет, он избыточен и только раздувает код. Он нужен только в скриптовых реализациях, где реальный URL хранится в data-src: тогда noscript остаётся единственным местом, где картинка присутствует в статическом HTML. Но правильнее не подпирать костылём, а перейти на нативный атрибут: это одновременно снимает риск для индексации, убирает нагрузку на основной поток и упрощает поддержку.
Влияет косвенно и обычно в плюс. Отложенные изображения ниже сгиба робот при обычном обходе не запрашивает, а значит не тратит на них обращения к серверу. Обратный случай — избыточные наборы srcset: десяток вариантов одного файла умножается на число карточек, и робот изображений начинает тянуть заметный объём. Проверить фактическое распределение можно только по логам, механика — в материале про краулинговый бюджет.
Нет, если этот текст важен для ранжирования. Описания товаров, характеристики, отзывы, блоки вопросов и ответов должны присутствовать в HTML сразу. Визуально сворачивать их в аккордеон допустимо — контент в коде есть, робот его получает. Недопустимо подгружать по клику или по кнопке: робот не кликает, и такого текста для него не существует. Ленивая загрузка — инструмент для медиа и сторонних виджетов, а не для контента.
Бесконечная лента для пользователя и пагинация ссылками для робота должны существовать параллельно. Технически это делается так: каждая порция товаров имеет собственный URL вида /category/?page=2, доступный по обычной ссылке, а лента подгружает те же данные скриптом. Если ссылок нет, робот увидит только первую порцию, и остальные товары останутся вне индекса — сколько бы их ни подгружалось при прокрутке у живого посетителя.
Нативный — как база во всех типовых случаях. Он не требует JavaScript, не ломается при ошибке в скрипте, не влияет на отзывчивость интерфейса и сохраняет URL в src. Библиотеки оправданы для задач, которые нативный механизм не решает: ленивая загрузка фоновых изображений из CSS, отложенная инициализация сторонних виджетов, эффекты постепенного проявления. Оптимальная схема — нативный атрибут для всех картинок плюс небольшой скрипт на IntersectionObserver для нестандартных элементов.
Ровно столько, сколько реально видно без прокрутки на самом узком массовом мобильном разрешении — обычно это 2–4 изображения: логотип, главный визуал и один-два элемента верхнего блока. Если оставить больше, они начнут конкурировать за полосу с LCP-элементом и метрика ухудшится. Не полагайтесь на настройку «пропустить первые N картинок» вслепую: у разных шаблонов число разное, проверяйте каждый тип страниц отдельно.
Настроим ленивую загрузку так, чтобы сайт стал быстрее, а картинки остались в индексе
Найдём LCP-элементы всех шаблонов, разведём eager и lazy, приведём в порядок форматы и размеры изображений, проверим рендеринг глазами робота и проследим за поиском по картинкам после релиза. Прозрачный договор, отчёты каждую неделю.
- Пакет «Старт» от 55 000 ₽/мес
- Пакет «Стандарт» 75 000 ₽/мес
- Пакет «Премиум» 95 000 ₽/мес
- Бесплатный аудит и прогноз
- Договор с гарантией результата
- Отчёты каждую неделю
Комментарии (14)
Кирилл
Раздел про то, что lazy не уменьшает вес картинок, а только раздвигает загрузку во времени, стоило бы вешать на стену в отделе разработки. У нас полгода считали, что «оптимизация изображений сделана», потому что галочку в плагине поставили.
Марина_В
У нас как раз случилось то, что описано в таблице типичных ошибок: LCP вырос после «ускорения». Оказалось, кэширующий плагин навесил lazy на баннер главной. Убрали, добавили fetchpriority — метрика вернулась на место за пару недель.
AdminSEO Мастер
Марина, классический сценарий. Проверьте заодно карточку товара и страницу категории отдельно — LCP-элемент у разных шаблонов свой, и плагин обычно ломает их все сразу. И обязательно посмотрите мобильную версию: там крупнейшим элементом часто оказывается совсем другая картинка.
dmitry_front
Как фронтендер добавлю: связка width + height обязательна даже при полностью резиновой вёрстке. Браузер берёт из них только пропорцию, а место резервирует сам. Многие боятся ставить, думая, что размер зафиксируется.
Аля_контент
А если у нас на сайте картинки выводятся React-компонентами и в исходном HTML их действительно нет — серверный рендеринг единственный выход или можно как-то попроще?
AdminSEO Мастер
Аля, попроще бывает: пререндер ключевых шаблонов или отдача статического HTML для роботов на уровне сервера. Но если картинки — значимый источник трафика, серверный рендеринг надёжнее любых обходных схем. Если хотите, посмотрим на вашем проекте, что дешевле внедрить — покажем на бесплатном аудите.
Олег Т.
Немного поспорю с тезисом, что скриптовые библиотеки уже не нужны. На больших слайдерах и галереях нативный атрибут ведёт себя непредсказуемо, приходится всё равно писать свою логику предзагрузки.
Настя_магазин
Спасибо за метод с оператором site: в поиске по картинкам. Проверила свой каталог — целого раздела с фото товаров в индексе не оказалось. Пошла разбираться со скриптом, который меняет src на заглушку.
AdminSEO Мастер
Настя, следующим шагом посмотрите логи сервера: если по этому разделу нет обращений робота изображений, диагноз подтверждён окончательно. Возвращайте реальный URL в src и переходите на нативный lazy — после этого раздел переиндексируется, но не мгновенно, закладывайте несколько недель.
Валентин
Контрольный вопрос перед релизом — есть ли хоть один реальный URL картинки в статическом HTML — забрал себе в чек-лист приёмки. Простая формулировка, которую понимает и разработчик, и тестировщик.
Женя_Битрикс
Про resize_cache в Битриксе прямо в точку. Превьюшки с хэш-именами и пустыми alt — беда почти всех проектов, которые я принимал в поддержку. Заполнение alt из свойств инфоблока решает половину проблемы.
Тимур
Вопрос по фасадам для видео: если вместо плеера ставим картинку-превью с кнопкой, а сам iframe грузим по клику — не посчитают ли это скрытием контента? Или разметки Schema достаточно?
AdminSEO Мастер
Тимур, для медиа это нормальная практика: контент никуда не прячется, откладывается только загрузка тяжёлого плеера. Главное — оставить в HTML разметку VideoObject с ссылкой на файл и превью, плюс осмысленный заголовок и описание рядом. Скрытием считается ситуация, когда по клику подгружается текст, а не проигрыватель.
Полина_аналитик
Совет выделять трафик из поиска по картинкам отдельным сегментом — очень практичный. Раньше смотрели органику одной кучей и просто не заметили бы просадку после релиза.
Роман С.
А что если первый экран у нас разный для десктопа и мобильного: на широком экране виден большой баннер, на телефоне он скрыт через display:none и показывается другая картинка. Обеим ставить eager?
AdminSEO Мастер
Роман, две eager-картинки будут конкурировать за полосу, и на мобильном вы получите лишний запрос. Правильнее отдавать один тег с srcset и sizes либо использовать picture с source по медиавыражению — тогда браузер сам скачает нужный вариант, а eager и fetchpriority будут ровно на одном элементе.
Ирина_Казань
Таблица «что можно откладывать, а что нельзя» — самая полезная часть. Особенно строка про описания и характеристики товара: у нас как раз хотели подгружать их по клику ради скорости. Отговорила разработчиков.
Станислав
Не хватило раздела про фоновые изображения в CSS. Понятно, что они не индексируются как картинки, но для скорости это часто самая тяжёлая часть страницы, и IntersectionObserver там ставится не так тривиально.
Гуля_Уфа
Пункт про регламент раз в квартал очень отрезвляет. У нас после обновления темы вся расстановка атрибутов слетела, и никто не заметил, пока не начали разбирать падение скорости.