DevTools: вкладка Network і дебаг

Що показує вкладка Network і навіщо вона тестувальнику?

Це журнал усіх мережевих звернень сторінки: сам документ, стилі, скрипти, шрифти, зображення й фонові виклики до API — кожному запиту відповідає один рядок. Замість здогадів вона видає факти: який метод і адреса пішли, що повернув сервер, що лежало в тілі, скільки часу з'їла кожна фаза. Для AQA це головний прилад локалізації: тут «форма не зберігається» перетворюється на «POST /api/orders віддав 422, у тілі — повідомлення про зайнятий email». Різниця між цими двома формулюваннями — це різниця між тікетом, який розробник закриє за годину, і тікетом, що місяцями висить у статусі «не відтворюється». Тому цінність Network не в переліку колонок, а у вмінні довести, на чиєму боці баг.

Відтворив баг, а в журналі порожньо. Що сталося?

Дві найчастіші причини, і жодна з них не про застосунок. Перша: панель відкрили вже після дії — записувати трафік DevTools починають тільки з моменту відкриття, тож усе, що сталося до цього, для них не існувало. Звідси базова звичка: спершу відкрити панель, потім відтворювати проблему. Друга причина: журнал змило переходом на іншу сторінку, і найчастіше це б'є саме по логіну, після якого одразу йде перенаправлення. Лікується прапорцем Preserve log — він тримає записи крізь навігації. Тому перед складним сценарієм два перемикачі ставлять заздалегідь: збереження журналу і вимкнений кеш.

Як знайти потрібний запит серед сотень рядків?

Фільтрів у панелі два рівні, і сильна відповідь називає обидва. Перший — кнопки типів ресурсу: Doc для самого документа, Fetch/XHR для фонових викликів, Img, CSS, JS, WS для сокетів. Другий — текстове поле, яке розуміє не тільки підрядок в URL, а й властивості: status-code:500, method:POST, domain:api.example.com, а для кукі — cookie-name і response-header-set-cookie. Дві деталі, на яких валяться навіть досвідчені: інверсія вмикається окремим прапорцем Invert, а не мінусом перед виразом; кілька властивостей поєднуються виключно логічним «і», умови «або» тут не існує. Тому запит на кшталт «покажи POST або PUT» одним фільтром не збирається — доведеться фільтрувати по черзі.

Обрали конкретний запит. Що читати першим?

Порядок читання економить найбільше часу: блок General дає метод, адресу й код; Response Headers і Request Headers — метадані обох сторін; Payload — те, що поїхало на сервер; Response — сире тіло, а Preview — його ж, але розібране браузером у зручне дерево. Мінімальний набір заголовків, який дивляться завжди: Content-Type (у якому форматі тіло), Content-Length (скільки байтів очікувати), Accept (що клієнт готовий прийняти) і Authorization (чи взагалі поїхали облікові дані). Класична пастка ручного формування запитів — неправильний Content-Type: сервер відхилить тіло, і канонічною відповіддю тут буде 415, а не 400, тож асерт на «будь-яку четвірку» приховає діагноз. Якщо тестуєте завантаження файлів, у Payload буде multipart/form-data: тіло поділене на частини з власними міні-заголовками, а межу між ними задає рядок, оголошений параметром boundary в Content-Type.

Запит завис у стані pending. Про що це говорить?

pending означає рівно одне: запит відправлено, а повної відповіді ще немає. Далі є дві принципово різні гілки. Перша — сервер справді думає: обробка довга, і час згорає у фазі очікування. Друга — запит навіть не почав виконуватися, бо стоїть у черзі: браузер тримає обмежену кількість одночасних з'єднань до одного походження, і зайві чекають, поки звільниться слот. Розрізняє їх вкладка Timing і колонка Connection ID: якщо час пішов у чергу, а не в очікування відповіді, це не «повільний бекенд», а конкуренція за з'єднання. Практичний наслідок для тестів: масові pending під час паралельного прогону — привід подивитися на кількість одночасних запитів, а не піднімати таймаути.

Що таке фаза Waiting (TTFB) і чим вона відрізняється від TTFB із метрик продуктивності?

