Хранится ли ответ сервера и как он передается в браузер

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

Понимаете ли вы, что происходит между запросом и отрисовкой: как ответ едет по сети, где он оседает и кто решает, можно ли его переиспользовать. Практический смысл прямой: почему пользователь после деплоя продолжает видеть старую версию приложения.

Как отвечать

Про передачу. После установки соединения и TLS браузер шлёт запрос, сервер отвечает строкой статуса, заголовками и телом. Тело обычно сжато (Content-Encoding: gzip или br), едет либо с известной длиной, либо частями, а в HTTP/2 и HTTP/3 это фреймы одного мультиплексированного соединения. Браузер не ждёт конца тела: HTML разбирается потоково, поэтому потоковая отдача страницы вообще возможна.

Про хранение, по слоям:

• HTTP-кэш браузера, им управляет ответ сервера: Cache-Control с max-age, no-store, no-cache, immutable, плюс валидаторы ETag и Last-Modified и условный запрос, на который приходит 304 без тела;
• Service Worker и Cache Storage: правила пишутся кодом, а не заголовками;
• память вкладки: переменные, стор, кэш библиотеки загрузки данных;
• localStorage, sessionStorage, IndexedDB: переживают перезагрузку, у первых двух синхронный доступ, который блокирует поток;
• кэш переходов назад и вперёд, где страница замораживается целиком вместе с состоянием.

Отдельно скажите про личные данные: ответ с ними должен идти как private либо вовсе не кэшироваться, иначе его сохранит промежуточный прокси.

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

Считают, что кэшем управляет фронтенд. Заголовки ставит сервер или CDN, а параметр cache у fetch влияет только на конкретный запрос конкретного браузера.

Путают no-cache и no-store. Первый разрешает хранить копию, но требует перепроверки валидатором, второй запрещает хранить вообще. Разница всплывает на странице с персональными данными.

Кладут токены и профиль в localStorage «чтобы не запрашивать заново». Хранилище доступно любому скрипту на странице и само не протухает, так что появляется и вектор для XSS, и вечно устаревшие данные.