Почему картинки решают судьбу скорости сайта
Когда клиент приходит с жалобой «сайт медленный», в девяти случаях из десяти мы начинаем разбор не с хостинга и не с кода темы, а с медиатеки. Изображения — самый тяжёлый тип контента на типовом сайте: они формируют основную часть веса страницы и почти всегда становятся тем самым элементом, который браузер дольше всего отрисовывает в видимой области.
Дело не только в ощущениях пользователя: Google тоже измеряет скорость — через метрику Largest Contentful Paint, время отрисовки самого крупного элемента в области просмотра. Официальный ориентир: LCP должен укладываться в 2,5 секунды, причём оценивается 75-й перцентиль загрузок, отдельно для мобильных и десктопа. То есть недостаточно, чтобы сайт быстро открывался у вас в офисе на оптоволокне — он должен открываться быстро у трёх четвертей реальных посетителей, включая тех, кто заходит с телефона в дороге.
А самый крупный элемент в первом экране — это, как правило, именно картинка: баннер, фото товара, обложка статьи. Поэтому оптимизация изображений WordPress даёт непропорционально большой эффект по сравнению с большинством других работ по ускорению. Сжали главный визуал вдвое — и метрика сдвинулась. Переписали пару функций в теме — и не изменилось ничего.
Что WordPress уже делает за вас
Хорошая новость: ядро WordPress за последние годы серьёзно продвинулось в автоматической оптимизации картинок. Прежде чем ставить плагины, стоит понимать, что уже работает по умолчанию — иначе легко заплатить за функцию, которая давно бесплатна.
Отложенная загрузка. Начиная с версии 5.5, WordPress сам добавляет атрибут loading="lazy" к изображениям в контенте записей, в анонсах, в текстовых виджетах, к аватарам и к картинкам, выводимым через wp_get_attachment_image(). Браузер не грузит такие изображения, пока пользователь до них не долистает. Важная деталь: атрибут применяется только к изображениям, у которых уже проставлены width и height — ядро при этом само дописывает эти размеры там, где их не было.
Приоритет для главной картинки. С версии 6.3 WordPress пытается определить, какое изображение станет LCP-элементом, и вешает на него fetchpriority="high". Браузер начинает грузить эту картинку раньше, ещё до расчёта раскладки страницы. По данным команды производительности WordPress, приём даёт выигрыш по LCP порядка 5 — 10%. Порог, выше которого изображение вообще рассматривается как кандидат, задаётся фильтром wp_min_priority_img_pixels: по умолчанию это произведение ширины на высоту, равное 50 000 пикселей.
Здесь есть нюанс, о котором честно писали сами разработчики ядра: точность автоматического определения LCP-изображения — около 50% по всем сценариям. То есть примерно в половине случаев приоритет достаётся не той картинке. Для типового сайта это всё равно лучше, чем ничего, но на проектах, где скорость критична, положение главного визуала стоит проверять руками.
Ограничение исходного размера. Ещё с версии 5.3 работает фильтр big_image_size_threshold. Если загруженное изображение по ширине или высоте превышает порог — по умолчанию 2560 пикселей — WordPress масштабирует его и использует уменьшенную копию как основную. Это спасает сайты от ситуации, когда контент-менеджер заливает в блог фотографию прямо с зеркалки.
Свежие улучшения. В версии 6.4 логику расстановки атрибутов загрузки упростили и свели в одну функцию wp_get_loading_optimization_attributes(), туда же переехала обработка decoding="async", появившегося в 6.1. Появились и новые фильтры для тонкой настройки. Отдельно оговорены контексты template_part_header и get_header_image_tag — изображения в них всегда считаются «шапочными» и не получают отложенную загрузку.
В версии 6.9 фокус сместился со скриптов и стилей: инлайн-лимит для стилей подняли с 20 КБ до 40 КБ, классические темы научились подгружать стили блоков по требованию (в среднем минус 45% CSS на тестовых страницах), а скрипт определения эмодзи стал отложенным модулем в подвале, убрав около 3 КБ блокирующего JavaScript. Для картинок принципиально нового там нет — механика fetchpriority="high" для LCP-элемента, введённая в 6.3, продолжает работать.
WebP: где реальная выгода, а где миф
WebP формат для сайта перестал быть экзотикой довольно давно. С версии 5.8, вышедшей в июле 2021 года, WordPress позволяет загружать и использовать WebP-изображения ровно так же, как JPEG или PNG. Условие одно: библиотека обработки изображений на вашем сервере должна поддерживать этот формат — WordPress работает и с Imagick, и с LibGD.
По оценке из официального анонса, WebP-файлы в среднем примерно на 30% меньше эквивалентных JPEG или PNG при сопоставимом качестве. Для сайта с сотнями фотографий это буквально треть трафика.
Но есть ограничения, о которых редко пишут в рекламных материалах плагинов. Формат без потерь (lossless WebP) в медиатеке поддерживается только при работе через Imagick — LibGD этого не умеет. Анимированные изображения и картинки с альфа-каналом при создании уменьшенных копий пересобираются в lossy-вариант. То есть если у вас на сайте есть анимированные WebP или прозрачные логотипы, поведение при ресайзе нужно проверять отдельно.
И главный миф, который стоит развеять: WebP не всегда меньше JPEG. Это не наша догадка, а причина громкой истории в самом ядре WordPress. В версии 6.1 планировалось включить автоматическую генерацию WebP-копий по умолчанию для всех загружаемых изображений. Инициативу откатили: тема оказалась слишком спорной, а одним из ключевых аргументов против стало то, что на фотографиях среднего разрешения WebP нередко получается тяжелее исходного JPEG. В результате страница проходит проверку «современные форматы изображений» в PageSpeed Insights, но грузится дольше — идеальный пример оптимизации ради отчёта, а не ради пользователя.
Разработка функции переехала в отдельный плагин от команды производительности WordPress, а ядро осталось при позиции: WebP можно загружать, но автоматически ничего не конвертируется.
AVIF: следующее поколение и его цена
С версии 6.5, вышедшей в апреле 2024 года, WordPress поддерживает AVIF «из коробки» — формат включён по умолчанию, и загружать такие файлы можно как обычные JPEG или PNG. AVIF при том же качестве бывает до 50% легче JPEG, поддерживает широкий цветовой охват, включая HDR, и заметно лучше держит детализацию на сложных участках изображения.
Цена — требования к инфраструктуре. AVIF в WordPress зависит от поддержки формата в библиотеке обработки изображений на вашем сервере. В случае GD поддержка возможна только на PHP 8.1 и новее, и только если расширение собрано с поддержкой AVIF — что далеко не всегда так на бюджетном шаред-хостинге. Проверить, доступен ли формат на конкретном сервере, можно в разделе «Здоровье сайта» в админке.
Ядро при этом само в AVIF ничего не перегоняет. Для разработчиков предусмотрен фильтр image_editor_output_format, которым можно задать, в каком формате создавать производные размеры из загруженных JPEG или HEIC. Но «из коробки» этой автоматизации в ядре нет.
Как включить конвертацию на практике
Самый предсказуемый путь для типового проекта — плагин Modern Image Formats (в прошлом он назывался WebP Uploads). Его разрабатывает и поддерживает команда производительности WordPress, то есть это не сторонняя разработка, а фактически «предбанник» будущих возможностей ядра.
Что он делает:
- По умолчанию конвертирует загружаемые изображения в AVIF, если сервер это поддерживает; если нет — в WebP.
- Формат вывода выбирается в разделе «Настройки → Медиафайлы».
- Генерируются только копии в современном формате — исходный JPEG или PNG при этом остаётся на диске.
- Есть отдельный чекбокс для генерации запасных изображений: тогда для каждого размера создаётся и обычная, и современная версия.
- Начиная с версии 2.0.0 поддерживается вывод через элемент
picture.
И два ограничения, которые нужно держать в голове при планировании работ. Первое: плагин обрабатывает только то, что попадает в медиатеку — изображения, прописанные в шаблонах темы или заданные через настройщик, остаются как есть. Второе: современные форматы генерируются только для новых загрузок. Всё, что уже лежит в медиатеке, придётся пересобирать отдельно.
Что делать с уже загруженной библиотекой
Именно этот шаг чаще всего забывают. Владелец сайта ставит плагин, видит галочку «включено», радуется — а страницы продолжают отдавать те же старые JPEG, потому что новых загрузок с момента установки было три штуки.
Для пересборки существующих изображений используются либо плагины перегенерации миниатюр, либо команда WP-CLI wp media regenerate, если у вас есть доступ к консоли сервера. Второй вариант надёжнее и заметно быстрее на больших библиотеках.
Перед массовой перегенерацией есть смысл выполнить три вещи. Сделать полный бэкап файлов и базы — операция затрагивает тысячи файлов, и откатывать её вручную вы не захотите. Оценить свободное место на диске: если вы включили генерацию запасных изображений, объём папки uploads вырастет, а не сократится. И прикинуть нагрузку — на медиатеке в несколько тысяч позиций перегенерация способна положить слабый шаред-хостинг, поэтому её лучше запускать в ночные часы и порциями.
Размеры важнее формата
Здесь стоит сказать вещь, которая противоречит логике большинства статей про WebP: смена формата — не первый по важности рычаг. Первый — правильный размер картинки.
Если в карточке товара изображение выводится в блоке шириной 400 пикселей, а браузеру отдаётся файл 2000 пикселей по ширине, то конвертация в WebP сэкономит вам условные 30% от заведомо избыточного объёма. Приведение размера к реальному месту вывода экономит в разы больше — и делается бесплатно.
Отдельная история — экраны с высокой плотностью пикселей. Распространённое заблуждение: раз бывают retina-дисплеи, значит грузить надо всё в двойном размере. На практике двукратный запас нужен далеко не везде: на мелких элементах интерфейса, иконках категорий, аватарах разница почти незаметна, а вес растёт кратно. Разумный подход — двойной размер только для тех изображений, где детализация действительно продаёт: главный визуал, крупные фотографии товара, портфолио. Для остального хватает одинарного.
WordPress здесь помогает: для загруженных изображений он формирует набор размеров и отдаёт их через атрибуты srcset и sizes, позволяя браузеру самому выбрать подходящий вариант под экран и плотность пикселей. Но работает это ровно настолько хорошо, насколько корректно тема объявляет свои размеры изображений и насколько аккуратно контент-менеджеры вставляют картинки в записи. Вставленная «на глаз» полноразмерная фотография в теле статьи ломает всю схему.
Поэтому порядок работ, который мы применяем при разработке и поддержке сайтов на WordPress, выглядит так: сначала аудит реальных размеров вывода в теме, потом настройка регистрируемых размеров изображений, потом ограничение исходников на загрузке, и только после этого — включение современных форматов. В обратном порядке результат получается вдвое скромнее при тех же трудозатратах.
Картинки работают не только на скорость
Пока речь шла о весе файлов, но у медиатеки есть и вторая функция — поисковая. Атрибут alt описывает содержимое изображения для тех, кто не может его увидеть: для программ экранного доступа и для поисковых роботов. Заодно он даёт вам дополнительную точку входа через поиск по картинкам, что особенно заметно на товарных и портфолийных сайтах.
Практика здесь простая и почти всегда игнорируемая. Alt заполняется у всех содержательных изображений и описывает то, что на картинке действительно изображено, а не набор ключевых слов через запятую. Декоративные элементы — разделители, фоновые узоры — наоборот, оставляют с пустым alt, чтобы не засорять озвучивание страницы. Имя файла тоже имеет значение: осмысленное латинское имя понятнее и роботу, и вам самим через год, чем набор цифр с камеры.
Ещё один момент, который стоит проверить до массовой конвертации: как ваш плагин работает с alt-текстами и подписями при пересборке библиотеки. Если конвертация создаёт новые вложения вместо копий существующих, метаданные могут не переехать — и вы разом потеряете описания у всей медиатеки. Это ровно тот случай, когда десять минут на тестовой копии сайта экономят несколько дней ручной работы.
Иллюстративный разбор: типовой интернет-магазин
Условный пример ниже — собирательный, но собран из ситуаций, которые повторяются на большинстве проектов.
Магазин на WordPress с WooCommerce, около 1200 товаров, каталог с сеткой карточек. Симптомы: главная и страницы категорий открываются на мобильных ощутимо медленно, LCP не укладывается в норматив, отчёт PageSpeed настойчиво рекомендует «использовать современные форматы изображений».
Что обычно обнаруживается при разборе. Фотографии товаров залиты менеджерами напрямую от поставщиков — по 2500 — 4000 пикселей по длинной стороне, каждая по паре мегабайт. Тема выводит в карточке каталога изображение шириной около 300 пикселей, но берёт его из размера, зарегистрированного как 1200 пикселей, потому что так проще было сверстать. В шапке стоит баннер, вставленный в шаблон напрямую, — то есть мимо медиатеки. Плагин кэширования установлен и настроен, но к картинкам он отношения не имеет.
Порядок действий в такой ситуации: привести размеры вывода в каталоге к реальным, чтобы карточка получала подходящий размер вместо избыточного; убедиться, что ограничение исходного размера на загрузке работает и менеджеры физически не могут залить четырёхтысячник в исходном виде; вынести баннер шапки в медиатеку, чтобы он попал под общую логику оптимизации; включить генерацию современных форматов и перегенерировать библиотеку по частям; и уже после этого проверить, действительно ли fetchpriority="high" достался главной картинке первого экрана, а не случайному логотипу.
Три из пяти шагов здесь вообще не про WebP: формат даёт финальный процент экономии, а основной вес снимается наведением порядка в размерах и в дисциплине загрузки контента.
Чек-лист для самопроверки
Если хотите быстро оценить состояние своего сайта, пройдитесь по списку:
- Версия WordPress — 6.5 или новее? Если нет, вы лишены и AVIF, и части улучшений по приоритетам загрузки.
- В «Здоровье сайта» видно, какие форматы поддерживает сервер? Проверьте, доступны ли WebP и AVIF на вашем тарифе хостинга.
- Какой самый тяжёлый файл на главной странице? Если это фотография весом больше пары сотен килобайт — начинать надо с неё.
- Совпадает ли размер файла с размером блока, в котором он выводится? Разница в два раза и больше — прямая потеря скорости.
- Работает ли отложенная загрузка на картинках ниже первого экрана и, наоборот, отключена ли она для главного визуала?
- Если плагин конвертации уже стоит — перегенерировали ли вы старую библиотеку или он обрабатывает только новые загрузки?
- Не выросла ли папка uploads после включения запасных изображений сильнее, чем вы рассчитывали?
Каждый пункт, на который вы ответили «не знаю», — это потенциально несколько десятых секунды LCP.
Частые вопросы
Нужен ли отдельный плагин, если WordPress и так поддерживает WebP?
Да, если вы хотите автоматическую конвертацию. Поддержка в ядре означает возможность загружать и использовать WebP-файлы, но ядро само ничего не перегоняет из JPEG. За автоматику отвечает плагин Modern Image Formats от команды производительности WordPress либо кастомная реализация через фильтр image_editor_output_format.
WebP или AVIF — что выбрать в 2026 году?
AVIF даёт более сильное сжатие: до 50% относительно JPEG против примерно 30% у WebP. Но он требовательнее к серверу — в случае GD нужна PHP 8.1 или новее и сборка с поддержкой AVIF. Практичный подход: включить AVIF, если сервер его поддерживает, с откатом на WebP. Именно так по умолчанию и работает плагин Modern Image Formats.
Потеряю ли я позиции в поиске из-за смены формата картинок?
Сам по себе формат файла позиции не меняет. Меняет их скорость загрузки, которая входит в оценку пользовательского опыта. При этом важно не сломать существующие URL изображений и корректно сохранить атрибуты alt — если конвертация выполняется с заменой файлов, это стоит проверить отдельно после запуска.
Почему после включения WebP некоторые картинки стали весить больше?
Это известный эффект, из-за которого автоматическую конвертацию в своё время не стали включать в ядре по умолчанию: на фотографиях среднего разрешения WebP не всегда выигрывает у JPEG. Проверяйте вес до и после на выборке реальных изображений вашего сайта, а не только показания синтетических тестов.
Что делать со старыми изображениями в медиатеке?
Их нужно пересобрать — либо плагином перегенерации миниатюр, либо командой wp media regenerate через WP-CLI. Обязательно с бэкапом и с запасом свободного места на диске, особенно если включена генерация запасных изображений.
Оптимизация изображений — та редкая работа, где результат виден в цифрах уже в день внедрения, а не через квартал. Начните с одной страницы: найдите на ней самый тяжёлый файл, приведите его к реальному размеру вывода, отдайте в современном формате и замерьте LCP до и после. Полученная цифра обычно убеждает лучше любых аргументов о том, стоит ли наводить порядок во всей медиатеке.