Отложенная загрузка изображений в WordPress полезна почти всегда, но на практике она иногда ломает первый экран: баннер появляется с задержкой, слайдер дергается, а LCP в отчётах становится хуже. Чаще всего проблема не в самой технологии, а в том, что lazy load включён для тех картинок, которые должны грузиться сразу.
Если у вас уже есть оптимизация через плагин, тему или CDN, сначала проверьте, кто именно добавляет атрибут loading="lazy" или скрипт lazy load. В WordPress это может быть ядро, тема, плагин оптимизации или сторонний JS-скрипт. Отключать всё подряд не нужно: лучше убрать отложенную загрузку только там, где она мешает.
Когда lazy load действительно мешает
Типичный сценарий — изображение находится выше первого экрана, но браузер всё равно откладывает его загрузку. В результате пользователь видит пустое место, а затем резкий сдвиг верстки. Это особенно заметно на:
- главных баннерах и hero-секциях;
- логотипах в шапке, если они крупные и важны для первого рендера;
- слайдерах на главной странице;
- обложках записей в списках, если они попадают в первый экран;
- фоновых изображениях, которые тема подгружает через HTML-элементы вместо CSS.
Как понять, что проблема именно в отложенной загрузке
Откройте страницу в режиме инкогнито и посмотрите, появляется ли картинка с задержкой. Затем проверьте исходный HTML: если у изображения есть loading="lazy", а оно находится в верхней части страницы, это уже повод для точечной правки. Дополнительно можно открыть DevTools и посмотреть, не уходит ли запрос за картинкой только после прокрутки.
Если lazy load добавляет плагин, в HTML часто видно не только loading="lazy", но и дополнительные атрибуты вроде data-src, data-lazy-src или замену src на заглушку. Это уже не ядро WordPress, а отдельная реализация.
Что отключать: ядро, плагин или конкретные изображения
Самая частая ошибка — полностью выключить lazy load ради одной проблемной картинки. Это ухудшает загрузку всего сайта. Практичнее оставить отложенную загрузку для контента ниже первого экрана и исключить только критичные изображения.
| Подход | Когда подходит | Минус |
|---|---|---|
| Отключить lazy load в плагине | Если плагин навешивает его на весь сайт и нет точечных исключений | Потеря оптимизации на всех страницах |
| Исключить отдельные изображения кодом | Если мешает только первый экран или несколько шаблонов | Нужно знать, где именно выводится картинка |
| Отключить lazy load в теме | Если тема сама добавляет JS-ленивую загрузку | Можно сломать другие визуальные эффекты темы |
Пошаговое решение через код
Начиная с WordPress 5.5, ядро может добавлять loading="lazy" автоматически. Для изображений первого экрана это можно отключить фильтром wp_img_tag_add_loading_attr. Ниже пример, который убирает lazy load для конкретных изображений по CSS-классу.
<?php
add_filter( 'wp_img_tag_add_loading_attr', function( $value, $image, $context ) {
if ( false === strpos( $image, 'class="no-lazy"' ) ) {
return $value;
}
return false;
}, 10, 3 );Дальше в шаблоне или в редакторе добавьте изображению класс no-lazy. Для картинок, которые выводятся через the_post_thumbnail(), можно передать класс в аргументах или добавить его через фильтр post_thumbnail_html, если нужен более точный контроль.
Если нужно убрать lazy load у featured image только на главной или в конкретном шаблоне, удобнее работать на уровне шаблона темы:
<?php
if ( has_post_thumbnail() ) {
echo get_the_post_thumbnail(
get_the_ID(),
'large',
array(
'loading' => 'eager',
'fetchpriority' => 'high',
'decoding' => 'async',
)
);
}Здесь важно не переборщить с fetchpriority="high". Этот атрибут имеет смысл только для одного, максимум двух изображений на странице. Если повесить его на всё подряд, браузер перестанет нормально расставлять приоритеты.
Если lazy load добавляет плагин
У плагинов логика обычно другая: они могут переписывать HTML уже после генерации WordPress. В таком случае ищите в настройках исключения по URL, CSS-классу или селектору. Если плагин не даёт точечных исключений, лучше отключить его lazy load и оставить только встроенный механизм ядра или наоборот — но не оба сразу.
Перед отключением проверьте, не отвечает ли за отложенную загрузку отдельная опция в плагине кеширования. Иногда lazy load включён одновременно в двух местах, и тогда изображения ведут себя непредсказуемо: часть получает loading="lazy", часть — data-src, а часть вообще подменяется JS.
Диагностика: что проверить до и после правки
Чтобы не гадать, откройте страницу и пройдитесь по этому чек-листу:
- в HTML у hero-изображения нет
loading="lazy"; - картинка загружается сразу, без ожидания прокрутки;
- в DevTools запрос к изображению появляется в начале загрузки страницы;
- нет скачка макета после появления изображения;
- в отчёте Lighthouse или PageSpeed не ухудшился LCP из-за задержки картинки;
- плагин кеша не добавляет свой lazy load поверх настроек темы.
Если после правки картинка всё равно загружается поздно, проблема может быть не в lazy load, а в тяжёлом CSS, блокирующем JS или слишком большом файле изображения. Тогда отключение отложенной загрузки не даст заметного эффекта.
Проверка результата после внедрения
Проверять нужно не только визуально. Сначала откройте страницу в чистом браузере и убедитесь, что первый экран рисуется без пустых плейсхолдеров. Затем:
- посмотрите исходный код страницы и найдите нужное изображение;
- убедитесь, что у него стоит
loading="eager"или нет атрибута lazy вообще; - проверьте Network в DevTools — запрос к файлу должен стартовать сразу;
- сравните поведение на мобильном и десктопе, потому что шаблоны могут отличаться;
- если используете CDN или кеш-плагин, очистите кеш перед тестом.
Для более надёжной проверки откройте страницу в режиме throttling в DevTools. Так видно, не появляется ли сдвиг контента и не уезжает ли текст вниз после подгрузки изображения.
Частые ошибки и как их исправить
Отключили lazy load для всех изображений
Это часто делают после одной жалобы на баннер. В итоге сайт начинает грузить тяжёлые изображения внизу страницы, а выигрыш на первом экране почти не меняется. Исправление простое: верните lazy load для контентных картинок и оставьте eager только для критичных элементов.
Правили не тот слой
WordPress может добавить loading="lazy", но плагин оптимизации потом перепишет HTML. Внешне кажется, что фильтр не работает. В таких случаях нужно найти источник последней модификации — тему, плагин кеша или отдельный скрипт.
Ставили fetchpriority="high" на несколько изображений
Этот атрибут не предназначен для массового использования. Если пометить им галерею или несколько карточек, браузер начнёт конкурировать сам с собой. Используйте его только для одного ключевого изображения на странице.
Не очистили кеш
После изменения шаблона или фильтра старый HTML может продолжать отдаваться из кеша. Если вы не видите эффекта, сначала сбросьте кеш страницы, объектный кеш и CDN, если он есть.
Практика безопасности и производительности
Не стоит править ядро или плагины напрямую. Если отключение lazy load делается кодом, добавляйте его в дочернюю тему или в небольшой mu-plugin. Так вы не потеряете изменения после обновления.
Если у вас много шаблонов и разные правила для изображений, лучше держать логику в одном месте, а не размазывать по файлам темы. Это упрощает поддержку и снижает риск случайно отключить оптимизацию на всём сайте.
Когда lazy load нужен только на части страниц, можно сделать условную логику по типу записи, шаблону или CSS-классу. Такой подход обычно лучше, чем глобальное отключение. Он сохраняет баланс между скоростью загрузки и нормальным первым экраном.
Если нужна более широкая чистка технических дублей и лишних настроек оптимизации, иногда удобнее посмотреть в сторону комплексных инструментов вроде Clearfy Pro: там можно централизованно управлять частью SEO- и технических опций без ручного разнесения по нескольким плагинам. Но даже в этом случае проверять итог нужно по факту в HTML и в DevTools, а не по галочкам в админке.