Картинки на сайте: как уменьшить вес втрое и ничего не испортить

На типичном сайте малого бизнеса картинки занимают от 60 до 80 процентов веса страницы. Это делает их самой выгодной целью: одна аккуратная пересборка галереи часто даёт больше, чем неделя работы с кодом.

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

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

Формат: что выбрать в 2026 году

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

И про SVG отдельно, потому что здесь есть неочевидная ловушка. SVG — это текст с описанием фигур, и он весит единицы килобайт, пока фигур немного. Логотип, экспортированный дизайнером из редактора без чистки, может содержать тысячи узлов и весить больше, чем та же картинка в PNG. Если ваш SVG тяжелее 30 КБ, его стоит прогнать через оптимизатор или попросить дизайнера упростить контуры.

Как выбрать степень сжатия

Почти в любом редакторе или онлайн-конвертере есть ползунок качества. Практический ориентир для фотографий — значение около 75–80: разница с исходником при обычном просмотре не видна, а вес падает в разы. Ниже 60 начинают появляться заметные артефакты, особенно на однотонных участках вроде неба или стены.

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

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

Размер: не больше, чем показывается

Браузер скачивает файл целиком, а потом уменьшает его до размера блока. Картинка шириной 4000 пикселей в блоке шириной 600 — это 85 процентов трафика впустую.

1. 01Откройте страницу, наведите на картинку, выберите «Просмотреть код».
2. 02В панели браузер покажет две пары чисел: собственный размер файла и размер на экране.
3. 03Если первое число больше второго вдвое и больше — картинку нужно пересохранить.
4. 04Заложите запас на экраны с высокой плотностью: ширина файла = ширина блока × 2, дальше смысла нет.

Множитель «×2» — про экраны с высокой плотностью точек: на них один пиксель разметки рисуется четырьмя физическими, и картинка ровно по размеру блока выглядит мягкой. Дальше двойного запаса идти не стоит: разницу между двукратным и трёхкратным на телефоне глазом не поймать, а вес растёт заметно.

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

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

Атрибуты, о которых забывают

Три атрибута тега картинки решают три разные задачи, и отсутствие каждого стоит по-своему.

• width и height — не для размера на экране, а чтобы браузер заранее знал пропорции и оставил место. Без них текст прыгает во время загрузки, и это прямо ухудшает оценку страницы.
• loading="lazy" — откладывает загрузку картинок ниже первого экрана. Ставится всем, кроме той, что видна сразу: у неё отложенная загрузка, наоборот, замедлит показ.
• alt — текстовое описание. Его читают экранные дикторы и поисковые роботы. Пустой alt допустим только для чисто декоративных картинок.

С отложенной загрузкой связана ошибка, которая встречается чаще самого атрибута. `loading="lazy"` ставят всем картинкам подряд, включая главную на первом экране. В результате браузер откладывает ровно то изображение, которое надо показать в первую очередь, и главный блок появляется позже. Правило простое: всё, что видно без прокрутки, грузится обычным способом; всё, что ниже, — отложенно.

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

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

Разные картинки для разных экранов

Атрибут srcset позволяет отдать телефону файл шириной 480 пикселей, а десктопу — 1600, из одного тега. Браузер выберет сам, ориентируясь на ширину экрана и его плотность.

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

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

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

И хорошая новость для тех, кто не верстает руками. Большинство современных CMS и конструкторов генерируют набор размеров и srcset автоматически при загрузке файла в медиатеку. Проверить просто: посмотрите код готовой страницы — если в теге картинки есть перечисление файлов с суффиксами вроде -300x200, механизм работает и вручную ничего писать не нужно. Достаточно загружать в медиатеку исходник разумного размера, а не восьмимегапиксельный кадр с телефона.

Порядок работы, чтобы не делать дважды

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

1. 01Договоритесь о максимальной ширине исходника, который вообще попадает на сайт: 2000 пикселей хватает почти всем.
2. 02Кадрируйте до нужных пропорций заранее, а не средствами вёрстки: обрезка стилями не уменьшает вес.
3. 03Прогоняйте файл через конвертер в WebP с качеством около 80.
4. 04Давайте файлам осмысленные имена латиницей: kuhnya-himki.webp, а не IMG_0042.webp. Это помогает и в поиске по картинкам, и вам самим через год.
5. 05Загружайте, проверяйте вес готовой страницы и записывайте результат.

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

Частые ошибки

• Сжали качество вместо размера. Файл 4000 пикселей с качеством 40 весит столько же, сколько 1200 пикселей с качеством 80, но выглядит хуже. Сначала пиксели.
• Уменьшили картинку стилями. Задать в CSS ширину 300 пикселей для файла на 3000 — значит скачать всё и показать малую часть. Браузер не умеет докачивать картинку частично.
• Переименовали JPEG в WebP. Расширение файла не меняет его содержимое. Нужен конвертер, а не переименование.
• Сохранили с прозрачностью там, где она не нужна. Фотография с прозрачным слоем не может быть JPEG и утаскивается в тяжёлый PNG без всякой причины.
• Пересохранили уже сжатый файл. Каждый цикл сжатия с потерями добавляет артефакты, и они не убираются обратно. Работайте всегда от исходника.
• Забыли про фоновые картинки в стилях. Их не видно в разметке, они не имеют alt и не поддерживают отложенную загрузку по умолчанию — но вес имеют такой же.
• Оставили в медиатеке старые тяжёлые версии. Они не грузятся посетителями, но раздувают резервные копии и мешают найти нужное.

Проверка результата

1. 01Замерьте вес страницы до правок: F12, вкладка «Сеть», обновление с очисткой кэша.
2. 02Пересоберите картинки: формат, размер, атрибуты.
3. 03Замерьте снова тем же способом.
4. 04Разница меньше 20 процентов означает, что основной вес не в картинках — возвращайтесь к серверу и скриптам.

Подробнее о том, как отделить одно от другого, — в разборе почему сайт грузится медленно.

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

И держите в голове, ради чего всё это. Смысл не в красивых числах в панели браузера, а в том, что человек с телефона в метро успевает увидеть вашу работу до того, как потеряет терпение. Картинки — самая дешёвая часть этой задачи; остальное разобрано в статье про аудит сайта своими силами.