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

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

Network показує всі мережеві запити, які зробила сторінка: завантаження HTML, скриптів, стилів, картинок і — найголовніше — фонові звернення до API. Кожен рядок таблиці — один запит із методом, статусом, розміром і часом виконання. Для тестувальника це основний прилад діагностики, бо те, що видно очима на сторінці, — вже наслідок: кнопка «Зберегти» могла відпрацювати ідеально на фронтенді, а справжня помилка в тому, що POST-запит повернув 422. Без Network залишаються лише здогади «не зберігається», з Network — факт: який запит пішов, з якими заголовками, що відповів сервер і скільки це тривало. Це перетворює баг-репорт із «щось не працює» на конкретне твердження, яке беруть у роботу відразу.

Чому DevTools треба відкрити до відтворення проблеми і що робить Preserve log?

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

На сторінці сотні запитів. Як швидко знайти потрібний виклик API?

Спершу фільтр за типом: кнопка Fetch/XHR лишає тільки фонові звернення до API (виклики через fetch() і XMLHttpRequest) — саме там майже вся робота з бекендом. Далі текстове поле фільтра: працюють прості підрядки на кшталт users і спеціальні оператори — status-code:500, method:POST, domain:api.example.com, а мінус на початку інвертує умову (-method:GET). Додатково допомагає колонка Initiator — вона показує, хто ініціював запит: рядок коду, інший запит чи редірект. У сучасному Chrome окремих кнопок XHR і Fetch немає — вони об'єднані, і для діагностики різниця між ними несуттєва.

Які класи HTTP-статусів існують і як перша цифра допомагає в діагностиці?

Перша цифра коду задає клас: 1xx — інформаційні, 2xx — успіх, 3xx — перенаправлення, 4xx — помилка клієнта, 5xx — помилка сервера. Ключове правило діагностики: 4xx означає «винен той, хто питав» — не той запит, не ті дані, немає прав; 5xx — «винен сервер»: упав, таймаут бекенду, помилка коду. Це відразу ділить розслідування на дві гілки: при 4xx дивишся на фронтенд і дані запиту (заголовки, payload), при 5xx — фіксуєш запит (URL, тіло, час, x-request-id, якщо є) і йдеш до серверних логів чи бекенд-команди. Важливо пам'ятати, що не кожен «не-200» — помилка: 304 Not Modified — це нормальне підтвердження актуальності кешу.

Чим 401 Unauthorized відрізняється від 403 Forbidden?

401 — це «не автентифікований»: у запиті немає валідних облікових даних (токен відсутній, протух або невалідний), і за RFC 9110 відповідь має містити заголовок WWW-Authenticate. 403 — протилежна ситуація: сервер зрозумів, хто ви, але у вас немає прав на цю дію, і повторний логін не допоможе. Практична різниця для тестувальника: при 401 перевіряєш Authorization у Request Headers і кукі сесії, при 403 — питання до ролі й прав користувача. Для тестів рольового доступу 403 — цінний очікуваний результат: він підтверджує, що сервер свідомо відмовляє користувачу без відповідних прав.

Що означає 422 і чим він відрізняється від 400?

422 Unprocessable Content каже: тіло запиту синтаксично коректне (інакше був би 400) і тип вмісту зрозумілий (інакше 415), але дані не проходять семантичну валідацію — наприклад, email уже зайнятий. Історична назва з RFC 4918 — «Unprocessable Entity», у RFC 9110 це саме «Unprocessable Content». У багатьох фреймворках (зокрема Rails) саме під 422 лежать повідомлення про помилки форм. Практика: побачили 422 чи 400 — відкривайте Payload і Response: у payload видно, що фактично полетіло на сервер, а у відповіді зазвичай список полів, які не пройшли валідацію. Часта знахідка саме тут: форма начебто заповнена, а в payload летить порожнє поле або старе значення — прямий доказ бага на фронтенді, а не на бекенді.

Що дивитися у вкладках Headers і Payload обраного запиту?