Це питання-детектор: під однією абревіатурою ховаються два різні виміри. Фаза Waiting (TTFB) у вкладці Timing починається після того, як з'єднання вже підняте, і містить один RTT до сервера плюс час, який сервер витратив на підготовку відповіді. Навігаційний TTFB із метрик рахують ширше — від моменту запиту сторінки до першого байта, тобто разом із пошуком у DNS і встановленням з'єднання. Тому число з панелі й число з метрики можуть відрізнятися в рази на першому запиті до нового хоста, і це не помилка вимірювання. Практичний висновок: довга фаза очікування вказує на серверну частину, а не на «повільний інтернет», бо канал у цей момент простоює.

Загальний Time великий. Це повільний бекенд?

Без розкладу по фазах — ні, це ще не діагноз. Колонка Time показує повну тривалість до останнього отриманого байта, і всередині неї можуть згоріти зовсім різні речі. Якщо час зібрався у фазі очікування — проблема на боці сервера. Якщо у фазі завантаження вмісту — питання до розміру тіла й пропускної здатності каналу: мегабайтна відповідь не стане швидшою від оптимізації запиту до бази. Якщо час пішов у DNS, TCP-рукостискання і TLS — це вартість першого звернення до нового хоста, і вона зникає на наступних запитах завдяки перевикористанню з'єднання. Окремо стоїть черга: там нічого не «гальмує», просто немає вільного слоту. Тому в баг-репорті про продуктивність цінний не загальний час, а те, у якій фазі він осів.

304 Not Modified формально в класі 3xx. Чому це не перенаправлення?

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

На старій адресі налаштований редирект, а тест бачить 200. Куди він подівся?

Нікуди — клієнт пройшов ланцюг сам. І браузери, і більшість HTTP-бібліотек за замовчуванням ідуть за перенаправленнями автоматично, тому в коді видно вже фінальний результат; помітний виняток — curl, який без прапорця -L зупиниться на першій сходинці. Щоб побачити ланцюг у браузері, потрібен увімкнений Preserve log, інакше проміжні рядки зникнуть разом із навігацією. Перевіряти сам факт редиректу треба явно: вимкнути автопрямування в HTTP-клієнті й асертити код разом із заголовком Location. І пам'ятайте про різницю в поведінці: 307 і 308 гарантовано зберігають метод і тіло, 303 навмисно переводить клієнта на GET, а от 301 і 302 дають таку гарантію лише для GET — інший метод клієнт має право підмінити й загубити тіло, і це історично реальна поведінка, а не теорія.

Виправили й задеплоїли, а на екрані стара версія. Як звузити коло?

Джерел «примари» рівно чотири, і лікуються вони по-різному: HTTP-кеш браузера, сховище Service Worker, проміжний кеш на кшталт CDN чи проксі, і кеш усередині самого застосунку. Починають із найдешевшого: прапорець Disable cache імітує візит новачка, який прийшов на сайт уперше; працює він тільки в самій панелі, а розширити його дію на решту інструментів дає змогу окрема панель Network conditions. Наступний крок — заголовки: доки копія рахується свіжою, браузер віддає її локально й у мережу не йде взагалі, а коли свіжість минула, шле умовний запит із валідатором. Тут же живе класична плутанина в назвах: no-cache не забороняє кешувати, він забороняє віддавати без перевірки, а забороняє зберігати no-store. Якщо заголовки правильні, а стара версія лишається — підозрюваний номер один Service Worker: він працює проксі між застосунком і мережею, віддає відповіді з власного сховища Cache API, ніяк не пов'язаного з HTTP-кешем, а нова версія воркера при активному старому спершу стає в стан очікування.

Навіщо вмикати колонку Protocol?

Бо без неї версію протоколу доводиться вгадувати, а вона впливає на поведінку сторінки. Значення в ній свої для кожного рядка: h2, h3 і http/1.1 мирно уживаються в межах однієї сторінки, бо домовляються про версію окремо на кожне з'єднання. Найчастіший практичний висновок: середовище, підняте локально без шифрування, у браузері працюватиме по HTTP/1.1 завжди, і дефекту тут немає. Причина в тому, що сама специфікація HTTP/2 шифрування не вимагає, але браузери заявили, що піднімають його виключно поверх TLS, а сервер має вміти узгодити протокол через ALPN усередині рукостискання. Ще одна деталь для сеньйорного рівня: керування з'єднанням діє між сусідніми вузлами, а не наскрізно, тому проміжний проксі цілком може «знизити» версію, і в панелі ви побачите його вибір, а не вибір походження.

Скільки з'єднань браузер відкриває до одного домену?

