Оптимизация изображений WordPress: размеры, srcset, WebP

Большинство медленных страниц на WordPress тормозят из-за картинок, причём почти весь этот вес можно убрать. Порядок работы всегда один. Сначала перестаньте загружать файлы, которые намного больше любого экрана. Затем убедитесь, что WordPress отдаёт каждому посетителю копию подходящего размера через srcset. Потом включите ленивую загрузку для всего, что находится ниже первого экрана, но никогда не для главного изображения вверху страницы. И только после этого имеет смысл переводить файлы в WebP: обычно это экономит от четверти до трети объёма при том же видимом качестве. Чем конвертировать - плагином или офлайн на своём компьютере - зависит от количества изображений, от того, как часто вы добавляете новые, и от того, сколько CPU даёт ваш тариф. Ниже разобран каждый шаг: настройки, фильтры и команды, и прямо сказано, где шаг даёт меньше, чем обещает реклама.

Откуда берётся вес#

Откройте в браузере панель Network на медленной странице WordPress и отсортируйте по размеру. Картина обычно одна и та же: несколько изображений составляют большую часть трафика - фото с телефона в 4000 пикселей в роли главного баннера, PNG-скриншот на 2 МБ, логотип в файле на 900 КБ, галерея из двадцати полноразмерных JPEG, уменьшенных средствами CSS. Браузер скачивает каждый байт, даже если отрисует всего 400 пикселей.

Здесь три разные проблемы, и лечатся они по-разному.

• Слишком много пикселей. Изображение в 4000 пикселей в колонке шириной 700 содержит примерно в тридцать раз больше пикселей, чем можно показать. Решение: уменьшить размер.
• Слишком много байтов на пиксель. JPEG, сохранённый с качеством 100, в несколько раз больше версии с качеством 80, а разницы на глаз нет. Решение: сжать или выбрать более удачный формат.
• Слишком много изображений сразу. Странице с сорока картинками не нужны все сорок, пока посетитель не прокрутил её. Решение: ленивая загрузка.

Конвертация в WebP решает только вторую проблему и подходит в последнюю очередь. Если отдать изображение в 4000 пикселей в формате WebP, файл станет меньше, но всё равно останется слишком большим. В материале как хостинг влияет на TTFB и Core Web Vitals объяснено, почему самое крупное изображение обычно и есть тот элемент, который измеряет Largest Contentful Paint, - поэтому правильная работа с картинками двигает показатель, на который смотрят поисковые системы. Скорость сервера тут не спасает: 3 МБ остаются 3 МБ на любом хостинге.

Что WordPress делает с загрузкой сам#

Когда вы добавляете файл в Media Library, WordPress сохраняет оригинал и создаёт уменьшенные копии. Размеры по умолчанию настраиваются в Настройки - Медиафайлы, а темы и плагины регистрируют свои в коде.

Темы добавляют новые размеры через add_image_size(), и каждый из них умножает число файлов на одну загрузку. Одна загрузка легко порождает от десяти до двадцати файлов на диске. Это важно для места и для времени конвертации, и поэтому инструменты, которые «обрабатывают изображение», на самом деле обрабатывают десяток файлов.

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

// Lower the cap from 2560 to 1920 pixelsadd_filter( 'big_image_size_threshold', function () {    return 1920;} );// Or disable the automatic scaling entirely// add_filter( 'big_image_size_threshold', '__return_false' );

Почти для любого сайта 1920 - более удачный предел, чем 2560, потому что мало какие макеты показывают изображение шире. Снижение порога не уменьшает то, что вы загрузили раньше: оно действует только на новые загрузки.

Две детали, которые многих удивляют. WordPress пересжимает JPEG, когда создаёт копии разных размеров, с качеством по умолчанию 82. Это разумное значение. И оригинальный файл остаётся на диске нетронутым, так что папка uploads тяжелее, чем сумма того, что скачивают посетители.

Размеры: не загружайте то, чего никто не увидит#

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

Фотографии лучше сохранять в JPEG или WebP. Скриншоты и плоская графика с чёткими краями часто лучше сжимаются в PNG или в WebP без потерь, а PNG с фотографией почти всегда ошибка, которую стоит исправить. Логотип или значок должен быть SVG; WordPress по умолчанию не разрешает загрузку SVG, потому что SVG может содержать скрипты, поэтому включайте её только через надёжный плагин и только для администраторов.

