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

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

Спершу браузер має дізнатися, куди стукати: імені example.com для підключення замало, тож іде резолвінг у IP-адресу. Далі відкривається транспортний канал (TCP), поверх нього сторони домовляються про шифрування (TLS), і лише після цього летить сам HTTP-запит. Потім — пауза очікування, у якій сервер готує відповідь, прихід першого байта, завантаження тіла й побудова сторінки з отриманого HTML. Сильна відповідь не зупиняється на переліку: варто одразу сказати, що кожен перехід між фазами коштує часу й ламається окремо від сусідів, тому «сайт не відкрився» — це сім різних діагнозів, а не один. І остання деталь, яку часто забувають: рендер не завершує ланцюг, а запускає нові його копії — під кожен CSS, скрипт, шрифт і картинку браузер шле власний запит.

Скільки рукостискань відбувається на шляху одного HTTPS-запиту?

Щонайменше два: транспортне TCP і криптографічне TLS. TCP домовляється трьома кроками — SYN, SYN-ACK, ACK; кроків саме три, бо сервер склеює підтвердження чужого SYN і власний SYN в одне повідомлення. TLS поверх нього автентифікує сторони, узгоджує шифри й виводить спільний ключовий матеріал, після чого record-протокол уже захищає трафік цими параметрами. Якщо сторінка відкриває реалтайм-канал, зʼявляється третє рукостискання — WebSocket, і воно оформлене як звичайний HTTP-запит з Upgrade. Практичний висновок: усе це платиться один раз на зʼєднання, а не на кожен запит, бо HTTP тримає канал відкритим і перевикористовує його — тому перше звернення до нового хоста завжди дорожче за наступні, і саме воно найчастіше не влазить у жорсткий таймаут.

Навіщо в ClientHello їде SNI і як це проявляється в тестах?

SNI (Server Name Indication) — розширення TLS, яким клієнт називає імʼя хоста ще на початку рукостискання. Без нього сервер, що тримає десяток доменів на одній IP-адресі, не знає, чий сертифікат віддавати: HTTP-заголовок Host він побачить пізніше, вже всередині шифрованого каналу. Умова успіху проста — імʼя з SNI має відповідати імені в сертифікаті, який приїде у відповідь. Звідси найтиповіша поломка нестабільних оточень: стенд підняли за новим доменом, сертифікат лишився старий, і тест валиться на TLS ще до того, як застосунок побачив хоч один запит. Помилка при цьому виглядає як проблема застосунку, хоча жодного HTTP тут ще не було.

Що змінилося в TLS 1.3 щодо видимості рукостискання і що дає режим 0-RTT?

У TLS 1.3 усе, що йде після ServerHello, уже зашифроване — включно з сертифікатом сервера. Для QA це означає, що в перехопленому трафіку деталей рукостискання не роздивитися так, як раніше, і діагностувати сертифікат доводиться інструментами, а не оком по дампу. Звичайне рукостискання специфікація описує як таке, що коштує одного обходу туди-назад. Режим 0-RTT дозволяє клієнту надіслати дані ще в першому повідомленні, якщо в сторін уже є спільний попередній ключ — отриманий або з попереднього рукостискання, або взагалі поза протоколом. Економія реальна, але плата названа прямо: у ранніх даних слабші гарантії безпеки, зокрема їх можна відтворити повторно. Тому 0-RTT — не той прапорець, який вмикають «щоб швидше», і для неідемпотентних операцій він небезпечний.

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

Fetch тримає поіменний перелік заборонених заголовків запиту — серед них Cookie, Origin, Referer, Host і Content-Length. Їх ставить сам браузер: з контексту сторінки й власного сховища, і код сторінки чи тесту переписати їх не може. Логіка тут не в примсі, а в безпеці: якби скрипт довільно малював Origin чи Cookie, уся модель походження й cookie-політик перестала б щось означати. Практичний наслідок — половина репортів «у Postman працює, а в браузері ні»: консольний клієнт ставить що завгодно, браузер — ні. Виняток, на якому ловлять найчастіше: User-Agent у цьому переліку відсутній, браузер лише підставляє своє значення, коли власного немає, — тому підміна User-Agent у тесті цілком робоча, а підміна Cookie тим самим способом мовчки ігнорується, і тест зеленіє на непідміненому запиті.

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

