Зауважимо: коли API повертає 200 з повним тілом на кожен запит, це марно витрачає трафік і навантажує сервер. Ми налаштовуємо HTTP-кешування так, щоб клієнти та CDN кешували відповіді, а сервер відповідав 304 Not Modified, якщо дані не змінилися. За 7 років ми впровадили цю стратегію в 50+ проектах — знижували трафік до 90% і прискорювали середню відповідь на 50%. Це дозволяє скоротити витрати на інфраструктуру до 70%. Типова економія на інфраструктурі для проектів з 10 000+ запитів на годину становить від 100 000 рублів на місяць.
Проблеми, які ми вирішуємо
Проблема 1: Відсутність ETag — клієнт не може зробити умовний запит. Кожен запит повертає повне тіло, навіть якщо дані не змінювалися. Рішення: обчислюємо хеш за updated_at та id (для одиничних ресурсів) або за максимальним updated_at + кількість записів (для колекцій). ETag точніший за Last-Modified, оскільки реагує на будь-які зміни, а не лише на час.
Проблема 2: Неправильний Vary — CDN кешує відповідь для однієї мови або стиснення і віддає всім. Наприклад, якщо Vary не містить Accept-Language, російський користувач може отримати англійську версію. Рішення: вказуємо всі заголовки, що впливають на представлення.
Проблема 3: «Мертвий» Cache-Control — no-cache без ETag — клієнт не кешує взагалі. Оптимальна комбінація: Cache-Control: public, max-age=60, s-maxage=300 + ETag.
Як ми це робимо: стек та кейс
Використовуємо Laravel 11 на PHP 8.3, PostgreSQL, Redis. Для кожного ендпоінту API визначаємо стратегію кешування:
- Одиничні ресурси — ETag на основі
updated_at+id. ЯкщоIf-None-Matchзбігається — 304. - Колекції — ETag за максимальним
updated_atі кількістю записів з урахуванням пагінації. - Багатомовні —
Vary: Accept-Language, ETag включає код мови.
Приклад з реального проекту: каталог товарів з 50 000 позицій, 10 мов. Після налаштування ETag + Vary трафік на CDN знизився з 200 ГБ/міс до 30 ГБ/міс (на 85%), а середній час відповіді впав з 800 мс до 150 мс для кешованих запитів. Середня економія на CDN-трафіку склала 120 000 рублів на місяць. Якщо хочете отримати аналогічний результат, замовте аудит кешування вашого API.
Чому ETag ефективніший за Last-Modified?
Last-Modified має точність до секунди — якщо оновлення відбуваються частіше, можливі колізії. ETag враховує сам вміст, тому детектує будь-які зміни, включаючи перезапис тих самих даних (якщо хеш рахується за вмістом). Для JSON API ми використовуємо хеш від updated_at та id — він дешевий і достатньо унікальний.
| Характеристика | ETag | Last-Modified |
|---|---|---|
| Точність | Всі зміни | Секундна гранулярність |
| Обчислення | Хеш даних | Часова мітка |
| Колізії | Немає при хорошому хеші | Можливі при частих оновленнях |
| Рекомендація | JSON API | Статичні файли |
Налаштування Vary для багатомовного API
Вкажіть у відповіді Vary: Accept-Language, Accept-Encoding. Для CORS з різними origin — Origin. Уникайте Vary: Authorization — кожен токен створює окремий запис у кеші CDN. Якщо потрібна авторизація, використовуйте приватне кешування (private, max-age=0, must-revalidate) та ETag.
Як інвалідувати кеш на CDN?
Використовуйте теги (Cache-Tag) або сурогатні ключі. При оновленні ресурсу надсилаєте запит на purge за тегом. Cloudflare і Fastly підтримують масову інвалідацію одним викликом API. Економія на CDN-трафіку може сягати 90%, що знижує витрати на хостинг.
Директиви Cache-Control
| Директива | Призначення | Приклад |
|---|---|---|
| no-cache | Вимагати свіжість | no-cache |
| no-store | Заборона кешу | Конфіденційні дані |
| public | Дозволити CDN | Публічний API |
| private | Тільки клієнт | Особистий кабінет |
| max-age | Час життя кешу клієнта | max-age=60 |
| s-maxage | Час життя кешу CDN | s-maxage=300 |
Приклад middleware для Laravel
public function handle($request, Closure $next) { $response = $next($request); if ($response->isSuccessful()) { $etag = md5($response->getContent()); $response->setEtag($etag); $response->setLastModified($response->getDate()); if ($response->isNotModified($request)) { return response()->noContent(304); } } return $response; } Процес роботи
- Аналітика — аудит поточних заголовків, виявлення вузьких місць.
- Проектування — вибір стратегії для кожного ендпоінту (сильне/умовне кешування).
- Реалізація — додавання ETag, Last-Modified, Vary в middleware або контролери.
- Тестування — перевірка кодів відповіді, заголовків, поведінки CDN.
- Деплой — налаштування інвалідації (сурогатні ключі, purge API).
Строки орієнтовно
| Етап | Строк |
|---|---|
| Базове кешування (ETag + Last-Modified) | 2–4 дні |
| Повна стратегія (Vary, Cache-Control, інвалідація) | 1–2 тижні |
Вартість розраховується індивідуально після аналізу вашого API.
Що входить в роботу
- Реалізація ETag / Last-Modified для всіх ендпоінтів
- Налаштування Cache-Control та Vary за типами ресурсів
- Інтеграція з CDN (Cloudflare, Fastly)
- Система інвалідації кешу (сурогатні ключі або purge API)
- Документація щодо стратегії кешування
- Пост-релізна підтримка протягом 2 тижнів
Підсумок
Правильне HTTP-кешування — дешевий спосіб радикально знизити навантаження. Ми гарантуємо, що після налаштування ви побачите падіння трафіку та прискорення відповідей. Отримайте консультацію з налаштування кешування вашого API — ми оцінимо поточну ситуацію та запропонуємо оптимальну стратегію.
RFC 7232