Оптимизация картинок как способ сэкономить на трафике: считаем эффект

MAATRIX

Если на сайте есть фотогалерея, каталог интернет-магазина или медиараздел с картинками, то изображения почти всегда — самая тяжёлая статья исходящего трафика, тяжелее HTML, CSS и JS вместе взятых. Проблема в том, что эту тяжесть редко считают отдельно: она растворяется в общем счёте за хостинг или в общей строке «трафик» у облачного провайдера. В этой статье — не советы «сожмите картинки», а конкретная методика: как оценить, сколько трафика сейчас уходит на изображения, сколько из этого реально можно отжать оптимизацией и сколько это стоит в рублях при вашей тарификации.

Зачем вообще считать, а не просто оптимизировать

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

Если у вас безлимитный тариф или трафик включён в стоимость сервера с большим запасом — экономический эффект от оптимизации картинок будет равен нулю в деньгах, хотя сайт станет быстрее, а SEO-метрики (Core Web Vitals, в частности LCP) улучшатся. Это тоже ценно, но это другая статья расчёта — про конверсию и позиции в поиске, а не про счета за инфраструктуру.

Если же вы платите за исходящий трафик по объёму — типичная ситуация в облаке, где egress тарифицируется отдельно и не включён в базовую стоимость инстанса, — то оптимизация картинок конвертируется в конкретную сумму в месячном счёте. И вот эту сумму стоит посчитать до того, как тратить время разработчика на перегонку тысяч файлов, а не после — иначе легко потратить неделю на задачу, которая экономит 300 рублей в месяц, или наоборот, не заметить задачу, которая экономит 30 тысяч.

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

Шаг 1. Оценить текущую долю картинок в трафике

Первый и самый важный шаг — не гадать, а посмотреть на реальные логи или метрики.

Вариант А — через логи nginx. Если в конфиге есть лог с размером ответа ($body_bytes_sent), можно вытащить суммарный объём по типам файлов за характерный период (сутки или неделю — так, чтобы захватить обычный трафик, а не аномальный день).

Простой разбор по расширению из access-лога:

awk '{
  match($7, /\.[a-zA-Z0-9]+($|\?)/, ext);
  e = tolower(ext[0]);
  gsub(/[?]/, "", e);
  bytes[e] += $10
}
END {
  for (k in bytes) printf "%-10s %10.2f MB\n", k, bytes[k]/1024/1024
}' /var/log/nginx/access.log | sort -k2 -nr | head -20

Здесь $7 — путь запроса, $10 — размер ответа в столбце access-лога (порядок полей зависит от вашего log_format, проверьте свой формат перед запуском). На выходе получаете таблицу вида:

.jpg        4821.30 MB
.js          312.40 MB
.css          98.10 MB
.png          876.20 MB
.woff2         45.00 MB

Сложив .jpg, .png, .webp, .gif и прочие форматы картинок, вы получаете абсолютный объём и его долю от общего трафика за период.

Вариант Б — через CDN или объектное хранилище. Если статика раздаётся через CDN или S3-совместимое хранилище (о механике такой раздачи — в статье что такое CDN изнутри и где лежит картинка), у большинства провайдеров в панели или через API есть разбивка исходящего трафика по префиксам путей или content-type. Это даже проще логов — не нужно парсить текст руками.

Вариант В — грубая прикидка. Если логов нет или разбирать их сейчас некогда, можно оценить долю картинок косвенно: открыть DevTools в браузере на нескольких характерных страницах (главная, карточка товара, галерея), посмотреть вкладку Network, отсортировать по размеру и посчитать долю картинок в общем весе страницы. Это не точная цифра по всему трафику сайта, а прикидка по «типичной» странице — но для решения «стоит ли вообще этим заниматься» этого обычно достаточно на старте.

На выходе шага 1 у вас должна быть одна цифра: какой процент исходящего трафика сайта — это изображения. Для галерей и интернет-магазинов эта доля часто оказывается заметно больше половины; для текстовых блогов с редкими иллюстрациями — существенно меньше. Именно поэтому важно посчитать конкретно для своего сайта, а не полагаться на усреднённые оценки из чужих кейсов.

Шаг 2. Оценить средний размер изображения и потенциал сжатия

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

Частые источники раздутого веса, которые стоит проверить по очереди:

• Изображения отдаются в исходном разрешении камеры или дизайн-макета, а на странице показываются в контейнере в 3-5 раз меньше — это самый частый и самый дорогой случай: браузер (а точнее — сеть) отдаёт мегапиксели, которые визуально никто не видит.
• Формат не соответствует содержимому: фотографии в PNG (формат без потерь, для фото избыточен), скриншоты интерфейса или иконки в тяжёлом JPEG вместо PNG/SVG.
• Отсутствует сжатие с потерями там, где глаз не заметит разницы — фотоконтент почти всегда допускает заметное сжатие без видимой потери качества, если не пережимать агрессивно.
• Не используются современные форматы (WebP, AVIF) с более эффективным сжатием при сопоставимом визуальном качестве по сравнению с классическими JPEG/PNG.
• Нет srcset и адаптивной отдачи под разные экраны — на мобильный экран уходит та же картинка, что и на десктопный монитор.

Чтобы понять, какой из этих пунктов у вас в приоритете, возьмите выборку из 15-20 характерных изображений с сайта (не самых маленьких иконок, а именно «рабочих» фото и картинок каталога) и прогоните через identify (из ImageMagick) — посмотрите реальное разрешение файла и сравните с тем, в каком контейнере оно выводится на странице:

identify -format "%f: %wx%h, %b\n" *.jpg

Если исходник 4000×3000 пикселей, а на странице картинка занимает 600×450 — это прямой сигнал, что ресайз даст основной эффект ещё до всякого разговора о качестве сжатия.

