Как устроено cache management во frontend?

Cache management во фронтенде устроен на нескольких уровнях: HTTP-кеш (браузер), Service Worker (офлайн), кеш данных (TanStack Query/SWR), кеш сборки (хеши файлов) и in-memory кеш приложения.

Уровни кеширования

HTTP-кеш браузера

Управляется заголовками ответа:

Cache-Control: max-age=3600, immutable
ETag: "abc123"

• Cache-Control — время жизни, стратегия.
• ETag/Last-Modified — валидация (304 Not Modified).
• Ресурсы с хешем в имени (app.a1b2.js) кешируют «навсегда» (immutable).

Service Worker

Программируемый кеш для офлайна: перехватывает запросы, отдаёт из Cache API по стратегиям (cache-first, network-first):

caches.match(request).then((cached) => cached || fetch(request));

Кеш данных (server state)

TanStack Query/SWR кешируют ответы API: рефетч, инвалидация, устаревание (stale-while-revalidate):

useQuery({ queryKey: ['users'], queryFn, staleTime: 60000 });

Кеш сборки

Хеши в именах файлов (main.[hash].js) — при изменении меняется имя, браузер грузит новую версию, старое кешируется по имени.

In-memory кеш приложения

Мемоизация (useMemo, reselect), кеш вычислений в Map/WeakMap.

Инвалидация кеша

Сложнее всего решить, когда сбрасывать: по времени (TTL), по событию (мутация → инвалидация запроса), по версии (хеш файла).

Коротко для собеседования

Cache management на фронте многоуровневый: HTTP-кеш браузера (Cache-Control, ETag, хеши файлов), Service Worker (офлайн через Cache API), кеш серверных данных (TanStack Query/SWR — рефетч, инвалидация, stale-while-revalidate), кеш сборки (хеши в именах) и in-memory (мемоизация). Главная сложность — инвалидация (по TTL, событию, версии).