Тест часу відповіді

Що входить у це число

Тест просить сервіс перевірки Tenium завантажити URL і показує час у мілісекундах для кожного регіону, що відповів. Відлік починається до розв’язання імені й зупиняється, коли надійшли заголовки відповіді, тож у цифру входять DNS, TCP-з’єднання, TLS-рукостискання, очікування сервера та всі редиректи (до п’яти). Тіло відповіді не завантажується. Тому це показник на кшталт TTFB, часу до першого байта: він трохи більший за власний час обробки на сервері й менший за час, потрібний сторінці, щоб завантажитися повністю.

Монітор працює інакше: він тримає відлік, доки не надійде тіло відповіді (до 1 МБ), тому час відповіді на графіку монітора вищий, ніж тут, для того самого URL. Порівнюйте порівнянне.

Чому перший запит повільний

Холодному запиту доводиться пройти кілька обмінів з сервером, перш ніж той щось побачить: один на DNS, один на TCP, один-два на TLS і ще один на сам запит. За RTT у 100 мс нове з’єднання коштує щонайменше 300 мс, перш ніж повернеться бодай один байт сторінки, навіть якщо застосунок відповідає миттєво. Через це швидкий тест до далекого регіону може виглядати погано на цілком здоровому сервері.

Є й фізична межа. Світло у волокні долає близько 200 км за мілісекунду, тож від Франкфурта до Нью-Йорка, приблизно 6 500 км, RTT не може бути меншим за 65 мс, а реальні маршрути дають скоріше 90–110 мс. Якщо ваші відвідувачі в одному регіоні, важливе те число, яке виміряно саме з цього регіону.

Як читати кольори

Рядки зеленіють нижче за 500 мс, стають бурштиновими від 500 мс і вище та червоніють, коли запит не вдався. Рекомендації Google щодо швидкодії вебу вважають хорошим TTFB до 800 мс на 75-му процентилі, тож 500 мс — обережна межа для одного виміру. Типові сторінки виглядають так:

• 50–150 мс: кешована сторінка з вузла CDN або статичний сайт на близькому хості.
• 200–500 мс: динамічна сторінка з кешем об’єктів або далекий, але здоровий origin-сервер.
• 800–1 500 мс: некешована сторінка WordPress чи WooCommerce, найчастіше через плагін або повільний запит до бази даних.
• Понад 2 000 мс: хост перевантажений, або застосунок робить щось дороге на кожному запиті.

Один вимір — ще не вимірювання

Запустіть тест тричі, перш ніж вірити результату. Перший виклик може потрапити на холодний кеш, холодний пул з’єднань або PHP-воркер, якому треба стартувати. Справжню картину дає розподіл. Візьмімо 100 перевірок: 90 із них по 200 мс і 10 по 3 000 мс. Середнє — 480 мс, медіана — 200 мс, а 95-й процентиль — 3 000 мс. Лише процентиль показує, що в одного відвідувача з десяти справи погані; саме тому сповіщення за порогом повільності працюють краще за сповіщення про окремі виміри.

З регіонами теж обережно. Сторінка перелічує Амстердам та Лондон, але сервіс перевірки може відповісти лише з одного з них за один виклик; рядки без відповіді показують н/д. Сприймайте кожен рядок як окремий вимір із цієї точки спостереження.

Відстеження в часі

Монітор записує час відповіді на кожній перевірці й показує його на графіку по регіонах, тож регрес після деплою чи оновлення плагіна видно як сходинку на лінії. На тарифі Free інтервал — 5 хв; Starter скорочує його до 1 хв, а Pro та Agency — до 30 с. Сповіщення, коли час відповіді тримається вище за обрану вами межу, входять до тарифу Pro за $29 на місяць і вище; про це розповідає розділ моніторинг часу відповіді. Обирайте межу за даними за тиждень, приблизно вдвічі вище за звичайне значення, а не за медіаною.