Тому що браузер додає цілий шар, якого поза ним не існує. По-перше, він сам ставить Cookie й Origin і не дозволяє їх переписати, тож автентифікація в браузері й у консолі може працювати по-різному. По-друге, вмикається CORS: крос-оріджин виклик, складніший за форму, спершу породжує окремий preflight, і без дозвільної відповіді основний запит не піде. По-третє, браузер здатен не відправити запит узагалі: незахищений підресурс на захищеній сторінці він або переводить на HTTPS, або відрізає, а CSP обмежує, звідки сторінці дозволено вантажити ресурси. По-четверте, відповідь могла приїхати не з мережі, а з кешу чи від service worker. Консольні клієнти заголовки Access-Control-* просто ігнорують, тому 200 у curl нічого не доводить про поведінку в браузері.

Що таке TTFB і чому два інструменти показують під ним різні числа?

TTFB — момент, коли до клієнта доходить перший байт відповіді, тобто межа між «сервер думає» і «дані йдуть». Проблема в тому, що абревіатура покриває два різні предмети вимірювання. Навігаційний TTFB, про який пишуть MDN і web.dev, рахується від старту навігації й тягне в себе резолвінг імені, обидва рукостискання, час усіх редиректів і передачу самого запиту. Фаза Waiting (TTFB) у DevTools рахується від моменту, коли запит уже пішов, і містить лише один обхід затримки плюс час підготовки відповіді — резолвінг і встановлення зʼєднання стоять у розкладці окремими смужками перед нею. Тому числа з різних інструментів не порівнюються в лоб, і в баг-репорті обовʼязково пишуть, звідки взято цифру. Діагностична цінність від цього тільки виграє: якщо роздута саме фаза очікування, а завантаження тіла й рендер у нормі, шукати треба на бекенді або в мережі до нього, а не у верстці.

У панелі мережі рядок запиту є, а бекенд його не бачив. Як таке можливо?

Найімовірніше, відповідь прийшла не з мережі. Поки збережена копія свіжа, кеш віддає її без жодного походу до сервера — і зміна, яку щойно викотили на бекенд, до тесту просто не доїде, доки свіжість не мине. Ще ближче до сторінки стоїть service worker: це фоновий скрипт-посередник між застосунком, браузером і мережею, який перехоплює навігаційні та ресурсні запити й може відповісти самотужки. Довідник DevTools це прямо фіксує — тіло відповіді браузер отримує або з мережі, або від воркера, і в обох випадках у панелі буде рядок. Розрізняти треба два схожі стани: свіжа копія з кешу означає, що сервера не питали взагалі, а 304 Not Modified — навпаки, живий запит, у якому сервер підтвердив копію й зекономив лише тіло. Перше — потенційна причина «бачу стару версію», друге — ознака справної ревалідації.

Що станеться з POST, якщо сервер відповість 301, і чому редирект не безкоштовний?

Метод може перетворитися на GET, а тіло — зникнути: для 301 і 302 незмінність гарантована лише для GET, решту методів клієнт має право підмінити. Виглядає це підступно — фінальний статус 200, тест зелений, а дані на сервер не доїхали, бо друга половина ланцюга була вже іншим запитом без тіла. 303 робить те саме навмисно й за визначенням переводить на GET. Зберігають і метод, і тіло лише 307 і 308 — тому перенаправляти POST, PUT чи DELETE треба саме ними. Щодо ціни: кожен крок ланцюга — це окремий повний HTTP-запит, і MDN називає вплив на продуктивність відчутним; час редиректів недарма входить у навігаційний TTFB. Дві деталі для перевірки: curl без -L за перенаправленням не піде, а петля редиректів — це зазвичай конфігурація сервера, і помітивши її, сервер віддає 500.