Тут перевіряють акуратність формулювань, а не число. На HTTP/1.x запити в одному з'єднанні йдуть строго по черзі, тому браузери відкривають кілька паралельних з'єднань до домену, і поширене нині значення — близько шести. Важливо додати, що це поточна практика браузерів, а не вимога протоколу: у RFC такого числа немає, і посилатися на нього як на норму — помилка. На HTTP/2 картина протилежна: специфікація радить обмежитися одним з'єднанням на кожну пару «хост і порт», бо запити мультиплексуються всередині нього. Пайплайнінг браузери сьогодні не вмикають, а розкидання ресурсів по кількох піддоменах MDN відносить до застарілих прийомів. А скільки з'єднань підняв ваш браузер насправді — не вгадують: вмикають колонку Connection ID і дивляться.

«У Postman запит проходить, а в браузері — ні». Що це означає?

Що ви щойно порівняли два різні світи. Політику одного походження реалізує саме браузер: він відправляє запит, отримує відповідь і вирішує, чи можна віддати її скрипту, спираючись на заголовки Access-Control-*. Postman, curl і будь-який HTTP-клієнт із бекенд-коду цих правил не застосовують узагалі, тому «у Postman працює» не є аргументом на користь того, що баг у фронтенді. Наслідок, який часто випускають: заблокована відповідь не означає, що на сервері нічого не сталося — простий запит сервер виконує повністю, і запис у базі з'явиться. Друга типова картина того ж роду: відповідь прийшла, статус 200, а скрипт не бачить потрібного заголовка — за замовчуванням йому доступні лише сім «безпечних» заголовків, решту сервер має явно перелічити в Access-Control-Expose-Headers.

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

Це preflight — попередній дозвільний запит методом OPTIONS, який браузер шле сам перед «непростим» крос-оріджин зверненням. У ньому він заявляє намір заголовками Access-Control-Request-Method і Access-Control-Request-Headers, а сервер відповідає, що з цього дозволено. Найпоширеніший тригер — звичайний JSON: Content-Type: application/json до переліку безпечних значень не входить, тому майже кожен виклик API з фронтенду породжує пару рядків. Перший практичний наслідок: якщо OPTIONS дозволу не дав, справжній запит не полетить зовсім — і шукати причину треба у відповіді на дозвільний рядок, а не в бекенді. Другий стосується автотестів: очікування зі сторінки вішають на змістовну відповідь, а не на дозвільний рядок, а сам OPTIONS перевіряють прямим API-запитом.

Скрипт не виконався, а в Network усе зелено. Де шукати?

У консолі — це майже завжди CSP. Політика безпеки вмісту приїжджає заголовком Content-Security-Policy, і браузер за нею вирішує, звідки дозволено вантажити й що дозволено виконувати. Ресурс при цьому міг цілком успішно завантажитися, тому в мережевій панелі жодного червоного рядка не буде — блокування відбувається на іншому рівні, а повідомлення про порушення падає в консоль. Саме тому кандидати, які дивляться лише в Network, у цьому сценарії застрягають надовго. Є й режим спостереження: Content-Security-Policy-Report-Only вмикає ту саму політику без примусу, щоб зібрати порушення до того, як вони щось зламають. Для AQA у цьому є пряма практична ціна: сувора політика ламає й автоматизацію, бо інʼєкція допоміжного скрипта або inline-обробника буде заблокована так само, як і чужий код.

Чому fetch() не кидає помилку на 500 і що з цього випливає для тесту?

Бо в Fetch API невдалий HTTP-статус — це не збій операції: мережевий обмін відбувся, відповідь отримано, тож проміс успішно резолвиться об'єктом Response. Реджект залишили для випадків, коли запит не вдалося виконати взагалі — наприклад, мережева помилка або некоректна схема адреси. Тому статус перевіряють руками, і зручний скорочений спосіб — властивість response.ok, істинна лише для діапазону 2xx. Наслідок для тестів і для розбору багів: код застосунку, написаний з розрахунком на «поламається саме», спокійно поїде далі з тілом помилки замість даних, і в панелі ви побачите чесний 500, тоді як інтерфейс покаже порожній список. Поряд корисно знати ще дві межі: тіло відповіді — потік, який читається лише один раз, а крос-оріджин fetch за замовчуванням не бере з собою облікових даних, бо режим credentials типово обмежений своїм походженням. У старому XMLHttpRequest аналогічна пастка зі станом readyState, що дорівнює чотирьом: він означає «операція завершилась», а не «завершилась успішно».

