Отложенная загрузка изображений в WordPress обычно полезна, но в реальных проектах она иногда ломает первый экран: слайдеры дергаются, превью в шапке появляются с задержкой, а LCP в отчётах становится хуже, чем был до оптимизации. В таких случаях не нужно отключать lazy load на всём сайте — чаще достаточно убрать его только там, где он мешает.
Когда lazy load действительно мешает
Проблема обычно проявляется не на всех страницах, а в конкретных сценариях:
- главное изображение статьи загружается позже текста и сдвигает верстку;
- в шапке стоит баннер или слайдер, который должен быть виден сразу;
- на главной странице первый экран состоит из нескольких картинок, и браузер откладывает их загрузку;
- вставки через блоки темы или плагина получают
loading="lazy", хотя должны быть приоритетными; - после обновления темы или плагина картинка стала появляться с задержкой, хотя раньше всё было нормально.
Как понять, что виноват именно lazy load
Откройте страницу в браузере и проверьте исходный HTML. Если у важного изображения есть атрибут loading="lazy", а оно находится в первом экране, это уже повод для точечной правки. Дополнительно посмотрите в DevTools на сетевые запросы: приоритет у картинки должен быть высоким, а не отложенным до скролла.
Ещё один практичный способ — сравнить страницу до и после отключения lazy load только для проблемного блока. Если картинка начинает загружаться сразу, а визуальный сдвиг исчезает, причина найдена.
Что лучше: отключить всё или только часть
Полное отключение lazy load — самый простой путь, но он почти всегда ухудшает производительность на длинных страницах. Для технически аккуратного сайта лучше снять отложенную загрузку только с тех изображений, которые находятся выше первого экрана.
| Подход | Когда уместен | Компромисс |
|---|---|---|
| Отключить lazy load глобально | Если сайт маленький и важнее стабильный первый экран | Больше ранних запросов и хуже поведение на длинных страницах |
| Исключить только hero-изображения | Если проблема только в шапке, слайдере или первом блоке | Нужно знать селекторы и проверить шаблон |
| Оставить lazy load как есть | Если первый экран не страдает | Ничего не меняется, но проблема может остаться |
Пошаговое решение через код
Ниже пример, который снимает lazy load с изображений в первом экране по классу. Это безопаснее, чем отключать механизм целиком. Код можно добавить в functions.php дочерней темы или в собственный мини-плагин.
add_filter( 'wp_img_tag_add_loading_attr', function( $value, $image, $context ) {
if ( is_admin() ) {
return $value;
}
// Не трогаем изображения в контенте, если они не помечены как критичные.
if ( false === strpos( $image, 'class="hero-image"' ) ) {
return $value;
}
return false;
}, 10, 3 );Что делает этот код: если у изображения есть класс hero-image, WordPress не добавит ему атрибут loading="lazy". Для остальных картинок поведение останется прежним.
Если вам нужно убрать lazy load у изображения по ID вложения, а не по классу, удобнее работать на уровне шаблона и явно выводить нужный тег без отложенной загрузки. Например:
<?php
$image_id = 123;
$src = wp_get_attachment_image_url( $image_id, 'full' );
$alt = get_post_meta( $image_id, '_wp_attachment_image_alt', true );
if ( $src ) :
?>
<img src="<?php echo esc_url( $src ); ?>" alt="<?php echo esc_attr( $alt ); ?>" width="1200" height="630" fetchpriority="high" decoding="async">
<?php endif; ?>Здесь важно не забыть про width и height: без них можно получить сдвиг макета, даже если lazy load отключён.
Если нужно убрать lazy load только для первого изображения в записи
Для контентных страниц можно обработать HTML фильтром и снять атрибут только у первого изображения. Это уже более тонкая настройка, но её стоит применять осторожно: фильтр должен быть предсказуемым и не ломать разметку.
add_filter( 'the_content', function( $content ) {
if ( is_admin() || ! is_singular() ) {
return $content;
}
$replaced = 0;
$content = preg_replace_callback( '/<img[^>]+>/i', function( $matches ) use ( &$replaced ) {
if ( $replaced >= 1 ) {
return $matches[0];
}
$img = $matches[0];
$img = preg_replace( '/\sloading=("|")lazy\1/i', '', $img );
$img = preg_replace( '/\sdecoding=("|")async\1/i', '', $img );
$img = preg_replace( '/<img/i', '<img fetchpriority="high"', $img, 1 );
$replaced++;
return $img;
}, $content, 1 );
return $content;
} );Этот вариант подходит только если вы понимаете структуру контента и уверены, что первое изображение действительно должно быть приоритетным. Для сложных шаблонов лучше править вывод в теме, а не постфактум в контенте.
Диагностика после внедрения
Проверка нужна не только визуально. Сначала откройте страницу в режиме инкогнито и убедитесь, что первый экран загружается без заметной задержки. Затем проверьте исходный код страницы:
- у критичного изображения нет
loading="lazy"; - есть корректные размеры
widthиheight; - если это главный баннер, можно добавить
fetchpriority="high"; - в DevTools картинка уходит в ранние запросы, а не появляется только после скролла.
После этого прогоните страницу через Lighthouse или PageSpeed Insights и сравните не только общий балл, а именно поведение первого экрана. Если проблема была в LCP, смотрите, изменился ли момент отрисовки крупного элемента. Если нет — значит, причина может быть не в lazy load, а в тяжёлом CSS, шрифте или стороннем скрипте.
Частые ошибки и как их исправить
Отключили lazy load на всём сайте
Это частая реакция, когда хочется быстро убрать задержку у первого изображения. Но вместе с этим вы теряете смысл отложенной загрузки на длинных страницах. Исправление простое: верните глобальное поведение и исключите только нужные изображения по классу, ID или шаблону.
Убрали lazy load, но забыли про размеры
Если у картинки нет фиксированных размеров, браузер не знает, сколько места ей нужно. В результате страница всё равно может прыгать. Проверьте, что тема выводит width и height, либо задаёт стабильные пропорции через CSS.
Правили HTML через слишком общий regex
Когда фильтр удаляет атрибуты из всех <img>, легко задеть иконки, эмодзи, изображения плагинов и другие элементы, которые лучше не трогать. Если используете обработку контента, ограничьте её конкретным шаблоном или классом.
Сломали совместимость с плагином оптимизации
Некоторые плагины кеша и оптимизации тоже управляют lazy load. Если у вас уже есть такая настройка, не дублируйте её в теме. Иначе один слой может добавлять атрибут, а другой — пытаться его убрать, и итоговое поведение станет непредсказуемым.
Что проверить в производительности и безопасности
После изменения лучше не оставлять код в виде временного хака. Если правка нужна надолго, вынесите её в отдельный мини-плагин или в дочернюю тему. Так проще откатить изменение после обновления шаблона.
- проверьте страницу на мобильном и десктопе отдельно;
- сравните исходный HTML до и после;
- посмотрите, не появилось ли лишних запросов к изображениям выше первого экрана;
- убедитесь, что код не выполняется в админке;
- не правьте ядро WordPress — обновление всё перетрёт.
Если у вас на сайте уже стоит плагин для технической чистки и SEO, например Clearfy Pro, часть подобных настроек можно централизовать в админке. Но даже в этом случае полезно понимать, что именно отключается и на каких страницах это влияет на LCP и визуальную стабильность.
Главная идея простая: lazy load нужен не для красоты, а для баланса между скоростью и удобством. Если первый экран от него страдает, отключайте точечно, проверяйте HTML и не забывайте возвращать контроль над изображениями в шаблон, а не в случайные правки контента.