Коли браузер шле preflight і чому на маршрут OPTIONS не можна вішати авторизацію?

Preflight зʼявляється тоді, коли крос-оріджин запит складніший за той, що вміє звичайна HTML-форма. Тригерів три: метод поза GET, HEAD і POST; Content-Type поза трьома дозволеними значеннями — саме через це звичайний REST-виклик із JSON додатковий раунд і породжує; нарешті, будь-який заголовок, якого немає в безпечному переліку. Браузер спершу шле окремий OPTIONS із Access-Control-Request-Method і Access-Control-Request-Headers, і лише отримавши дозвіл у діапазоні 200–299, відправляє основний виклик. Тепер головне: preflight ніколи не несе облікових даних — ні cookie, ні Authorization. Тому перевірка авторизації, повішена на OPTIONS, гарантовано завалить його і заблокує весь ендпоінт для браузерних клієнтів, хоча в curl усе працюватиме бездоганно. Окремо памʼятають і про облікові дані в основному запиті: сервер має віддати Access-Control-Allow-Credentials: true, а зірочка в Access-Control-Allow-Origin при цьому не годиться — потрібне конкретне походження.

Чому один виклик API дає два рядки в панелі мережі і як це ламає очікування в тесті?

Бо preflight — це окремий мережевий запит, а не службова частина основного. У панелі зʼявляються два записи: спершу OPTIONS, потім реальний POST чи PATCH. Очікування на відповідь, написане надто широко — «дочекайся першої відповіді з цього URL», — має шанс зачепитися саме за OPTIONS, а він приходить раніше й нічого не каже про дані. Тест після цього йде далі, коли справжня відповідь ще в дорозі, і починає плавати без видимої причини. Лікується це точністю предиката: звіряти не лише URL, а й метод і статус відповіді. Побічний бонус — Access-Control-Max-Age дозволяє кешувати дозвіл, тож у частині прогонів другого рядка не буде взагалі, і очікування, привʼязане до наявності OPTIONS, теж стане нестабільним.

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

Залежить від версії протоколу, і це головне в питанні. Одне зʼєднання HTTP/1.x пропускає запити строго по черзі — доки не прийшла відповідь, наступний не рушить. Щоб обійти обмеження, браузер відкриває до одного походження кілька зʼєднань — колись їх було два-три, зараз поширене число шість, і саме на нього посилається DevTools, пояснюючи, чому запит стоїть у черзі. Важливо, що шістка — спостережувана поведінка браузерів, а не норма протоколу: у RFC її немає. Для HTTP/2 правило протилежне й нормативне: більш ніж одне зʼєднання на ту саму пару хоста й порту клієнту відкривати не належить. Практичний наслідок для аналізу продуктивності: гіпотеза «сторінка гальмує, бо тягне сотню дрібних файлів» на HTTP/1.1 має сенс, а на HTTP/2 — ні, і перевіряється вона колонкою Protocol, яку в панелі треба вмикати руками.

Чому локальний стенд на http:// завжди йде по HTTP/1.1, хоча сервер уміє HTTP/2?

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

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

DOMContentLoaded спрацьовує, коли HTML розібрано й DOM побудовано, — підресурси при цьому можуть іще вантажитися. load настає пізніше: сторінку завантажено разом із залежними ресурсами — стилями, скриптами, картинками, iframe, — крім лінивих. Різниця в часі буває суттєвою, але для автотестів важливіша спільна межа обох подій: жодна з них не засвідчує даних, які JavaScript тягне вже після завантаження сторінки. Тест, що чекає на load і одразу асертить таблицю, прокидається раніше за її вміст. Тому сучасні фреймворки радять чекати на факт, а не на подію чи секунди: на появу конкретного елемента, на конкретну мережеву відповідь, на стан застосунку. Фіксована пауза — найгірший з варіантів: на швидкій машині вона зайва, на повільній недостатня, а падіння від неї виглядає як баг продукту.

У панелі запит висить у стані pending. Це помилка?

