Отложенная загрузка изображений в WordPress обычно полезна, но на некоторых страницах она мешает: главный баннер, первый слайд, логотип в шапке или обложка статьи начинают грузиться позже, чем нужно. В результате браузер тянет LCP-элемент с задержкой, а визуально страница выглядит «тяжёлой», хотя сами картинки не большие.
Проблема почти всегда не в самой технологии lazy load, а в том, что она применяется ко всем изображениям одинаково. Для первого экрана это часто лишнее. Ниже — как быстро диагностировать ситуацию, отключить отложенную загрузку точечно и проверить, что изменения действительно помогли.
Когда lazy load мешает, а не помогает
Если на странице есть изображение, которое пользователь видит сразу после загрузки, его лучше не откладывать. Типичные случаи:
- герой-баннер на главной;
- обложка записи над заголовком;
- логотип в шапке, если он крупный и влияет на отрисовку;
- первое изображение в лендинге или статье;
- слайдер, где первый кадр — основной визуальный элемент.
WordPress сам добавляет атрибут loading="lazy" к изображениям, если считает это уместным. Плагины оптимизации могут делать то же самое, но уже по своим правилам. Поэтому сначала важно понять, кто именно ставит lazy load: ядро, тема или плагин.
Диагностика проблемы
Начните не с кода, а с проверки факта. Откройте страницу в Chrome DevTools и посмотрите:
- какое изображение является LCP-элементом;
- есть ли у него
loading="lazy"в HTML; - не подменяется ли картинка через JS после загрузки;
- не стоит ли на ней CSS-фон вместо
<img>.
Если LCP — это картинка, а она помечена как lazy, причина уже почти найдена. Дополнительно проверьте исходный HTML страницы: иногда тема выводит изображение через шаблон, а плагин оптимизации потом переписывает атрибуты на лету.
Что смотреть в отчёте Lighthouse
В Lighthouse полезны не только баллы, а конкретные подсказки. Ищите предупреждения вроде «Defer offscreen images» и смотрите, не попало ли в список изображение первого экрана. Если оно там есть, отложенная загрузка применяется слишком агрессивно.
Как отключить lazy load только для нужных изображений
Самый надёжный путь — не выключать lazy load целиком, а исключить конкретные изображения. Для этого в WordPress есть фильтр wp_img_tag_add_loading_attr. Он позволяет управлять атрибутом loading для каждого изображения отдельно.
<?php
add_filter( 'wp_img_tag_add_loading_attr', function( $value, $image, $context ) {
// Не трогаем изображения в админке и в нестандартных контекстах.
if ( is_admin() ) {
return $value;
}
// Отключаем lazy load для первого изображения в контенте записи.
if ( $context === 'the_content' ) {
static $first_image_skipped = false;
if ( ! $first_image_skipped ) {
$first_image_skipped = true;
return false;
}
}
return $value;
}, 10, 3 );Этот вариант подходит, если вам нужно убрать lazy load у первого изображения в контенте. Но для шапки, баннера или отдельного шаблона лучше работать точнее — через класс, ID или контекст вывода в теме.
Отключение по CSS-классу или размеру
Если тема выводит критическое изображение с понятным классом, можно проверять HTML-строку и отключать lazy load только для него. Это грубее, но на практике удобно для точечных исключений.
<?php
add_filter( 'wp_img_tag_add_loading_attr', function( $value, $image, $context ) {
if ( false !== strpos( $image, 'class="hero-image"' ) ) {
return false;
}
if ( false !== strpos( $image, 'class="site-logo"' ) ) {
return false;
}
return $value;
}, 10, 3 );Такой подход не идеален с точки зрения архитектуры, но он рабочий, если у вас нет доступа к шаблону плагина или темы. Главное — не делать проверку слишком общей, иначе вы случайно отключите lazy load у лишних изображений.
Если lazy load добавляет плагин оптимизации
У плагинов логика часто своя. Некоторые умеют исключать изображения по классу, URL или селектору. В этом случае лучше использовать встроенные настройки, а не писать костыли в functions.php. Это проще поддерживать и легче откатывать.
| Подход | Когда подходит | Минус |
|---|---|---|
| Настройки плагина | Если lazy load включён в плагине оптимизации | Зависимость от интерфейса и конкретного плагина |
| Фильтр WordPress | Если нужно исключить изображения точечно | Нужно аккуратно выбрать условие |
| Правка шаблона темы | Если изображение выводится в одном месте и всегда одинаково | Сложнее поддерживать при обновлении темы |
Если вы используете плагин оптимизации и он умеет исключения, сначала проверьте именно его. Код нужен тогда, когда настройка отсутствует или работает слишком грубо.
Пошаговое решение без лишнего риска
- Определите, какое изображение является LCP на странице.
- Проверьте, кто добавляет
loading="lazy": ядро, тема или плагин. - Оставьте lazy load для изображений ниже первого экрана.
- Исключите только критические изображения: баннер, логотип, первый кадр.
- После правки очистите кеш страницы, объектный кеш и CDN, если он есть.
- Снова прогоните страницу через Lighthouse или PageSpeed Insights.
Как проверить, что решение сработало
Проверка должна быть не визуальной, а технической. Откройте исходный код страницы и убедитесь, что у нужного изображения больше нет loading="lazy". Затем в DevTools на вкладке Network посмотрите, что файл запрашивается сразу, а не после прокрутки.
Если вы тестируете LCP, сравнивайте не только итоговый показатель, но и цепочку загрузки: когда стартует запрос картинки, не блокируется ли она CSS или JS, не уехал ли элемент ниже первого экрана из-за поздней подстановки контента.
Полезно проверить и мобильную версию. Иногда на десктопе изображение видно сразу, а на узком экране оно уходит ниже первого экрана, и тогда lazy load уже не мешает.
Частые ошибки и как их исправить
- Отключили lazy load глобально. В итоге выросла нагрузка на страницу с большим количеством изображений. Исправление: исключайте только первый экран, а не весь сайт.
- Правят не тот фильтр. В WordPress есть несколько механизмов, связанных с изображениями, и не все они отвечают за
loading. Исправление: проверяйте исходный HTML после каждого изменения. - Не очистили кеш. Изменение в коде есть, но на фронтенде всё по-старому. Исправление: сбросьте кеш плагина, серверный кеш и CDN.
- Проверяют только главную страницу. На внутренних страницах логика может отличаться. Исправление: тестируйте шаблоны, где есть крупные изображения над первым экраном.
- Путают lazy load с preload. Это разные механизмы. Исправление: если картинку нужно грузить раньше, иногда нужен
preload, а не просто отключение lazy load.
Безопасность и производительность
Если вы добавляете код в functions.php, лучше делать это в дочерней теме или через небольшой mu-plugin. Так правка не потеряется после обновления темы. Для production-сайта это надёжнее, чем редактировать файлы напрямую в родительской теме.
Не стоит отключать lazy load «на всякий случай». Для длинных страниц с галереями, каталогами и списками записей он по-прежнему полезен. Ваша задача — убрать задержку только там, где она реально мешает первому экрану.
Если нужно быстро навести порядок в технических настройках сайта, иногда удобнее использовать набор точечных инструментов вроде Clearfy Pro: он помогает управлять лишними функциями и дублями без ручного разбрасывания правок по теме. Но даже в этом случае логику исключений для критических изображений лучше проверять вручную.
Когда после правки первый экран начинает загружаться без задержки, а остальные изображения по-прежнему подгружаются лениво, это и есть нормальный результат: не «выключили оптимизацию», а настроили её под конкретный шаблон.