Життєвий цикл запиту

Що відбувається між натисканням Enter в адресному рядку і появою сторінки?

Запит проходить ланцюг фаз: DNS-резолвінг → TCP-зʼєднання → TLS-рукостискання → надсилання HTTP-запиту → очікування відповіді сервера → отримання відповіді → рендер. Спершу браузер перетворює імʼя на IP-адресу, потім відкриває TCP-канал, поверх нього домовляється про шифрування, і лише тоді летить сам HTTP-запит. Сервер обробляє його й віддає відповідь, а браузер парсить HTML, будує DOM і домальовує сторінку, дозавантажуючи підресурси окремими запитами. Кожна стрілка в цьому ланцюгу — це час і можлива точка збою, тому для AQA важливо вміти локалізувати, на якій саме фазі тест зависнув чи флакнув: більшість «повільних» тестів ламаються не на видимому рендері, а на невидимих ранніх фазах.

Як браузер дізнається IP-адресу за доменним іменем?

Через DNS (Domain Name System), причому пошук іде каскадом кешів від найближчого до найдальшого: кеш браузера → кеш ОС і файл hosts → резолвер провайдера чи корпоративний DNS → рекурсивний обхід від кореневих серверів через TLD до авторитетного сервера домену. Кожен запис має TTL (Time To Live), після якого кеш вважається застарілим і резолвінг повторюється. Файл hosts має пріоритет над мережевим запитом — і це класична пастка для AQA: тест на машині розробника через запис у /etc/hosts ходить на локальний бекенд, а в CI — на справжній, і поведінка різна. Тому якщо тест падає лише в одному оточенні, перша гіпотеза — не код, а те, куди насправді резолвиться імʼя; перевірити можна через dig +short або nslookup.

Що таке TCP three-way handshake і навіщо keep-alive?

Це «потискання руки» з трьох кроків для відкриття зʼєднання: клієнт шле SYN, сервер відповідає SYN-ACK, клієнт підтверджує ACK — після цього канал відкритий. Зʼєднання не одноразове: HTTP тримає його відкритим (keep-alive) і повторно використовує для наступних запитів, щоб не платити щоразу за handshake, а на HTTPS — ще й за TLS. Саме тому перший запит до нового хоста завжди «дорожчий» за наступні. Для тестувальника корисно розрізняти помилки цього рівня: ECONNREFUSED означає, що на порту ніхто не слухає (типова гонка в CI — тест стартував раніше, ніж піднявся застосунок), а ETIMEDOUT — що пакети йдуть «у нікуди»: фаєрвол, неправильна мережа чи VPN.

Чим відрізняються помилки ECONNREFUSED і ETIMEDOUT?

ECONNREFUSED — сервер активно відмовив: до машини дістатися вдалося, але на вказаному порту ніхто не слухає. Найчастіша причина в CI — сервіс іще не встиг піднятися, коли тест уже пішов, або переплутаний порт. ETIMEDOUT — відповіді немає взагалі: пакети губляться дорогою, і клієнт чекає до вичерпання ліміту; типові винуватці — фаєрвол, неправильна мережа, VPN. Практична різниця для діагностики: перша помилка каже «хост є, сервісу немає» (дивись логи запуску і порт), друга — «до хоста не достукатися» (дивись мережу). Плутати їх у баг-репорті не варто, бо виправлення зовсім різні.

Що відбувається під час TLS-рукостискання і чому тести падають на сертифікатах?

TLS (Transport Layer Security) — це «S» у HTTPS: поверх уже відкритого TCP клієнт і сервер домовляються про шифрування. Клієнт шле ClientHello з підтримуваними версіями та наборами шифрів, а також SNI (Server Name Indication) — імʼя хоста, щоб сервер із багатьма доменами на одній IP віддав правильний сертифікат; сервер відповідає ServerHello і сертифікатом, далі сторони узгоджують спільний ключ. У тестах найчастіші падіння тут — самопідписаний або прострочений сертифікат на стейджингу та невідповідність імені: запит іде на staging.example.com, а сертифікат виданий на example.com. Браузер такі зʼєднання відхиляє за замовчуванням; у Playwright є явний вимикач ignoreHTTPSErrors: true, але вмикати його варто свідомо й лише для тестових оточень, бо він ховає реальні проблеми з сертифікатами.

