Какие есть варианты кэширования на уровне приложения?

Что проверяют

Различаете ли вы уровни кэша, с которыми сталкивается фронтенд: HTTP-кэш браузера, Service Worker, хранилища, кэш данных в клиентских библиотеках и мемоизацию в рендере. Следом обычно спрашивают, как выкатить новую версию, чтобы пользователи не застряли на старом бандле.

Как отвечать

• HTTP-кэш: статику с хэшем в имени файла отдают с Cache-Control: public, max-age=31536000, immutable, а index.html с no-cache, чтобы браузер каждый раз сверялся с сервером по ETag и получал 304. Новая версия подхватывается сразу, а бандлы не качаются повторно;
• CDN: тот же HTTP-кэш на пограничных узлах, управляется через s-maxage и stale-while-revalidate;
• Service Worker и Cache API: офлайн-режим и свои стратегии (cache first, network first, stale-while-revalidate), обычно через Workbox;
• кэш серверных данных: TanStack Query, SWR, RTK Query, Apollo Client. У TanStack Query v5 по умолчанию staleTime равен нулю, а неиспользуемые данные удаляются через gcTime в 5 минут. Одинаковые запросы склеиваются, при фокусе окна данные перезапрашиваются;
• хранилища браузера: localStorage синхронный, хранит только строки и ограничен несколькими мегабайтами, для объёмных данных лучше IndexedDB;
• мемоизация: useMemo, React.memo, селекторы reselect. Это кэш вычислений в рамках рендера, а не данных.

Если работаете с Next.js, упомяните, что его поведение кэша по умолчанию менялось между мажорными версиями, и назовите ту, на которой писали сами.

Где спотыкаются

Называют Redis и Memcached кэшем фронтенда. Это серверный уровень, до браузера он не доходит.

Ставят долгий max-age на index.html. Пользователи видят старую версию, а старый index.html ссылается на чанки, которых после деплоя на сервере уже нет.

Кладут в localStorage токены и персональные данные, считая это безопасным кэшем. Он доступен любому скрипту на странице, и одна XSS-уязвимость отдаёт токен атакующему.