Важно: здесь не будет точных цифр «сжатие даёт минус X%». Эффект зависит от содержимого (градиентное фото сжимается иначе, чем скриншот с текстом) и от того, насколько агрессивно вы готовы жертвовать качеством. Общий и проверяемый на практике принцип: правильный ресайз под фактический размер отображения и переход на современный формат обычно дают заметное, часто кратное снижение веса — но конкретный процент нужно измерить на своей выборке, а не брать из чужой статьи (см. шаг 3).

Шаг 3. Инструменты для измерения на практике

Чтобы получить свою цифру снижения, не нужно ничего внедрять в продакшен — достаточно локального прогона выборки.

Для сравнения форматов и уровней сжатия удобны консольные утилиты:

# JPEG/PNG -> WebP с заданным качеством
cwebp -q 80 input.jpg -o output.webp

# JPEG/PNG -> AVIF
avifenc --min 20 --max 40 input.jpg output.avif

# Ресайз под конкретную ширину отображения (пример: 800px)
convert input.jpg -resize 800x output.jpg

# Оптимизация PNG без потерь (для скриншотов, иконок)
oxipng -o 4 input.png

Практичный подход — прогнать одну и ту же выборку изображений через несколько вариантов (только ресайз, ресайз + WebP, ресайз + AVIF) и сравнить итоговый размер каталога:

du -sh ./original/ ./resized/ ./resized-webp/ ./resized-avif/

Это даёт наглядную таблицу «было / стало» на реальном контенте сайта, а не на абстрактных цифрах из интернета. Именно эту таблицу и стоит использовать дальше в расчёте — она честная, потому что посчитана на ваших файлах.

Шаг 4. Перевести снижение объёма в деньги

Когда есть доля картинок в трафике (шаг 1) и коэффициент снижения их веса по вашей выборке (шаг 3), расчёт экономии — арифметика в несколько строк.

Общая формула:

Экономия трафика (ГБ/мес) = Общий трафик (ГБ/мес)
                             × Доля изображений в трафике
                             × Коэффициент снижения веса картинок

Экономия в деньгах = Экономия трафика (ГБ/мес) × Цена за ГБ трафика

Пример расчёта (цифры условные, для иллюстрации метода — подставьте свои):

Подставьте в последнюю строку свою реальную цену за гигабайт из счёта провайдера — и получите месячную сумму экономии. Если провайдер продаёт трафик по ступенчатой шкале (первые N ГБ по одной цене, следующие — дешевле или дороже), считайте по предельной ставке — той, которую вы фактически платите за последний использованный гигабайт, потому что именно её вы перестанете платить при снижении объёма.

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

Где эффект больше, а где почти нулевой

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

Эффект заметный:

• Фотогалереи, портфолио фотографов и иллюстраторов — почти весь трафик это и есть изображения.
• Каталоги интернет-магазинов с карточками товаров — счёт может идти на тысячи изображений, часто загруженных без всякой обработки прямо с камеры поставщика.
• Медиа и блоги с обилием иллюстраций, скриншотов, инфографики.
• Сайты с пользовательским контентом (отзывы с фото, объявления с фото) — контроль качества загрузки на входе минимален, вес случайный и часто избыточный.

Эффект скромный или нулевой:

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

Про последний пункт — если у вас уже настроен CDN перед сайтом, часть эффекта оптимизации изображений он мог забрать на себя ещё до вашей работы; стоит свериться с его настройками до расчёта, а не после. Базовая настройка CDN разобрана в статье про CDN для сайта.

Если оптимизация картинок — реакция на конкретный болевой сигнал (счёт вырос, лимит трафика исчерпывается раньше конца месяца), стоит на минуту отступить от темы изображений и проверить общую картину: иногда рост связан не с картинками, а с ботами или неудачно настроенным кешированием, из-за которого одни и те же файлы отдаются повторно. Про счета, которые растут незаметно и «всплывают» через месяц-два после реального роста нагрузки, — отдельный разбор про egress-трафик как статью счёта, о которой узнают поздно. И не путайте оптимизацию изображений со сжатием на лету на уровне веб-сервера (gzip/brotli) — для уже сжатых форматов вроде JPEG или WebP повторное сжатие на лету почти бессмысленно и только тратит CPU, этот нюанс разобран в статье про сжатие на лету.

Как внедрить оптимизацию без переписывания всего проекта

После того как расчёт показал, что игра стоит свеч, порядок внедрения обычно такой:

1. Автоматизировать обработку новых загрузок — при загрузке изображения через административную панель или API сразу прогонять через ресайз (под максимальный реально используемый размер отображения плюс запас под retina-экраны, обычно ×1.5-×2) и конвертацию в современный формат с фолбэком на JPEG для старых браузеров через тег <picture>.

1. Обработать существующую медиатеку батчем — на этом этапе и пригодится измеренный на шаге 3 коэффициент: запускаете конвертацию по всей библиотеке, проверяете визуально выборку результатов (автоматика иногда портит изображения со сложной прозрачностью или мелким текстом — их стоит смотреть глазами, а не доверять скрипту вслепую).

1. Отдавать с правильными HTTP-заголовками кеширования, чтобы браузеры и промежуточные кеши не запрашивали одни и те же файлы повторно — это отдельный источник экономии сверх самого сжатия.

1. Пересчитать реальную экономию через 2-4 недели по тем же логам, что и на шаге 1 — сравнить фактическую долю трафика на изображения до и после. Это подтверждает или опровергает прогноз из шага 4 и даёт основание либо продолжать (например, добавить AVIF там, где пока только WebP), либо остановиться, если эффект оказался меньше ожидаемого.

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

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