Если вы чините существующий сайт, а не начинаете с нуля, отправная точка видна по числам. Сначала выведите самые крупные файлы:

$ cd wp-content/uploads$ find . -type f \( -name '*.jpg' -o -name '*.jpeg' -o -name '*.png' \) \    -size +500k -printf '%s %p\n' | sort -rn | head -20

Любой файл больше 500 КБ среди изображений в тексте - кандидат на исправление. Приведите в порядок двадцать верхних вручную, и вы обычно снимете большую часть веса.

Как работает srcset и почему ему нужны правильные размеры#

Атрибут srcset позволяет браузеру выбирать между несколькими ширинами одного изображения, а sizes сообщает, какой ширины оно будет показано. WordPress добавляет оба автоматически к изображениям, вставленным через редактор, и строит их из созданных копий:

<img src="/wp-content/uploads/2026/10/cafe-1024x683.jpg"     srcset="/wp-content/uploads/2026/10/cafe-300x200.jpg 300w,             /wp-content/uploads/2026/10/cafe-768x512.jpg 768w,             /wp-content/uploads/2026/10/cafe-1024x683.jpg 1024w,             /wp-content/uploads/2026/10/cafe-1536x1024.jpg 1536w"     sizes="(max-width: 1024px) 100vw, 1024px"     width="1024" height="683" alt="A cafe interior" loading="lazy">

Браузер читает подсказку sizes, умножает на плотность пикселей экрана и скачивает самого маленького кандидата, которого достаточно по ширине. Телефону с окном шириной 390 пикселей и плотностью 3x нужно около 1170 пикселей; настольному компьютеру с колонкой 700 пикселей при 1x - 700. Дескриптор ширины (300w) - это реальная ширина файла в пикселях, благодаря чему браузер сравнивает кандидатов, не скачивая их.

Это работает, только если кандидаты существуют. Три частых сбоя:

• Крупная копия только оригинал. Если тема не регистрирует размеров между 768 и 2560, телефон, которому нужно 1170 пикселей, получит копию на 1536 или оригинал. Размер на 1200 или 1600 поможет, но только для новых загрузок (см. ниже про перегенерацию).
• Неверный `sizes`. WordPress угадывает ширину показа по размеру, который вы вставили. Если тема показывает изображение в узкой колонке, а sizes говорит 100vw, браузер скачает кандидата крупнее нужного. Разработчики тем исправляют это фильтром wp_calculate_image_sizes; владельцу сайта остаётся выбрать меньший размер при вставке или поправить тему.
• Изображения, прописанные прямо в шаблонах темы или в конструкторах страниц. Если вывод собран из голого URL, а не из ID вложения, srcset не будет. Используйте поле изображения в конструкторе - оно хранит вложение, а не адрес.

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

Чтобы увидеть, какие размеры реально есть на вашем сайте, и проверить конкретное изображение, воспользуйтесь WP-CLI, если он у вас есть:

$ wp media image-size$ wp post meta get 123 _wp_attachment_metadata --format=json | head -c 600

Первая команда выводит все зарегистрированные размеры с их габаритами и признаком обрезки. Вторая показывает, что было создано для вложения 123.

Перегенерация миниатюр после изменений#

Добавили размер, изменили обрезку или снизили качество - для уже загруженных изображений ничего не изменится. Копии на диске создавались в момент загрузки. Чтобы их пересоздать, нужна перегенерация:

$ wp media regenerate --only-missing --yes

--only-missing создаёт только те размеры, которых ещё нет: это быстро и безопасно. Без него WordPress пересоберёт все размеры для всех вложений, а на библиотеке из нескольких тысяч изображений это долго и сильно нагружает CPU, поэтому запускайте в тихие часы. Без доступа к командной строке используйте плагин перегенерации из консоли администратора и будьте готовы, что он обрабатывает файлы небольшими пакетами.

Перед полной перегенерацией сделайте backup. Она заменяет файлы, и прерванный запуск на небольшом сервере может оставить часть записей со ссылками на удалённые размеры. В материале backup, который действительно восстанавливается описано, как убедиться, что копия пригодна, до того как на неё положиться, а рабочий процесс со staging-сайтом - хорошее место для первого прогона.

Прибирайте за собой. Неиспользуемые размеры от старой темы остаются на диске навсегда. После смены темы перегенерация с новым набором и удаление «сирот» может освободить гигабайты в большой библиотеке.

Ленивая загрузка и одно изображение, где её быть не должно#

