Когда использовать синтетический мониторинг, а не мониторинг реальных пользователей

Компания Embrace спонсировала этот пост.

Большинство веб-команд начинают свой путь к повышению производительности с синтетического мониторинга. Вы запускаете тест Lighthouse или средство проверки работоспособности, устанавливаете несколько пороговых значений и называете это хорошим.

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

Это иллюстрирует классический разрыв между синтетическим мониторингом и реальным мониторингом пользователей (RUM). Синтетические тесты показывают, как ваш сайт должен работать в контролируемых, достаточно предсказуемых условиях. RUM, с другой стороны, раскрывает иногда уродливую правду о том, как ваш сайт на самом деле работает на разных устройствах, в сетях, географических регионах и версиях выпуска.

Оба имеют свое место. Хитрость заключается в том, чтобы знать, когда следует полагаться на синтетические данные, а когда инвестировать в реальную информацию о пользователях.

Вот пять распространенных веб-сценариев, которые иллюстрируют разницу.

1. Запуск новой страницы или функции → Начните с синтетического

Прежде чем продвигать новую целевую страницу, процесс оформления заказа или обновление пользовательского интерфейса (UI), синтетические тесты — ваш лучший друг. Они позволяют вам сравнивать основные веб-показатели и ключевые взаимодействия в чистых, воспроизводимых условиях.

Вы можете автоматизировать их в конвейерах CI/CD или запускать их в промежуточных сборках, чтобы выявить регрессии до того, как пользователи их увидят. Синтетические данные поддерживают петлю обратной связи, пока код движется быстро.

Однако после развертывания вам захочется начать отслеживать сеансы реальных пользователей. Это связано с тем, что реальные пользователи вносят в среду сборки непредсказуемый хаос: сторонние скрипты, рекламные сети, периферийное кэширование, неоптимальные сети и т. д. Синтетические проверки не могут выявить эти разнообразные условия.

Скорее, вам понадобится инструмент RUM, чтобы вы могли замкнуть цикл, подтвердив, что повышение производительности при разработке на самом деле приводит к более комфортным и быстрым сеансам в рабочей среде.

2. Региональные жалобы или жалобы на конкретное устройство → RUM

Синтетические мониторы обычно работают в нескольких глобальных центрах обработки данных на быстрых машинах. Это нормально для бесперебойной работы, но не поможет вам предсказать проблемы, когда многие из ваших пользователей используют Android среднего класса через нестабильный 3G.

RUM, с другой стороны, отражает то, что на самом деле испытывают эти пользователи. Он создан для того, чтобы дать вам представление о распределении устройств, браузеров и сетей, которые влияют или снижают воспринимаемую производительность.

Использование инструмента RUM — единственный способ убедиться, например, что ваш сценарий оформления заказа не будет выполняться на недорогих телефонах в Южной Америке, в то время как пользователи настольных компьютеров в Соединенных Штатах не будут затронуты.

3. Отслеживание соглашений об уровне обслуживания и времени безотказной работы → Синтетический

Синтетические пинги отлично подходят для мониторинга надежности. Они предсказуемы, недороги и их легко предупредить. Если ваш сайт выйдет из строя в 3 часа ночи, синтетическая проверка узнает об этом раньше, чем это сделает человек.

RUM дополняет это, но он не предназначен для ежеминутного контроля времени безотказной работы. Вместо этого он сообщает вам, кто пострадал и насколько сильно произошел инцидент. Это дает вам контекст, необходимый для воспроизведения и решения проблемы, в идеале до того, как слишком многие ваши конечные пользователи почувствуют разочарование.

Их совместное использование дает вам как быстрое представление о проблеме, так и ее масштаб. Например, технически сбой может длиться три минуты, но ваш инструмент RUM показывает, что только 5% сеансов фактически завершились сбоем. Это нюанс, который вы никогда не получите, используя только синтетику.

4. Оптимизация основных веб-показателей и реального UX → RUM

Синтетические инструменты могут оценивать «Наибольшую отрисовку контента» (LCP), «Совокупный сдвиг макета» (CLS) и «Взаимодействие с следующей отрисовкой» (INP), но они работают, по сути, в «лабораторных» условиях. Однако реальные пользователи вносят хаос, который может улучшить или разрушить эти показатели.

RUM фиксирует, как ваши основные веб-показатели ведут себя в зависимости от браузера, устройства и скорости сети, и именно на этом основан набор данных Google CrUX. Вы можете обнаружить, что только 5% сеансов имеют ужасный INP, но эти 5% представляют собой тысячи разочарованных мобильных покупателей. Это идеи, которые синтетический метод не может обнаружить.

5. Исследование замедления работы серверной части или API → используйте оба варианта.

Когда страница кажется вялой, это редко происходит только по вине внешнего интерфейса. Часто проблемы кроются где-то в внутренней инфраструктуре, и чтобы это выяснить, требуется некоторое расследование. Синтетическое тестирование здесь очень полезно. Эти тесты могут подтвердить, что ваши API отвечают в пределах SLO (целей уровня обслуживания) и что критические потоки (например, вход в систему или оформление заказа) не регрессируют.

Однако RUM идет дальше, демонстрируя фактическое влияние на пользователей.

С помощью современной распределенной трассировки (например, с помощью OpenTelemetry) вы можете сопоставить медленный диапазон API с ухудшенным событием LCP внутри реальной трассировки сеанса. Это позволяет вам напрямую понять, как проблемы с серверной частью мешают реальным конечным пользователям использовать ваш сайт так, как он должен восприниматься. Вы не только видите узкое место серверной части, вы точно видите, как оно проявляется в браузере. Чтобы узнать больше о современных подходах к RUM, посетите этот вебинар по запросу от Embrace.

Выбор подходящего инструмента для работы

Синтетический мониторинг и мониторинг реальных пользователей являются взаимодополняющими инструментами. Команды, сочетающие оба подхода, получают лучшее из всех миров: синтетическое для контролируемых базовых показателей и тестирования безотказной работы, RUM для проверки реальных данных и распределенную трассировку для их связи.

Embrace — это ориентированная на пользователя платформа наблюдения, которая связывает техническую производительность с воздействием на конечного пользователя. Embrace, основанный на OpenTelemetry, обеспечивает реальный мониторинг пользователей на мобильных устройствах и в Интернете, поэтому инженерные группы могут быстрее решать проблемы, повышать производительность и предоставлять исключительные цифровые возможности. Узнайте больше Последние новости от Embrace TRENDING STORIES YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Вирна Секуй — маркетолог в Embrace. Она имеет почти 10-летний опыт работы в области управления продуктами, маркетинга и исследовательского анализа. До работы в Embrace Вирна работала в Bose, Onside Sponsorship и GWI. За время работы в Embrace… Подробнее от Вирны Секуй.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *