Аптайм, час відповіді й Core Web Vitals

Клієнти просять «швидкий і надійний сайт» і мають на увазі три різні речі. Агенції ж звітують одним числом і дивуються, що воно не відповідає на запитання. Аптайм, час відповіді та Core Web Vitals пов’язані, але вимірюються по-різному, ламаються по-різному й потребують різних інструментів.

Цей посібник розділяє їх, дає пороги, які варто знати, і підказує, за чим стежити за якої проблеми. Частина порад корисна навіть без жодного інструмента моніторингу.

Аптайм: чи відповідає сайт?

Аптайм — це частка періоду, протягом якої сайт відповідав правильно. Слово «правильно» — те місце, з якого починаються суперечки. Код 200 із повідомленням про помилку на сторінці — це не «працює» в жодному розумінні, яке прийняв би відвідувач, тому серйозні монітори перевіряють і текст, і код відповіді.

Називайте простій у хвилинах, бо відсотки приховують масштаб:

Перетворіть число зі свого договору калькулятором аптайму.

Три речі визначають, чи чесне число, яке ви наводите:

1. Інтервал перевірки. П’ятихвилинна перевірка не побачить триххвилинний збій. Коротші інтервали вимірюють коротші збої.
2. Підтвердження. Один невдалий запит часто є збоєм мережі. Добрий монітор перевіряє ще раз, перш ніж записати простій, тож цифру не «роздуто» хибними збоями.
3. Вікна обслуговування. Запланований простій слід виключати, і виключення має бути видно у звіті.

Час відповіді: скільки часу потрібно серверу?

Час відповіді — це те, скільки часу триває відповідь на запит, виміряна монітором на сервері. У Tenium це час від надсилання запиту до надходження всього тіла відповіді, тож він відображає повільні запити до бази даних і великі сторінки, а не лише швидкий перший байт.

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

Читайте його правильно:

• Користуйтеся процентилями, а не лише середнім. Середнє в 400 мс може приховувати p95 у 2,5 секунди. Саме повільний «хвіст» викликає скарги відвідувачів.
• Дивіться на тенденцію. Стабільні 600 мс — це інший сайт, ніж той, де за місяць час повзе від 300 до 900 мс.
• Знайте базовий рівень. Сповіщайте про кратне перевищення звичайного значення, а не про число зі статті.
• Порівнюйте з того самого місця. Відстань має значення. Перевірка з Амстердама на сервер в Амстердамі швидша, ніж та сама сторінка для відвідувача в Сіднеї.

На Pro й Agency Tenium може сповіщати, коли час відповіді тримається вище за межу, і записує це як інцидент зниженої працездатності (degraded), окремий від збою. Кожен тариф зберігає це число й будує графік. Перевірити будь-яку адресу можна просто зараз за допомогою тесту часу відповіді.

Core Web Vitals: що відчуває відвідувач?

Core Web Vitals — це три вимірювання, визначені Google, які знімають у справжніх браузерах:

Google оцінює їх за 75-м процентилем справжніх відвідувань, а пороги опубліковано на web.dev. Дані бувають двох видів:

• Польові дані: що відчули справжні відвідувачі, зібрані від користувачів Chrome. Це показують звіт Core Web Vitals у Search Console і польова частина PageSpeed Insights.
• Лабораторні дані: синтетичний запуск у контрольованому браузері, наприклад Lighthouse. Корисні для пошуку причин, але це симуляція.

Ці числа залежать від зображень, шрифтів, JavaScript, сторонніх скриптів і макета, а не від того, наскільки швидко відповідає ваш сервер. Сайт може мати час відповіді 150 мс і LCP у 4 секунди через неоптимізоване головне зображення.

Tenium не запускає браузер, тому не вимірює LCP, INP чи CLS. Для них користуйтеся PageSpeed Insights, звітом Search Console і, для постійного вимірювання, інструментом моніторингу реальних користувачів (RUM).

Яке число за якої проблеми

Що внести до звіту для клієнта

Вкладіться в одну сторінку. Для кожного сайту: аптайм за місяць у відсотках і в хвилинах, кількість інцидентів з тривалістю й причиною, середній час відповіді та p95 порівняно з минулим місяцем, а також дати закінчення терміну дії сертифіката й домену. Якщо клієнта цікавить пошук, додайте один рядок зі статусом Core Web Vitals із Search Console, позначивши його як дані Google, а не ваші.

Змішування їх в одне число («здоров’я сайту 94%») вигадує число, яке ніхто не може перевірити. Звітуйте окремо й указуйте, звідки кожне.

Налаштування порогів

1. Дайте монітору попрацювати тиждень. Не задавайте сповіщення в перший день.
2. Прочитайте графік часу відповіді й зафіксуйте звичайний діапазон та p95.
3. Задайте межу повільності приблизно вдвічі вище за звичайне значення й вимагайте, щоб її перевищували кілька перевірок поспіль.
4. Тримайте сповіщення про збій окремо. Таймаут — це збій, а не повільність.
5. Переглядайте після кожного великого випуску; важча сторінка зсуває базовий рівень.

У Tenium тариф Free (30 моніторів, перевірки кожні 5 хв) уже зберігає час відповіді та будує його графік. Сповіщення про повільну відповідь потребує Pro ($29), який також перевіряє кожні 30 с. Як працює поріг, дивіться на сторінці моніторингу часу відповіді, а порівняння Tenium з Pingdom допоможе, якщо вам потрібен моніторинг реальних користувачів: Pingdom його пропонує, а Tenium — ні.

Поширені запитання

Читайте також

Пов’язані сторінки Tenium

• Моніторинг часу відповіді
• Тест часу відповіді
• Tenium проти Pingdom
• Усі матеріали блогу
• Тарифи