Скорость сайта

Lazy load для картинок: как включить и не потерять SEO

Native loading=lazy и плагины для WordPress, Битрикс и Tilda. Где lazy load уместен, а где он ломает LCP и индексацию.

обновлено 9 минут чтения 0 Дмитрий Акиндинов
Содержание
  1. Зачем нужен lazy load
  2. Native loading=lazy: что это и в чём подвох
  3. Где правильно ставить lazy load
  4. Как ставить на разных движках
  5. Lazy load для iframes и видео
  6. Тонкие настройки: rootMargin и приоритеты
  7. Поломанная индексация: как проверить
  8. Типичные истории, которые я лечил
  9. Чек-лист правильной настройки
  10. Когда стоит звать подрядчика
  11. Частые вопросы

Отложенная загрузка картинок включается атрибутом loading со значением lazy и работает во всех актуальных браузерах с 2020 года. Главная ошибка это вешать её на изображение первого экрана: тогда LCP не ускоряется, а замедляется на 200-400 мс и добавляется прыжок вёрстки.

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

Разберу, как включить нативный lazy load правильно, чем он отличается от плагинных решений, где его использовать нельзя и как не уронить индексацию.

Стек плейсхолдеров изображений со стрелкой подгрузки

Зачем нужен lazy load

Идея в одном предложении: не грузить картинки, которых пользователь ещё не видит. Когда страница открывается, в браузер сразу едут только те картинки, что попадают в видимую область. Остальные подгружаются по мере прокрутки.

Что это даёт:

  • Меньше передачи данных. Если у вас на странице 30 картинок, и пользователь читает только верх, он не платит трафиком за нижние.
  • Быстрее парсинг и рендер первого экрана. Браузер не воюет за полосу пропускания между критичными ресурсами и нижними картинками.
  • Меньше нагрузки на сервер на пиковых отдачах.

Что это не даёт:

  • Не уменьшает общее время полной загрузки страницы.
  • Не помогает LCP, если LCP это картинка над сгибом. Скорее наоборот, может ухудшить.
  • Не делает картинку легче. Сжатие WebP, AVIF и оптимизация это отдельная история.

Native loading=lazy: что это и в чём подвох

С 2020 года все основные браузеры поддерживают атрибут loading="lazy" прямо в HTML. Достаточно написать так:

<img src="/img/photo.jpg" alt="Фото" loading="lazy" width="800" height="600">

Браузер сам решает, когда грузить картинку, и отлично справляется с типичным сайтом. Это работает в Chrome, Edge, Firefox, Safari (с iOS 16). Для российских пользователей с актуальными смартфонами это 95+ процентов аудитории.

Подвохи бывают разные.

Подвох 1: lazy load на картинке выше сгиба

Самая частая ошибка. Тема WordPress или плагин кеширования врубили loading="lazy" глобально, и теперь lazy load висит на картинке героя, на логотипе, на главном баннере. Браузер видит атрибут, тормозит загрузку до момента, когда он увидит элемент в видимой области, и LCP уезжает на 300-800 миллисекунд.

Правило: для картинок в первом экране (above the fold) НЕ ставить loading="lazy". Для критичной картинки лучше явно указать loading="eager" и fetchpriority="high":

<img src="/img/hero.jpg" alt="..." loading="eager" fetchpriority="high">

Это говорит браузеру: грузи в первую очередь, не жди ничего. LCP с такой пометкой обычно опускается на 300-500 миллисекунд.

Подвох 2: размеры

Без width и height lazy-картинка приходит и расталкивает контент. CLS прыгает. Поэтому атрибуты обязательны на каждом <img>, не только на критичных.

Подвох 3: пустой src или плейсхолдер 1×1

Старые скрипты lazy load (LazyLoad.js, BJ Lazy Load, BLT) подменяли src на крошечный 1×1-пиксельный плейсхолдер и загружали реальную картинку через JS. С нативным lazy load этого делать не нужно. Если у вас на сайте остались такие плейсхолдеры, они мешают индексации картинок.

Подвох 4: индексация картинок

Поисковые роботы Google и Яндекса умеют выполнять JavaScript и видеть итоговую картину. Но не все картинки они видят одинаково. Нативный loading="lazy" не мешает индексации, потому что атрибут не скрывает ссылку на картинку, она всё равно в src атрибуте.

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

Лучший подход в 2026: нативный loading="lazy" или комбинация нативного с минимальным fallback на JS для совсем старых браузеров. JS-плагины как основной механизм это атавизм.

Где правильно ставить lazy load