Які заголовки браузер додає до запиту автоматично і чому це важливо?

Браузер сам підставляє Origin, Cookie, User-Agent, Referer — розробник у коді їх не пише, вони беруться з контексту сторінки та сховища cookie. Це принципово, бо саме ці «невидимі» заголовки пояснюють різницю між браузером і інструментами на кшталт Postman: Postman нічого з цього не шле, поки не додаси вручну. Практичний наслідок: сервер може вимагати Origin або авторизацію через cookie, і тоді запит із браузера працює, а «той самий» запит із Postman — ні (або навпаки). Для AQA це означає, що при відтворенні запиту поза браузером треба свідомо відтворити і його контекст, інакше порівнюєш різні речі.

Чим DOMContentLoaded відрізняється від load і чому не можна чекати лише на них?

DOMContentLoaded спрацьовує, коли HTML розпарсено й DOM побудовано — підресурси можуть іще вантажитися; load — коли завантажено все, зокрема картинки й стилі. Але обидві події засвідчують лише завантаження початкових ресурсів сторінки: JavaScript часто запускає XHR/fetch уже після load, або відповідь приходить пізніше за неї. Тому тест, який чекає лише на load, може «прокинутися» до того, як дані підвантажилися й відмалювалися. Звідси головне правило сучасних фреймворків: чекай на елемент або на конкретний мережевий запит, а не на подію завантаження сторінки — наприклад, waitFor() на рядок таблиці або page.waitForResponse() на потрібний API-виклик.

Що таке TTFB і що в нього входить?

TTFB (Time To First Byte) — час до моменту, коли до клієнта доходить перший байт відповіді. Важливо, що це не «час обробки на сервері» окремо: у TTFB входить усе, що передувало першому байту — DNS, TCP, TLS, передача запиту, робота бекенду і шлях першого байта назад; якщо на шляху був редирект, його час теж додається. Практична цінність для AQA: якщо TTFB великий, а завантаження тіла й рендер нормальні, проблема майже напевно на бекенді або в мережі до нього — це вже конкретний напрям для баг-репорту, а не розмите «сторінка гальмує». Нюанс для сеньйора: різні інструменти рахують TTFB від різних точок відліку (від старту навігації з редиректами чи від відправлення конкретного запиту), тому перш ніж порівнювати числа з DevTools і стороннього моніторингу, звір, від чого кожен веде відлік.

Що означає стан pending навпроти запиту в DevTools?

Pending означає, що браузер уже ініціював запит, але ще не отримав повної відповіді — це «в процесі», а не помилка сама по собі. Якщо ж запит висить у pending довго, причини різні: Waiting — запит пішов, а сервер довго обробляє (великий TTFB); Queued/Stalled — запит навіть не відправлено, бо браузер обмежує кількість одночасних зʼєднань до однієї origin (для HTTP/1.1 у багатьох браузерах близько 6 на хост) і зайві чекають черги; для стрімів, SSE чи WebSocket вічний pending — узагалі нормальний стан, бо зʼєднання тримається відкритим навмисно. Для тесту це виглядає як зависання на дії до таймауту фреймворку: він чесно чекає на відповідь, якої немає. Діагностика — подивитися, у якій саме фазі застряг запит: черга проти очікування сервера одразу розводить «повільний бекенд» і «браузер уперся в ліміт зʼєднань».

Які бувають коди редиректів і чим 307/308 відрізняються від 301/302?

Сервер відповідає статусом 3xx і заголовком Location, і клієнт іде за новою адресою; таких стрибків може бути кілька — це ланцюг редиректів. Ключова різниця: 301 (постійний) і 302 (тимчасовий) історично можуть змінити метод на GET, 303 завжди переводить на GET, а 307 і 308 гарантовано зберігають метод і тіло — 307 тимчасовий, 308 постійний. Кожен крок ланцюга — окремий повний запит із власними DNS/TCP/TLS, тобто редиректи додають затримку. Типові пастки в тестах: перевірка URL одразу після переходу ловить проміжний крок, а не кінцевий; API-тест, налаштований не йти за редиректами, отримує порожнє тіло замість даних; циклічний редирект браузер обриває з помилкою. Весь ланцюг зручно подивитися через curl -sIL.