Сам собою — ні. pending означає рівно те, що браузер запит ініціював, а повної відповіді ще не отримав; це стан «у процесі», а не діагноз. Далі важливий контекст. Для звичайного REST-виклику довгий pending — привід дивитися, на якій фазі стоїть час: якщо велика смужка Queueing чи Stalled, запит навіть не відправлено і він чекає вільного зʼєднання; якщо Waiting (TTFB) — думає сервер. А для стрімів, SSE й піднятого WebSocket вічний pending абсолютно нормальний: канал тримають відкритим свідомо, дані течуть по ньому, і плутати це із зависанням не варто. Помилково заведений баг «запит ніколи не завершується» на WebSocket-зʼєднанні — класика.

Тест падає лише на одному стенді, код у нього однаковий. Ваші дії?

Тут перевіряють не знання, а порядок дій: спершу фаза, потім гіпотеза, і лише тоді код. Перша підозра при «падає тільки тут» — не логіка тесту, а те, куди насправді резолвиться імʼя: запис у локальному файлі hosts на CI-ранері або машині розробника тихо відправляє трафік на інший стенд, а недавня зміна IP у середовищі може ще не розійтися, бо старий запис живе стільки, скільки дозволяє TTL, — а типовий орієнтир тут порядок днів, не хвилин. Друга підозра — сертифікат: на нестабільних оточеннях він буває самопідписаний, прострочений або виданий на інше імʼя, і тоді падіння станеться на TLS, ще до першого HTTP-запиту. Далі перевіряють різницю в конфігурації: проксі, шлюз, CORS-налаштування, версія застосунку. Найдешевший спосіб розвести ці версії — розкласти час запиту по фазах з консолі й подивитися, яка з них зʼїла час або обірвалася.

Як розкласти час запиту по фазах, маючи лише консоль?

curl вміє віддати таймінги окремими змінними у --write-out: час резолвінгу, час встановлення TCP-зʼєднання, час завершення TLS і час до першого байта. Ключова тонкість — усі вони відлічуються від старту запиту, а не від кінця попередньої фази, тож вартість кожної фази це різниця сусідніх чисел, і рахувати її треба самому.

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer}\n' \
  https://example.com/

Читається це просто. Великий перший показник — винен резолвінг. Резолвінг швидкий, а зʼєднання довге — проблема на транспорті або в мережі до хоста. Зʼєднання й TLS швидкі, а час до першого байта великий — думає сервер. Усі чотири числа малі, а сторінка все одно гальмує — вузьке місце вже на клієнті, у рендері чи в JavaScript, і далі треба йти в панель мережі й у профайлер. Такий розклад займає секунди й перетворює «щось гальмує» на конкретний напрямок пошуку.

Тест падає по таймауту. Чому не можна просто підняти таймаут?

Бо спершу треба відповісти, чий саме таймаут спрацював — вони живуть на різних рівнях і означають різне. Обмеження на встановлення зʼєднання в клієнті стосується лише фази підключення й нічого не каже про швидкість відповіді. Обмеження на читання відповіді закриває очікування даних. Шлюз, який не дочекався бекенда, віддає клієнту 504 — це вже чужий таймаут, і в конфігурації тесту він не лікується взагалі. І окремим шаром стоять таймаути тест-фреймворку: на навігацію, дію, перевірку й тест цілком. Підняти число, не зрозумівши рівня, означає сховати проблему: тест не стане стабільним, він стане повільним, а швидке падіння перетвориться на довге зависання, яке зʼїдає час прогону і все одно колись почервоніє.

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

