Lazy loading и SEO: вредит ли отложенная загрузка изображений

Lazy loading вредит SEO только в одном случае: когда атрибут loading="lazy" поставлен на LCP-изображение. Правило простое — hero-баннер и первый экран загружаем eager, всё ниже — lazy. Как настроить правильно и проверить результат — подробно в этой статье.

Что такое lazy loading и как он работает

Lazy loading (отложенная загрузка) — это техника, при которой изображения, видео и iframe не загружаются сразу при открытии страницы, а только тогда, когда пользователь прокручивает их в зону видимости. Браузер экономит трафик и время начальной загрузки, не запрашивая ресурсы, которые, возможно, никогда не попадут на экран.

Существует два подхода к реализации:

• Нативный атрибут loading="lazy" — встроен в HTML5, поддерживается браузерами Chrome 77+, Firefox 75+, Safari 15.4+ (более 96% сессий по состоянию на 2025 год).
• Intersection Observer API — JavaScript-интерфейс, отслеживающий пересечение элемента с областью просмотра (viewport). На нём построены библиотеки lazysizes, lozad.js, vanilla-lazyload.

Механика нативного loading="lazy" проста: браузер выставляет внутренний порог расстояния до viewport (обычно 1250 px для медленных соединений, 200–500 px для быстрых) и начинает загрузку изображения только тогда, когда до него остаётся меньше этого порога при прокрутке.

Важно понимать контекст появления этой технологии. До нативного loading="lazy" разработчики были вынуждены подключать JavaScript-библиотеки или писать собственные решения на основе Intersection Observer. Нативная реализация, стандартизированная в HTML5 и поддерживаемая всеми современными браузерами, значительно упростила задачу: один атрибут в теге <img> — и браузер сам управляет приоритетами загрузки.

Влияние на Core Web Vitals: LCP и CLS

Lazy loading напрямую влияет на две метрики Core Web Vitals — LCP (Largest Contentful Paint) и CLS (Cumulative Layout Shift). Влияние может быть как положительным, так и крайне негативным — в зависимости от того, правильно ли выставлены атрибуты.

LCP: где чаще всего ломается

LCP измеряет время, за которое отрисовался наибольший видимый элемент на первом экране. Как правило, это hero-баннер, первое изображение в статье или превью видео. Если на этот элемент установлен loading="lazy", браузер откладывает его загрузку — LCP вырастает в 2–3 раза. Цель Google: LCP менее 2.5 секунды. Эта ошибка — одна из самых распространённых, которую мы видим на аудитах клиентских сайтов.

Подробнее о метриках LCP, INP и CLS и их влиянии на ранжирование — в нашей статье о Core Web Vitals.

CLS: изображения без размеров

CLS фиксирует, насколько «прыгает» содержимое страницы в процессе загрузки. Если тег <img> не имеет атрибутов width и height, браузер не резервирует место в макете, и контент смещается, когда изображение загружается. Lazy loading не вызывает это сам по себе, но усиливает последствия — элементы загружаются асинхронно и непредсказуемо.

Хорошая новость состоит в том, что исправление обеих проблем требует минимальных правок в HTML-шаблоне. Чаще всего достаточно найти шаблонный тег вывода изображений в CMS и добавить туда два атрибута. Например, в WordPress это делается через фильтр wp_lazy_loading_enabled совместно с функцией wp_get_attachment_image, которая автоматически добавляет width и height из метаданных медиафайла.

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

Googlebot использует Web Rendering Service (WRS) на базе Chromium. Это означает, что он выполняет JavaScript и, теоретически, видит изображения с lazy loading — включая те, что загружаются через Intersection Observer.

Как Googlebot рендерит JavaScript-контент и какие есть ограничения — подробнее в статье о JavaScript SEO.

Но есть нюансы, которые важно понимать:

• Рендеринг происходит не в реальном времени. Google собирает HTML и JavaScript отдельно. Между первым краулингом и рендерингом может пройти от нескольких часов до нескольких дней. Изображения, которые видны только после рендеринга, могут быть проиндексированы с задержкой.
• Googlebot не прокручивает страницу. WRS рендерит страницу в условиях симулированного viewport. Если ваш JS-lazyloader запускается только при scroll-событии реального пользователя — Googlebot это не триггерит. Нативный loading="lazy" от этого не зависит.
• Изображения в alt и src индексируются надёжнее. Если lazyloader подменяет src через data-src, есть риск, что Googlebot зафиксирует пустой src и не увидит изображение до рендеринга.

Google официально подтверждает поддержку нативного lazy loading: "Google Search does support lazy-loading images implemented via the loading='lazy' attribute". Источник: developers.google.com — Google Images best practices.

Практический вывод: нативный loading="lazy" — безопасен для SEO. JS-реализации с подменой src через data-атрибуты требуют дополнительной проверки через URL Inspection Tool в Google Search Console.

Дополнительный способ убедиться, что Googlebot видит нужные изображения — использовать функцию «Просмотреть как Google» в Search Console. Инструмент показывает скриншот рендеринга страницы боттом Google и наглядно демонстрирует, какие изображения попали в viewport, а какие ещё не загружены.

Нативный lazy loading vs JavaScript-библиотеки

Из нашего опыта работы с более чем 200 проектами: нативный lazy loading решает задачу в подавляющем большинстве случаев. JS-библиотеки оправданы только для интернет-магазинов со сложными галереями или лендингов с кинематографическими фоновыми видео.

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

Правила настройки: eager vs lazy

Ключевой принцип — above the fold (первый экран) всегда eager, below the fold — lazy. Но есть детали, которые часто игнорируются.

Особого внимания требуют страницы с адаптивным дизайном. То, что находится above the fold на десктопе (1440px), может быть ниже fold на мобильном устройстве с шириной 375px и наоборот. Поэтому решение о том, какой тип загрузки использовать, нужно принимать на основе мобильной версии страницы — именно её Google использует для оценки Core Web Vitals через Mobile-First Indexing.

Lazy loading для видео и iframe

Атрибут loading="lazy" поддерживается не только для <img>, но и для <iframe>. Это особенно полезно для встроенных YouTube-видео и Google Maps, которые по умолчанию загружают огромное количество ресурсов независимо от положения на странице.

YouTube-вставки

Стандартный iframe YouTube загружает ~500 KB JavaScript и несколько DNS-запросов при первом рендеринге. Для страниц с видео ниже fold это критически влияет на TTI (Time to Interactive). Решения:

1. Нативный lazy iframe: <iframe src="https://www.youtube.com/embed/ID" loading="lazy" width="560" height="315">
2. Lite YouTube Embed — лёгкий веб-компонент от Paul Irish, заменяющий iframe на thumbnail + JavaScript только после клика. Сокращает загрузку с ~500 KB до ~3 KB при начальном рендеринге.
3. Facade pattern: вместо iframe отображаем статичный preview-thumbnail (можно брать с https://i.ytimg.com/vi/VIDEO_ID/hqdefault.jpg), а настоящий iframe вставляем только по клику.

Google Maps

Карты Google — один из самых «тяжёлых» элементов: они загружают отдельный JS-движок, шрифты, тайлы. Если карта находится в footer или на странице контактов внизу — обязательно добавьте loading="lazy" к iframe. Для Maps Embed API атрибут loading="lazy" можно прописать непосредственно в теге.

Практика показывает, что страницы с несколькими YouTube-видео могут выиграть до 1.5–2 секунд на показателе TTI только за счёт правильного применения lazy loading к iframe. Это особенно актуально для блогов, обучающих платформ и новостных сайтов с богатым мультимедийным контентом.

Типичные ошибки при внедрении

По данным технических аудитов, которые мы проводим для клиентов, ошибки lazy loading встречаются примерно в 60% сайтов, где эта техника вообще используется. Вот наиболее распространённые:

• loading="lazy" на LCP-элементе. Наиболее критичная и наиболее частая ошибка. Hero-баннер, первое изображение в статье, обложка — всё это должно быть eager.
• Отсутствие width и height в тегах img. Без размеров показатель CLS падает в «плохую» зону (>0.25). Браузер не может зарезервировать место в макете до загрузки изображения.
• JS-lazyloader без fallback. Если JS заблокирован или ещё не выполнился, пользователь видит пустые блоки. Нативный loading="lazy" этой проблемы не имеет.
• data-src без src. Некоторые реализации lazyloader'ов вообще не прописывают атрибут src, только data-src. Googlebot при первом краулинге (до рендеринга) не видит изображение вовсе.
• Lazy loading на изображениях в meta Open Graph. OG-изображения не попадают в viewport браузера — они только считываются парсерами соцсетей. lazy/eager на них не влияет, но некоторые CMS некорректно прописывают атрибуты и для этих изображений.
• Lazy loading для фона (CSS background-image) без JS. Нативный loading="lazy" не работает для фоновых изображений CSS. Их нужно либо загружать обычным образом, либо использовать JS-решение.

Отдельно стоит упомянуть ошибку, типичную для WordPress: плагины оптимизации изображений нередко добавляют loading="lazy" ко всем тегам <img> без исключения — включая логотип и hero-баннер. Проверяйте настройки плагина и исключайте из обработки изображения с классами первого экрана.

Кейс: как lazy loading уничтожил LCP клиента

К нам обратился клиент — интернет-магазин мебели. После обновления темы сайта их LCP на мобильных устройствах вырос с 2.1 секунды до 4.8 секунды. Трафик из Google упал на 18% за первые три недели после апдейта.

Диагностика:

1. Открыли Chrome DevTools → вкладка Network, отфильтровали по типу «Img».
2. Увидели, что главное изображение категории (крупный баннер 1440×600 px) начинает загружаться через 2.3 секунды после DOMContentLoaded — типичная картина для lazy.
3. Проверили HTML: разработчик при обновлении темы добавил loading="lazy" ко всем тегам <img> через глобальный фильтр в PHP-шаблоне без исключений.
4. Подтвердили через PageSpeed Insights: «Image elements do not have explicit width and height» — 12 изображений без размеров, CLS = 0.31.

Исправление:

1. В PHP-шаблоне категорий исключили первый <img> баннера из фильтра lazy — добавили loading="eager" fetchpriority="high".
2. Через функцию обработки изображений прописали width и height для всех <img> на основе реальных размеров файлов.
3. Подключили <link rel="preload" as="image" href="/images/category-hero.jpg"> в секции <head>.

Результат через 2 недели: LCP вернулся к 1.9 секунды, CLS снизился до 0.04, трафик восстановился и превысил предыдущий уровень на 7%.

Этот кейс — классический пример того, что «добавить lazy loading ко всем изображениям» без анализа LCP-элемента опасно. Автоматизация без понимания механики = гарантированный регресс производительности.

Показательно, что падение трафика на 18% произошло без каких-либо изменений в контентной стратегии или ссылочном профиле. Google's Page Experience update напрямую учитывает Core Web Vitals при ранжировании, и замедление LCP с 2.1 до 4.8 секунды оказалось достаточным, чтобы сайт потерял позиции по конкурентным запросам категории мебели.

Как проверить: Lighthouse, PSI, Chrome DevTools

После внедрения или аудита lazy loading используйте следующий порядок проверки:

1. Google PageSpeed Insights (PSI)

Перейдите на pagespeed.web.dev и введите URL. В отчёте ищите:

• «Largest Contentful Paint element» — PSI покажет, какой конкретно элемент является LCP. Проверьте, является ли он eager.
• «Defer offscreen images» — если появляется, значит есть below-fold изображения без lazy.
• «Image elements do not have explicit width and height» — это риск CLS.

2. Chrome DevTools → Performance

1. Откройте DevTools (F12) → вкладка Performance.
2. Нажмите Ctrl+Shift+E (или кнопку записи) и перезагрузите страницу.
3. В таймлайне найдите событие «LCP candidate» — оно укажет время и элемент.
4. Если LCP > 2.5s — проверьте, является ли элемент eager и есть ли preload в head.

3. Chrome DevTools → Network

Во вкладке Network отфильтруйте по «Img». Сортируйте по колонке «Waterfall». Изображения с большой задержкой перед началом загрузки — кандидаты на проверку атрибута loading.

4. Lighthouse (локально или в DevTools)

DevTools → Lighthouse → выбрать Mobile → Generate report. Секция «Performance» покажет LCP, CLS, FCP. Секция «Opportunities» укажет конкретные изображения для оптимизации.

После оптимизации lazy loading рекомендуем провести полный технический SEO-аудит сайта — lazy loading является лишь одним из элементов скоростной оптимизации. Полная картина требует проверки кеширования, CDN, сжатия изображений и критического CSS.

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

На практике

Портфолио-сайт киевского свадебного фотографа: 18 галерей по 40–80 изображений в каждой, движок на WordPress с плагином-галереей. Когда клиент обратился, Lighthouse на мобильных показывал Score 14 — LCP составлял 9,2 секунды.

Причина обнаружилась сразу в DevTools: все 80 фотографий в галерее грузились одновременно со статусом eager. Суммарный объём запросов к изображениям на одной странице — 34 МБ, браузер ждал самую тяжёлую фотографию и считал её LCP-элементом. Screaming Frog при обходе фиксировал время ответа страниц галерей в 8–11 секунд.

Исправление заняло один рабочий день. В шаблоне галереи выставили loading="eager" fetchpriority="high" для первых 4 изображений (первый экран на мобильном 375px), остальные 76 получили loading="lazy" с прописанными width и height. Дополнительно добавили <link rel="preload"> на hero-фотографию — горизонтальный снимок 1920×1280, который занимал весь первый экран.

Результат через 3 недели по данным PageSpeed Insights и Google Search Console: LCP опустился до 1,9 секунды, мобильный Lighthouse Score вырос до 81. Запросы «фотограф Киев свадьба» поднялись с 18-й на 4-ю позицию — это подтверждено данными GSC по средней позиции и Ahrefs по динамике ключа.

Галерейный сайт с 40+ фотографиями на странице — это крайний случай, где каждый eager сверх первых 3–4 изображений напрямую убивает LCP. Не «оптимизируйте галерею» абстрактно — считайте, сколько фото попадает в первый экран конкретно на мобильном 375px, и только эти делайте eager.

Часто задаваемые вопросы

Видит ли Googlebot изображения с lazy loading?

Да. Googlebot использует Chromium-рендерер (WRS) и выполняет JavaScript, поэтому изображения с отложенной загрузкой индексируются. Однако рендеринг может произойти с задержкой — от нескольких часов до нескольких дней в зависимости от приоритета краулинга страницы.

Вредит ли lazy loading показателю LCP?

Да, если атрибут loading="lazy" установлен на LCP-изображение (как правило, hero-баннер или первый крупный блок страницы). В таком случае браузер откладывает загрузку главного изображения, и LCP резко возрастает. LCP-элементы всегда должны иметь атрибут eager.

Что лучше: нативный lazy loading или JavaScript-библиотеки?

Для большинства сайтов достаточно нативного loading="lazy". Он поддерживается в 96%+ браузеров, не требует JS и не блокирует рендеринг. JavaScript-библиотеки (lazysizes, lozad.js) оправданы только при необходимости сложной логики: фоновые CSS-изображения, анимированные placeholder'ы, поддержка очень старых браузеров.

Нужно ли указывать width и height при lazy loading?

Да, это критически важно. Без атрибутов width и height браузер не знает размер изображения до его загрузки и не резервирует место в макете. Это вызывает смещение контента (Layout Shift) и ухудшает метрику CLS. Всегда указывайте реальные размеры изображений.