Оптимизация создания и хранения динамически генерируемых картинок

[monochromer]

Есть проблема - на каждую сборку запускается два очень тяжёлых процесса. Один - генерация картинок для социальных сетей, другой - генерация контентных картинок для элемента picture. Судя по разделу Github Actions, эти процессы занимают до 75%-80% всего времени сборки. Поэтому самое время задуматься об оптимизации.

Задачу можно разбить на две подзадачи:

• [ ] Оптимизация создания картинок для социальных сетей
• [x] Оптимизация создания картинок контента статей

Оптимизация создания картинок для социальных сетей

Варианты решения:

1. Self-hosted сервис с динамической генерацией картинок на каждый запрос

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

Недостаток способа - техническая поддержка сервиса - производительность, защита от большого числа запросов и др.

2. Хранение картинок в репозитории с контентом.

У такого способа есть несколько преимуществ - уменьшение ненужных повторных генераций картинок, проще в обслуживании, можно размещать для отдельных статей особые уникальные картинки (https://github.com/doka-guide/platform/issues/590).

Сценарий использования: на каждый push в ветку main проходимся по всем папкам images/covers/, если нет изображений, то создаём их и делаем commit в репозиторий. Если картинка устарела, то удаляем её - при следующем деплое будет создана новая.

Оптимизация создания картинок контента статей

Здесь вижу только одно решение - сервис для динамической генерации, так как хранение картинок в репозитории будет сильно раздувать его.

В качестве сервиса можно взять imgproxy.