Повторів на шляху більше, ніж здається, і вони багаторівневі. Найнижче TCP сам перевідправляє втрачені сегменти — цього з HTTP не видно взагалі. Вище ретраять HTTP-клієнти й проксі, зазвичай на 502, 503 і 504, причому пауза між спробами навмисно збільшується (бекоф) — інакше повтори добʼють сервіс, який і так лежить під навантаженням. Відповідь на «чи безпечно повторювати» дає ідемпотентність методу: GET, HEAD, OPTIONS, TRACE, PUT і DELETE лишають стан сервера однаковим після одного й після кількох однакових викликів, а POST, PATCH і CONNECT — ні. Звідси конкретний ризик: автоматичний повтор POST, що створює замовлення, здатен породити дубль — і на такий дубль потім заведуть баг у продукт, хоча винен ретрай у клієнті. Тому шар ретраїв у тестовому фреймворку теж має бути свідомим: повторювати сценарій, що створює сутності, безпечно лише тоді, коли дані сценарію унікальні на кожній спробі.

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

Кейс 1. Червоно лише на CI: розклад часу замість гіпотез

Сюїта локально зелена, на ранері падає з таймауту навігації. Спокуса очевидна — підняти таймаут і забути. Правильний перший крок інший: зʼясувати, яка фаза зʼїла час. Найдешевше це робиться прямо з ранера, без браузера й фреймворку.

# запускаємо з тієї ж машини, де падає тест
curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
  https://staging.example.com/api/health

Усі чотири таймінги відлічуються від старту запиту, а не від кінця попередньої фази. Тому саму фазу видно лише як різницю сусідніх чисел: TLS коштував time_appconnect мінус time_connect, а сервер думав time_starttransfer мінус time_appconnect. Порівняння двох прогонів — з ранера й з ноутбука — одразу показує, де саме розходяться середовища.

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

• «Падає лише в одному оточенні» майже завжди починається з імені, а не з коду. Запис у файлі hosts на образі ранера тихо відправляє тести на інший стенд, і жодна перевірка коду цього не покаже. Так само працює недавня зміна IP: старий запис живе рівно стільки, скільки дозволяє TTL, а типовий орієнтир тут — порядок днів, тож «уже ж перевикотили» нічого не гарантує.
• Сертифікат ламає тест ще до першого HTTP-запиту. Самопідписаний або прострочений сертифікат на стейджингу, домен, що не збігається з іменем у сертифікаті, — і застосунок про ваш запит навіть не дізнається. Вимикач перевірки на кшталт ignoreHTTPSErrors тут доречний, але свідомо і лише для тестових доменів: на проді він робить тест сліпим до реальної регресії.
• Числа з різних інструментів не складаються. Таймінг curl до першого байта і фаза Waiting (TTFB) у DevTools міряють різні відрізки: перший тягне в себе резолвінг і рукостискання, друга рахується від уже відправленого запиту. У тікет варто писати не лише число, а й чим його зняли.

Кейс 2. «У curl 200, у браузері порожньо»: два записи на один виклик

Ручний тестувальник каже, що форма не зберігає дані, бекендер показує успішний curl і закриває тікет. Обидва праві — просто дивляться на різні запити. Браузер перед крос-оріджин POST з application/json шле окремий OPTIONS, і якщо той не пройшов, основний виклик не полетить узагалі: бекенд його не побачить, а в панелі мережі буде червоний OPTIONS і жодного POST.

Відтворення руками займає хвилину — треба повторити саме preflight, а не основний запит:

curl -i -X OPTIONS https://api.example.com/v1/orders \
  -H 'Origin: https://app.example.com' \
  -H 'Access-Control-Request-Method: POST' \
  -H 'Access-Control-Request-Headers: content-type'

Дивимося три речі: статус має бути в діапазоні 200–299, у відповіді мають бути дозволені метод і заголовок, а походження — вказане конкретно, якщо основний виклик іде з обліковими даними. Характерна знахідка тут — 401 на OPTIONS: preflight принципово не несе облікових даних, тож будь-яка авторизація, повішена на цей маршрут, гарантовано його завалить.

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

// крихко: перший запит за цим URL — це OPTIONS, а не збереження
const [res] = await Promise.all([
  page.waitForResponse((r) => r.url().includes('/v1/orders')),
  page.getByRole('button', { name: 'Зберегти' }).click(),
]);

expect(res.status()).toBe(201); // зачепилися за відповідь на OPTIONS, а не на збереження

