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

Одной из многих проблем веб-архитектора является управление активами. И самая важная проблема в ресурсах — это изображения. Наивным подходом было бы установить изображение и позволить браузеру изменять его размер с помощью CSS:

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

В этом посте будут рассмотрены две альтернативы: традиционные и совершенно новые решения.

Предварительное изменение размера

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

• большое для поста на его странице
• среднее для публикации на главной странице
  
• маленькое для связанных сообщений на странице сообщения
  

Я также удаляю метаданные JPEG для еще большего уменьшения размера.

Тем не менее, традиционный подход заключается в использовании тега picture HTML:

Элемент Picture в веб-документах MDN

В свою очередь, его можно использовать следующим образом:

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

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

Изменение размера на лету

Недавно я наткнулся на imgproxy, компонент для оперативного изменения размера изображений:

Сайт imgproxy

Он предлагает конечную точку, куда вы можете отправить закодированный URL-адрес, который определяет:

• Изображение, размер которого нужно изменить, и его местоположение, например, локальное, URL-адрес HTTP, сегмент S3 и т. д.
• Различные параметры размеров, например, размеры, подходят ли они или заполняются и т. д.
• Формат imgproxy поддерживает стандартные форматы, такие как JPEG и PNG, а также более современные, такие как WebP и AVIF. Он также может выбрать лучший формат в зависимости от заголовка Accept.
• Множество (много!) других опций, таких как водяные знаки, фильтрация, поворот и т. д.

imgproxy предлагает как бесплатную, так и платную версию с открытым исходным кодом.

Одним из решений было бы, чтобы веб-разработчик закодировал каждый URL-адрес imgproxy в HTML:

На веб-странице происходит утечка информации, связанной с топологией. Это необслуживаемое решение. Мы можем решить проблему с помощью обратного прокси-сервера или шлюза API. Я буду использовать Apache APISIX по понятным причинам.

При таком подходе приведенный выше HTML становится намного проще:

Apache APISIX перехватывает запросы, начинающиеся с /resize, перезаписывает URL-адрес для imgproxy и перенаправляет переписанный URL-адрес в imgproxy. Вот общий поток:

Соответствующая конфигурация Apache APISIX выглядит следующим образом:

1. Запросы на совпадение с префиксом /resize
   
2. Перепишите URL-адрес
   
3. Улавливает ширину и изображение в регулярном выражении
4. Отформатирует URL-адрес imgproxy. http://server:3000 — сервер, на котором размещено исходное изображение; @webp указывает на предпочтение формата WebP (если браузер его поддерживает)
   

С учетом вышеизложенного /resize/200/ai-generated.jpg для Apache APISIX перезаписывается как /rs:fill/w:200/plain/http://server:3000/ai-generated.jpg@webp в imgproxy.

Тестирование

Мы можем настроить небольшой тестовый образец с помощью Docker Compose:

Простой веб-сервер, на котором размещается HTML и основное изображение.

Теперь мы можем протестировать описанную выше настройку с помощью инструментов разработчика браузера, эмулируя устройства с небольшим экраном, например iPhone SE. Результат следующий:

• Из-за разрешения экрана запрошенное изображение имеет ширину 400 пикселей, а не исходное. Вы можете увидеть это в URL-адресе запроса.
• Возвращенное изображение имеет формат WebP; его вес 14,4кб
• Исходное изображение в формате JPEG весит 154 КБ, что более чем в десять раз больше. Это существенная экономия пропускной способности сети!

Обсуждение

 Сокращение затрат на хранение в десять раз, естественно, является большим преимуществом. Однако это не только единороги и радуги. Вычисление изображения с измененным размером — это трудоемкая операция; на каждый запрос тратится процессорное время. Более того, какой бы эффективной imgproxyона ни была, на создание имиджа требуется время. Мы заменили затраты на хранилище на затраты на процессор, и теперь мы столкнулись с небольшим снижением производительности.  

Чтобы это исправить, нам нужен слой кэширования спереди, либо собственный, либо, что более вероятно, CDN. Вы можете возразить, что мы снова будем хранить активы; таким образом, затраты на хранение снова вырастут. Однако существенное отличие состоит в том, что кеш работает только для использованных изображений, тогда как в первом решении мы ранее платили за хранение всех изображений. Вы также можете применить известные рецепты кэширования, такие как предварительное прогревание, когда вы знаете, что группа изображений будет пользоваться большим спросом, например, перед каким-либо событием.

Заключение

В этом посте мы описали, как использовать Apache APISIX imgproxyдля снижения стоимости хранения изображений в разных разрешениях. Благодаря кэшированию на вершине в общую архитектуру добавляется больше компонентов, но при этом сокращаются затраты на хранение.