Чому в Request Headers не видно HttpOnly і Secure?

Бо обмін кукі асиметричний. Сервер видає кукі заголовком Set-Cookie і надсилає значення разом з атрибутами — строком життя, доменом, шляхом, ознаками Secure і HttpOnly. Назад браузер відправляє лише пари «ім'я = значення» в заголовку Cookie, без жодного атрибута, тому шукати їх у запиті марно: дивитися треба Set-Cookie у відповіді, яка їх встановила. Практично це означає, що перевірка «чи стоїть у сесійної кукі прапорець HttpOnly» — це перевірка відповіді на логін, а не наступних запитів. Поруч живе дзеркальне правило про сховище браузера: вміст localStorage не їде на сервер сам ніколи, і якщо токен там, застосунок мусить явно покласти його в заголовок. Звідси проста вилка при діагностиці: немає Authorization у запиті — шукайте баг у клієнтському коді, а не в бекенді.

Як зрозуміти, чи WebSocket узагалі підключився?

Дивитися перший рядок під фільтром WS, бо з'єднання починається як звичайний HTTP-запит. Клієнт відправляє GET, у якому просить перемкнути протокол заголовками Upgrade і Connection, та додає Sec-WebSocket-Key. Підтвердженням переходу служить рівно один код — 101 у парі з Sec-WebSocket-Accept у відповіді. Усе інше означає, що перемикання не відбулося й сторони лишилися в межах звичайного HTTP, тому «реалтайм не працює» дуже часто виглядає як банальний 401 або 404 у першому ж рядку. Після переходу це вже самостійний протокол поверх TCP, і всередині запису видно окремі кадри з напрямком, вмістом і часом. Дві практичні деталі: пари «запит — відповідь» тут немає, тому в тесті чіпляються за подію, яка є наслідком повідомлення, а не за таймер; а перезавантаження сторінки вбиває з'єднання разом зі станом підписок, бо воно живе в контексті виконання JavaScript цієї вкладки.

Тест то зелений, то червоний. Як панель Network доводить до діагнозу?

Спершу гіпотеза: якщо результат залежить від того, яка з асинхронних операцій завершиться першою, а гарантій щодо порядку немає — це гонка станів. Відтворюють її не повторними прогонами наосліп, а тротлінгом: меню обмеження швидкості емулює канал і мінімальну затримку, і для відтворюваності краще задати власний профіль із фіксованими числами, бо набір готових пресетів між версіями Chrome змінювався. Далі в панелі знаходять запит, який реально завершує перевірювану дію, і прив'язують очікування саме до нього — а не до появи спінера й не до фіксованої паузи. Жорстка пауза гонку не усуває, а ховає: вона нічого не перевіряє й лише сподівається, що система встигне. Головна теза для співбесіди: тест, який падає на повільному профілі, не «колись зафлакає» — він уже некоректний, просто на швидкій машині ще не встиг це показати.

Як передати мережевий контекст у баг-репорт?

Найкоротший шлях — експорт журналу у HAR: це JSON-запис сесії з усіма запитами, заголовками й таймінгами, який приймальна сторона може завантажити назад у DevTools і роздивитися вашу сесію як власну. Це знімає найдорожчу фазу листування «а покажи ще заголовки» і працює навіть тоді, коли баг у вас не відтворюється вдруге. Про безпеку варто сказати окремо, бо це часте питання: типовий експорт санітизований — з нього прибрані Cookie, Set-Cookie й Authorization, тому файл можна чіпляти до тікета без страху злити чужу сесію. Той самий запис має друге життя в автоматизації: HAR можна використати як джерело підмінених відповідей у тесті. Плата за це чесна: збережений знімок поступово розходиться з реальністю, і перевірка бадьоро зеленітиме на відповідях, яких бекенд давно не повертає.

Три кейси з робочого дня AQA: як за півтори хвилини довести, на чиєму боці баг «кнопка не працює»; чому автотест на форму почав плавати після винесення API на окремий домен; і як із плаваючого падіння зробити відтворюваний сценарій та доказовий тікет.

Кейс 1. «Кнопка не працює»: протокол локалізації за 90 секунд