Headers — метадані запиту й відповіді, поділені на блоки: General (метод, повний URL, статус, IP сервера), Request Headers (що надіслав браузер) і Response Headers (що прислав сервер). Найчастіші заголовки для AQA: Content-Type (формат тіла), Authorization (токен, наприклад Bearer <token>), Cookie / Set-Cookie, Cache-Control, Location (куди редіректить при 3xx), Access-Control-Allow-Origin (дозвіл CORS). Payload показує фактичне тіло, яке браузер відправив у POST/PUT/PATCH; для GET окремого payload немає — параметри летять у URL, і DevTools розкладає їх у блоці Query String Parameters. Заголовки — часто перше місце, де ховається баг: немає Authorization — сервер поверне 401; неправильний Content-Type — сервер не зрозуміє тіло і віддасть 400 чи 415.

Чим вкладка Response відрізняється від Preview?

Обидві показують тіло відповіді, але по-різному: Response — сирий текст, як прийшов від сервера; Preview — той самий вміст, але відрендерений: JSON — розгорнутим деревом, HTML — превʼю, картинка — зображенням. Для тестувальника це місце звірки контракту: чи повернув сервер очікувані поля, у тому форматі й з тими значеннями. Це джерело правди для API-перевірок — DOM може показувати одне, а сервер віддавати інше, і без цієї вкладки не зрозуміти, на чиєму боці розбіжність.

Як зрозуміти, що відповідь прийшла з кешу, і що означає 304 Not Modified?

Ознаки відповіді з кешу: у колонці Size написано (from memory cache) або (from disk cache), статус 200, а фаза мережі в Timing практично нульова — мережею не передавалося нічого. 304 — інший випадок: це живий запит, браузер таки сходив на сервер із заголовком If-None-Match (значення — ETag) або If-Modified-Since, а сервер відповів «нічого не змінилось, бери своє з кешу». Тобто мережа була, але тіло повторно не передавалося — тому Size у 304 малий, а не «from cache». Чому це болить у тестах: тест міняє дані, перезавантажує сторінку — а бачить старі, бо браузер віддав кеш; далі хибний висновок «баг у збереженні», хоча збереження працює. Розрізнення живого 200, 200 from cache і 304 рятує від цілого класу хибних діагнозів.

Що робить прапорець Disable cache і про який нюанс варто пам'ятати?

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

Що показує Waterfall і що таке TTFB?

Waterfall — горизонтальна діаграма, де довжина смужки дорівнює часу запиту, а положення показує, коли він стартував відносно інших; вона відповідає на «чому довго» і «що на що чекало». Вкладка Timing розкладає смужку на фази: Queueing/Stalled (чекання в черзі — браузер обмежує кількість одночасних з'єднань до хоста, для HTTP/1.1 зазвичай 6), DNS Lookup, Initial connection, SSL, Waiting (TTFB) і Content Download. Найважливіша для тестувальника фаза — TTFB (Time To First Byte), час очікування першого байта відповіді: великий TTFB означає, що гальмує бекенд, а не «інтернет» чи фронтенд; великий Content Download — відповідь надто важка або канал вузький. Дві вертикальні лінії на діаграмі позначають події сторінки: синя — DOMContentLoaded (DOM побудовано), червона — Load (завантажено всі підресурси). Для AQA waterfall ще й пояснює флак: тест «клікнув і одразу перевірив» падає, бо POST ще у фазі Waiting, а асерт уже виконався — рішення не «поспати секунду», а чекати на конкретну відповідь.

Чому куку сесії не видно через document.cookie і як її тоді перевірити?

Бо вона має атрибут HttpOnly — така кука навмисно недоступна для JavaScript, це захист від крадіжки токена скриптом. Механіка кукі двонаправлена: сервер у відповіді шле Set-Cookie («збережи це»), браузер у наступних запитах — заголовок Cookie («ось що я зберіг»), і обидва напрями видно в Headers або в окремій вкладці Cookies обраного запиту, де кукі розкладені в таблицю з атрибутами. Тому HttpOnly-куку перевіряють через Network чи вкладку Application, а в автотесті — через API браузера для роботи з кукі: у Playwright це context.cookies(), а не document.cookie. З інших атрибутів варто знати Expires/Max-Age (сесійна vs постійна), Domain/Path (чому кука «не долітає» до потрібного запиту), Secure (лише HTTPS, з винятком для localhost) і SameSite (часта причина «злетілої» сесії на крос-сайтових запитах).

Навіщо тестувальнику throttling у Network?

Throttling штучно ріже пропускну здатність і додає затримку, відтворюючи повільне з'єднання без реального поганого інтернету. Це дає три класи перевірок: стани завантаження (чи є спінер і скелетон, чи не «моргає» порожній екран), гонки, які на швидкому Wi-Fi не відтворюються (кнопка активна, поки запит іще летить — подвійне надсилання), і профіль Offline — поведінка без мережі взагалі. Нюанс із пресетами: їх набір змінювався між версіями Chrome (зараз, зокрема, Fast 4G, Slow 4G, 3G — раніше були Fast/Slow 3G), тому для відтворюваних умов краще створити власний профіль із фіксованими числами завантаження, віддачі й затримки. Для AQA це чесний спосіб знайти race condition до того, як його знайде CI: якщо тест падає на повільному профілі, він не «флакне на швидкому» — він просто ще не впав, бо його очікування недостатньо прив'язані до подій.

Чим Local Storage відрізняється від Session Storage і кукі, і до чого тут ізоляція тестів?

Local Storage зберігає рядки ключ-значення, поки їх не видалять; Session Storage — те саме, але живе лише поки відкрита вкладка; кукі живуть за Expires/Max-Age і, на відміну від сторедж, автоматично їдуть на сервер із запитами. Усе це видно у вкладці Application (у Firefox — Storage), там же IndexedDB для структурованих даних і Cache Storage сервіс-воркера. Для AQA це друге після кукі місце, де ховається стан: токен доступу, вибрана мова, флаги фіч, позначка «побачив онбординг». Звідси два наслідки: діагностичний — «чому користувач після логіну бачить старий інтерфейс» може пояснюватися старим флагом у Local Storage; і тестовий — залишені між тестами localStorage чи IndexedDB є типовою причиною «тест проходить сам, але падає в наборі». Тому стан або чистять між тестами (вручну — кнопка Clear site data), або дають кожному тесту свіжий контекст браузера.

Запит у Network червоний, але коду статусу немає — (failed), (blocked). Які можливі причини?

Відсутність коду означає, що до логіки сервера справа навіть не дійшла — запит зупинився раніше, і деталі треба шукати в Console. Типові причини: CORS (у Console — «blocked by CORS policy», перевіряти Access-Control-Allow-Origin у Response Headers); net::ERR_BLOCKED_BY_CLIENT — запит зарізало розширення на кшталт адблока, перевіряється в інкогніто; блокування CSP — політика безпеки сторінки заборонила ресурс; Mixed Content — HTTPS-сторінка тягне ресурс по HTTP, браузер блокує; довгий (pending) або ERR_CONNECTION_* — сервер недоступний, немає з'єднання чи проблеми DNS, дивитись Timing, де саме зависло. Зручний прийом — тримати Console і Network поруч: побачили червоний запит у Network, зазирнули в Console по розгорнуту причину, вона часто лежить там одним рядком.

Що таке CORS і preflight? Чому дія в логах сервера пройшла, а браузер показує помилку?

CORS (Cross-Origin Resource Sharing) — механізм, який дозволяє сторінці з одного походження (origin) читати відповідь із іншого. Для «непростих» запитів — метод не з переліку GET/POST/HEAD, кастомні заголовки на кшталт Authorization, або Content-Type, відмінний від трьох простих (application/x-www-form-urlencoded, multipart/form-data, text/plain) — браузер спершу шле preflight: окремий OPTIONS-запит із Access-Control-Request-Method і Access-Control-Request-Headers, питаючи сервер, чи можна. Якщо сервер не відповів потрібними Access-Control-Allow-* заголовками, браузер блокує відповідь. Пастка в тому, що «простий» запит (без preflight) міг таки дійти до сервера й виконатись — тіло сформувалось, але браузер не дає його прочитати: у логах сервера дія пройшла, а в браузері «помилка». Звідси і практичний висновок: CORS-збій — майже завжди питання конфігурації сервера чи проксі, а не бага в тесті чи фронтенді.

Запит повернув 200, але функціонал не працює. Як розслідувати?

Це найпідступніший випадок: мережа ок, а результат ні, — тому перевіряю три речі по черзі. Перше — Response/Preview: сервер міг повернути 200 з тілом-помилкою на кшталт {"error": "..."}, порожнім тілом або не тим форматом, і формально успішний статус нічого не гарантує. Друге — Console: дуже частий сценарій, коли fetch повернув не той формат, JS упав з Uncaught TypeError при обробці відповіді, і сторінка «застигла» — при цьому в Network запит зелений. Третє — колонка Size: якщо там (from cache), ви дивитесь на старі дані, а не на свіжу відповідь. Для автотестів звідси прямий висновок: асертити тільки статус-код недостатньо — перевіряйте і тіло відповіді, і стан сторінки, а помилки консолі корисно збирати програмно й фейлити тест на несподіваних error-логах.

Як спостереження з вкладки Network переносяться в автотести?

Network — джерело правди, проти якого звіряють поведінку тестів, і кожна концепція з ручної діагностики має продовження в автоматизації. Очікування замість пауз: побачили, який запит завершує дію, — чекайте в тесті саме на нього (waitForResponse за URL і статусом у Playwright), а не фіксовану паузу; це прибирає найпоширеніший вид флаку. Перехоплення мережі (network interception): те, що в DevTools лише спостерігаєте, у тесті можна підмінити — віддати мок-відповідь, примусово повернути 500 для перевірки обробки помилок, затримати запит для перевірки спінера чи заблокувати сторонні скрипти; у Playwright це route/fulfill/abort. Ізоляція стану: кукі та Storage з вкладки Application між тестами обнуляють — свіжий контекст на тест означає, що не буде «падає лише в наборі». Асерти по контракту: тіло з Response — еталон, тест перевіряє не тільки DOM, а й що API повернув потрібні поля з потрібними значеннями. І нарешті кеш: розуміння різниці між живим 200, 200 from cache і 304 рятує від хибних баг-репортів про «зламане збереження».

Три кейси, де Network перетворює «щось не працює» на конкретне твердження: ручний розбір «червоної» реєстрації через Status → Payload → Response, переписування флакі-тесту з паузи на waitForResponse за реальною відповіддю, і перехоплення мережі, щоб примусово повернути 500 і перевірити обробку помилки. Скрізь — що дивитися і чому.

Кейс 1. «Не зберігається»: читаємо червоний запит згори вниз

Користувач тисне «Зберегти», нічого не відбувається, на фронтенді жодної помилки. Відкриваємо Network (заздалегідь, до дії), фільтр Fetch/XHR, відтворюємо клік. У списку — червоний рядок. Перше, на що дивимось, — колонка Status:

POST /api/v1/register HTTP/1.1
Host: app.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJI...

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json; charset=utf-8

Далі відкриваємо вкладку Payload — що саме браузер відправив:

{
  "email": "user@example.com",
  "password": "hunter2",
  "name": ""
}

І вкладку Response — що відповів сервер:

{
  "errors": {
    "name": ["can't be blank"],
    "email": ["has already been taken"]
  }
}

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

• Status 422 одразу ділить розслідування. 4xx — «винен» той, хто питав: тіло синтаксично коректне, тип зрозумілий, але не проходить семантичну валідацію. Це не 500 — бекенд відпрацював штатно й ще й пояснив, що не так. Йти в серверні логи не треба.
• Payload — доказ бага на фронтенді. "name": "" летить порожнім, хоча в полі щось введено. Класика: стан не встиг оновитися до сабміту. Форма «начебто заповнена», а на сервер пішло старе/порожнє значення — це фронтенд, не бекенд.
• Response — це список полів, що не пройшли валідацію. email has already been taken показує, що навіть з правильним name реєстрація впаде: email зайнятий. У багатьох фреймворках (зокрема Rails) саме тіло 422 несе повідомлення про помилки форми.
• Authorization присутній — тож 401 виключено. Якби токена не було, ми б бачили 401, а не 422, і копали б у бік сесії. Підсумковий баг-репорт: «POST /api/v1/register → 422, у payload name порожній, у response has already been taken, Authorization присутній».

Кейс 2. Флакі-тест: пауза → очікування на реальну відповідь

Тест «клікнув і одразу перевірив» то зелений, то червоний без змін у коді. У Network видно чому: асерт виконується, поки POST ще у фазі Waiting (TTFB) — відповідь не прийшла, DOM не оновився. Типова, але хибна «латка» — поспати фіксовану секунду:

// так робити не треба: пауза або флакне на повільній мережі, або гальмує на швидкій
await page.getByRole('button', { name: 'Створити' }).click();
await page.waitForTimeout(1000);
await expect(page.getByText('Замовлення створено')).toBeVisible();

Прив'язуємо очікування до тієї самої відповіді, яку видно в Network:

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

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

  // чекаємо саме на завершальний запит дії — за URL і статусом
  const responsePromise = page.waitForResponse(
    (res) => res.url().includes('/api/v1/orders') && res.request().method() === 'POST',
  );
  await page.getByRole('button', { name: 'Створити' }).click();
  const response = await responsePromise;

  // асерт по контракту: не лише DOM, а й що API реально повернув
  expect(response.status()).toBe(201);
  const body = await response.json();
  expect(body.status).toBe('created');

  await expect(page.getByText('Замовлення створено')).toBeVisible();
});

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

