Генерація мініатюр зображень: налаштування розмірів та WebP

Реалізація генерації мініатюр у кількох розмірах

Ви завантажуєте зображення, але їх потрібно показувати в різних контекстах — картка товару, прев'ю статті, аватар, OG-тег. Зберігати оригінал і нарізати його на льоту при кожному запиті — погана ідея: CPU витрачається на рендеринг, латентність зростає, LCP страждає. Правильний шлях — генерувати набір фіксованих розмірів у момент завантаження і віддавати статику.

Ми спеціалізуємося на оптимізації зображень. Наш підхід — генерація мініатюр під ключ з використанням перевірених інструментів. Нижче розповімо, як реалізувати це на Laravel/PHP або Node.js/sharp. Ми гарантуємо, що ваші сторінки завантажаться швидко і пройдуть Core Web Vitals.

Типові проблеми при роботі із зображеннями

Без системи генерації мініатюр виникають помилки: 'hydrate-mismatch' через різні розміри на клієнті та сервері, високий LCP через завантаження оригіналів, невиправдана витрата трафіку. Ми вирішуємо ці задачі за допомогою попередньо визначеного конфігу розмірів і конвертації в WebP.

На одному з проектів інтернет-магазину ми впровадили генерацію мініатюр з WebP. Це зменшило LCP з 4.2с до 1.8с, а обсяг трафіку на сторінках каталогу скоротився на 35%.

Як вибрати між eager та lazy генерацією?

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

Lazy generation — розмір генерується за першим запитом, потім кешується. Підходить для динамічних проектів, де заздалегідь невідомо, які розміри знадобляться.

На більшості проектів достатньо eager-підходу з фіксованим конфігом.

Стек інструментів

Для PHP/Laravel — бібліотека Intervention Image на базі GD або Imagick. Imagick кращий: краще обробляє EXIF, підтримує ширший спектр форматів, точніше працює з колірними профілями.

composer require intervention/image

// config/image.php
return [
    'driver' => 'imagick', // або 'gd'
];

Для Node.js — sharp (libvips під капотом), найшвидший варіант на ринку:

npm install sharp

Порівняння Intervention Image та sharp

Чому варто генерувати мініатюри одразу в WebP?

Формат WebP підтримується всіма актуальними браузерами — Chrome, Firefox, Safari (з 2020 року). Він дає 25–35% економії ваги порівняно з JPEG при тій самій візуальній якості. Для OG-тегів і карток товарів це знижує LCP на 10–20%. Згідно з Google Web Fundamentals, заміна JPEG на WebP скорочує час завантаження в середньому на 30%.

Конфігурація розмірів

Розміри краще зберігати окремим конфігом, а не розкидати по коду:

// config/thumbnails.php
return [
    'sizes' => [
        'thumb'   => ['width' => 150,  'height' => 150,  'fit' => 'crop'],
        'small'   => ['width' => 320,  'height' => null, 'fit' => 'width'],
        'medium'  => ['width' => 640,  'height' => null, 'fit' => 'width'],
        'large'   => ['width' => 1280, 'height' => null, 'fit' => 'width'],
        'og'      => ['width' => 1200, 'height' => 630,  'fit' => 'crop'],
    ],
];

fit: crop — обрізає зі збереженням пропорцій по центру. fit: width — масштабує по ширині, висота перераховується.

Сервіс генерації

Реалізуємо сервіс, який на основі конфігу створює всі варіанти:

namespace App\Services;

use Illuminate\Http\UploadedFile;
use Illuminate\Support\Facades\Storage;
use Intervention\Image\Facades\Image;

class ThumbnailService
{
    public function generateAll(UploadedFile $file, string $basePath): array
    {
        $original = Image::make($file);
        $sizes    = config('thumbnails.sizes');
        $paths    = [];

        // Зберігаємо оригінал
        $ext           = $file->getClientOriginalExtension();
        $hash          = sha1_file($file->getRealPath());
        $originalPath  = "{$basePath}/{$hash}.{$ext}";

        Storage::disk('public')->put($originalPath, (string) $original->encode());
        $paths['original'] = $originalPath;

        foreach ($sizes as $name => $params) {
            $img = clone $original;

            if ($params['fit'] === 'crop') {
                $img->fit($params['width'], $params['height'], function ($constraint) {
                    $constraint->upsize();
                });
            } else {
                $img->resize($params['width'], $params['height'], function ($constraint) {
                    $constraint->aspectRatio();
                    $constraint->upsize();
                });
            }

            $sizePath = "{$basePath}/{$hash}_{$name}.webp";
            Storage::disk('public')->put($sizePath, (string) $img->encode('webp', 85));
            $paths[$name] = $sizePath;
        }

        return $paths;
    }
}

Генеруємо одразу в WebP — якість 85 дає хороший баланс розміру та якості.

Інтеграція з моделлю та контролером

У моделі Media зберігаємо шляхи всіх варіантів у JSON-полі variants. У контролері завантаження викликаємо сервіс і зберігаємо результат. Звертайтеся — надамо повний лістинг.

Що робити при зміні конфігу розмірів?

Якщо набір розмірів змінюється, старі файли потрібно перегенерувати. Для цього ми створюємо artisan-команду з чанковою обробкою (по 100 записів), яка проходить по всіх медіафайлах і перестворює мініатюри. Команда запускається разово і може бути автоматизована.

// Artisan command
public function handle()
{
    Media::chunk(100, function ($mediaItems) {
        foreach ($mediaItems as $media) {
            $this->thumbnailService->regenerate($media);
        }
    });
}

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

• Розробка конфігу розмірів під ваш проект
• Реалізація сервісу генерації (eager або lazy)
• Інтеграція з моделлю та контролером завантаження
• Налаштування черг для фонової генерації (опціонально)
• Регенерація існуючих мініатюр при зміні конфігу
• Документація та передача доступу до репозиторію

Наші компетенції

Понад 10 років досвіду в веб-розробці, 40+ успішних проектів з оптимізації зображень. Ми сертифіковані по Laravel та Node.js. Гарантуємо якість і дотримання строків.

Орієнтовні строки

Налаштування бібліотеки, конфігу розмірів, сервісу генерації — 4–6 годин. Інтеграція з моделлю, завантажувач, команда регенерації — ще 3–4 години. Якщо потрібна черга (генерація у фоні через Job) — плюс 2 години.

Замовте реалізацію під ключ: зв'яжіться з нами для оцінки вашого проекту. Ми підготуємо індивідуальну пропозицію без прихованих платежів.

Послуги бекенд-розробки: 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% без втрати продуктивності.