Картинки съедают скорость WordPress: WebP, размеры и отложенная загрузка

Картинки съедают скорость WordPress тише всех остальных причин: плагины видно в списке, тему видно в настройках, а фотография выглядит как обычная иллюстрация к абзацу — и весит при этом больше, чем вся разметка, все стили и все скрипты страницы вместе взятые. Откройте панель разработчика на любой странице блога, отсортируйте запросы по размеру и посмотрите на первые пять строк. В девяти случаях из десяти это будут JPEG из медиатеки.

Ниже — механика: где WebP реально выигрывает, как считать размеры вместо того, чтобы поручать масштабирование браузеру, почему отложенная загрузка на первом экране делает хуже, и сколько мусора накапливает медиатека за год. Отдельно — что из этой работы отражается в измерениях скорости, а что на позициях сказывается сильнее, чем на цифрах в отчёте. В SEO с 2005 года, и картинки остаются той частью технической оптимизации, которую чинят последней, хотя выигрыш там самый крупный.

Почему одна фотография весит как вся страница

Арифметика простая. Телефон снимает кадр 4032 × 3024 пикселя, при камерном уровне сжатия это 2,5–4 МБ. Файл загружают в запись как есть, а тема выводит картинку шириной 760 пикселей — в пять раз меньше по стороне и в двадцать пять по площади. Браузер честно скачивает все четыре мегабайта и рисует крошечную копию. Дальше складываются три издержки, и путать их нельзя: лечатся они по-разному.

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

Память и декодирование. Распакованный растр занимает примерно ширина × высота × 4 байта: кадр 4032 × 3024 разворачивается в 48 МБ оперативной памяти независимо от сжатия файла. Пять таких картинок — четверть гигабайта, и бюджетный Android выгружает вкладку из памяти. Сжатие тут не помогает вообще, помогает только уменьшение пиксельных размеров.

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

WordPress тут не помощник, а источник ложного чувства безопасности. Движок при загрузке создаёт уменьшенные копии и подставляет в srcset подходящую по ширине. Но если тема объявила размер full для главной картинки записи или изображение вставлено с явной ссылкой на оригинал, весь механизм обходится стороной. Поэтому у одного сайта одни страницы грузятся за секунду, а другие за восемь: разница не в хостинге, а в том, какой файл подставился в конкретный блок. Похожая логика — в разборе «WordPress тормозит не из-за плагинов: где искать настоящую причину».

Форматы: когда WebP действительно даёт выигрыш

Ожидания от WebP завышены. Формат экономит не «в разы», а 25–35 процентов относительно грамотно сжатого JPEG того же визуального качества. Против необработанного камерного JPEG выигрыш выглядит впечатляюще, но там основную экономию даёт не формат, а нормальный уровень сжатия и уменьшение размеров.

Много WebP выигрывает на графике с прозрачностью: PNG с альфа-каналом на скриншотах, логотипах и схемах весит сотни килобайт, WebP с той же прозрачностью — десятки. Это экономия 60–80 процентов и единственный случай, когда переход даёт эффект без всякой другой работы.

Формат	Сильная сторона	Где проигрывает	Когда применять
JPEG	Фотографии, поддерживается везде без исключений, предсказуемое качество	Нет прозрачности, заметные артефакты на резких границах и тексте	Запасной вариант в <picture>, фото при отсутствии конвертера на сервере
PNG	Точная передача пикселей, прозрачность, не портит скриншоты и схемы	Вес фотографий в разы больше JPEG; на сложных снимках непригоден	Только исходники и картинки, где важна попиксельная точность
WebP	−25–35 % против JPEG на фото, −60–80 % против PNG на графике, есть прозрачность и анимация	Старые версии Safari до 14 и Internet Explorer не открывают	Основной рабочий формат для фотографий и графики на сайте
AVIF	Ещё −20–30 % против WebP, лучше держит градиенты и тёмные сцены	Медленное кодирование, повышенные требования к серверу, поддержка чуть уже	Крупные первые экраны и обложки, где вес критичен
SVG	Векторные логотипы, иконки, схемы; масштабируется без потерь, вес в килобайтах	Не подходит для фотографий, требует чистки от лишних данных редактора	Логотипы, иконки интерфейса, простые диаграммы

Практическое правило: WebP — основной формат, JPEG остаётся запасным через элемент <picture> или через перехват на сервере по заголовку Accept. Плагины делают это автоматически, но проверить надо, что отдаётся именно WebP, а не оба файла подряд: при кривых правилах в .htaccess сайт качает и WebP, и оригинал, и вместо экономии выходит перерасход. Вторая ловушка — кэш: при отдаче разных форматов по одному адресу нужен заголовок Vary: Accept, иначе прокси и CDN отдадут WebP браузеру, который его не понимает.

Правильные размеры вместо масштабирования браузером

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