• waitForResponse реєструють ДО кліку. Проміс створюють перед дією, що ініціює запит, — інакше можна проґавити відповідь, яка прийшла швидше, ніж рядок з очікуванням. Клік — між створенням проміса і await.
• Прив'язка до події, яку видно в Network, а не до годинника. waitForTimeout(1000) — це ставка: «сервер устигне за секунду». На Slow 4G не встигне (червоний), на швидкому — секунда простою на кожен тест. Очікування конкретної відповіді знімає обидві проблеми.
• Асерт по контракту ловить те, що DOM ховає. Сервер міг повернути 200 з тілом-помилкою або не тим форматом, а UI показати старий кеш. Перевірка status() і полів тіла звіряє результат із джерелом правди — самою відповіддю, як у вкладці Response.
• Це той самий флак, що ловить throttling. Якщо тест падає на Slow 4G, він не «флакне на швидкому» — просто ще не впав: очікування недостатньо прив'язане до події.

Кейс 3. Перехоплення мережі: примусовий 500 і спіймана помилка консолі

У DevTools мережу лише спостерігають; у тесті її можна підмінити. Перевірити, чи застосунок коректно показує помилку сервера, без реального падіння бекенду — перехопити запит і повернути 500. Заразом слухаємо консоль, щоб спіймати JS-помилки в обробнику відповіді:

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