Простая модель.

  • Картинки в первом экране: НЕТ lazy load, явный loading="eager", и для главной картинки fetchpriority="high".
  • Картинки в видимой области ниже первого экрана: МОЖНО lazy load, но влияние на скорость минимальное.
  • Картинки в нижних блоках, в футере, в галереях, в блогах: ДА lazy load, основной выигрыш именно тут.
  • Iframes (YouTube, карты, виджеты): ОБЯЗАТЕЛЬНО lazy load. Можно через тот же атрибут loading="lazy" на <iframe>.

Особый случай: иконки SVG и совсем мелкие картинки до 5 КБ. На них lazy load не нужен, потому что они грузятся быстрее, чем браузер успеет принять решение.

Как ставить на разных движках

WordPress

С версии WP 5.5 ядро автоматически добавляет loading="lazy" ко всем <img>. Для большинства сайтов это работает.

Но: ядро не понимает, что картинка героя на главной не должна быть lazy. Браузер пометит её и не загрузит первой. Это надо чинить.

Ручной способ для главной картинки:

add_filter('wp_get_attachment_image_attributes', function($attr, $attachment, $size) {
  global $is_main_hero;
  if ($is_main_hero) {
    $attr['loading'] = 'eager';
    $attr['fetchpriority'] = 'high';
  }
  return $attr;
}, 10, 3);

Или, проще, через плагин Perfmatters: в его настройках есть тонкая настройка lazy load с возможностью исключить определённые селекторы.

Альтернатива: WP Rocket делает то же самое из коробки и автоматически определяет картинки выше сгиба.

Tilda

В Tilda lazy load включается централизованно: Настройки сайта > Дополнительно > Ускорение загрузки. По умолчанию включено и работает прилично. Особенностей мало.

Что стоит проверять: на главной странице с большим Cover-блоком убедиться, что фоновая картинка не lazy. Tilda обычно справляется, но иногда в Zero Block с большим количеством картинок проблема возникает.

Битрикс

В Битриксе нативного lazy load из коробки нет. Самый простой способ это атрибут loading="lazy" в самих компонентах, через их настройки или через переопределение шаблона. На современных шаблонах часто уже добавлено.

Если шаблон старый, ручная правка несложная: в bitrix:catalog.section и подобных компонентах в шаблоне template.php находим <img> и добавляем атрибут.

Для картинок в WYSIWYG-редакторе можно сделать глобальный JS-обработчик, который проходит по <img> без lazy и добавляет атрибут после загрузки страницы.

Astro и SSG

В Astro компонент <Image> из astro:assets сам ставит loading="lazy" для не-приоритетных картинок и eager для приоритетных, если указать priority. Удобно: вы пишете <Image src={hero} alt="..." priority />, и фреймворк делает правильные атрибуты.

Тот же принцип в Next.js (<Image priority />), Nuxt (<NuxtImg loading="lazy" />), Hugo ({{ partial "image.html" . }} с настройкой). На любом современном SSG это решается одной строкой.

Браузерная плитка с тайтлом и иконкой часов

Lazy load для iframes и видео

Это часто пропускают. На странице есть встроенное видео YouTube и виджет Яндекс Карт, которые в сумме весят 800-1500 КБ и тянут массу JS.

Для <iframe> тот же атрибут loading="lazy". Поддерживается всеми современными браузерами.

<iframe src="https://www.youtube.com/embed/..." 
        loading="lazy" 
        width="560" height="315"></iframe>

Но и тут есть нюанс. YouTube embed по умолчанию тянет на главный документ много кода ещё до клика по плееру. Если у вас на странице есть большое видео, лучше использовать lite-youtube-embed или похожий лёгкий плеер: он показывает превью-картинку и подгружает реальный embed только после клика. Загрузка страницы при этом ускоряется на 200-500 КБ.

Похожее с Яндекс Картами: пока пользователь не доскроллил до карты, она не должна грузиться. Плагин или ручная JS-обёртка через IntersectionObserver:

const map = document.querySelector('.map-placeholder');
const obs = new IntersectionObserver((entries) => {
  for (const e of entries) {
    if (e.isIntersecting) {
      e.target.innerHTML = '<iframe src="..."></iframe>';
      obs.unobserve(e.target);
    }
  }
}, { rootMargin: '200px' });
obs.observe(map);

rootMargin: '200px' означает, что карта загрузится за 200 пикселей до того, как окажется в видимой области. Пользователь дойдёт до неё, а она уже почти готова.

Тонкие настройки: rootMargin и приоритеты

Нативный lazy load под капотом использует тот же механизм, что IntersectionObserver. Но rootMargin у браузера зашит и не настраивается. Это значит, что картинка начнёт грузиться в момент, который выбрал браузер, и обычно это работает хорошо.