1. Посмотреть отображаемый размер в панели разработчика: Chrome показывает «intrinsic» — реальные размеры файла и «rendered» — размеры на экране.
2. Умножить отображаемую ширину на 2 — запас под экраны удвоенной плотности. На 3 умножать не нужно: разницу глазом не видно, а вес растёт вдвое.
3. Убедиться, что в медиатеке есть копия близкой ширины и она попадает в srcset. Если ближайшая шире нужного больше чем в полтора раза, добавьте промежуточный размер.

Для типичного блога получается набор: 480, 768, 1024 и 1600 пикселей по ширине; для магазина добавляются квадратные превью каталога — 300 и 600. Больше шести размеров держать бессмысленно.

Атрибут sizes важнее, чем кажется. WordPress подставляет что-то вроде (max-width: 760px) 100vw, 760px, и если реальная колонка контента уже, браузер выберет копию крупнее нужной. Сравните в панели разработчика выбранный из srcset файл с фактической шириной блока: расхождение вдвое — повод править sizes в шаблоне.

Уровень сжатия WordPress держит на 82 из 100 — разумный компромисс. Ниже 70 опускать не стоит: на плавных переходах (небо, кожа, размытый фон) появляются полосы. Для фотографий товаров граница выше, около 80: артефакты на кромке предмета читаются как брак самого товара. Что фото в карточках влияют на выдачу — в материале «Фотографии товаров интернет магазина — это фактор ранжирования».

Ширина и высота в разметке против скачков вёрстки

Атрибуты width и height у тега img долго считали пережитком табличной вёрстки. С 2019 года браузеры используют их иначе: из соотношения чисел вычисляется пропорция, под картинку заранее резервируется место нужной высоты, и приход файла ничего не сдвигает. Работает это только вместе с правилом img { height: auto; } — без него жёсткая высота исказит пропорции на узких экранах. Числа в разметке задают пропорцию, CSS разрешает высоте подстраиваться под фактическую ширину блока.

Проблема называется сдвигом макета и измеряется отдельной метрикой в наборе Core Web Vitals. Значение выше 0,1 считается плохим и набирается почти всегда на трёх вещах: картинки без размеров, рекламные блоки без зарезервированной высоты, шрифты, меняющие высоту строк при подгрузке. Первая причина самая массовая и самая дешёвая в устранении.

В WordPress атрибуты проставляются автоматически при вставке через медиатеку. Ломаются в трёх случаях: картинка вставлена руками в текстовом режиме, выводится шорткодом стороннего слайдера, или тема чистит атрибуты фильтром. Проверять надо не в редакторе, а в исходном коде готовой страницы — искать <img без width. Фоновым изображениям из CSS место таким способом не зарезервировать вообще: о фоне первого экрана браузер узнаёт только после разбора стилей. Подробнее о метриках — в статье «Core Web Vitals: скрытая причина, почему ваш сайт не растёт в позициях».

Отложенная загрузка и почему её нельзя вешать на первый экран

Отложенная загрузка означает, что браузер скачивает картинку не сразу, а когда пользователь долистает до неё. В WordPress она включена по умолчанию с версии 5.5: движок сам добавляет loading="lazy" ко всем изображениям в контенте.

Именно в слове «всем» и кроется проблема. Если атрибут попал на главную картинку первого экрана, браузер откладывает её загрузку до окончания разбора вёрстки вместо того, чтобы взять в работу сразу. Метрика отрисовки крупнейшего элемента ухудшается на 300–600 миллисекунд: формально всё оптимизировано, фактически главный показатель просел. С версии 5.9 движок пытается это учитывать и не вешает атрибут на первое изображение контента, но логика грубая — «первое в потоке» и «на первом экране» совпадают не всегда: если сверху стоит обложка из шаблона, ленивая загрузка снимется не с той картинки.

Правильная схема выглядит так:

• Картинка первого экрана — без loading="lazy", с атрибутом fetchpriority="high" и предзагрузкой через <link rel="preload"> в шапке документа.
• Всё, что ниже сгиба, — с loading="lazy".
• Встроенные карты и видео — тоже с отложенной загрузкой, они тяжелее любой фотографии.

Второй побочный эффект — поиск по картинкам. Робот не всегда исполняет скрипты подстановки и в ряде реализаций видит вместо адреса заглушку. Речь о плагинах, подменяющих src на пустышку; штатный атрибут браузера такой проблемы не создаёт. Разница разобрана в материале «Ленивая загрузка картинок съедает ваш трафик из поиска по изображениям».

Лишние копии размеров в медиатеке

При загрузке одного файла WordPress создаёт от четырёх копий, и это базовый набор. Тема добавляет свои размеры под обложки и превью, WooCommerce — три размера под каталог, плагины слайдеров и портфолио — ещё по два-три. На практике одна фотография превращается в 10–18 файлов на диске. Прямого вреда позициям нет: копии просто лежат и никем не запрашиваются. Вред косвенный.

Объём резервных копий. Папка загрузок разрастается до десятков гигабайт, бэкап перестаёт помещаться в лимит хостинга и тихо перестаёт создаваться. Обнаруживается это в тот день, когда копия понадобилась.

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

