Как отключить отложенную загрузку изображений в WordPress для критического первого экрана

Отложенная загрузка изображений полезна почти всегда, пока не начинает мешать первому экрану. Типичный сценарий: на главной, в шапке статьи или на лендинге крупная картинка грузится с loading="lazy", браузер откладывает запрос, а визуально страница «тяжелеет» и хуже проходит проверку по LCP. В WordPress это часто происходит не из-за ядра, а из-за темы, конструктора или оптимизирующего плагина.

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

Когда lazy load становится проблемой

Проверять нужно не по ощущениям, а по факту. Если картинка в первом экране получает loading="lazy", браузер может отложить её запрос до тех пор, пока не поймёт, что элемент близко к viewport. Для hero-изображения это лишняя задержка.

Признаки, что проблема именно в lazy load

• в отчёте Lighthouse или PageSpeed у изображения первого экрана высокий вклад в LCP;
• в HTML у hero-картинки есть loading="lazy";
• в DevTools на вкладке Network запрос к изображению стартует заметно позже HTML и CSS;
• после отключения lazy load только для первого изображения LCP улучшается, а количество запросов на длинных страницах почти не меняется.

Если у вас медленный сервер, тяжёлый шрифт или блокирующий JS, lazy load может быть не единственной причиной. Но если картинка первого экрана явно откладывается, это хороший кандидат на точечную правку.

Диагностика: где именно WordPress добавляет lazy load

В WordPress атрибут loading может появляться из нескольких мест: ядро, тема, фильтры плагинов оптимизации, фильтры в functions.php или HTML, который генерирует блок/конструктор. Поэтому сначала нужно понять источник.

1. Откройте страницу в браузере и посмотрите исходный HTML.
2. Найдите изображение первого экрана и проверьте, есть ли у него loading="lazy".
3. Если атрибут есть, проверьте, не добавляет ли его плагин оптимизации изображений или кэш-плагин.
4. Если атрибута нет в исходнике, но он появляется в DOM после загрузки, значит вмешивается JS-скрипт.

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

Как отключить lazy load только для первого изображения

Самый надёжный вариант — не выключать механизм целиком, а снять lazy load с конкретного изображения по его ID. Это работает, если изображение вставлено через медиатеку WordPress и у него есть attachment ID.

Вариант через фильтр wp_img_tag_add_loading_attr

Начиная с современных версий WordPress, для управления атрибутом loading у тега img можно использовать фильтр wp_img_tag_add_loading_attr. Он позволяет вернуть false для нужного изображения и тем самым убрать lazy load.

<?php
add_filter( 'wp_img_tag_add_loading_attr', function( $value, $image, $context ) {
    if ( is_admin() ) {
        return $value;
    }

    // Снимите lazy load только с изображения первого экрана.
    // Пример: проверяем attachment ID, если он известен.
    $hero_image_id = 123;

    if ( ! empty( $image['attachment_id'] ) && (int) $image['attachment_id'] === $hero_image_id ) {
        return false;
    }

    return $value;
}, 10, 3 );

Этот способ удобен, если hero-картинка одна и вы точно знаете её ID. Но на практике ID не всегда стабилен, особенно если контент редактируют разные люди. Тогда лучше ориентироваться на контекст вывода.

Вариант через исключение по размеру или классу

Если тема выводит у первого изображения отдельный класс, можно использовать фильтр wp_get_attachment_image_attributes и убрать loading по признаку класса.

<?php
add_filter( 'wp_get_attachment_image_attributes', function( $attr, $attachment, $size ) {
    if ( is_admin() ) {
        return $attr;
    }

    if ( ! empty( $attr['class'] ) && strpos( $attr['class'], 'hero-image' ) !== false ) {
        unset( $attr['loading'] );
        $attr['fetchpriority'] = 'high';
        $attr['decoding'] = 'async';
    }

    return $attr;
}, 10, 3 );

Здесь важно не переборщить: fetchpriority="high" имеет смысл только для действительно главного изображения страницы. Если поставить его на несколько картинок, браузер может начать конкурировать сам с собой за приоритеты.

Если изображение выводится как фон

Lazy load через img на фоновые изображения не влияет напрямую. Если hero-блок сделан через CSS background-image, проблема обычно в другом: фон грузится поздно из-за CSS, JS или ленивой подгрузки самого блока. В этом случае лучше вынести критический фон в HTML-изображение или убедиться, что блок не скрыт до инициализации скрипта.

Сравнение подходов

Пошаговое решение без поломки остальной оптимизации

1. Определите изображение первого экрана, которое влияет на LCP.
2. Проверьте, откуда приходит loading="lazy".
3. Добавьте точечное исключение через фильтр в дочерней теме или мини-плагине.
4. Для hero-изображения задайте fetchpriority="high", если оно действительно одно на странице.
5. Очистите кэш страницы и CDN, если они используются.
6. Снова проверьте HTML и сетевые запросы.

Если вы работаете с несколькими типами страниц, лучше вынести логику в отдельную функцию и ограничить её только нужными шаблонами: главная, одиночная запись, посадочная страница.

<?php
add_filter( 'wp_get_attachment_image_attributes', function( $attr, $attachment, $size ) {
    if ( is_admin() ) {
        return $attr;
    }

    if ( ! is_front_page() && ! is_singular( 'post' ) ) {
        return $attr;
    }

    if ( ! empty( $attr['class'] ) && strpos( $attr['class'], 'site-hero__image' ) !== false ) {
        unset( $attr['loading'] );
        $attr['fetchpriority'] = 'high';
    }

    return $attr;
}, 10, 3 );

Как проверить, что решение сработало

Проверка должна быть двойной: в HTML и в поведении браузера.

• Откройте исходный код страницы и убедитесь, что у hero-изображения больше нет loading="lazy".
• В DevTools на вкладке Network проверьте, что запрос к изображению стартует сразу после загрузки HTML, а не после прокрутки.
• Сравните LCP до и после на той же странице, в тех же условиях.
• Проверьте мобильную версию отдельно: именно там lazy load чаще всего мешает заметнее.

Если у вас подключён PageSpeed Insights, не гонитесь за единичным баллом. Смотрите на конкретный элемент, который стал LCP, и на то, когда он начал загружаться.

Частые ошибки и как их исправить

Отключили lazy load вообще для всего сайта

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

Сняли lazy load не с того изображения

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

Поставили fetchpriority="high" на несколько картинок

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

Плагин оптимизации снова добавляет lazy load

Некоторые плагины имеют собственные настройки и фильтры. Если после правки атрибут возвращается, ищите отдельную опцию в плагине или исключение по CSS-классу/URL.

Что учесть по безопасности и производительности

Правки лучше делать не в functions.php активной темы, а в дочерней теме или небольшом mu-plugin. Тогда обновление шаблона не затрёт изменения. Если на сайте есть кэш, после внедрения обязательно очистите серверный кэш, объектный кэш и CDN, иначе вы будете проверять старую версию HTML.

Если вы уже используете комплексную оптимизацию и чистку WordPress, часть таких исключений можно централизовать в инструментах вроде Clearfy Pro: это удобнее, чем держать набор разрозненных сниппетов в теме. Но даже в этом случае логику исключения первого экрана всё равно нужно проверять вручную, потому что тема и шаблон могут генерировать HTML по-разному.

Практический ориентир простой: lazy load должен помогать длинным страницам, а не мешать первому экрану. Если после точечного исключения hero-изображение начинает грузиться раньше, а остальная страница не раздувается по запросам, решение сделано правильно.