Ленивая загрузка откладывает скачивание изображения, пока оно не окажется рядом с видимой областью, поэтому длинная страница не грузит всё сразу. Начиная с WordPress 5.5 она включена по умолчанию: атрибут loading="lazy" добавляется к изображениям и iframe в содержимом, плагин не нужен. Браузеры поддерживают его нативно, и он дешевле и надёжнее JavaScript-загрузчиков, которые были раньше.

Важнее обратное правило. Никогда не включайте ленивую загрузку для изображения вверху страницы. Главное или записное изображение обычно и есть элемент Largest Contentful Paint, и просьба к браузеру подождать с ним напрямую задерживает то, что измеряется. Свежие версии WordPress уже не добавляют loading="lazy" к первому изображению в тексте и ставят ему fetchpriority="high", но темы и конструкторы часто это переопределяют, поэтому проверяйте готовый HTML, а не предполагайте.

Правильная разметка для главного изображения простая, с подсказкой приоритета:

<img src="/wp-content/uploads/2026/10/hero-1600.webp" width="1600" height="900"     alt="Product on a desk" fetchpriority="high" decoding="async">

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

add_filter( 'wp_img_tag_add_loading_attr', function ( $value, $image, $context ) {    // Return false to omit loading="lazy" for this tag    if ( strpos( $image, 'hero-' ) !== false ) {        return false;    }    return $value;}, 10, 3 );

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

Фоновые изображения, заданные в CSS, loading="lazy" не покрывает. Баннер, сделанный как CSS-фон, нельзя приоритизировать или лениво загружать этим способом, и это ещё одна причина предпочитать настоящий тег img для важных картинок.

WebP: что он даёт и чего не даёт#

WebP - формат изображений от Google, поддерживающий сжатие с потерями и без, а также прозрачность. Фотографии обычно получаются примерно на 25-35 процентов меньше, чем эквивалентный JPEG при похожем видимом качестве, а WebP без потерь обычно меньше PNG, который он заменяет. Все современные браузеры его показывают, так что формат можно считать безопасным по умолчанию и не беспокоиться о посетителях, которые не могут его открыть. AVIF сжимает ещё сильнее, но кодируется намного дольше; WordPress 6.5 и новее принимает загрузку AVIF, хотя большинству сайтов он не нужен.

WordPress принимает загрузку WebP начиная с версии 5.8. Файл .webp можно перетащить в Media Library, и он работает как любое другое изображение: копии создаются, srcset работает. Смогут ли создаваться копии нужных размеров, зависит от библиотеки обработки изображений на сервере: редактору нужен GD или Imagick, собранные с поддержкой WebP. Экран Site Health в разделе Инструменты - Здоровье сайта показывает, что установлено. Если там сказано, что поддержки WebP нет, файлы .webp загрузятся, но уменьшенные версии создаваться не будут.

Стоит честно назвать ограничения:

• WebP не исправляет изображение слишком большого размера. Сначала уменьшайте.
• Выигрыш разный. Фотография экономит много; уже сильно сжатое изображение - мало; некоторые крошечные PNG становятся больше.
• Конвертированная копия - это второй файл на каждый размер. Если хранить оба, расход диска сначала растёт и только потом падает.
• При очень высоких настройках качества преимущество уменьшается. Для фотографий полезный диапазон - качество от 75 до 85.

Плагин или офлайн-конвертация#

Есть два подхода, и правильный зависит от сайта.

Плагин

Плагины для изображений, такие как ShortPixel, Imagify, EWWW Image Optimizer и Smush, конвертируют и сжимают при загрузке, обрабатывают уже имеющуюся библиотеку пакетом и переписывают разметку так, чтобы посетители с поддержкой WebP получали его. Одни выполняют работу на вашем сервере с помощью GD или Imagick; другие отправляют файл в сервис производителя и забирают результат: это экономит ваш CPU, но означает, что изображения покидают ваш сервер, и обычно связано с квотой или платным тарифом. Прочтите, что именно делает плагин, прежде чем включать его: детали различаются, а рекламные страницы их размывают.

Практические замечания для плагина на небольшом тарифе:

• Пакетная конвертация - место, где тарифы страдают. Конвертация библиотеки из нескольких тысяч изображений - это всплеск нагрузки на CPU и память PHP. На RE:NODE лимит CPU - жёсткое ограничение до купленной доли, поэтому пакетный запуск на небольшом тарифе идёт дольше, а не падает, а задача, превысившая лимит памяти, приводит к тому, что ядро останавливает контейнер, и он перезапускается начисто, не уходя в swap. Настройте плагин на небольшие пакеты и дайте ему поработать ночью.
• Проверьте, как отдаётся WebP. Плагины либо переписывают теги img на WebP, либо оборачивают их в элемент picture, либо опираются на серверные правила, подменяющие файл по заголовку Accept. Первые два варианта работают с любым кэшем. Последнему нужна настройка сервера и заголовок Vary: Accept, чтобы кэш не выдал WebP браузеру, который не умеет его читать.
• Сохраняйте оригиналы. Большинство плагинов умеют хранить копию оригинала; не выключайте это, пока не посмотрите результат на настоящей странице.
• Один оптимизатор, а не три. Два плагина для изображений на одних и тех же файлах означают файлы, сжатые дважды, и правила, которые мешают друг другу.

Офлайн-конвертация

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

С инструментом cwebp из пакета libwebp от Google или с ImageMagick папка конвертируется одной командой:

$ for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done# or with ImageMagick, also resizing to 1600 px wide at most$ mogrify -path out -format webp -quality 80 -resize '1600x>' *.jpg

Символ > в аргументе изменения размера означает «только уменьшать более крупные», так что файлы поменьше остаются как есть. Прежде чем обрабатывать всю библиотеку, проверьте несколько результатов на глаз и сравните размеры файлов: если WebP не меньше исходного, оставьте исходный.

Загрузите результаты через файловый менеджер или SFTP. Файловый менеджер RE:NODE принимает загрузку папок перетаскиванием и показывает изображения в браузере, этого достаточно, чтобы выборочно проверить пакет. Файлы, брошенные прямо в wp-content/uploads, не появляются в Media Library, потому что библиотека - это таблица в базе данных. Файлы, которые должны быть видны в редакторе, загружайте через саму Media Library. Файлы, на которые ссылается только тема (фоны, логотипы), кладите в папку темы и ссылайтесь на них напрямую.

Гибридный вариант, который подходит большинству: крупные изображения (баннеры, шапки), где важнее всего качество, уменьшать и сжимать вручную, а поток обычных загрузок от редакторов отдать плагину.

Отдаём WebP с запасным вариантом#

Если вы конвертируете, но хотите поддержать браузер, не умеющий читать WebP, стандартная разметка - picture, который позволяет браузеру выбрать по формату:

<picture>  <source srcset="/wp-content/uploads/2026/10/cafe.webp" type="image/webp">  <img src="/wp-content/uploads/2026/10/cafe.jpg" width="1024" height="683" alt="A cafe"></picture>

В 2026 году запасной вариант нужен редко, и самый простой подход - только WebP. Плагин с режимом picture или режимом по заголовку Accept решает проблему, которой у большинства сайтов уже нет, поэтому выбирайте настройку, которая оставляет меньше всего серверной конфигурации.

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

<IfModule mod_rewrite.c>RewriteEngine OnRewriteCond %{HTTP_ACCEPT} image/webpRewriteCond %{REQUEST_FILENAME} \.(jpe?g|png)$RewriteCond %{REQUEST_FILENAME}.webp -fRewriteRule ^(.+)$ $1.webp [T=image/webp,E=WEBP:1,L]</IfModule><IfModule mod_headers.c>Header append Vary Accept env=REDIRECT_accept</IfModule>

В nginx нет .htaccess, поэтому та же идея живёт в конфигурации сервера в виде map по $http_accept. Убедитесь, что сервер отдаёт image/webp как тип содержимого для файлов .webp. В старых файлах mime.types этой записи нет, и WebP, отданный как application/octet-stream, скачивается, а не показывается. Проверьте через curl:

$ curl -sI https://example.com/wp-content/uploads/2026/10/cafe.webp \    | grep -i -E '^(content-type|content-length|cache-control)'

Затем задайте изображениям длинный срок кэширования: под одним и тем же именем файла они не меняются. О Cache-Control для статических файлов рассказано в материале заголовки HTTP-кэширования, а кэширование WordPress объясняет, почему страничный кэш и оптимизация изображений решают разные половины задачи.

Пример из практики#

В магазине на странице товара восемь фотографий, загруженных прямо с телефона в 4032 на 3024 пикселя, около 3,4 МБ каждая. WordPress уменьшил каждую до 2560 пикселей, так что самый крупный отдаваемый файл - около 1,4 МБ, а сетка показывает их шириной 380 пикселей.

1. Установите big_image_size_threshold в 1920 и зарегистрируйте размер 760 пикселей для сетки (вдвое от ширины показа 380).
2. Выполните wp media regenerate --only-missing --yes, чтобы создать новый размер для существующих товаров.
3. Заново экспортируйте восемь главных изображений в 1600 пикселей в WebP с качеством 80, это даёт примерно от 120 до 200 КБ на файл.
4. Убедитесь, что srcset есть в исходном коде страницы и что первое изображение не имеет loading="lazy".
5. Замерьте снова.

Вес изображений на странице падает примерно с восьми-одиннадцати мегабайт до заметно меньше двух. Плагин для этого не понадобился. Сетка тоже сильно полегчала просто потому, что браузер теперь выбирает копию на 760 пикселей, а не на 2560.

Как проверить, что получилось#

Не доверяйте процентам из рекламы плагина. Измеряйте страницу до и после одним и тем же инструментом: панель Network в браузере (отключите кэш, затем смотрите переданный размер изображений), Lighthouse или PageSpeed Insights. Смотрите на три величины: общий вес изображений, элемент LCP и время его загрузки, сдвиг макета.

Из командной строки можно проверить, что получил бы конкретный посетитель:

$ curl -s -o /dev/null -w '%{size_download} bytes\n' \    -H 'Accept: image/webp,*/*' \    https://example.com/wp-content/uploads/2026/10/cafe.jpg

Выполните это один раз с заголовком Accept и один раз без. Если число байтов различается, согласование на стороне сервера работает; если совпадает, вы отдаёте оригинал всем. Помните, что CDN или страничный кэш перед сайтом могут хранить старую версию страницы, поэтому очищайте их после изменения, иначе вы измерите вчерашний HTML.

Короткий список для любой проблемы с изображениями:

1. Файл больше показываемого размера в два раза или больше?
2. Есть ли у тега srcset, width и height?
3. Свободно ли верхнее изображение от loading="lazy"?
4. Подходит ли формат содержимому (фото, графика, логотип)?
5. Задан ли для этого типа файлов длинный Cache-Control?

Заметки о хостинге#

Работа с изображениями - в основном дело фронтенда, и ни один тариф не компенсирует слишком большие файлы. От хостинга зависит удобство механики. На тарифе WordPress от RE:NODE вы можете править .htaccess или wp-config.php в файловом менеджере, загружать папки по SFTP и делать backup на вкладке Backups перед пакетным запуском. Число слотов backup зависит от тарифа, поэтому проверьте его на странице тарифа, прежде чем на них рассчитывать. Другой предел, за которым стоит следить, - место на диске: каждая загрузка размножается в десяток файлов, а плагин, хранящий оригиналы рядом с копиями WebP, занимает больше места, а не меньше, пока вы не почистите. Если проблема в большой библиотеке, вынос медиафайлов WordPress в S3 убирает её с диска веб-сервера ценой ещё одной подвижной детали.

FAQ#

WebP лучше JPEG для WordPress?

Для фотографий он обычно на 25-35 процентов меньше при том же видимом качестве, и его читают все современные браузеры. Он не поможет, если изображение изначально неподходящего размера, поэтому сначала уменьшайте, потом конвертируйте.

Нужен ли плагин, чтобы использовать WebP?

Нет. WordPress принимает WebP начиная с 5.8, а конвертировать можно офлайн через cwebp или ImageMagick и загружать готовые файлы. Плагин имеет смысл, когда загружают многие и вы хотите, чтобы конвертация происходила автоматически.

Вредит ли ленивая загрузка SEO?

Нативный loading="lazy" корректно читается поисковыми системами, так что изображения ниже первого экрана индексируются. Вред приносит ленивая загрузка главного изображения вверху страницы: она задерживает Largest Contentful Paint. Первое изображение оставьте обычным.

Почему изображения всё ещё большие после оптимизации?

Обычно страница использует оригинал или копию -scaled, потому что нет srcset, тема не зарегистрировала копии среднего размера или картинка взята из CSS-фона. Проверьте в готовом HTML атрибут srcset, а в панели Network - какой файл на самом деле скачивается.

Нужно ли перегенерировать миниатюры после смены темы?

Да, если новая тема использует другие размеры изображений. Иначе она запрашивает несуществующие размеры и возвращается к более крупному. Выполните wp media regenerate --only-missing --yes, предварительно сделав backup.

Может ли оптимизация испортить изображения?

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