Обход роботом. Если в теме включены страницы вложений — отдельные адреса под каждый файл, — робот тратит на них лимит обхода. Тысяча картинок даёт тысячу пустых страниц с одной фотографией и заголовком. Отключается в настройках SEO-плагина: страницы вложений перенаправляются на сам файл или на запись.

Чистка делается по порядку: сначала в functions.php отключаются ненужные размеры функцией remove_image_size, затем плагином регенерации пересобираются производные для уже загруженных файлов, и только потом удаляются осиротевшие. Если сделать наоборот, при следующей регенерации мусор создастся заново.

Что видно в измерениях скорости, а что нет

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

Действие с картинками	Заметно в отчёте о скорости	Что реально меняется	Приоритет
Уменьшить пиксельные размеры до отображаемых	Да, крупный прирост баллов и метрики отрисовки	Меньше трафика и памяти, страница показывается быстрее на мобильных	Первый
Снять ленивую загрузку с картинки первого экрана	Да, метрика крупнейшего элемента улучшается на 0,3–0,6 с	Первый экран показывается заметно раньше, снижается доля отказов	Первый
Проставить width и height	Да, падает показатель сдвига макета	Вёрстка не прыгает, пользователь не промахивается по ссылкам	Второй
Перевести фотографии в WebP	Да, но скромнее ожиданий — обычно единицы баллов	Экономия трафика 25–35 %, ощутимо на мобильном интернете	Второй
Заполнить атрибут alt	Нет, на скорость не влияет вообще	Трафик из поиска по картинкам, доступность для незрячих	Второй
Настроить долгий срок кэша для картинок	Да, в разделе рекомендаций	Повторные визиты грузятся без сетевых запросов	Третий

Из таблицы видно главное: работы делятся на те, что двигают цифры в отчёте, и те, что двигают деньги, и пересечение неполное. Атрибут alt не даёт ни одного балла скорости, но приводит переходы из поиска по изображениям — для магазинов и сайтов услуг с фотографиями работ это заметная доля визитов. Бывает и обратное: сайт набирает 95 баллов, а пользователи жалуются на медленную загрузку, потому что измерение шло по прогретому кэшу, а посетители приходят на страницы, которые кэш не покрывает. Почему баллы и ощущения расходятся — в материале «Скорость загрузки сайта — обман: настоящая метрика, которая решает позиции, прячется в другом месте».

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

Когда возиться с картинками не нужно

Есть ситуации, где оптимизация изображений не даст ничего, и время лучше потратить на другое.

Сайт-визитка на пять страниц с двумя картинками. Экономия в 300 килобайт не изменит ни поведения, ни позиций; важнее ответ сервера и внятные тексты. То же и когда крупнейший элемент уже отрисовывается за 1,2 секунды: дальше растёт только цифра в отчёте.

Проблема в базе или в сервере. Когда сервер отдаёт первый байт за две секунды, никакая работа с картинками не спасёт: пользователь эти две секунды смотрит на белый экран ещё до того, как браузер узнает о существовании изображений. Сначала кэширование и сервер, потом картинки — порядок именно такой, и он описан в разборе «Кэширование сайта: как ускорить загрузку и улучшить пользовательский опыт».

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

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

Частые вопросы

Нужно ли удалять оригиналы после конвертации в WebP? Нет. Они держат запасной вариант для старых браузеров и нужны, если понадобится пересжать иначе. Восстановить утраченный исходник неоткуда.

Сколько картинок нормально на странице статьи? Ограничение не в количестве, а в суммарном весе: ориентир — до 800 КБ на все изображения вместе, это восемь-десять фотографий шириной 1024 в WebP приличного качества.

Что писать в alt? Описание изображённого обычной фразой, не перечисление ключевых слов. Для декоративных элементов атрибут оставляют пустым — alt="": так программа чтения с экрана поймёт, что картинку можно пропустить.

Коротко

• Основной вес страницы почти всегда в картинках, и главная причина — не формат, а загруженные без уменьшения оригиналы с камеры.
• WebP экономит 25–35 % против JPEG на фото и 60–80 % против PNG на графике; ждать от смены формата кратного ускорения не стоит.
• Пиксельные размеры считаются как отображаемая ширина, умноженная на два; больше шести размеров в наборе держать бессмысленно.
• Атрибуты width и height вместе с height: auto в стилях убирают скачки вёрстки — самая дешёвая правка из всех.
• Отложенная загрузка на первом экране вредит: главной картинке нужны fetchpriority="high" и предзагрузка, а не loading="lazy".
• Часть работ не отражается в баллах скорости, но приносит трафик и надёжность: alt, чистка лишних размеров, отключение страниц вложений.

Если непонятно, с чего начинать на конкретном сайте — картинки, сервер или кэш, — посмотрю и скажу, где у вас основная потеря и в каком порядке это чинить: SEO-консультация по вашему сайту. Разбор строится на ваших цифрах, а не на общих рекомендациях сервиса проверки.