Чому запит працює в Postman, але падає в браузері?

Тому що Postman і браузер — різні клієнти з різними правилами: Postman просто надсилає HTTP-запит, а браузер додає цілий шар політик безпеки й контексту. Браузер застосовує CORS і може заблокувати крос-доменний запит, автоматично шле preflight OPTIONS, сам підставляє cookie й заголовки Origin/Referer, блокує змішаний контент, а ще на запит впливають CSP, Service Worker і кеш — Postman усе це ігнорує. Найтиповіший випадок: у Postman 200 OK, у браузері — помилка CORS у консолі; це не баг фронтенду, а те, що сервер не дозволяє крос-доменний доступ, і лише браузер це перевіряє. Висновок для баг-репорту: «в Postman працює» доводить лише те, що бекенд віддає дані, а не те, що з браузера теж спрацює — це різні рівні перевірки, і плутати їх не можна.

Коли браузер шле preflight-запит і як він виглядає?

Preflight — це попередній запит методом OPTIONS, який браузер шле перед «небезпечним» крос-доменним запитом, питаючи сервер, чи дозволена запланована дія; лише після дозвільної відповіді летить справжній запит. Простими (без preflight) є GET, HEAD і POST з обмеженим набором Content-Type (form-urlencoded, multipart, text/plain) і лише «безпечними» заголовками; PUT/PATCH/DELETE, Content-Type: application/json чи будь-який кастомний заголовок на кшталт X-Request-Id тригерять preflight — тому типовий REST-виклик із JSON майже завжди його спричиняє. У preflight браузер передає Access-Control-Request-Method і Access-Control-Request-Headers, а сервер відповідає заголовками Access-Control-Allow-*; Access-Control-Max-Age дозволяє кешувати дозвіл і не повторювати OPTIONS щоразу. Класична пастка в тестах: сам запит правильний, але сервер зле відповідає на OPTIONS — і браузер блокує основний запит ще до відправлення; у тесті це виглядає як «дані не приходять», тож дивитися треба на OPTIONS, а не лише на цільовий виклик.

Чому крос-доменний запит із cookie ламається, хоча CORS начебто налаштований?

Для запитів з обліковими даними (cookie або заголовок Authorization) діють жорсткіші правила: сервер має повернути Access-Control-Allow-Credentials: true, і при цьому Access-Control-Allow-Origin не може бути * — потрібен конкретний origin. Типова конфігурація «дозволити всім» через зірочку працює для анонімних запитів, але браузер відхилить відповідь на запит із cookie. При цьому origin — це схема + домен + порт, і зміна будь-якої з трьох частин робить запит крос-доменним, тож навіть інший порт того самого домену вмикає всі ці перевірки. Це часта причина, чому запит із cookie ламається саме в браузері, тоді як у Postman той самий виклик проходить — Postman правил CORS не застосовує взагалі.

Тест упав із таймаутом. Які бувають таймаути і як зрозуміти, чий саме спрацював?

Таймаут — верхня межа часу, який компонент готовий чекати, перш ніж визнати операцію невдалою, і вони живуть на різних рівнях: connection timeout на встановлення TCP/TLS, read/response timeout HTTP-клієнта, gateway timeout проксі (клієнт бачить 504), а у тест-фреймворку — окремі navigation, action, expect і test timeout. Перший крок діагностики — зрозуміти, чий саме таймаут спрацював: 504 від шлюзу, обрив на рівні HTTP-клієнта й «expect не дочекався елемента» — три різні діагнози з різними виправленнями. Корисно знати дефолти свого інструмента: у Playwright таймаут тесту 30 с і expect 5 с, а action/navigation за замовчуванням окремого ліміту не мають і стримуються загальним таймаутом тесту; у Cypress — command 4 с, pageLoad 60 с. І окреме правило: не «лікуй» флак простим підняттям таймауту — більший таймаут ховає проблему, уповільнює тести й перетворює швидкі падіння на довгі зависання.

