Как настроить мониторинг Page Speed

Основные настройки

У этого типа нет отдельного скриншота для группы Main Settings, но каждый элемент управления в ней стандартен для всех типов мониторов HostTracker:

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

Эта группа также несет переключатель Enabled, приостанавливающий или возобновляющий монитор.

Настройка страницы

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

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

Проверка ответа

Это не оценка Core Web Vitals - HostTracker здесь не вычисляет оценку производительности в стиле Lighthouse. Вместо этого он считает конкретные сбои на уровне браузера и лимиты использования ресурсов, а вы решаете, какие из них должны засчитываться как Down. Каждый порог ниже можно установить в 0 (либо, для CPU и памяти, переключить на "без порога"), чтобы отключить его.

Page health:

• Document/IFrame loading fail threshold - проверка уходит в Down, когда хотя бы столько документов или iframe на странице не загружаются. Диапазон 0-50; 0 отключает.
• CPU usage threshold - проверка уходит в Down, когда использование CPU страницей (на ядро) достигает этого процента. Ползунок покрывает только 80-100%, так что он ловит тяжелые всплески CPU, а не обычную нагрузку; отдельный элемент "без порога" полностью его отключает, это значение по умолчанию.
• Memory usage threshold - проверка уходит в Down, когда использование памяти страницей достигает этого объема, в мегабайтах. Диапазон 1-1000 Мб с шагом 50 Мб, либо "без порога" для отключения, это значение по умолчанию.
• 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 отключает.

Локации мониторинга

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

Подписки на оповещения

Один переключатель подписывает всех контактов на события Up/Down за один шаг, либо таблица с поиском позволяет подписывать отдельных контактов на Down, Up и Repeat (повторные напоминания о Down) независимо. Если оставить этот раздел пустым, для этого монитора не будет отправлено ни одного оповещения - панель явно предупреждает вас об этом.

Подписки на отчеты

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

Разобранный пример

Допустим, вы хотите следить за тем, как страница оформления заказа работает для мобильных покупателей. Вы бы выбрали Page Speed, ввели URL страницы оформления заказа и установили Device emulation в профиль телефона, а не Desktop, поскольку большая часть трафика на этой странице мобильная. Оставьте Page load timeout с комфортным запасом выше обычного времени загрузки страницы - это потолок, предназначенный для ловли настоящих сбоев, а не цель по производительности. В Response Validation установите Document/IFrame loading fail threshold в 1, поскольку страница обычно загружает платежный iframe, и вы хотите знать, если он перестанет загружаться. Оставьте пороги CPU и Memory usage на "без порога", поскольку страница оформления заказа редко требовательна к 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 или памяти как будто никогда не срабатывают, даже на тяжелой странице. Оба начинаются на "без порога", а ползунок CPU покрывает только 80-100% после включения. Если отслеживание тяжелого использования ресурсов важно, явно уберите элемент управления с "без порога" и выберите значение в диапазоне.
• Предупреждения консоли от рекламных или аналитических скриптов постоянно срабатывают на Client-side warns threshold. Многие сторонние скрипты логируют предупреждения, которые не являются настоящими проблемами. Оставьте этот порог на 0, либо установите выше обычного числа предупреждений вашей страницы.

Связанные материалы

• Мониторинг времени доступа браузера - страница продукта для этого типа проверки.
• Бесплатный тест скорости страницы - выполните разовую проверку перед настройкой постоянного мониторинга.
• Руководство по проверке Transaction - для скриптования многошагового пользовательского сценария вместо наблюдения за загрузкой одной страницы.
• Правила проверки ответа - язык правил, используемый для проверки HTTP и API.
• Как проверить скорость сайта - разовый тест и что означает каждое число тайминга.
• Все руководства по мониторингу - руководство по настройке для каждого другого типа проверки.