Як налаштувати моніторинг швидкості сторінки

Main Settings

Для цього типу немає окремого скриншота групи Main Settings, але кожен елемент керування в ній стандартний для всіх типів моніторів HostTracker:

• Domain/IP - URL чи домен для завантаження. Приймає повний URL чи голий домен.
• Name - опційна мітка, що показується у вашій панелі керування, сповіщеннях, звітах і віджетах. Якщо лишити порожнім, використовується URL.
• Interval schedule / Cron schedule - сегментований перемикач між простим повторюваним інтервалом і повним cron-виразом (пресети щогодини, щодня, щотижня, щомісяця, чи розширений синтаксис cron). Мінімальний доступний інтервал залежить від вашого плану.
• Tags - довільні мітки для групування й фільтрування цього монітора.
• Full Log - зберігає кожен окремий результат перевірки для цього монітора без групування.
• Open Stats - дає змогу поділитися статистикою й логами цього монітора з іншими, включно з людьми, що не увійшли в акаунт.

Ця група також містить перемикач Enabled, що призупиняє чи відновлює монітор.

Page Configuration

• Device emulation - розкривний список, що завантажує сторінку так, як це робив би конкретний пристрій: розмір вікна перегляду, рядок user agent і емуляція сенсорного вводу. За замовчуванням - Desktop. Список доступних пристроїв підтягується наживо з набору можливостей самого флоту агентів, тож точні варіанти можуть із часом рости; обирайте пристрій, що найкраще відповідає тому, як ваші відвідувачі переглядають сторінку.
• Page load timeout - максимальний час, дозволений на завершення завантаження сторінки, від 1 до 40 секунд. Якщо сторінка не завершила завантаження до цього моменту, перевірка провалюється.

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

Response Validation