Чому фіксовані паузи на кшталт waitForTimeout — головне джерело флаку і що використовувати замість них?

Жорсткий sleep/waitForTimeout — це гонка з реальним часом завантаження: на швидкій машині пауза зайва і лише уповільнює прогін, на повільній — недостатня, і тест падає. Реальний час відповіді залежить від усіх фаз шляху (DNS, зʼєднання, TTFB, дозавантаження через fetch), і жодна фіксована цифра не покриває їх стабільно. Правильний підхід — чекати на факт, а не на секунди: waitFor() на конкретний елемент або page.waitForResponse() на потрібну відповідь API. Саме заміна очікування часу на очікування факту відрізняє стабільний автотест від такого, що «іноді проходить» — це наскрізний принцип для всіх фаз життєвого циклу запиту.

Що таке ідемпотентність і чому її треба враховувати, перш ніж додавати retry?

Ідемпотентний запит можна безпечно повторити, бо повтор не змінює результат: умовно GET, а також DELETE конкретного ресурсу — видалити вже видалене дає той самий стан. А от повтор POST, що створює замовлення, може створити дублікат — тому «просто додати retry» не є безпечним рішенням за замовчуванням. Ретраї при цьому живуть на кількох рівнях: TCP сам ретрансмітить втрачені пакети нижче за HTTP, HTTP-клієнти й проксі можуть повторювати запити на 502/503/504, і розумний ретрай використовує експоненційний відступ (exponential backoff), щоб не добивати перевантажений сервіс. Для AQA це означає: перш ніж вмикати автоповтори в API-тестах чи хелперах, перевір, які методи повторюються і чи не породить повтор побічних ефектів у тестових даних.

Ретраї впалих тестів у CI — це добра практика чи маскування проблем?

Двосічна: з одного боку, ретрай гасить рідкісний зовнішній флак і не валить весь прогін через одне моргання мережі; з іншого — маскує реальні нестабільності, бо тест, що проходить із другої спроби, це не «зелений» тест, а прихований баг у тесті або в продукті. Розумний підхід: ретраї ввімкнені, але кожен «passed on retry» видно у звіті, і хтось за ним іде розбиратися, а не радіє зеленому статусу. Практична конфігурація в Playwright — retries: process.env.CI ? 2 : 0: у CI повтори згладжують інфраструктурний шум, а локально флак видно одразу, поки він свіжий і його легко відтворити. Сеньйорська відповідь тут завжди включає процес: ретрай — інструмент спостереження за флаком, а не спосіб його «вилікувати».

Тест стабільно падає лише в одному оточенні. З чого почати діагностику з погляду життєвого циклу запиту?

Почати з локалізації фази, а не з коду тесту: пройтися по шляху DNS → TCP → TLS → відповідь → рендер і зіставити симптом із фазою. Падає лише в одному оточенні — перша гіпотеза DNS: запис у hosts, повільний корпоративний резолвер, пропагація свіжого домену (перевіряється через dig). ECONNREFUSED/ETIMEDOUT — рівень TCP: сервіс не піднявся або фаєрвол. Помилка сертифіката — TLS на стейджингу. Порожнє тіло чи не той URL — ланцюг редиректів (curl -IL). «Дані не приходять» у браузері — CORS/preflight, дивись на OPTIONS. Вічний pending — черга зʼєднань або мовчазний сервер, дивись фазу запиту в DevTools. Тест бачить лише кінцеве «червоно», але причина майже завжди на конкретній фазі — тому спершу локалізуй фазу (мережа проти сервера проти рендеру), і лише потім став гіпотезу про виправлення.

Три кейси, що ловлять флак на конкретних фазах шляху запиту: читання розкладки часу в DevTools і заміна sleep на очікування факту в Playwright, пастка preflight-у, коли «дані не приходять», а сервер до основного запиту й не дійшов, і ланцюг редиректів, який ловить не той URL і порожнє тіло. Скрізь — що дивитися і чому.

