Побудова production-ready конвеєра обробки зображень

Зображення — найважча частина будь-якого сайту. Одна необроблена фотографія з камери може важити 10+ МБ і завантажуватися секунди. При цьому користувачі покидають сторінку, якщо LCP перевищує 2.5 секунди. Ми регулярно стикаємося з проєктами, де картинки не оптимізовані: немає ресайзу під різні екрани, немає WebP, водяний знак ставиться вручну. Все це — втрата конверсії та зайві витрати на трафік.

Типовий сценарій: інтернет-магазин з тисячами товарів. Фотографії завантажуються через адмінку, але доводиться робити прев’ю вручну або через костилі. Ми пропонуємо готову інфраструктуру: при завантаженні файл проходить через pipeline, і на виході — одразу кілька варіантів: thumbnail (150x150), medium (800x600), large (1920x1080), всі в WebP та JPEG. Плюс оригінал зберігається окремо.

Водяний знак накладається автоматично, якщо зображення публічне. Ми використовуємо напівпрозорий логотип у правому нижньому куті — це не заважає перегляду, але захищає контент. Всі операції займають не більше 200 мс на одне зображення.

Наш pipeline вирішує ці проблеми автоматично. Ви завантажуєте оригінал — система сама генерує набір прев’ю, конвертує в сучасні формати та накладає watermark. При цьому не потрібно переписувати існуючу логіку: інтеграція займає від 2 до 3 днів.

Які проблеми вирішує конвеєр?

Повільне завантаження через великі оригінали — перша проблема. Одне фото з камери може важити 20 МБ. На мобільному інтернеті це вбиває UX. Ресайз до потрібних розмірів і конвертація в WebP зменшують об’єм у 3-5 разів без втрати якості.

Відсутність адаптивних зображень — друга проблема. Якщо на десктопі показувати картинку 1920x1080, на телефоні вона буде такою ж за розміром, але стиснутою браузером. Це збільшує LCP. Наш pipeline генерує кілька версій під різні роздільні здатності, а ми підключаємо srcset — браузер сам обирає відповідний варіант.

Неможливість автоматично конвертувати формати — третя. Ручна конвертація в WebP або AVIF — довгий процес, який часто забувають. Pipeline робить це на льоту, зберігаючи і оригінал, і похідні. Економія трафіку досягає 40%.

Як ми будуємо pipeline: стек та архітектура

Для синхронної обробки використовуємо Node.js з Sharp. Sharp працює в 3 рази швидше за аналоги на Python. Для асинхронної — Celery + Pillow. Якщо навантаження велике, відправляємо завдання в чергу Redis — сервер не блокується. Альтернатива — imgproxy, який трансформує зображення on-the-fly за URL.

Порівняння підходів:

Який обрати? Якщо у вас до 1000 завантажень на день — вистачить синхронного. Для великих проєктів з мільйонами зображень — асинхронний з чергою.

Порівняння форматів:

Перехід на WebP знижує LCP на 30% та економить до 40% трафіку.

Що входить в роботу?

В послугу входить:

• Проектування архітектури pipeline (вибір підходу, стек).
• Розробка та інтеграція з вашим проєктом (API, middleware).
• Налаштування CDN та кешування (Cloudflare, Vercel).
• Документація з використання та доопрацювання.
• Навчання команди (1 година онлайн).
• Гарантія стабільної роботи — 30 днів підтримки.

Досвід нашої команди — 7+ років у веб-розробці, понад 50 реалізованих проєктів з обробкою зображень.

Процес роботи

1. Аналітика — аудит поточної інфраструктури, типові розміри, формати, навантаження.
2. Проектування — вибір підходу (синхронний/асинхронний), визначення набору прев’ю.
3. Реалізація — написання коду pipeline, інтеграція зі сховищем та CDN.
4. Тестування — навантажувальне тестування, перевірка сумісності з браузерами.
5. Деплой — розгортання на production, моніторинг.

Терміни та вартість

Базова реалізація з Sharp або imgproxy займає від 2 до 5 днів. Вартість розраховується індивідуально після аудиту — залежить від складності, обсягів та необхідності асинхронної обробки. Оцінимо проєкт безкоштовно протягом дня.

Типові помилки при реалізації

• Ігнорування EXIF-орієнтації — фото з телефону можуть бути повернуті. В Sharp ми автоматично читаємо метадані та коригуємо.
• Втрата прозорості — при конвертації PNG в JPEG фон стає білим. Наш pipeline зберігає альфа-канал або замінює на білий фон.
• Завеликі прев’ю — генерація 10+ варіантів сповільнює обробку. Оптимально 3-4 розміри.
• Відсутність кешування — кожен запит до imgproxy витрачає ресурси. Налаштовуємо Cache-Control на рік.

# tasks.py (Celery) from celery import Celery from PIL import Image import io, boto3 app = Celery('image_tasks', broker='redis://redis:6379') @app.task(bind=True, max_retries=3) def process_image(self, image_id: int): try: record = db.get_image(image_id) raw = s3.get_object(Bucket='uploads', Key=record.original_key)['Body'].read() img = Image.open(io.BytesIO(raw)) img = ImageOps.exif_transpose(img) if img.mode == 'RGBA': background = Image.new('RGB', img.size, (255, 255, 255)) background.paste(img, mask=img.split()[3]) img = background variants = {} for name, (w, h) in SIZES.items(): resized = img.copy() resized.thumbnail((w, h), Image.LANCZOS) buf = io.BytesIO() resized.save(buf, 'WEBP', quality=85, method=6) buf.seek(0) key = f"processed/{image_id}/{name}.webp" s3.put_object(Bucket='media', Key=key, Body=buf, ContentType='image/webp', CacheControl='public, max-age=31536000') variants[name] = key db.update_image_variants(image_id, variants) except Exception as exc: raise self.retry(exc=exc, countdown=60)