Кешування

Що таке кешування в HTTP і хто вирішує, що зберігати?

Кешування — це збереження вже отриманої відповіді в проміжному сховищі, щоб наступного разу закрити такий самий запит без походу в мережу. Головне, що плутають: рішення ухвалює не браузер за власним бажанням, а сервер — через заголовки відповіді. Браузер лише виконує ці вказівки, тому кеш-поведінка є такою самою частиною контракту, як формат тіла чи код відповіді, і перевіряється звичайним асертом на заголовок. Правила стосуються не тільки картинок і скриптів: відповідь API для HTTP нічим не особлива й підпадає під ті самі директиви. Окремо варто памʼятати контрінтуїтивне: мовчання в заголовках не дорівнює забороні — за певних умов кеш має право зберегти й перевикористати відповідь навіть без явних вказівок, це евристичне кешування. Практичний висновок для QA: розслідування «чому я бачу старе» починається з читання заголовків, а не з коду застосунку.

Чим приватний кеш відрізняється від спільного?

Приватний обслуговує рівно одного користувача й зазвичай живе всередині клієнта — це кеш браузера. Спільний стоїть на дорозі між багатьма користувачами й сервером: проксі, шлюз, CDN. Різниця не академічна, а безпекова: персоналізована відповідь — баланс, ПІБ, чужий кошик, — яка осіла у спільному кеші, здатна поїхати іншій людині. Саме тому серед директив є окрема, що спільним кешам зберігати забороняє. Окремо виділяють керовані кеші (reverse proxy, CDN, Cache API у Service Worker): їх розгортає й налаштовує сама команда сервісу, тобто відповідальність за їхню конфігурацію — ваша, а не «десь у браузері».

Чим no-cache відрізняється від no-store?

Назва обманює: no-cache зберігати не забороняє. Копія лягає у сховище, просто перед кожним використанням її треба звірити з сервером — мережевий похід відбувається щоразу, зате тіло не передається, якщо ресурс не змінився. no-store — інша річ: зберігати не можна жодну частину запиту чи відповіді, тож і економити нема на чому, щоразу їде повне тіло. Практично no-cache ставлять там, де відповідь мусить бути актуальною щоразу, — класика тут HTML-оболонка застосунку, яка й приносить актуальні імена хешованих файлів; no-store лишають для даних, зберігати які не можна взагалі. І застереження, за яке дають бали: no-store не є засобом приватності, RFC прямо називає директиву ненадійною і недостатньою для цієї мети.

Чи правда, що no-cache — це просто інша назва для max-age=0, must-revalidate?

Наполовину, і сильна відповідь якраз розводить ці половини. MDN справді фіксує, що комбінацію часто вважають рівнозначною no-cache, — і там же радить її не вживати: max-age=0 у цій ролі є спадком реалізацій, давніших за HTTP/1.1, які директиви no-cache не вміли обробляти. RFC 9111 такої тотожності не встановлює: вона існує на рівні опису MDN, а не специфікації. Тому коректне формулювання звучить так — збіг є, джерело в нього одне, підстав писати так у новому коді немає.

Як кеш обчислює, скільки відповідь лишається свіжою?

Він бере перше, що знайде, у фіксованому порядку: s-maxage (але лише якщо кеш сам спільний), далі max-age, далі різницю між Expires і Date. Звідси відповідь на класичне питання «що переможе, max-age чи Expires» — відносний max-age, бо його перевіряють раніше. Якщо директиви суперечать одна одній, кеш зобовʼязаний виконати найсуворішу. Поки вік копії не перевищив цей термін, вона свіжа й віддається без жодного мережевого запиту; щойно термін вичерпано, копія стає застарілою і без перевірки її віддавати не можна.

Що таке умовний запит і що насправді означає 304?

Коли копія застаріла, кеш її не викидає, а йде питати сервер, чи вона ще годиться. Питання формулюється валідатором: збережене значення ETag клієнт відправляє заголовком If-None-Match, а дату з Last-Modified — заголовком If-Modified-Since. Якщо на сервері та сама версія, у відповідь приходить 304 Not Modified без тіла: кеш освіжає метадані своєї копії й віддає її далі. Виграш тут не в кількості запитів — запит таки відбувся, — а в тому, що мережею не поїхало тіло. У мережевій панелі 304 треба читати як «ревалідація працює», а не як помилку.

Чим ETag відрізняється від Last-Modified і чому ETag не можна розбирати?

Last-Modified — це дата останньої зміни, і в умовному запиті вона їде заголовком If-Modified-Since. ETag — непрозорий ідентифікатор версії ресурсу, який їде в If-None-Match: його зміст належить серверу, а клієнт має право лише порівнювати значення, а не тлумачити їх. Непрозорість — не побажання, а правило: витягати з ETag хеш, номер ревізії чи довжину заборонено. Для автотестів це дає конкретну межу: асертити можна наявність заголовка й те, що після зміни ресурсу значення стало іншим, а от парсити його всередині — самообман, який зламається на першій же зміні реалізації бекенду.

Що насправді означає директива public?

Не «дозвіл спільним кешам» — саме так її переказують найчастіше, і це помилка. public знімає заборону зберігати для будь-якого кешу: відповідь позначається придатною для збереження навіть там, де інакше це було б заборонено. Відповідь на запит із заголовком Authorization — приклад такої знятої заборони, а не зміст самої директиви. Розмежовує ж кеші private: спільному зберігати таку відповідь не можна, приватному — можна. Існує ще кваліфікована форма private, у якій прямо перелічують імена полів: під заборону для спільного кешу потрапляють тільки ці заголовки, а все інше повідомлення він зберегти може. Поруч працює s-maxage: він задає окремий строк саме для спільних кешів, тож CDN може тримати відповідь довго, а браузер користувача — коротко; звідси й упізнаваний симптом «локально свіже, на стенді старе».

Що показує заголовок Age і в чому тут типова помилка?

Age показує приблизний вік відповіді в секундах, і відлік починається з моменту, коли її створили або ревалідували на origin-сервері. Хибне прочитання, яке зустрічається постійно, — «скільки вона пролежала в CDN»: відлік ведеться від події на джерелі, а не від моменту потрапляння у конкретний вузол. Практична користь від заголовка все одно велика: разом із max-age він відповідає на питання «мені щойно віддали свіже чи вже полежале». Якщо Age підповз до значення max-age, копія ось-ось стане застарілою, і наступний запит уже піде на ревалідацію.

Навіщо потрібен Vary і чим шкідливий надто широкий Vary?

Vary перелічує заголовки запиту, які входять до ключа кешу: збережену відповідь віддадуть лише тому запиту, у якого ці заголовки збігаються. Класичні застосування — Accept-Encoding і Accept-Language: стиснена й нестиснена, англомовна й україномовна версії не повинні підмінювати одна одну. Зворотний бік — надто широкий ключ: Vary: User-Agent фактично множить ключ на кількість версій браузерів, тож кеш роздувається копіями, які майже не перевикористовуються. Для тестів це ще й пояснення дивних розбіжностей між клієнтами: два запити з різними значеннями таких заголовків законно отримують різні копії однієї й тієї самої відповіді.

У панелі Network один запит показує (from disk cache), інший — 304. Це один діагноз?

Ні, і плутанина тут дорого коштує. Рядок із позначкою (from memory cache) або (from disk cache) читається однозначно: запиту не було взагалі — копія ще не вичерпала свій строк, тож браузер обійшовся сховищем і до сервера не звертався. Наслідок неприємний: оновлення з бекенду не дійде до клієнта, поки цей строк не мине. 304 — протилежна картина: запит відбувся, сервер звірив валідатор і підтвердив копію, зекономивши тільки тіло. Перше пояснює скаргу «я задеплоїв, а нічого не змінилося», друге каже, що механізм працює як задумано. Колонка Size у цих рядках показує не байти, а походження відповіді, — це найшвидший спосіб визначити рівень, на якому запит обірвався.

Що таке cache busting і чому HTML віддають інакше, ніж бандли?

Cache busting розвʼязує суперечність «кешувати надовго, але бачити нове одразу» через зміну адреси: змінився вміст — змінився URL. Практична реалізація — фінгерпринтинг: до імені файлу підмішують хеш його вмісту (app.a1b2c3d4.js). Кожна збірка отримує власну адресу, старий запис у кеші просто перестає стосуватися справи, і примусово інвалідувати його не треба. Звідси двоскладова схема: документ лишають на no-cache, бо в ньому й лежить актуальний список адрес, а хешовані асети — на дуже довгому строку з immutable. Побічний нюанс, цінний для AQA: хеш в імені файлу — благо, а хеш в імені CSS-класу — джерело ламких локаторів, бо змінюється щобілду.

Що змінює наявність CDN для тестування?

CDN — мережа проміжних серверів ближче до користувача, і з погляду HTTP це звичайний спільний кеш: він слухає private, s-maxage і решту директив за тими самими правилами. Різниця для QA в іншому: зʼявляється рівень, на який тестовий код не має жодного впливу. Кеш браузера можна вимкнути, воркер — заблокувати, а вузол CDN стоїть на чужій машині в чужому регіоні, і «почистити» його з тесту неможливо. Звідси характерний симптом: локально свіже, на стенді стабільно старе — підозра лягає на CDN раніше, ніж на код. Лікується це процесом — примусове скидання вузлів одразу після релізу, звірка версії збірки до того, як сюїта стартувала, — і перехопленням там, де потрібен детермінізм; але не паузами, бо пауза перетворює системну проблему на плаваючий флак.

Чим шлюз відрізняється від проксі і навіщо це тестувальнику?

Визначальна ознака проксі — його обирає клієнт: компанія навмисно проганяє весь трафік через один вузол, щоб мати на ньому безпекові перевірки або один кеш на всіх. Шлюз (він же reverse proxy) влаштований дзеркально: для зовнішнього зʼєднання він поводиться як origin-сервер, а що саме за ним — кеш-прискорювач, розподіл навантаження, кілька машин — клієнт не бачить. Третя форма — тунель: сліпий ретранслятор, який повідомлень не змінює і учасником HTTP-обміну не вважається. Практичний бонус для баг-репортів: 502 і 504 за означенням віддає вузол у ролі шлюзу чи проксі, тобто зламалася ланка за посередником, тоді як 503 каже, що сам сервіс тимчасово не тягне. І окремо про мережі, де вашої згоди не питали: вузол, що фільтрує трафік без відома відправника, протокольно не відрізняється від атакувальника на шляху, — тому в корпоративній мережі чи на публічному Wi-Fi запит може повестися інакше без жодної зміни в застосунку.

Що таке Service Worker і чому його кеш не лікується заголовками?

Це JavaScript, який браузер виконує у фоні окремо від сторінки, у власному потоці й без доступу до DOM; за роллю він є проксі між застосунком, браузером і мережею та перехоплює навігаційні й ресурсні запити. Працює лише в захищеному контексті — HTTPS, з винятком для http://localhost. Головне для QA: сховище в нього своє, Cache API, і з HTTP-кешем браузера воно не повʼязане; віддача звідти відбувається явно, у коді обробника, а не автоматично. Тобто бездоганні Cache-Control на бекенді на вміст цього сховища не впливають — воркер поверне те, що йому наказали повернути. Звідси й порядок підозр: заголовки перевірені, а примара старої версії лишилася — дивіться на воркер.

Чому після деплою користувач може лишатися на старій версії воркера?

Через життєвий цикл. Браузер бере файл воркера на встановлення у двох випадках: коли бачить його вперше і коли виявляє байтову різницю з тим, що вже стоїть; на етапі install зазвичай наповнюють кеш, на activate — прибирають застаріле. Але якщо сторінку вже контролює активний воркер, нова версія встановлюється у фоні й зупиняється в стані очікування: контроль вона візьме лише після закриття всіх вкладок сайту — або одразу, якщо код сам викликав skipWaiting(). Для тесту це означає, що після деплою логіка кешування цілком може лишатися старою, і звичайне перезавантаження сторінки цього не змінює. Тому «оновив сторінку — маю бачити нову версію» без явного skipWaiting() не є валідним очікуванням.

Назвіть патерни віддачі з кешу у воркері та ціну кожного.

Перший — cache-first (у документації «Cache, falling back to network»): беремо зі сховища, у мережу йдемо лише за відсутності копії; ціна — залипання на старій версії після деплою. Другий — network-first («Network falling back to cache»): спершу мережа, кеш як запасний варіант; ціна — на поганому звʼязку користувач чекає, поки мережа впаде. Третій — stale-while-revalidate: збережене віддається негайно, а оновлення підтягується у фоні, тож свіжий вміст користувач побачить наступного разу. Для тестів це три різні очікування: із cache-first асерт «після деплою одразу нове» законно провалиться, а зі stale-while-revalidate новий вміст зʼявиться лише на другому заході.

Як зробити тест незалежним від кешу, не чіпаючи самих сховищ?

Перехопити мережу — тобто перестати гадати про вміст сховищ і самому визначити, що прийде у відповідь. Playwright дає маршрути, у яких обробник має три можливі рішення: віддати запит на сервер, за потреби переписавши адресу, метод, заголовки чи тіло; підмінити відповідь власною, і тоді сервера ніхто не турбує; або обірвати запит. Перехоплення вибіркове: усе, що під шаблон не підпало, іде звичним шляхом, а маршрут, зареєстрований на рівні контексту, поширюється й на попапи. Дві пастки варто назвати вголос: заборонені заголовки на кшталт Cookie чи Host підмінити не вийде, override просто проігнорують — і тест зеленітиме на непідміненому запиті; а якщо на один шаблон повісити кілька обробників, спрацюють вони у зворотному до реєстрації порядку, причому передати керування далі можна лише через route.fallback(), бо route.continue() ланцюг завершує. Коли рукотворні відповіді виходять нереалістичними, є режим запису й відтворення трафіку через HAR.

Як ізолювати тести від кешу — і коли цього робити не можна?

Найдешевший рівень ізоляції — свіжий профіль на прогін; у Playwright цю роль грає окремий browser context, який не тягне за собою накопичений стан, і робиться це без жодного коду очищення. Воркер доводиться прибирати окремою дією, бо його сховище лежить поза HTTP-кешем, і тут є нюанс, що коштує годин: зняття реєстрації діє лише на наступні навігації, тож у поточному контексті воркер після виклику ще працює. Надійніше взагалі не дати йому зареєструватися — опцією контексту serviceWorkers: 'block'. І межа, без якої все це перетворюється на ритуал: глушити кеш у кожному тесті — помилка. Якщо предметом перевірки є саме кешування — що умовний запит повертає 304, що офлайн-режим працює, — кеш мусить бути ввімкнений, інакше ви перевіряєте застосунок, якого в проді не існує.

«Тест бачить стару версію. Ваші дії?»

Спершу визначити рівень, а не правити код — саме порядок кроків тут і слухають. Крок перший, мережева панель: (from disk cache) означає, що запиту не було зовсім, 304 — що ревалідація відпрацювала, живий 200 — що тіло справді поїхало мережею, але віддати його міг і спільний кеш, а не origin. Крок другий — Service Worker: якщо він зареєстрований, правильні HTTP-заголовки нічого не доводять. Крок третій — спільний кеш: стабільно старе на стенді при свіжому локально вказує на CDN або проксі. І лише коли всі три рівні відкинуто, підозра переходить на застосунок — його стан у памʼяті, сховище браузера чи кеш HTTP-клієнта. Саме тому фраза «почистив кеш» нічого не означає як процедура: з неї не зрозуміло ні про який рівень ідеться, ні чим і коли його чистили, а до двох рівнів із чотирьох браузерна кнопка взагалі не дотягується.

Три кейси про той самий симптом із різних боків: як за хвилину визначити рівень, з якого прийшла стара відповідь; як заасертити кеш-контракт замість того, щоб на нього сподіватися; і як зробити тест детермінованим, не вимикаючи кеш там, де він і є предметом перевірки.

Кейс 1. «На стенді стара версія»: діагностика за рівнями

Тест не знаходить нову кнопку, у розробника все свіже. Перш ніж чіпати локатор, треба зʼясувати, який саме рівень віддав відповідь: сховищ між сторінкою і сервером кілька, і лікуються вони по-різному. Порядок огляду завжди однаковий — від найближчого до сторінки до найдальшого.

Три висновки, які економлять години.

• (from disk cache) і 304 — різні діагнози, а не синоніми «кеш спрацював». У першому випадку мережі не було зовсім: строк ще не вичерпано, тож оновлення з бекенду до клієнта просто не дійде, скільки б разів тест не перезавантажив сторінку. У другому запит відбувся, сервер підтвердив копію і зекономив лише тіло — тобто механізм справний, і причину треба шукати далі.
• Правильні заголовки нічого не доводять, поки не перевірено воркер. Cache API — окреме сховище, на яке Cache-Control бекенду не впливає. Якщо воркер зареєстрований, він міг віддати збережену копію, навіть коли з сервером усе бездоганно.
• «Почистив кеш» — не крок у баг-репорті. З неї не видно ні рівня, ні інструмента, а до двох рівнів із чотирьох браузерна кнопка й не дотягується: воркер знімається окремо і не миттєво, а спільний кеш узагалі живе на чужій машині. Відтворюваний запис звучить інакше: «свіжий контекст, воркери заблоковані, версія бандла в HTML — така-то».

Кейс 2. Кеш-контракт як предмет асерту

Заголовки кешу — така сама домовленість між бекендом і фронтендом, як формат тіла. Її можна перевіряти без браузера, через request: тут не потрібні ні кліки, ні рендер.

import { test, expect } from '@playwright/test';

test('HTML-оболонка ревалідується щоразу', async ({ request }) => {
  const res = await request.get('/');
  // саме HTML приносить актуальні імена хешованих файлів
  expect(res.headers()['cache-control']).toContain('no-cache');
});

test('хешований бандл кешується надовго', async ({ request }) => {
  const res = await request.get('/assets/app.a1b2c3d4.js');
  const cc = res.headers()['cache-control'] ?? '';

  expect(cc).toContain('immutable');
  expect(cc).toMatch(/max-age=\d{8,}/); // вісім цифр — від кількох місяців і більше
});

test('персоналізована відповідь не осяде у спільному кеші', async ({ request }) => {
  const res = await request.get('/api/me', {
    headers: { Authorization: `Bearer ${process.env.USER_TOKEN}` },
  });

  const cc = res.headers()['cache-control'] ?? '';
  expect(cc, 'відповідь із даними користувача мусить бути закрита для спільних кешів')
    .toMatch(/private|no-store/);
});

Ревалідацію перевіряють умовним запитом: спершу забирають валідатор, потім повертаються з ним і чекають 304. Це той рідкісний тест, де кеш вимикати категорично не можна, — він і є предметом перевірки.

test('умовний запит із валідатором повертає 304 без тіла', async ({ request }) => {
  const first = await request.get('/assets/app.a1b2c3d4.js');
  const etag = first.headers()['etag'];
  expect(etag, 'без ETag ревалідації не буде').toBeTruthy();

  const second = await request.get('/assets/app.a1b2c3d4.js', {
    headers: { 'If-None-Match': etag },
  });

  expect(second.status()).toBe(304);
  expect(await second.text(), '304 не несе тіла').toBe('');
});

Що дивитися і чому:

• no-cache на HTML — не «вимкнули кеш», а свідома пара до immutable на асетах. Схема тримається на тому, що HTML щоразу приносить свіжі імена файлів; варто закешувати його надовго — і користувач годинами тягтиме старі бандли за старими адресами.
• Асерт на private для персоналізованих відповідей — це тест безпеки, а не продуктивності. Пропущена директива тут дає не повільну сторінку, а чужі дані в спільному кеші.
• ETag перевіряють на факт і на зміну, а не на вміст. Значення непрозоре: правильний асерт — «заголовок є» і «після зміни ресурсу став іншим». Розбір його на частини зламається від першої ж зміни реалізації на бекенді.
• Age у відповіді читають обережно. Він відлічує час від генерації або ревалідації на origin, а не строк лежання в конкретному вузлі; асерт «Age менший за N» перевіряє саме вік відповіді, а не географію вузла, який її віддав.

Кейс 3. Детермінізм без ритуалів: контекст, воркер, маршрут

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

import { test, expect } from '@playwright/test';

// воркеру не дають зареєструватися — його кеш у цьому прогоні просто не існує
test.use({ serviceWorkers: 'block' });

test('банер показує тариф із підміненої відповіді', async ({ page }) => {
  // маршрут ставимо ДО навігації: правило діє лише на запити після реєстрації
  await page.route('**/api/pricing', (route) =>
    route.fulfill({
      status: 200,
      contentType: 'application/json',
      body: JSON.stringify({ plan: 'pro', price: 49 }),
    }),
  );

  await page.goto('/pricing');
  await expect(page.getByTestId('plan-price')).toHaveText('49');

  // маршрут, залишений після тесту, перехоплюватиме запити наступних у тому ж воркері
  await page.unroute('**/api/pricing');
});

А ось спроба, яка виглядає робочою й мовчки не працює: підміна забороненого заголовка.

// НЕ спрацює: Cookie у списку заборонених — override просто проігнорують,
// запит поїде з реальними cookie, а тест зеленітиме на непідміненому запиті
await page.route('**/api/**', (route) =>
  route.continue({
    headers: { ...route.request().headers(), cookie: 'role=admin' },
  }),
);

Що дивитися і чому:

• Свіжий browser context — найдешевша ізоляція. Він не тягне ні HTTP-кеш, ні сховища попереднього прогону, і для цього не потрібно жодного коду очищення.
• serviceWorkers: 'block' надійніший за зняття реєстрації. Скасування реєстрації діє лише на наступні навігації — у поточному контексті воркер після виклику ще працює і ще віддає своє. Заборона на рівні контексту знімає цю гонку повністю.
• Порядок «спершу маршрут, потім дія» не косметичний. Перехоплення поширюється тільки на запити, надіслані після реєстрації обробника; маршрут, поставлений після goto, першу порцію запитів пропустить.
• Кілька обробників на один шаблон спрацьовують у зворотному порядку. Останній зареєстрований перекриває попередні, а далі по ланцюгу веде тільки route.fallback(); route.continue() на цьому місці ланцюг обриває.
• Блокувати кеш «про всяк випадок» у всій сюїті не варто. Тести з кейсу 2 вимагають увімкненого кешування, інакше вони перевіряють неіснуючий режим роботи застосунку. Розділяйте: детермінізм — для продуктових сценаріїв, реальний кеш — для тестів самого кешу.

Хто кешує і на якій підставі

• Можу пояснити, чому правила диктує сервер заголовками, а браузер їх лише виконує — і чому мовчання в заголовках не означає «кеш вимкнено» (евристичне кешування).
• Знаю різницю приватного vs спільного кешу і вмію назвати ризик: персоналізована відповідь у спільному кеші може поїхати чужій людині.

Директиви Cache-Control

• Знаю різницю no-cache vs no-store: перша дозволяє зберігати, але вимагає валідації щоразу; друга забороняє зберігання й не економить нічого.
• Можу сказати, чому no-store не є механізмом приватності, і послатися на застереження RFC, а не на власну думку.
• Розумію статус формули «no-cache = max-age=0, must-revalidate»: еквівалентність фіксує MDN (і радить так не писати), специфікація директиви не ототожнює.
• Знаю порядок обчислення терміну свіжості — s-maxage, потім max-age, потім Expires мінус Date — і правило конфлікту: виконується найсуворіша директива.

Свіжість і валідація

• Можу розвести свіжу vs застарілу копію й описати механіку умовного запиту: збережений ETag іде як If-None-Match, дата — як If-Modified-Since, а 304 читається «копія годиться, тіло не шлю».
• Розумію, чому ETag непрозорий і чому асерт має перевіряти зміну значення, а не його вміст.
• Памʼятаю межу no-cache: при навігації по історії ревалідація не гарантована, бо браузер може відновити сторінку з bfcache.

Спільний кеш, CDN і посередники

• Знаю різницю private vs public (перша розмежовує кеші, друга лише знімає заборону зберігати — для будь-якого) і навіщо поруч існує s-maxage.
• Читаю два дебаг-заголовки без помилок: Age відлічує час від генерації або ревалідації на origin, а не строк лежання у вузлі; Vary додає перелічені поля до ключа кешу, і надто широкий (User-Agent) роздуває кеш копіями, які майже не перевикористовуються.
• Знаю різницю проксі vs шлюз (перший обирає клієнт, другий видає себе за origin) і памʼятаю, що 502 і 504 віддає посередник, а 503 — сам сервіс.
• Можу пояснити cache busting через зміну URL: хеш вмісту в імені файлу плюс пара «HTML з no-cache, асети з immutable».

Service Worker і Cache API

• Знаю різницю Cache API vs HTTP-кеш браузера: це окремі сховища, тому коректні заголовки бекенду вміст воркерського кешу не змінюють.
• Можу описати життєвий цикл і стан очікування: нова версія встановилася, але контроль бере лише після закриття всіх вкладок або після skipWaiting().
• Розрізняю cache-first, network-first і stale-while-revalidate і можу назвати ціну кожного патерну для тестового очікування.

Діагностика й ізоляція тестів

• Не плутаю (from disk cache) vs 304: у першому випадку мережею не пішло нічого, у другому запит відбувся і ревалідація спрацювала.
• Можу назвати порядок діагностики «бачу стару версію» — рівень у мережевій панелі, воркер, спільний кеш, і лише тоді код — і пояснити, чому «почистив кеш» не є відтворюваною процедурою, а свіжий browser context із заблокованим воркером є.
• Знаю три рішення обробника маршруту (пропустити, підмінити, обірвати) і дві пастки: заборонені заголовки не підміняються, а кілька обробників спрацьовують у зворотному до реєстрації порядку.
• Памʼятаю виняток із правила ізоляції: якщо предмет перевірки — саме кешування, вимикати кеш не можна.