В редких случаях вы видите, что картинка появляется не плавно, а с заметной задержкой (особенно при быстрой прокрутке на мобильном по 3G). Тут в дополнение к нативному lazy полезен JS-полифилл с настраиваемым rootMargin. Например, плагин lazysizes даёт настройку expand: 300, и картинка начнёт грузиться за 300 пикселей до видимости.

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

Поломанная индексация: как проверить

Если вы недавно переключились на lazy load и боитесь за поисковики, проверка простая.

Google Search Console, проверка URL: вводите URL страницы, смотрите HTML и скриншот рендера. Если робот видит ваши картинки в скриншоте, индексация работает.

Яндекс Вебмастер, инструменты переобхода: добавляете URL, через сутки смотрите, как Яндекс отрисовал страницу. Если картинки на месте, всё хорошо.

Полезный тест: откройте страницу в Chrome через chrome://network-internals/#events, отключите JS (Settings > Advanced > Privacy > Site settings > JavaScript > Don't allow), перезагрузите страницу. Если картинки видны без JS, ваш lazy load на нативном механизме, и поисковикам они тоже видны. Если без JS картинок нет, у вас плагин с data-src, и тут возможны проблемы.

Типичные истории, которые я лечил

История 1: WP Super Cache + Lazy Load

Стандартная связка на WordPress. Результат: на главной сайт грузится медленно, потому что картинка героя помечена data-src и видна только после загрузки JS. Лечение: настройка плагина Above the fold или ручное исключение селектора героя.

История 2: Slider Revolution и lazy load в нём

Slider Revolution в старых версиях ставит свой собственный lazy load на слайды, и при первом показе слайда внутрь страницы прилетает картинка с задержкой 200-400 мс, что сразу даёт прыжок CLS и неприятный мерцающий эффект. Лечение: либо отключить lazy load слайдов в настройках Slider Revolution, либо обновить плагин до версии, где поведение исправлено.

История 3: lazy load с placeholder-svg

Тема использовала плагин с пустым SVG-плейсхолдером 1×1. Робот Яндекса при индексации видел этот плейсхолдер и считал, что у страницы нет картинок. В выдаче пропали превью. Лечение: переключиться на нативный lazy load или хотя бы задать в data-src реальную картинку.

История 4: Astro priority забыт на герое

Сайт на Astro, фреймворк сам поставил lazy на все картинки. Главная картинка героя загружалась последней, LCP уезжал за 3 секунды. Лечение: один атрибут priority на компоненте <Image>, и LCP опустился до 1.5 секунд.

Маленький сайт с появляющимися картинками постепенно

Чек-лист правильной настройки

  • Нативный loading="lazy" на всех <img> ниже первого экрана.
  • loading="eager" и fetchpriority="high" на главной картинке героя.
  • width и height указаны явно у каждого <img>.
  • loading="lazy" на всех <iframe> (видео, карты, виджеты).
  • Никаких data-src и 1×1-плейсхолдеров без необходимости.
  • Если используется JS-плагин, у него выключено правило lazy load above the fold.
  • В админке страница в первом экране проходит проверку: PageSpeed Insights показывает LCP меньше 2.5 секунд.
  • В Search Console (если работает) и в Яндекс Вебмастере страница рендерится с картинками в превью.

Когда стоит звать подрядчика

Включить lazy load правильно на типичном WordPress-сайте задача на 1-2 часа: настройка плагина, исключения для героя, проверка LCP до и после. На Битриксе чуть дольше, потому что часто требуется правка шаблонов компонентов. В сложных случаях, когда сайт сделан на старой теме с самописным lazy load, проще переписать на нативный, и это занимает 4-6 часов.

Эта работа входит в часовую ставку или в любой из тарифов на /#pricing. Если у вас плохой LCP и есть подозрение, что виноват lazy load на герое, опишите ситуацию через /#contact. Дополнительные материалы по скорости и Core Web Vitals в /blog/category/speed/, там есть статьи про LCP, INP, CLS и сжатие картинок в WebP/AVIF.

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

Как включить отложенную загрузку картинок

Атрибутом loading со значением lazy на теге картинки. Отдельный плагин или скрипт для этого не нужен: браузеры поддерживают это сами уже несколько лет.

На какие картинки не ставить lazy load

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

Портит ли lazy load индексацию картинок

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

Что делать с видео и картами

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

Передайте техническую часть в надёжные руки.

Слежу за хостингом, бэкапами и обновлениями. Когда что-то пойдёт не так – звоните мне, не своему программисту, не в спортзал и не маме.

Короткие вопросы по теме

Все вопросы по теме "Скорость сайта"

Заявка

Обсудим задачу

Напишите имя и телефон, выберите удобный канал. Перезвоню или напишу в течение часа в рабочее время.

Куда удобнее ответить?