Тестувальниця тисне «Зберегти», сторінка мовчить, тост не з'являється. Формулювання «не працює» непридатне для тікета, тому спершу збираємо факти. Порядок дій жорсткий: відкрити DevTools до повторного натискання, поставити прапорці Preserve log і Disable cache, перейти на фільтр Fetch/XHR — і лише тоді повторити дію.

Далі можливі рівно три картини, і кожна веде до свого висновку.

Name              Status   Size     Time     Protocol
(a) — жодного нового рядка після кліку —
(b) orders         422     318 B    140 ms   h2
(c) orders         200     1.2 kB   90 ms    h2

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

• Порожній журнал — це не завжди «бекенд не отримав запит». Спершу переконайтеся, що панель була відкрита до дії: записувати трафік DevTools починають лише з моменту відкриття. Якщо порожньо і при повторній спробі — запит справді не формувався, і це вже баг клієнта, а не сервера.
• 422 у другому рядку — найкорисніший результат із трьох. Сервер розібрав запит і відхилив його за змістом, тож у тілі майже завжди лежить причина. Відкрийте Payload і звірте, що поїхало: часто виявляється, що поле відправлене порожнім або в іншому форматі, і баг у формі, а не у валідації.
• Не плутайте 400 і 415. Якщо тіло сформовано вручну (наприклад, у ручному запиті через консоль) і Content-Type не відповідає вмісту, канонічна відмова — саме 415, а не «якийсь 4xx». Асерт на «будь-яку четвірку» цю різницю з'їдає й ховає причину.
• Третій рядок — найпідступніший. Статус 200, тіло на місці, застосунок порожній. Це майже завжди браузерна політика або мовчазна помилка в коді: fetch() на невдалий статус не кидає винятку, тож обробник спокійно поїде далі й запише в стан те, що прийшло. Перевіряти треба консоль, а не колонку Status.
• Колонка Protocol тут не декорація. Якщо локально видно http/1.1, а на стейджі h2 — це нормально й не є частиною дефекту: браузер піднімає HTTP/2 лише поверх TLS. Один раз пояснивши це в тікеті, ви економите цикл листування.

Готове формулювання для баг-репорта замість «не працює»: на кліку «Зберегти» йде POST /api/orders, відповідь 422, тіло — "deliveryDate must be in the future", при цьому у формі обрана завтрашня дата; заголовок Authorization на місці, кеш був вимкнений, HAR у вкладенні.

Кейс 2. Тест на форму почав плавати після винесення API на окремий домен

Симптом класичний: локально зелено, у CI падає приблизно кожен третій прогін, помилка — таймаут очікування. Змінилася при цьому не логіка застосунку, а адреса: фронтенд лишився на app.example.com, API переїхав на api.example.com. У панелі це видно одразу — на одну відправку форми з'явилося два рядки.

Name     Method     Status   Time
orders   OPTIONS    204      180 ms
orders   POST       201      340 ms

Перший рядок — preflight: браузер сам питає дозволу, перш ніж відправити «непростий» крос-оріджин запит. Тригер тут найбанальніший — заголовок Content-Type: application/json, який до безпечного переліку не входить. Логіка застосунку не змінилася, а от кожна відправка форми подорожчала на цілий додатковий обхід — і фіксована пауза, якої «вистачало» до переїзду, на завантаженому агенті CI вистачати перестала. Лікує це не більше число в паузі, а очікування на конкретну відповідь.

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

test('замовлення створюється', async ({ page }) => {
  await page.goto('https://app.example.com/orders/new');

  // очікування оголошуємо ДО кліку, інакше відповідь може приїхати раніше,
  // ніж ми почнемо її чекати
  const created = page.waitForResponse(
    (r) => r.url().endsWith('/api/orders') && r.request().method() === 'POST'
  );

  await page.getByTestId('submit-order').click();

  const response = await created;
  expect(response.status()).toBe(201);
  await expect(page.getByRole('status')).toContainText('Замовлення створено');
});

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