Надійний варіант звіряє ще й метод — і не покладається на присутність preflight узагалі:

const [res] = await Promise.all([
  page.waitForResponse(
    (r) => r.url().includes('/v1/orders') && r.request().method() === 'POST',
  ),
  page.getByRole('button', { name: 'Зберегти' }).click(),
]);

expect(res.status()).toBe(201);
await expect(page.getByTestId('order-id')).toBeVisible();

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

• 200 у консольному клієнті нічого не доводить про браузер. Заголовки Access-Control-* перевіряє виключно браузер — curl, Postman і серверні клієнти їх ігнорують. Тому «у Postman працює» не закриває тікет, а лише звужує пошук до браузерного шару.
• Один логічний виклик — два записи в мережі. Прочитати їх треба обидва: провал на OPTIONS означає проблему конфігурації CORS, провал на основному — уже логіку застосунку.
• Кешований дозвіл робить тест плаваючим. Заголовок Access-Control-Max-Age дозволяє серверу дозволити preflight наперед, тож у частині прогонів запису OPTIONS не буде зовсім. Очікування, побудоване на його наявності чи на порядковому номері запиту, ламається саме на цьому.
• Зірочка і облікові дані несумісні. Якщо виклик іде з обліковими даними (cookie або HTTP-автентифікація), серверу потрібен Access-Control-Allow-Credentials: true і конкретне походження у відповіді — узагальнене значення браузер відхилить, і симптом знову виглядатиме як мовчазна відсутність даних. Заголовок Authorization ламається інакше: Access-Control-Allow-Headers: * його не покриває, тож у дозволі він має стояти поіменно.

Кейс 3. «Сторінка гальмує»: тікет замість підняття таймауту

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

Порядок дій у панелі мережі. Спершу відкрити DevTools до відтворення: запис ведеться лише поки панель відкрита, і перезняти вже пройдений прогін не вийде. Далі увімкнути дві колонки, яких у дефолтному наборі немає — Protocol і Connection ID. Перша відповідає, по HTTP/1.1 чи по HTTP/2 пішов трафік, друга показує, чи товпляться запити в одному зʼєднанні. Потім прочитати розкладку Timing проблемного запиту.

Друге питання — чий таймаут. Вони живуть на різних рівнях і лікуються в різних місцях: клієнтське обмеження на встановлення зʼєднання стосується лише фази підключення; обмеження на читання закриває очікування відповіді; 504 віддає шлюз, який сам не дочекався бекенда, і в конфігурації тесту це не лікується взагалі; а таймаути навігації, дії, перевірки й тесту — це вже рівень фреймворку. Останній рівень часто й ховає справжню картину: тест валиться на очікуванні елемента, хоча зламалося зʼєднання двома фазами раніше.

І типова причина «непояснюваного» таймауту в самому тесті — очікування часу замість очікування факту:

// погано: змагаємося з реальним часом завантаження
await page.goto('/orders');
await page.waitForTimeout(3000);
await expect(page.getByRole('row', { name: 'Some order name' })).toBeVisible();

// добре: чекаємо на подію, яка справді щось означає
await page.goto('/orders');
await page.waitForResponse((r) => r.url().includes('/api/orders') && r.ok());
await expect(page.getByRole('row', { name: 'Some order name' })).toBeVisible();

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

• load не означає «дані на місці». Подія засвідчує ресурси самої сторінки, а запити, які JavaScript робить після неї, до неї не належать. Тест, що прокинувся на load, легко випередить власні дані.
• pending у панелі — не автоматично поломка. Це стан «запит іде, повної відповіді ще немає». Для стріма, SSE чи піднятого WebSocket він нормальний і вічний за задумом; заводити на нього баг — марна робота.
• HAR у тікет вкладати можна, але з поправкою. Експорт типово санітизований: Cookie, Set-Cookie і Authorization з нього прибрано. Це добре для безпеки й погано для відтворення сценаріїв з авторизацією — про відсутність цих заголовків у файлі варто попередити в описі тікета.
• Хороший тікет про продуктивність називає фазу, а не відчуття. «Сторінка гальмує» повертається з питаннями; «на /api/orders фаза очікування — 4,2 с у DevTools, завантаження тіла — 80 мс, протокол h2» одразу адресує проблему бекенду.