Кейс 1. pending назавжди: чекаємо на факт, а не на секунди

Тест клікає кнопку, яка тригерить запит за списком, і зависає до свого таймауту. У DevTools цей запит висить у pending. Перше питання — не «чому код зламався», а на якій фазі застряг запит. Розкладка часу в панелі Network (Queued, Stalled, Waiting for server response / TTFB, Content Download) відповідає одразу:

• Час осів у Waiting (TTFB) — запит пішов, сервер мовчить: довга обробка на бекенді.
• Час осів у Queued / Stalled — запит навіть не відправлено. Браузер тримає близько 6 одночасних зʼєднань на хост для HTTP/1.1, зайві чекають черги. Під навантаженням це розводить «повільний бекенд» і «браузер уперся в ліміт зʼєднань».

Тепер сам тест. Класична причина, чому він то падає, то ні, — очікування часу замість очікування факту:

// погано: гонка з реальним часом завантаження
await page.getByRole('button', { name: 'Оновити' }).click();
await page.waitForTimeout(3000);
await expect(page.getByRole('row', { name: 'John Doe' })).toBeVisible();

load засвідчує лише початкові ресурси сторінки, а не подальші fetch, які JS запускає вже після події (або відповідь на які приходить пізніше). Тому чекати треба на елемент або на конкретну відповідь:

// добре: чекаємо на факт
await page.getByRole('button', { name: 'Оновити' }).click();
await page.getByRole('row', { name: 'John Doe' }).waitFor();

// або саме на потрібну відповідь API — зручно, коли рядок зʼявляється не одразу
await Promise.all([
  page.waitForResponse((r) => r.url().includes('/api/users') && r.ok()),
  page.getByRole('button', { name: 'Оновити' }).click(),
]);

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

• Фаза застрягання в DevTools — перший крок діагностики. Черга проти очікування сервера — два різні діагнози з різними виправленнями. Фреймворк у цей час чесно чекає відповіді, якої немає, аж до свого таймауту.
• waitForTimeout(3000) — головне джерело флаку. На швидкій машині це зайве очікування, на повільному CI — недостатнє, і перевірка зрізає ще живий запит.
• Promise.all навколо кліку й waitForResponse. Слухач вішається до дії, інакше швидка відповідь встигне прилетіти раніше, ніж ми почали її чекати.

Кейс 2. Preflight: «дані не приходять», а сервер їх і не бачив

Репорт: у застосунку DELETE /api/users/42 не спрацьовує, у відповідь «нічого». У Network видно OPTIONS перед цільовим запитом — і це нормально: REST-виклик із Content-Type: application/json майже завжди тригерить preflight, бо application/json не входить до «безпечного» (safelisted) списку значень. Пастка в тому, що сам DELETE правильний, але сервер зле відповідає на OPTIONS — і браузер блокує основний запит ще до відправлення. У тесті це виглядає як «дані не приходять», хоча до бекенда справа не дійшла.

Спершу відтворюємо preflight напряму, без застосунку:

# імітуємо preflight, який шле браузер перед крос-доменним DELETE
curl -i -X OPTIONS https://api.example.com/api/users/42 \
  -H 'Origin: https://app.example.com' \
  -H 'Access-Control-Request-Method: DELETE' \
  -H 'Access-Control-Request-Headers: authorization, content-type'

У здоровій відповіді має бути дозвіл саме на наш метод, заголовки й origin:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, DELETE
Access-Control-Allow-Headers: authorization, content-type

Якщо запит іде з cookie або Authorization, є окрема вимога: сервер має повернути Access-Control-Allow-Credentials: true, і тоді Access-Control-Allow-Origin не може бути * — потрібен конкретний origin. Це часта причина, чому запит із cookie ламається саме в браузері.