• Чекати треба на змістовну відповідь, а не на дозвіл. Умова request().method() === 'POST' тримає очікування саме на створенні: на одну адресу зазвичай ходить кілька методів, і фоновий GET /api/orders для списку закриє очікування замість потрібного запиту. Відповідь сервера на сам OPTIONS перевіряють прямим API-запитом, а зі сторінки чекають на змістовну відповідь.
• «У Postman працює» тут нічого не доводить. Політику одного походження застосовує браузер: він відправляє запит і вирішує, чи віддавати відповідь скрипту. Postman і curl цих правил не реалізують узагалі, тому зелений запит у них не спростовує CORS-проблеми в застосунку.
• Заблокована відповідь не означає, що нічого не сталося. Простий запит сервер виконує повністю, тому «CORS-помилка» на POST-подібному сценарії цілком може лишити по собі створений запис. При розборі даних у тесті це рятує від хибного висновку «запит не дійшов».
• Окремий симптом того ж кореня — відсутній заголовок. Якщо тест читає, наприклад, X-Request-Id з відповіді, а він порожній при статусі 200, справа не в сервері: скрипту типово доступні лише сім «безпечних» заголовків, решту бекенд має перелічити в Access-Control-Expose-Headers.
• Асерт на статус плюс асерт на інтерфейс — різні перевірки. Перший фіксує контракт, другий — що застосунок ним скористався. Залишити тільки другий означає щоразу вгадувати, де саме зламалося.

Кейс 3. Плаваюче падіння: відтворити, довести, віддати

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

Крок перший — зробити падіння відтворюваним. Замість гри в рулетку вмикають меню Throttling: воно емулює швидкість завантаження, швидкість віддачі й мінімальну затримку. Для повторюваності готовий пресет не годиться — набір пресетів між версіями Chrome змінювався, тож «повільна мережа» у двох людей означатиме різні умови; заводять власний профіль із фіксованими числами й ці числа записують у тікет разом із кроками.

Крок другий — знайти в панелі запит, який реально завершує дію, і прив'язати очікування саме до нього, а не до спінера й не до паузи. Крок третій — перевірити, що інтерфейс не бреше, коли запиту не пощастило:

// різні класи збою — це різні коди, а не синоніми
await page.route('**/api/orders**', (route) => route.abort('connectionrefused'));
await expect(page.getByRole('alert')).toContainText('Не вдалося завантажити');

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

• Жорстка пауза гонку не лікує. Вона нічого не перевіряє й лише сподівається, що система встигне; на завантаженому агенті CI вона не встигає. Очікування за умовою чесніше: таймаут у ньому — стеля терпіння, а не запланований простій.
• Падіння на повільному профілі — це вирок тесту, а не мережі. Якщо перевірка розсипається від доданої затримки, вона вже некоректна: на швидкій машині їй просто щастило. Піднімати таймаут у такій ситуації означає лікувати симптом.
• Обрив запиту — окремий клас перевірки. Коди на кшталт 'connectionrefused', 'namenotresolved' і 'internetdisconnected' описують різні збої, і застосунок має право реагувати на них по-різному. Підміняти їх усі одним 500 — означає не перевірити стан «мережа недоступна» взагалі.
• Перехоплення вибіркове, і це видно в панелі. Усе, що не підійшло під шаблон маршруту, поїде на реальний сервер, тому в журналі буде суміш справжніх і рукотворних відповідей. Перед висновком «мок не спрацював» перевірте, чи взагалі шаблон збігся з адресою.
• У тікет — HAR, а не переказ. Експорт журналу дає розробнику вашу сесію цілком, з таймінгами й заголовками; типовий експорт санітизований, тобто без Cookie, Set-Cookie й Authorization, тому файл безпечно прикладати. Той самий запис можна підключити як джерело відповідей у тесті — але пам'ятайте про ціну: HAR старіє, і зелений тест на застарілих даних гірший за червоний.

Панель, колонки й фільтри

• Готую панель до дії, а не після неї: журнал пишеться лише за відкритих DevTools, а Preserve log вмикаю наперед для сценаріїв із логіном, редиректами й багатокроковими формами.
• Знаю типовий набір колонок — Name, Status, Type, Initiator, Size, Time, Waterfall, де Status показує або код HTTP, або окреме значення CORS error, — і вмикаю приховані Protocol та Connection ID, щойно питання стосується версії протоколу чи кількості піднятих з'єднань.
• Володію обома рівнями фільтрації — кнопки типів ресурсу (Doc, Fetch/XHR, Img, JS, CSS, WS) і властивості status-code:, method:, domain:, cookie-name — і пам'ятаю, що інверсію дає прапорець Invert, а умови поєднуються лише через «і».
• Розрізняю вкладки обраного запиту: Headers — метадані, Payload — що поїхало на сервер, Response — сире тіло, Preview — розібране браузером; помилковий Content-Type у тілі читаю як канонічний 415, а не 400.
• Знаю, що HAR-експорт типово санітизований (без Cookie, Set-Cookie, Authorization), тому його безпечно чіпляти до тікета, і що його можна завантажити назад у панель.
• Не переношу звички Chrome на Firefox: там Status при збої порожній або з графічною позначкою, причина блокування словами живе в колонці Transferred, Name зветься File, а збереження журналу — «Enable persistent logs» у Settings. Про Safari нічого не стверджую: довідки Web Inspector у нашому реєстрі джерел немає.

