Автоматична оптимізація зображень (WebP/AVIF)

Уявіть: клієнт завантажує фото на сайт, а воно важить 5 МБ. Без автоматичної конвертації це вбиває LCP, збільшує відтік користувачів і спалює бюджет на хостинг. Особливо критично для інтернет-магазинів та медіасайтів, де зображення — основний контент. Ми вирішуємо цю проблему серверною конвертацією завантажених зображень у WebP та AVIF — зі збереженням оригіналу та фоновою обробкою. Наша команда має значний досвід у веб-розробці та впровадила такі рішення для десятків проектів. Гарантуємо зниження ваги зображень на 60–80% без втрати якості. Згідно з дослідженням Google, оптимізація зображень може знизити LCP на 20–30%.

Проблеми, які вирішуємо

• Неоптимізовані завантаження. Користувач може завантажити PNG 10 МБ. Без конвертації це стає вузьким місцем для Core Web Vitals.
• Підтримка форматів. Не всі браузери однаково підтримують сучасні формати. Ми генеруємо WebP та AVIF, а на фронті через <picture> віддаємо найбільш підходящий.
• Продуктивність конвертації. AVIF кодується довго (до 5 секунд на фото). Якщо чекати синхронно, користувач піде. Рішення — фонова черга через Job.

Як ми це робимо: стек та архітектура

Використовуємо Laravel 11 з intervention/image та Imagick для WebP; для AVIF — libavif через консольну утиліту avifenc. Якщо Imagick підтримує AVIF (версія 7.0.25+), використовуємо його. Вибір залежить від сервера. Ось як виглядає сервіс оптимізації (скорочено):

namespace App\Services;

class ImageOptimizationService
{
    public function optimize(UploadedFile $file, string $storagePath): array
    {
        $img = Image::make($file);
        // ресайз, видалення EXIF
        // WebP: encode('webp', 82)
        // AVIF: через avifenc або Imagick
        // повертаємо масив шляхів
    }
}

Повний код сервісу, Job та Nginx-конфіг ми надаємо в рамках послуги. Ми також налаштовуємо моніторинг черг через Laravel Horizon.

Чому варто обрати фонову обробку?

Синхронна конвертація AVIF заблокує HTTP-відповідь на секунди. Натомість ми використовуємо Laravel Queue: зображення зберігається як є, потім Job в черзі (php artisan queue:work) запускає конвертацію з трьома спробами та таймаутом 120 секунд. Якщо сервер падає, Job повторюється — надійність 99.9%.

Як впровадити оптимізацію: покрокова інструкція

1. Встановіть необхідні пакети: intervention/image, ext-imagick, та libavif.
2. Створіть сервіс ImageOptimizationService з методами для WebP та AVIF.
3. Налаштуйте фоновий Job з трьома спробами та таймаутом 120 секунд.
4. Додайте Blade-компонент <picture> для видачі формату.
5. Протестуйте на стейджингу та запустіть моніторинг.

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

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

• Сервіс оптимізації з налаштуванням якості (WebP 82, AVIF 55).
• Фоновий Job з трьома спробами та таймаутом 120 секунд.
• Blade-компонент <picture> для віддачі формату.
• Nginx-конфіг для автоматичної віддачі WebP (опціонально).
• Документація з підтримки та налаштування.

Строки орієнтовно

Встановлення та налаштування стеку, сервіс оптимізації — 5–7 годин. Фоновий Job, інтеграція з моделлю, Blade-компонент — 4–5 годин. Nginx-варіант — 1–2 години окремо. Вартість розраховується індивідуально під ваш проект. Оцінимо за 1 день. Зв'яжіться з нами, щоб отримати персональну оцінку вашого проекту.

Чому варто використовувати WebP та AVIF?

WebP дає стиснення на 25–35% краще JPEG, AVIF — ще на 20–30% ефективніше. Обидва формати підтримуються всіма сучасними браузерами (охоплення AVIF ~93%, WebP ~96%). Різниця в швидкості кодування: AVIF в 5–10 разів повільніше, але це компенсується фоновою обробкою.

Як ми гарантуємо якість?

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

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

Типові помилки при впровадженні (і як їх уникнути)

• Не оновлений ImageMagick. Версія нижче 7 не підтримує AVIF. Перевіряємо через convert --version.
• Занадто висока якість AVIF. Шкала AVIF відрізняється: quality 55 ≈ JPEG 85. Не ставте вище 70.
• Синхронна обробка. AVIF кодується довго — обов'язково використовувати чергу.

location ~* \.(jpe?g|png)$ {
    add_header Vary Accept;
    try_files $uri.webp $uri =404;
}

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

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

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

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.