Пастка інструмента: у Chromium (дефолтний браузер Playwright) preflight OPTIONS не потрапляє в мережеві події page.route/waitForResponse — чекати його зі сторінки марно, тест просто зависне до таймаута. Тому відповідь сервера на OPTIONS перевіряємо прямим API-запитом, а сторінковим тестом — лише наслідок:

test('сервер коректно відповідає на preflight', async ({ request }) => {
  // прямий OPTIONS тим самим API-контекстом — незалежно від браузерних обмежень
  const opt = await request.fetch('https://api.example.com/api/users/42', {
    method: 'OPTIONS',
    headers: {
      Origin: 'https://app.example.com',
      'Access-Control-Request-Method': 'DELETE',
    },
  });
  // якщо preflight не 2xx — браузер основний запит навіть не відправить
  expect(opt.status()).toBeLessThan(300);
  expect(opt.headers()['access-control-allow-methods'] ?? '').toContain('DELETE');
});

test('видалення проходить наскрізь', async ({ page }) => {
  await page.getByRole('button', { name: 'Видалити' }).click();
  await expect(page.getByText('Користувача видалено')).toBeVisible();
});

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

• Дивись на OPTIONS, а не лише на цільовий запит. Preflight подвоює кількість запитів — це очікувано; збій на ньому блокує основний виклик мовчки.
• Access-Control-Max-Age. Дозволяє браузеру кешувати дозвіл і не слати OPTIONS перед кожним викликом — тому в Network preflight може бути не перед кожним DELETE.
• Запит із cookie + Allow-Origin: *. Робоча на вигляд конфігурація, яка валиться саме на облікових даних: із * браузер відкине відповідь, хоча в Postman усе «зелено».

Кейс 3. Ланцюг редиректів: не той URL і порожнє тіло

Два різні прояви однієї причини — за 3xx треба (або не треба) йти далі, і тест ловить проміжний крок.

Перший — UI-тест перевіряє URL одразу після переходу й ловить проміжний, бо ланцюг ще не завершився. Типовий ланцюг: http:// → https://, потім example.com → www.example.com, потім / → /login, і кожен крок — окремий повний запит зі своїми DNS/TCP/TLS. Тому перевіряй не голий URL відразу, а чекай на кінцевий стан:

// погано: ловимо проміжний крок ланцюга
await page.goto('http://example.com/');
expect(page.url()).toContain('/login'); // може впасти: редирект ще в дорозі

// добре: чекаємо, поки браузер осяде на фінальній адресі
await page.goto('http://example.com/');
await page.waitForURL('**/login');

Другий прояв — API-тест, який має читати тіло відповіді, налаштований не йти за редиректами й отримує порожнє тіло замість даних. Весь ланцюг видно так:

# показати кожен крок редиректу і фінальний код
curl -sIL https://example.com | grep -i -E 'HTTP/|location'

HTTP/1.1 301 Moved Permanently
location: https://www.example.com/
HTTP/1.1 302 Found
location: https://www.example.com/login
HTTP/1.1 200 OK

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

• waitForURL замість миттєвої перевірки page.url(). Редиректи додають затримку — між goto і фінальною адресою браузер устигає пройти кілька стрибків.
• Прапор «йти за редиректами» в API-клієнті. Якщо тест лишає його вимкненим, на 302 він бачить порожнє тіло й заголовок Location, а не очікувані дані. Свідомо вирішуй, що перевіряєш: сам факт редиректу чи вміст фінальної сторінки.
• Метод при переході залежить від коду. 301/302 історично можуть змінити метод на GET, а 307/308 зберігають метод і тіло. Для тесту, що шле POST і чекає редирект, це різниця між «тіло доїхало» і «загубилося».
• Циклічний редирект. Неправильно налаштована авторизація зациклює переходи, і браузер обриває їх з помилкою після певної кількості кроків — у тесті це навігаційний таймаут, а не «повільна сторінка».

Шлях запиту та ранні фази