Це не оцінка Core Web Vitals - HostTracker тут не обчислює оцінку продуктивності в стилі Lighthouse. Натомість він рахує конкретні відмови на рівні браузера й ліміти використання ресурсів, а ви вирішуєте, які з них мають рахуватися як Down. Кожен поріг нижче можна встановити на 0 (або, для CPU й пам'яті, перемкнути на "no threshold"), щоб вимкнути його.

Page health:

• Document/IFrame loading fail threshold - перевірка йде в Down, коли принаймні стільки документів чи iframe-ів на сторінці не завантажуються. Діапазон 0-50; 0 вимикає поріг.
• CPU usage threshold - перевірка йде в Down, коли використання CPU сторінкою (на ядро) досягає цього відсотка. Повзунок охоплює лише 80-100%, тож він ловить важкі сплески CPU, а не звичайне навантаження; окремий елемент керування "no threshold" вимикає його повністю, і це значення за замовчуванням.
• Memory usage threshold - перевірка йде в Down, коли використання пам'яті сторінкою досягає цієї кількості, у мегабайтах. Діапазон 1-1000 Мб кроками по 50 Мб, або "no threshold", щоб вимкнути, і це значення за замовчуванням.
• Client-side errors threshold - перевірка йде в Down, коли під час завантаження сторінки трапляється принаймні стільки помилок консолі браузера. Діапазон 0-50; 0 вимикає поріг.
• Client-side warns threshold - та сама ідея для попереджень консолі. Діапазон 0-50; 0 вимикає поріг.

Content Load Checks:

• Page load timeout without XHR - альтернативний, коротший тайм-аут, що застосовується, щойно всі фонові запити XHR/AJAX сторінки завершилися, окремо від основного Page load timeout вище. При 0 (за замовчуванням) застосовується лише основний тайм-аут завантаження сторінки; ненульове значення дозволяє прийняти сторінку, чий видимий вміст готовий, навіть поки фоновий опитувальний запит триває.
• Total load fails threshold - перевірка йде в Down, коли принаймні стільки ресурсів будь-якого типу не завантажуються. Діапазон 0-50; 0 вимикає поріг.
• Script / Stylesheet / Image / Font / AJAX request fails threshold - той самий підрахунок відмов, розбитий по кожному типу ресурсу, тож ви можете толерувати нестабільне рекламне зображення, не толеруючи зламаний скрипт. Кожен - 0-50, 0 вимикає поріг.

Monitoring Locations

• Locations - дерево прапорців регіонів і окремих точок моніторингу з пошуком. Оберіть конкретні локації або лишіть позначеним "All world".
• Recheck strategy - що відбувається, коли перевірка виявляє зміну стану. За замовчуванням перевірка повторюється з кількох локацій, і новий стан приймається голосуванням більшості, щоб захиститися від хибного спрацювання через одну нестабільну локацію. Альтернативи: задана кількість локацій має підтвердити Down (розкриває повзунок підтверджень Down від 1 до 7); без повторної перевірки взагалі; повна згода всіх локацій повторної перевірки; або повна згода для Down, тоді як Up потребує лише більшості.
• If selected locations are unavailable - "Selected locations only" (за замовчуванням) чекає, доки відповідять обрані вами локації; "Closest locations" підставляє найближчі доступні; "Any location" відкочується на весь світ.

Alert Subscriptions

Перемикач підписує кожен контакт на події Up/Down одним кроком, або таблиця з пошуком дає змогу підписати окремі контакти на Down, Up і Repeat (повторні нагадування про Down) незалежно. Якщо лишити цей розділ порожнім, для цього монітора не надсилатиметься жодне сповіщення - панель прямо попереджає про це.

Report Subscriptions

Той самий патерн застосовується до звітів про аптайм: перемикач підписує кожен контакт на щотижневі й щомісячні звіти, або ви можете обрати Daily, Weekly і Monthly для кожного контакту окремо.

Розібраний приклад

Припустімо, ви хочете стежити, як сторінка оформлення замовлення поводиться для покупців з мобільних пристроїв. Ви обрали б Page Speed, ввели б URL сторінки оформлення замовлення і встановили б Device emulation на профіль телефона, а не Desktop, бо більшість трафіку на цій сторінці мобільна. Лишіть Page load timeout зручно вищим за звичайний час завантаження сторінки - це стеля, призначена ловити справжні відмови, а не ціль продуктивності. У Response Validation встановіть Document/IFrame loading fail threshold на 1, бо сторінка зазвичай завантажує платіжний iframe, і ви хочете знати, якщо він перестане завантажуватися. Лишіть пороги CPU й Memory usage на "no threshold", бо сторінка оформлення замовлення рідко навантажує CPU чи пам'ять, а ці пороги все одно починаються лише з 80%. Встановіть Total load fails threshold на 2 чи 3, а не на 0, тож один нестабільний сторонній трекер не сповіщатиме вашу команду щоразу, коли він збоїть, тоді як справді зламане завантаження все одно спрацює. Лишіть Page load timeout without XHR на 0, бо сторінки оформлення замовлення часто опитують статус оплати у фоні, і це не має визначати успіх чи провал. Запустіть перевірку з двох-трьох локацій поблизу ваших реальних клієнтів, лишіть типову стратегію повторної перевірки голосуванням більшості, підпишіть черговий контакт на сповіщення Down і Repeat, і налаштуйте щотижневий звіт на спільну адресу команди.

Діагностика

• Перевірка показує Down, але сторінка виглядає нормально, коли ви відкриваєте її самі. Найімовірніше, спрацював лічильник відмов завантаження (Script, Image, Total тощо) через нестабільний сторонній ресурс, наприклад рекламну мережу чи скрипт аналітики, а не через вашу власну сторінку. Перевірте, який саме лічильник спрацював, перш ніж припускати справжній збій, і розгляньте підняти його з 0 до 1 чи 2, якщо ця нестабільність - відомий, прийнятний патерн.
• Час завантаження помітно змінився після зміни Device emulation. Очікувано, а не регресія: інший профіль пристрою змінює вікно перегляду, user agent і емуляцію дотику, що змінює те, що завантажує сторінка і як вона рендериться. Порівнюйте таймінги лише в межах одного налаштування пристрою.
• Перевірка постійно впирається в Page load timeout, хоча сторінка нормально завантажується у вашому власному браузері. Локація моніторингу може бути далеко від вашого сервера, або тайм-аут вимірює повне завантаження, включно з повільними фоновими запитами. Підніміть тайм-аут із реальним запасом, і якщо сторінка продовжує опитувати у фоні після того, як видимий вміст готовий, спробуйте ненульовий Page load timeout without XHR.
• Пороги CPU чи Memory usage ніколи не спрацьовують, навіть на важкій сторінці. Обидва починаються з "no threshold", а повзунок CPU охоплює лише 80-100% після увімкнення. Якщо відстеження важкого використання ресурсів має значення, явно переведіть елемент керування з "no threshold" і оберіть значення в діапазоні.
• Попередження консолі від рекламних скриптів чи скриптів аналітики постійно спрацьовують Client-side warns threshold. Багато сторонніх скриптів логують попередження, що не є справжніми проблемами. Лишіть цей поріг на 0, або встановіть його вищим за звичайну кількість попереджень вашої сторінки.

Пов'язане

• Моніторинг таймінгів доступу в браузері - сторінка продукту для цього типу перевірки.
• Безкоштовний тест швидкості сторінки - запустіть разову перевірку, перш ніж налаштовувати постійний моніторинг.
• Посібник з Transaction Check - для скриптування багатокрокового шляху користувача замість спостереження за одним завантаженням сторінки.
• Правила перевірки відповіді - мова правил, що використовується для перевірки HTTP і API.
• Як перевірити швидкість сайту - разовий тест і те, що означає кожне число таймінгу.
• Усі посібники з моніторингу - посібник з налаштування для кожного іншого типу перевірки.