Карта фаз

• Можу назвати фази шляху запиту по порядку — від резолвінгу імені до рендеру — і пояснити, чому кожен перехід між ними це і час, і окремий режим відмови.
• Розумію, що рендер ланцюг не завершує, а множить: під кожен CSS, скрипт, шрифт і зображення йде власний запит, часто вже по відкритому зʼєднанню.

Резолвінг імені

• Памʼятаю, що запис живе стільки, скільки дозволяє TTL, а орієнтир RFC для типового вузла — порядок днів; наслідок: після зміни IP середовища тести можуть ще довго стукати за старою адресою.
• Тримаю локальний файл hosts і резолвер оточення у списку перших підозрюваних, коли тест падає рівно на одній машині чи одному ранері.

Рукостискання

• Знаю, що на звичайному HTTPS-запиті рукостискань щонайменше два — TCP і TLS, — і можу сказати, чому кроків у TCP саме три.
• Можу пояснити роль SNI: імʼя хоста в ClientHello дає серверу з багатьма доменами вибрати потрібний сертифікат, і воно має відповідати імені всередині нього.
• Розумію, чому перший запит до нового хоста дорожчий за наступні, і памʼятаю, що WebSocket відкривається як HTTP-запит Upgrade, а ознака успіху — рівно 101.

Запит і TTFB

• Знаю, що частину заголовків код підставити не може — Cookie, Origin, Referer, Host, Content-Length ставить сам браузер, — і що User-Agent у цей перелік не входить.
• Можу назвати випадки, коли браузер не відправляє запит узагалі: заблокований змішаний контент і заборона CSP спрацьовують ще до мережевої фази.
• Розрізняю два виміри під однією абревіатурою TTFB — навігаційний і фазу очікування в DevTools — і не порівнюю їхні числа в лоб.

Кеш, редирект, preflight

• Не плутаю свіжу копію з кешу і 304, і памʼятаю, що відповідь могла прийти від service worker: рядок у панелі не доводить факту мережевого обміну.
• Знаю, що 301 і 302 дозволяють клієнту підмінити метод на GET і втратити тіло, 303 робить це навмисно, а зберігають і метод, і тіло лише 307 та 308.
• Можу назвати три тригери preflight і пояснити, чому авторизацію не можна вішати на маршрут OPTIONS: облікових даних цей запит не несе.

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

• Знаю, що шість паралельних зʼєднань на походження — практика браузерів для HTTP/1.x, а не норма, і що на HTTP/2 клієнту належить одне зʼєднання на хост із портом.
• Розумію, чому локальний стенд на http:// завжди йде по HTTP/1.1: версію узгоджують через ALPN усередині TLS, а браузери піднімають HTTP/2 лише поверх нього.

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

• Знаю різницю DOMContentLoaded vs load і головне обмеження обох: жодна подія не засвідчує даних, які JavaScript тягне пізніше.
• Чекаю на факт — елемент, конкретну відповідь, стан, — а не на фіксовану паузу, і можу пояснити, чому пауза однаково погана на швидкій і повільній машині.

Панель мережі й діагностика

• Памʼятаю, що трафік пишеться лише за відкритих DevTools, читаю розкладку Timing по фазах і вмикаю колонки Protocol та Connection ID, яких у дефолтному наборі немає.
• Вмію розкласти час запиту по фазах з консолі через таймінги curl і памʼятаю, що всі вони рахуються від старту, тож вартість фази — різниця сусідніх чисел.
• Перш ніж піднімати таймаут, зʼясовую, чий саме спрацював: клієнтський на зʼєднання, на читання відповіді, шлюзовий (504) чи таймаут тест-фреймворку; так само перед повтором дивлюся на ідемпотентність методу, бо автоповтор POST здатен породити дубль.