test('на 500 показуємо повідомлення, а не білий екран', async ({ page }) => {
  // збираємо помилки консолі протягом тесту
  const consoleErrors: string[] = [];
  page.on('console', (msg) => {
    if (msg.type() === 'error') consoleErrors.push(msg.text());
  });

  // примусово повертаємо 500 на цільовий ендпоінт
  await page.route('**/api/v1/orders', (route) => {
    route.fulfill({
      status: 500,
      contentType: 'application/json',
      body: JSON.stringify({ error: 'internal' }),
    });
  });

  await page.goto('https://app.example.com/orders');
  await page.getByRole('button', { name: 'Створити' }).click();

  // застосунок має показати зрозумілу помилку, а не «мовчки зламатись»
  await expect(page.getByRole('alert')).toContainText('Спробуйте пізніше');

  // і не впасти в консоль по дорозі
  expect(consoleErrors, `несподівані помилки консолі: ${consoleErrors.join('; ')}`).toEqual([]);
});

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

• route/fulfill — це «підмінити», а не «підглянути». DevTools показує, що POST повернув 500; тест може цей 500 згенерувати сам і перевірити, що UI на нього реагує спінером-стопом, тостом, повідомленням — а не застигає. Так само abort імітує обірваний запит, а затримка у fulfill — перевірку спінера.
• Мок ізолює фронтенд від бекенду. Тесту не потрібен реальний зламаний сервер: перевіряємо саме обробку помилки на клієнті, детерміновано й швидко.
• Слухати консоль програмно ловить приховані регресії. Дуже частий сценарій: запит зелений 200, а JS упав на обробці відповіді (Uncaught TypeError, код прочитав неіснуюче поле). Візуально «наче працює», а page.on('console') зафіксує error-лог і зафейлить тест.
• Асерт саме на role="alert", а не «зникла кнопка». Перевіряємо наявність зрозумілого повідомлення про помилку — це і є критерій «не зламалось мовчки» з профілю Offline та 5xx-сценаріїв.

