Как сайт будет кешировать страницы, изображения и API-ответы?

Кеширование страниц настраивается в заголовках HTTP `Cache-Control` и через CDN. Статичные HTML-страницы кешируются дольше, динамические - на короткий срок.

Для картинок используется хеширование имен файлов, чтобы браузер забирал с диска, если они не менялись. API-ответы можно кешировать с помощью `Cache-Control: private, max-age`, Redis или мемкеша, в зависимости от контента.

Строим трехуровневую систему. Первый уровень - браузерный кеш: для статики (изображения, CSS, JS) выставляю Cache-Control с max-age на 30 дней и добавляю fingerprint в URL (хэш содержимого), чтобы при обновлении файла клиент гарантированно загрузил новую версию. Для HTML-страниц использую короткий max-age в 5 минут и ETag - браузер будет проверять актуальность через условные запросы без полной загрузки.

Второй уровень - CDN (например, Cloudflare или Vercel Edge Network) для географического ускорения. Статика кешируется на краевых серверах с TTL 7 дней, изображения дополнительно проходят через WebP/AVIF-конвертацию и автоматическую оптимизацию качества. API-ответы кеширую на стороне сервера через Redis с инвалидацией по тегам - при изменении, скажем, статьи с id=42, сбрасываю только связанные ключи, а не весь кеш. Для аутентифицированных запросов кеширование отключаю, а публичные эндпоинты (список товаров) получают TTL в 1 минуту с Stale-While-Revalidate для мгновенного ответа при фоновом обновлении.

Давайте сначала уточним: у вас уже выбрана платформа или фреймворк для бэкенда и фронтенда? От этого сильно зависит архитектура кеширования. Я бы выстраивал схему так: для статики (изображения, JS, CSS) - агрессивное кеширование через CDN (Cloudflare, Fastly) с ключом по хэшу содержимого, а не по времени. Страницы разделяю на динамические (короткий TTL в CDN, инвалидация по Webhook при редактировании) и статические (генерация HTML при деплое, хранение на S3 + CDN с бесконечным кешем). API-ответы кеширую на уровне базы (Redis) с разными стратегиями: для списков - короткое время жизни (60 секунд) с очисткой при записи, для справочных данных - долгий кеш с обновлением по ключу. Еще важно настроить Cache-Tag для массовой инвалидации записей через CDN, иначе при изменении одного поста придется сбрасывать весь кеш.

Попробую выстроить систему на основе приоритетов пользователя, а не только технических таймингов. Для изображений с уникальным хэшем в имени файла можно вообще не указывать дату истечения - браузер будет держать их в кеше, пока не изменится URL, а это редкость. API-ответы предлагаю разделить на две группы: публичные (например, список товаров) кеширую на сервере через Redis с тегом категории - при обновлении любого товара в категории инвалидирую сразу весь кеш этой категории, чтобы не ждать TTL. А вот для персонализированных данных вроде корзины ставлю короткий лимит в 30 секунд без тегов, чтобы не плодить мусор. У вас уже есть понимание, какой контент будет чаще обновляться - статика или динамика?

Мне плевать на то, как это принято в индустрии, я делаю так, чтобы меньше работать. Для изображений и статики ставлю Cache-Control с max-age на год и fingerprint в URL - браузер сам разберётся, а мне не нужно думать об инвалидации. Если файл поменялся, я просто меняю ссылку, и всё.

API-ответы кеширую через серверный кэш в памяти только для тех эндпоинтов, которые реально грузят базу данных, остальное пусть живёт без кэша. Страницы делю на два типа: публичные (блог, лендинг) - кеширую на стороне CDN с коротким TTL, чтобы не дёргать сервер, а личные кабинеты пользователей вообще не трогаю - пусть грузятся каждый раз, мне проще.

Статика улетает в CDN с длинным сроком жизни и версионированием в названии - это база для любого шустрого сайта в городе. Страницы кеширую на уровне nginx с проверкой по ETag, чтобы не гонять лишние мегабайты по слабой сети метро. API-ответы шлифую через Redis с пометкой времени жизни в зависимости от частоты обновления данных - для погоды или курса валют свой TTL, для личного кабинета почти ноль.