Час, фази й статуси

• Можу назвати фази запиту по порядку й сказати, у якій із них згорів час: очікування вказує на бекенд, завантаження вмісту — на розмір тіла й пропускну здатність, а перший похід до нового хоста дорожчий на DNS, TCP і TLS.
• Не плутаю два виміри під однією абревіатурою: фаза Waiting (TTFB) рахується вже після встановлення з'єднання, а навігаційний TTFB із метрик включає ще DNS і саме з'єднання.
• Знаю два прочитання стану pending — бекенд ще обробляє звернення або слот під нього досі не звільнився — і що розрізняє їх усе та сама вкладка Timing.
• Розумію, що 304 формально 3xx, але не перенаправлення (він лише підтверджує валідність збереженої копії), і пам'ятаю поведінку методу при справжніх редиректах: 307 і 308 зберігають метод і тіло, 303 навмисно переводить на GET, а 301 і 302 дають гарантію лише для GET.

Кеш, Service Worker і стара версія

• Знаю чотири домівки «примари після деплою» — HTTP-кеш браузера, сховище Service Worker, CDN чи проміжний проксі, кеш усередині застосунку — і починаю розбір із Disable cache, пам'ятаючи, що він діє в межах панелі.
• Не плутаю директиви: no-cache дозволяє зберігати, але вимагає перевірки перед видачею, а забороняє зберігати no-store.
• Можу пояснити, чому правильні заголовки на бекенді не рятують від Service Worker: його Cache API живе окремо від HTTP-кешу, а нова версія при активному старому воркері стає в стан очікування.

З'єднання і версія протоколу

• Формулюю акуратно: близько шести паралельних з'єднань на домен — поточна практика браузерів для HTTP/1.x, а не норма протоколу; для HTTP/2 специфікація радить обмежитися одним з'єднанням на пару «хост і порт». Звідси ж пояснюю, чому локальний сайт без шифрування піде по HTTP/1.1: браузери вмикають HTTP/2 лише поверх TLS, а версію узгоджують через ALPN.

Фонові запити, кукі й сховище

• Розумію, що «сторінка відкрилась» не дорівнює «дані приїхали»: фонові виклики живуть у фільтрі Fetch/XHR, окремо від рядка з документом, а readyState === 4 у старому XMLHttpRequest означає лише «операція закінчилась», хай навіть помилкою.
• Знаю межі fetch(): він не реджектиться на 404 чи 500 (статус перевіряють через response.ok), тіло відповіді читається лише раз, а крос-оріджин виклик за замовчуванням облікових даних не шле.
• Можу пояснити, чому атрибути кукі (Secure, HttpOnly, строк життя) видно тільки в Set-Cookie у відповіді, і знаю дзеркальне правило: вміст localStorage на сервер сам не потрапляє, тому відсутній Authorization вказує на баг у клієнтському коді.

Браузерні політики й розбір «червоного» запиту

• Можу пояснити, чому «у Postman працює» не є аргументом: політику застосовує браузер, а сторонні клієнти заголовки Access-Control-* ігнорують — і чому порушення CSP при цьому шукають у консолі, а не в Network.
• Знаю, що preflight методом OPTIONS дає два рядки на один логічний запит, що JSON-виклик його викликає і що без дозволу від OPTIONS справжній запит не піде зовсім.
• Тримаю в голові порядок розбору: панель до дії, далі Status, далі «чи дійшло до сервера взагалі» (CORS error, preflight, консоль), і насамкінець найпідступніше — 200 без результату, де читають Response, консоль і Size.
• Розумію, що для AQA обмеження швидкості — інструмент відтворення гонок, а не вимірювання продуктивності (заради повторюваності краще задати власний профіль), і що очікування чіпляють до запиту, який завершує дію, а не до паузи.