Изменение размера и сжатие изображений

Зачем уменьшают и сжимают изображения

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

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

Третий сценарий связан с подготовкой сайта к публикации. Картинки в галерее, превью, баннеры и favicon-иконки, схемы и скриншоты в статьях, аватарки в комментариях. Всё это удобнее готовить одним инструментом с понятным счётчиком экономии. Отдельно отметим, что при пересохранении через canvas служебные данные EXIF, включая геолокацию и модель камеры, в новый файл не переносятся. Для кадрирования пригодится обрезка изображений.

• Подготовка картинок для статьи, блога или ленты новостей.
• Сжатие фотографии перед отправкой в поддержку, в заявку или в мессенджер.
• Приведение аватарок и иконок к требуемым размерам.
• Оптимизация галерей и превью на странице перед выкладкой.
• Сжатие скриншотов, которые идут в баг-репорт или в задачу.
• Подготовка картинок для рассылки, где есть лимит на размер вложения.
• Уменьшение веса схем и диаграмм без потери читаемости.
• Конвертация фотографий в WebP для сайта, который его поддерживает.

Ошибки, из-за которых файл получается хуже

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

Третья ошибка связана с прозрачностью. Если у картинки есть прозрачные участки, а на выходе выбран JPEG, прозрачность исчезает, и на её месте обычно появляется чёрный фон. Для PNG и WebP прозрачность сохраняется, а вот JPEG её не умеет. Четвёртая ошибка касается анимации: анимированный GIF или APNG при отрисовке на canvas попадает в результат только первым кадром, и анимация исчезает без предупреждения.

Пятая ошибка, о которой стоит знать отдельно, связана с качеством. Ползунок качества действует только на JPEG и WebP, у PNG такого параметра нет. При этом слишком низкое значение даёт характерные артефакты вокруг контрастных деталей, а слишком высокое почти не даёт выигрыша в размере, зато съедает его. Практичное правило: для публикации в интернете обычно хватает 75-85 процентов, а для фотографий с мелкими деталями лучше начинать с 85. Счётчик экономии на странице честно показывает результат, включая случаи, когда файл вырос.

• Растягивание маленького исходника до большого размера. Разрешения при этом не появляется.
• Выбор PNG для фотографии. Файл в итоге получается больше исходного.
• Переход с прозрачного PNG на JPEG: прозрачные участки превращаются в чёрный фон.
• Ожидание, что анимированный GIF останется анимированным. В результат попадает только первый кадр.
• Игнорирование ползунка качества, хотя именно он даёт основную экономию в весе.
• Слишком высокое значение качества: файл тяжелее почти без разницы на глаз.
• Расчёт, что после обработки EXIF-данные сохранятся. При пересохранении через canvas они теряются.
• Загрузка результата на сервис, который принимает только определённый размер, без проверки габаритов.

Как устроено изменение размера и сжатие

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

Последний шаг, кодирование, отдан кодировщику самого браузера. Функция `canvas.toBlob` принимает тип файла и, для JPEG и WebP, параметр качества от 0.1 до 1. В инструменте ползунок идёт от 10 до 100 процентов и приводится к этому диапазону, значение по умолчанию 80. PNG качество не принимает вовсе, поэтому для него параметр просто не передаётся. Размер результата считается в байтах и сравнивается с размером исходника, отсюда и процент экономии.

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

Пропорции сохраняются всегда: при задании только ширины или только высоты второе число вычисляется автоматически.

Сравнение способов уменьшить картинку

Уменьшить картинку можно тремя разными путями, и они дают разный результат. Простое уменьшение в графическом редакторе перерисовывает изображение и даёт примерно то же, что и браузерный canvas. Серверные оптимизаторы, например ImageMagick или модули Nginx, работают аккуратнее, потому что используют качественные фильтры вроде Lanczos, и обычно дают лучший результат на той же скорости. Специализированные CDN-сервисы умеют менять формат и размер прямо по URL, что удобно для сайтов с большим количеством картинок.

Отдельно стоит упомянуть сжатие при передаче. Форматы WebP и AVIF уже содержат встроенное сжатие, а вот для JPEG, который остаётся самым распространённым, на сервере часто дополнительно включают gzip. При этом PNG, который и так сжат, от gzip почти ничего не выигрывает, зато заметно теряет в скорости обработки. Практический вывод простой: сначала приведите картинку к разумным габаритам и разумному формату на своей машине, а дальше отдайте её серверу как есть.

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

Оценить, сколько весит проект, поможет счётчик слов и символов для текста и сжатие изображений для картинок.

Привычки, которые берегут время и качество

Оптимизация картинок становится предсказуемой, если понимать, что именно влияет на вес файла. Размер в пикселях и качество сжатия решают почти всё, а остальное вторично.

• Сначала определите, где картинка будет показываться, и только потом подбирайте размер.
• Уменьшайте, а не увеличивайте: лишние пиксели при растягивании только добавляют вес.
• Начинайте с 80 процентов качества и поднимайте выше только если картинка и правда мыльная.
• Помните, что PNG для фотографий не подходит, а JPEG для картинок с прозрачностью тоже.
• Смотрите на счётчик экономии: он покажет и случай, когда файл вырос.
• Не ждите, что EXIF и геолокация переживут обработку. Они будут удалены.
• Проверяйте анимацию: если GIF должен остаться анимированным, не пропускайте его через canvas.