• Можу назвати фази шляху по порядку: DNS → TCP → TLS → надсилання запиту → очікування сервера → відповідь → рендер.
• Розумію, чому «повільні» й флакі тести частіше ламаються на невидимих ранніх фазах (резолвінг, зʼєднання, очікування першого байта), а не на видимому рендері.
• Знаю каскад DNS-резолвінгу (кеш браузера → кеш ОС і hosts → резолвер провайдера → рекурсивний обхід) і що таке TTL.
• Можу пояснити, чому запис у /etc/hosts дає різну поведінку тесту локально й у CI, і чому «падає лише в одному оточенні» — це перша гіпотеза про DNS, а не про код.
• Розумію три кроки TCP-рукостискання (SYN → SYN-ACK → ACK) і чому keep-alive робить перший запит до хоста дорожчим за наступні.
• Знаю, що означають ECONNREFUSED (ніхто не слухає порт, сервіс не піднявся) і ETIMEDOUT на зʼєднанні (фаєрвол/мережа/VPN).

TLS, запит і TTFB

• Можу пояснити фази TLS-рукостискання (ClientHello з SNI → ServerHello із сертифікатом → узгодження ключа) і різницю в раундах TLS 1.2 (~2 RTT) vs 1.3 (~1 RTT, 0-RTT при відновленні).
• Розумію, чому self-signed / прострочений сертифікат чи невідповідність SNI імені валить тест, і навіщо ignoreHTTPSErrors лише для тестових доменів.
• Знаю, які заголовки додає саме браузер (Origin, Cookie, Referer, User-Agent) і що розробник їх у коді не пише.
• Можу пояснити, що TTFB — це не лише обробка на сервері, а сума DNS + TCP + TLS + передача запиту + робота бекенду + очікування першого байта (і час редиректів теж).
• Розумію практичний висновок: великий TTFB при нормальному рендері вказує на бекенд/мережу, а не на фронтенд.

Рендер і очікування в тестах

• Знаю різницю між DOMContentLoaded (DOM побудовано) і load (завантажено всі початкові ресурси), і чому обидві не гарантують, що дані з fetch/XHR уже прийшли.
• Можу пояснити, чому синхронний <script> без async/defer і зовнішній CSS блокують рендер.
• Розумію головне правило: чекати на елемент або конкретну мережеву відповідь, а не на подію load чи фіксований sleep/waitForTimeout.

CORS, редиректи та pending

• Можу пояснити, коли потрібен preflight (OPTIONS): небезпечний метод, Content-Type: application/json чи кастомні заголовки поза safelist — і чому типовий REST-виклик його тригерить.
• Розумію, чому запит із cookie/Authorization вимагає Access-Control-Allow-Credentials: true і конкретного origin замість *.
• Знаю коди редиректів і різницю: 307/308 зберігають метод і тіло, 301/302 історично можуть перейти на GET, а 303 — завжди GET; і що кожен крок ланцюга — окремий повний запит із власними DNS/TCP/TLS.
• Розумію пастки редиректів у тестах: ловимо проміжний URL замість кінцевого; API-тест без автопереходу за 3xx отримує порожнє тіло.
• Можу пояснити стани pending у DevTools: Waiting (TTFB), Queued/Stalled (ліміт ~6 зʼєднань на хост для HTTP/1.1), Blocked, а також нормальний pending для стрімів/SSE/WebSocket.

Postman vs браузер, таймаути й ретраї

• Можу пояснити, чому запит успішний у Postman, але падає в браузері: CORS, preflight, автопідстановка cookie й заголовків, mixed content, CSP/Service Worker — усе це є в браузері й відсутнє в Postman.
• Розумію, що «в Postman працює» доводить лише що бекенд віддає дані, а не що спрацює з браузера.
• Знаю, що таймаути діють на різних рівнях (connection, read/idle HTTP-клієнта, gateway 504, navigation/action/expect/test у фреймворку), і що при падінні треба зрозуміти, чий саме таймаут спрацював.
• Розумію, чому не можна «лікувати» флак підняттям таймауту — це ховає проблему й перетворює швидкі падіння на довгі зависання.
• Можу пояснити звʼязок retry й ідемпотентності: GET/DELETE безпечно повторити, а повтор POST може створити дублікат; і чому «passed on retry» — це прихований баг, а не зелений тест.