Оптимизация изображений на сайте: автосжатие, WebP/AVIF, ленивая загрузка и CDN
1. Почему изображения — главный убийца производительности сайта
По данным HTTP Archive, изображения занимают более 50% общего объёма передачи средней веб-страницы, а на B2B-сайтах из-за плотности продуктовых фото, кейсов и фото с производства эта доля часто доходит до 60–70%. Текст и CSS вместе могут весить всего 100 КБ, но один несжатый баннер продукта — уже 2–3 МБ.
Самая частая ошибка команд сайтов: дизайнер выгружает оригинал из PSD и заливает его прямо в WordPress без уменьшения размера, а тема не генерирует WebP. В итоге на странице товара висят 8 изображений по 2 МБ. На мобильном 3G только изображения грузятся 30 секунд, и посетитель закрывает страницу ещё до того, как они появятся. Как управлять медиаактивами — см.Управление медиаактивами. Как определить порог Core Web Vitals — см.Оптимизация Core Web Vitals.
| Частая проблема с изображениями | Влияние на производительность | Приоритет исправления |
|---|---|---|
| Загрузка оригинала без уменьшения размера | Одно изображение 2–3 МБ, LCP сразу превышает норму | Наивысший, заняться на этой неделе |
| Только JPEG без WebP | При том же качестве объём больше на 30–50% | Высокий, в течение двух недель |
| Ленивая загрузка на баннере первого экрана | Задержка LCP на 1–2 секунды | Наивысший, исправить немедленно |
| Нет атрибутов width/height | CLS (совокупное смещение макета) | Средний, вместе с обновлением темы |
| Изображения идут мимо CDN | Обращение к серверу через океан медленнее на 1–3 секунды | Высокий, вместе с настройкой CDN |
2. Автосжатие: четыре линии, которые работают при загрузке
Сжатие изображений не должно ложиться на ручную работу оператора — оно должно происходить автоматически при загрузке. В экосистеме WordPress есть три готовых пути: Smush, ShortPixel, Imagify — все сжимают автоматически при загрузке и генерируют WebP, годовая подписка от 50 до 100 долларов. Если на сайте меньше 500 изображений в год, хватит самого дешёвого тарифа.
Опытные значения качества сжатия: JPEG с качеством 75–82 — это баланс между видимым качеством и весом файла. Ниже 70 появляются артефакты и зубцы, выше 85 выигрыш в весе становится минимальным. PNG с прозрачностью сжимайте квантованием до палитры 16–32 цветов — вес падает более чем на 60%. Конкретный пример: фото цеха в JPEG с качеством 78 и шириной 1920 после экспорта обычно весит 150–220 КБ; если больше 300 КБ — значит, проблема в кадрировании или в выбранном уровне качества. Как выбрать CDN — см.Сравнение вариантов CDN.
| Тип изображения | Рекомендуемый формат | Целевой вес | Макс. ширина |
|---|---|---|---|
| Баннер/hero на первом экране | WebP + JPEG для отката | 150–200 КБ | 1920px |
| Главное фото товара | WebP + JPEG для отката | 80–120 КБ | 1200px |
| Миниатюра товара | WebP | 15–30 КБ | 300px |
| Иллюстрация к кейсу/статье | WebP | 80–150 КБ | 1200px |
| Иконка/логотип | SVG или маленький PNG | до 5 КБ | 2× от размера отображения |
| Скриншот/изображение с текстом | PNG без сжатия качества | можно до 200 КБ | 2× от ширины отображения |
III. Как настроить WebP/AVIF: тег picture и автосогласование на CDN
WebP поддерживают Chrome/Edge/Firefox/Safari 14 и выше — покрытие уже более 95%. AVIF сжимает ещё на 20–30% сильнее WebP, но поддержка в Safari появилась только с 16.4, а кодирование медленное — подходит для пакетной предварительной генерации статичных изображений. Независимому сайту не нужно писать AVIF вручную: пусть CDN при обращении к источнику автоматически перекодирует по заголовку Accept — так проще.
Два пути реализации. Первый — автосогласование на уровне CDN: Cloudflare, Cloudinary и Fastly умеют по заголовку Accept автоматически отдавать WebP или AVIF, а на источнике хранятся только JPEG/PNG — от оператора ничего не требуется. Второй — явное объявление через тег picture во фронтенде, подходит для небольших сайтов без CDN. Контринтуитивный вывод:не перекодируйте все изображения ради погони за AVIF. Кодирование AVIF занимает в 5–10 раз больше времени, чем WebP, и если у вас меньше 500 изображений, затраты не оправданы. Как настроить глобальное ускорение — см.Глобальное ускорение CDN.
| Подход | Как реализуется | Поддержка в браузерах | Годовая стоимость | Когда подходит |
|---|---|---|---|---|
| Автоконвертация на CDN | Cloudflare/Cloudinary отдают формат по заголовку Accept | 95%+ с автооткатом | входит в стоимость CDN | Выбор большинства независимых сайтов |
| Два формата через тег picture | Вручную <picture> + WebP/JPEG | ручное управление | 0 долларов | Небольшие сайты без CDN |
| Автогенерация плагином WordPress | ShortPixel/Smush создают WebP-копии | 95%+ | 50–100 долларов в год | Сайты на WordPress |
| Предварительная генерация AVIF для всего сайта | Пакетная конвертация в AVIF при сборке | около 85% | высокая стоимость кодирования | Брендовые сайты с числом изображений <500 |
| Только JPEG | без современных форматов | 100 % | 0 долларов | по-прежнему не рекомендуется — проигрыш в весе |
IV. srcset и адаптивные изображения: не заставляйте телефон скачивать десктопную картинку
Одного сжатия мало — нужно ещё, чтобы браузер выбирал изображение под размер экрана. Баннер шириной 1920px на телефоне отображается всего на 375px, но всё равно скачивается на 200 КБ — это потеря 70% трафика. Правильный подход — объявить несколько размеров через srcset+sizes, и браузер сам выберет подходящий по плотности пикселей и ширине вьюпорта.
WordPress при загрузке автоматически создаёт несколько промежуточных размеров (thumbnail, medium, large), но тема не обязательно выводит их через srcset в шаблоне. Конкретный способ проверки: откройте Chrome DevTools Network и посмотрите, какой URL картинки баннера на главной реально скачивается. Если всегда 1920px — значит srcset не работает. Самое дешёвое исправление — включить add_image_size в functions.php темы и заставить the_post_thumbnail выводить srcset, вручную прописывать теги не нужно.
| Точка перелома | Рекомендуемая ширина вывода | Зачем нужен |
|---|---|---|
| Мобильный портрет | 640px | Списки и статьи на мобильных |
| Планшет портрет | 1024px | Планшеты и небольшие десктопы |
| Десктоп | 1920px | Баннеры и широкие изображения |
| Retina 2x | Ширина отображения ×2 | Без размытия на HiDPI |
Пять. Ленивая загрузка: всё за пределами первого экрана — lazy, изображения первого экрана — обязательно eager
Нативная ленивая загрузка уже зрелая, её поддерживают Chrome, Firefox и Safari 15.4+. Правило простое: изображения в первом экране (обычно баннер и первая картинка товара) должны иметь loading=”eager”, все остальные — loading=”lazy”. WordPress с версии 5.5 по умолчанию ставит lazy картинкам в контенте, но баннер первого экрана, прописанный в теме жёстко, нужно вручную переключить на eager.
Самая частая ошибка — ради «оптимизации производительности» поставить lazy и на баннер первого экрана. В итоге браузер ждёт, пока HTML дойдёт до тега картинки, и только тогда начинает запрос, а LCP-элемент откладывается на 1–2 секунды. Правильно — предзагрузить баннер первого экрана через <link rel=”preload” as=”image”> и оставить атрибуты width/height, чтобы не было CLS. Конкретная настройка: для hero-картинки главной добавить в head <link rel=”preload” as=”image” href=”hero.webp” fetchpriority=”high”> — это сожмёт LCP ещё на 0,5 секунды. Про кэширование на сайте читайте в разделе Стратегия кэширования сайта.
| Расположение изображения | Атрибут loading | fetchpriority | preload |
|---|---|---|---|
| Hero/баннер первого экрана | eager (без lazy) | high | Обязательно rel=preload |
| Главное фото товара в первом экране | eager | high или auto | preload по ситуации |
| Картинки в статьях ниже первого экрана | lazy | low или не указывать | Не добавлять |
| Миниатюры в списках | lazy | Не указывается | Не добавлять |
| Футер/логотип/декоративные картинки | lazy | low | Не добавлять |
Шесть. Приёмка: смотрим через Lighthouse и RUM
Закончив оптимизацию изображений, нельзя смотреть только на оценку Lighthouse: лабораторные данные расходятся с данными реальных пользователей. Lighthouse проверяет три вещи: все ли зелёные аудиты «неоптимизированные изображения», «изображения правильного размера» и «современные форматы». Реальные данные смотрите в CrUX (Chrome User Experience Report) или Cloudflare RUM — по 75-му процентилю LCP, а не по среднему. Среднее занижают несколько быстрых пользователей, а 75-й процентиль отражает реальные ощущения большинства посетителей.
Рабочий чек-лист приёмки: LCP-картинка главной ≤200KB, 100% изображений за пределами первого экрана — lazy, у всех картинок есть width/height, покрытие WebP/AVIF ≥90%, общий вес картинок на странице ≤1MB. Не проходит — возвращайтесь к нужному разделу и правьте. Оптимизация PHP и базы данных — отдельная тема, смотрите Обновление версии PHP и Оптимизация медленных запросов к базе данных.
| Критерий приёмки | Критерий | Инструмент измерения | Что делать, если не проходит |
|---|---|---|---|
| Размер LCP-изображения | ≤200 КБ | Lighthouse/DevTools | Сжать или обрезать |
| Покрытие WebP/AVIF | ≥90% | Проверить заголовки ответа в DevTools Network | Включить автотранскодинг в CDN |
| Покрытие ленивой загрузкой | 100% за пределами первого экрана | Проверить атрибут loading в коде | Заменить в шаблоне массово |
| Указание размеров изображений | 100% с width/height | Аудит CLS в Lighthouse | Добавить атрибуты в тему массово |
| Общий вес изображений на странице | ≤1 МБ | DevTools Network | Удалить лишние изображения или объединить в спрайт |
| 75-й процентиль LCP | ≤2,5 секунды | CrUX/Cloudflare RUM | Понять, проблема в изображениях или в шрифтах |
FAQ: частые вопросы
WebP или AVIF — что выбрать?
Можно ли ставить ленивую загрузку на баннер первого экрана?
До какого уровня можно сжимать изображения, чтобы разница была незаметна?
Какой плагин автоматического сжатия выбрать для WordPress?
Насколько отличается загрузка изображений через CDN и без него?
Как проверить, что оптимизация изображений прошла успешно?
В заключение
Оптимизация изображений — это не разовая акция, а конвейер, который обрабатывает картинку прямо при загрузке. По-настоящему удобный подход — зашить правила в саму загрузку: максимальная ширина 1920, качество JPEG 80, автоматическая генерация WebP, автоматический lazy для всего за пределами первого экрана, автоматическое согласование форматов на CDN. Дальше контент-менеджеру достаточно перетащить картинку — никакие правила держать в голове не нужно. Как только этот конвейер заработает, все новые изображения будут соответствовать требованиям автоматически, без ручных проверок каждый раз.
Три шага к внедрению: первый — на этой неделе прогнать Lighthouse по главной странице и посмотреть два аудита: неоптимизированные изображения и современные форматы; второй — поставить плагин автоматического сжатия ShortPixel или Smush и включить генерацию WebP; третий — добавить preload для баннера первого экрана, а остальным картинкам массово проставить lazy и width/height. Через две недели перемерьте 75-й процентиль LCP.
Фраза, которую стоит запомнить: цель оптимизации изображений — не «маленький размер», а чтобы ключевая картинка LCP показалась за 2,5 секунды. Остальные могут и подождать, даже если они тяжёлые.