Как ускорить изображения в WordPress: Web Vitals и WebP

Последнее обновление: June 28, 2026

Это спутник, ориентированный на скорость, к моему руководству по оптимизации изображений WordPress для 2026 года WordPress image optimization guide for 2026. В том руководстве описывается общая настройка: плагины, srcset, CDN и htaccess. Это же сужает фокус до одного вопроса: как сделать изображения WordPress достаточно быстрыми, чтобы показатели Core Web Vitals стали зелеными? Я измерил каждый шаг на своем блоге с большим количеством медиаконтента, и улучшения, описанные ниже, — это то, что действительно переместило Largest Contentful Paint с 3.8s до 1.1s.

Быстрый ответ: что делает изображения в WordPress быстрыми?

Сжимайте каждое изображение в WebP перед загрузкой, ограничьте его отображаемую ширину так, чтобы браузер никогда не скачивал файл размером 4000px для слота в 400px, используйте ленивую загрузку всего ниже сгиба и разместите CDN перед /wp-content/uploads/. На моем собственном блоге эти четыре шага сократили общий вес изображений на 84 percent и снизили мобильный LCP с 3.8s до 1.1s. Largest Contentful Paint в блоге WordPress почти всегда является изображением, поэтому именно здесь и кроется скорость.

Почему изображения WordPress влияют на ваши Core Web Vitals?

Core Web Vitals оценивают воспринимаемую скорость, и чаще всего на WordPress падает Largest Contentful Paint, который для контентного сайта обычно является главным или первым встроенным изображением. Я запустил PageSpeed Insights на 40 своих постах, и элемент LCP был изображением в 37 из них.

Изображения также косвенно влияют на другие метрики:

• Главное изображение (hero) размером 4MB блокирует LCP до завершения загрузки в режиме медленного 4G.
• Происходит скачок Layout shift, когда изображения поступают без указания ширины и высоты.
• INP страдает, когда гигантская очередь изображений лишает основного потока ресурсов во время парсинга (parse).

Google измеряет их по реальным пользователям Chrome и включает в них сигналы ранжирования поиска, о чем подробно описано в web.dev fast loading guidance. Решение редко кроется на сервере. Чаще всего проблема в изображениях.

Как сильно можно уменьшить вес изображений?

Я зафиксировал эти цифры на одном блоге до и после оптимизации. Те же посты, тот же контент, изменились только изображения.

Падение с 9.4MB до 1.1MB — это не исключительный случай. Это происходит, когда вы перестаете публиковать несжатые JPEG в нативном разрешении. Самый большой рычаг воздействия — это формат и размеры, которые подробно разбирает руководство optimize images for web speed, рассматривая метрику за метрикой.

Что такое LCP и почему это почти всегда изображение?

Largest Contentful Paint отмечает момент рендеринга самого большого видимого элемента. В блоге на WordPress этим элементом является фото-заголовок, изображение в статье или первое большое встроенное изображение — а не текст. Пока это изображение не загружено, декодировано и не отображено (painted), для пользователя и для Google страница выглядит так, будто она «еще загружается».

Три вещи могут увеличить LCP изображения, и я проверяю все три при каждом аудите:

• Файл слишком большой для области просмотра (viewport), которую он занимает.
• Изображение LCP ошибочно загружается отложенно (lazy-loaded), поэтому оно начинает загружаться поздно.
• Отсутствие CDN, из-за чего файл передается с одного источника (origin) на другом конце света.

Последние две — это ошибки конфигурации, которые можно исправить за минуты. Первая — это привычка при загрузке файлов, о которой подробно рассказано в руководстве по размеру файлов изображений image file size guide.

Какой формат изображения самый быстрый для WordPress?

WebP. Он на 25–35 процентов меньше, чем JPEG при равном воспринимаемом качестве, и ядро WordPress поддерживает загрузку его с версии 6.5. AVIF сжимает еще на 20–30 процентов меньше, но поддержка браузерами и CDN все еще неравномерна, поэтому я рассматриваю его как дополнительный слой, а не базовый.

Я сжимаю в WebP перед загрузкой и позволяю CDN выбирать AVIF для браузеров, которые это поддерживают. Для более глубокого сравнения форматов я отправляю людям сравнение JPG PNG WebP как эталон.

Как обеспечить нужный размер изображения для каждого устройства?

Это преимущество, которое люди часто упускают. WordPress автоматически генерирует размеры thumbnail, medium, large и intermediate и выдает srcset, но только если ваша тема вызывает wp_get_attachment_image() вместо жесткого кодирования тега <img>. Телефон никогда не должен загружать файл размером 2560px.

Разметка, которую выдает WordPress, выглядит следующим образом:

<img
  src="hero-1536x800.webp"
  srcset="hero-768x400.webp 768w,
          hero-1200x628.webp 1200w,
          hero-1536x800.webp 1536w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1536" height="800"
  alt="Storefront hero photograph at full width">

Как я проверяю это: откройте DevTools, установите ограничение на Slow 4G, перезагрузите страницу и понаблюдайте за вкладкой Network. Телефон должен запросить файл размером 768w. Если каждое устройство загружает один и тот же URL, значит, тема сломана или конструктор страниц обходит адаптивную разметку. Логика точек останова находится в руководстве responsive image breakpoints.

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

С версии WordPress 5.5 каждое <img> по умолчанию получает loading="lazy", а версия 6.1 добавила подсказку fetchpriority="high" для первого крупного изображения, чтобы оно больше не конфликтовало с ленивым загрузчиком. Вам редко понадобится плагин для этого, что является реальным приростом скорости без какой-либо настройки.

Два правила, которые я соблюдаю, потому что оба раза снижали мой LCP до того, как я их заметил:

• Никогда не используйте ленивую загрузку для изображения LCP в верхней части экрана (above the fold).
• Всегда устанавливайте явную ширину и высоту, чтобы предотвратить сдвиг макета.

В официальной документации по ленивой загрузке WordPress перечислены фильтры для исключения элемента LCP и ленивой загрузки iframes. О распространенных ошибках, включая ошибку с героем (hero mistake), прочитайте наш материал о ленивой загрузке изображений.

Как CDN ускоряет изображения в WordPress?

CDN обслуживает каждое изображение с ближайшего к посетителю edge и устраняет круговые пути до вашего origin. После того как я перевел одного клиента с JPEGs, размещенных на origin, на Cloudflare с включенным Polish, TTFB изображений упал с 420ms до 60ms для посетителей в Сингапуре и Бразилии — двух регионов, где их отчет PageSpeed был красным.

Что я настраиваю на каждом сайте:

• Cloudflare with Polish on, lossless plus WebP.
• Кэшировать все в папке /wp-content/uploads/.
• Кеш браузера на один год для MIME-типов изображений.
• CDN-negotiated AVIF layer на базе WebP.

Edge-кэширование наиболее важно для магазинов WooCommerce с большим количеством изображений и блогов с несколькими авторами. Полная настройка, включая заголовки кэша и правила очистки (purge rules), описана в image CDN guide.

Главный вывод: четырехэтапная "стека" скорости

Если вы ничего больше не запомните, запомните эти четыре пункта, потому что они ответственны за падение LCP, которое я измерил:

1. Сжимайте до WebP перед загрузкой, не более 200KB на изображение.
2. Ограничьте ширину отображения и позвольте srcset подавать нужный файл.
3. Используйте ленивую загрузку для контента ниже сгиба (below the fold), но никогда — для изображения LCP.
4. Кэшируйте изображения на краевом узле CDN с TTL в один год.

Сделайте это, и ваш отчет Core Web Vitals станет зеленым. Пропустите этап адаптивного srcset, и даже идеально сжатый WebP все равно отправит файл для рабочего стола на телефон.

Чеклист по скорости перед запуском

• Изображение LCP должно быть в формате WebP и весить менее 200KB.
• Изображение LCP должно иметь fetchpriority="high", а не loading="lazy".
• Должен присутствовать srcset, и на телефоне загружается небольшой файл.
• У каждого изображения должны быть указаны явные ширина и высота.
• CDN должен кэшировать /wp-content/uploads/.
• Кэш браузера для изображений установлен на один год.
• Мобильный LCP менее 2.5s в PageSpeed.
• CLS ниже 0.1 без смещения, вызванного изображениями.

Одно реальное предостережение: сжатый WebP при качестве ниже 70 рано или поздно подведет вас для предметной фотографии и экранов Retina, где текстура и детализация краев продают продукт. Я сохраняю каждый оригинал в облачном хранилище и переэкспортирую оттуда, потому что как только вы перезапишете исходник сжатой копией, детали потеряны навсегда. Проверьте на пяти реальных изображениях, прежде чем конвертировать тысячу сразу.

Изображения в качестве референса

• Яркое рабочее место с настольным компьютером, используемым для управления сайтом на WordPress — фото от SHVETS Production на Pexels
• Уютный домашний офис с ноутбуком, открытым на записи блога WordPress — фото от Pixabay на Pexels
• MacBook, отображающий страницу поиска Google на деревянном столе на улице — фото от Pixabay на Pexels
• Программист, кодирующий на ноутбуке и мониторе в современном офисе — фото от Claudio Emanuel на Pexels