Network: захоплення й колонки

• Розумію, чому DevTools пишуть мережу лише поки відкриті, тож першим ділом відкриваю Network і перезавантажую сторінку, щоб побачити повний цикл із першого запиту.
• Знаю, навіщо Preserve log: без нього редірект після логіну зітре журнал, а з ним запити зберігаються крізь навігації — must-have для логінів, редіректів і багатокрокових форм.
• Можу пояснити, що дає кожна ключова колонка (Name, Status, Type, Initiator, Size, Time, Waterfall) і чому Status — перше, на що дивишся при збої.
• Розумію, що колонка Size показує два числа (передано мережею vs розпакований розмір), а (from disk/memory cache) означає, що мережею не йшло нічого.

Фільтри та деталі запиту

• Знаю, що Fetch/XHR лишає виклики до API (тут майже вся робота з бекендом), і що в сучасному Chrome окремих кнопок XHR і Fetch уже немає — вони обʼєднані, а для діагностики різниця несуттєва.
• Можу користуватися текстовим фільтром з операторами (status-code:500, method:POST, domain:api.example.com, інверсія через -) замість прокручування всього списку.
• Розумію структуру панелі Headers (General / Response Headers / Request Headers) і що означають найчастіші заголовки: Content-Type, Authorization, Cookie/Set-Cookie, Cache-Control, ETag, Location, Access-Control-Allow-Origin.
• Знаю, де дивитися відправлене тіло (Payload, а для GET — Query String Parameters) і навіщо звіряти Response (сирий текст) vs Preview (відрендерений) як джерело правди для API-перевірок.

Статуси, кеш і тайминг

• Розумію поділ: 4xx — «винен» той, хто питав (веде до фронтенду й даних запиту), 5xx — «винен» сервер (веде до серверних логів).
• Можу розрізнити коди, які плутають: 401 (не автентифікований, немає/невалідний токен) vs 403 (автентифікований, але немає прав), 422 (тіло валідне, але не проходить семантичну валідацію) і 304 (не помилка, кеш підтверджено).
• Можу читати Waterfall/Timing по фазах і розумію, що великий TTFB вказує на бекенд, а великий Content Download — на важку відповідь чи вузький канал.
• Розрізняю живий 200, 200 (from cache) і 304 Not Modified (мережа була, тіло не передавалось) — і розумію, чому кеш породжує хибний діагноз «баг збереження».
• Знаю, що Disable cache працює лише поки DevTools відкриті, тож стабільні автотести на нього не покладаються — беруть чистий профіль/контекст.

Стан, консоль і CORS

• Знаю різницю сховищ у Application (Local Storage, Session Storage, Cookies, IndexedDB, Cache Storage) і чому залишений між тестами стан дає «тест проходить сам, але падає в наборі».
• Розумію, навіщо throttling (спінери, подвійне надсилання, Offline) і що це чесний спосіб знайти race condition до того, як його знайде CI.
• Можу читати Console у парі з Network: 200 у мережі, але червоний TypeError у консолі означає баг в обробці відповіді, а не в запиті; там же лежать деталі CORS, Mixed Content і CSP.
• Можу пояснити CORS і preflight (OPTIONS): чому «непрості» запити питають дозволу, чому без Access-Control-Allow-* браузер блокує відповідь, і чому дія могла пройти на сервері, а в браузері — «помилка».
• Знаю алгоритм діагностики червоного запиту: подивитися Status → якщо статусу немає (failed/blocked/pending), шукати причину в Console → якщо 200, але не працює, звірити Response/Preview, Console і кеш.

Мережа й автотести

• Розумію, чому очікування треба привʼязувати до реальної події з Network (waitForResponse), а не до фіксованої паузи — це прибирає найпоширеніший флак.
• Можу пояснити перехоплення мережі (route/fulfill/abort): мок відповіді, примусовий 500, затримка запиту, блокування сторонніх скриптів — і навіщо кожне з них у тестах.