Наблюдение не должно портить наблюдаемое
Скрипт, который измеряет скорость загрузки, сам её замедляет. В вебе это не философское замечание, а измеримая величина.
Любой сбор данных из браузера — это дополнительный код на странице. Он занимает главный поток, может тянуть внешний запрос и отправляет данные наружу.
То есть инструмент измерения скорости загрузки участвует в скорости загрузки. Это не парадокс для рассуждений — это то, что видно в замерах.
Из чего складывается вклад
Загрузка самого скрипта. Если он приходит с чужого домена, это отдельное соединение: разрешение имени, установка защищённого канала, запрос. На плохой сети это заметные сотни миллисекунд ещё до того, как скрипт начал работать.
Исполнение. Обработчики событий, подписки, вычисление показателей — всё это работа на главном потоке, то есть в той же очереди, что и отрисовка.
Отправка. Запросы с данными конкурируют за канал с полезной загрузкой страницы.
Что с этим делать
Собирать со своего домена. Убирает отдельное соединение и разрешение чужого имени — самую дорогую часть на медленных сетях.
Отправлять пакетами и в удобный момент, а не по каждому событию. Отправка при уходе со страницы дешевле, чем десять отправок во время загрузки.
Не собирать то, что не нужно. Каждый дополнительный показатель — это подписка и вычисление; выгода от него должна перекрывать стоимость.
И проверять вклад измерением: собрать метрики со сбором и без, сравнить распределения. Это единственный честный способ узнать цену.
Почему у своего стека здесь преимущество
Не потому, что открытый код быстрее по своей природе — это было бы неправдой.
Потому что у вас есть контроль над тремя решениями, которые определяют вклад: откуда грузится скрипт, что именно собирается и когда отправляется. У внешнего сервиса первое обычно фиксировано его доменом, второе задано продуктом, третье не настраивается.
Отдельный случай: сбор в момент проблемы
Худший сценарий — когда система наблюдения нагружает страницу сильнее именно тогда, когда странице плохо.
Так бывает при сборе ошибок без ограничений: страница входит в состояние, где ошибка повторяется в цикле, обработчик отправляет каждую, и отправки добивают то, что и без них не работало.
Отсюда обязательное ограничение частоты на стороне клиента. Не на сервере — на клиенте, до отправки. Ограничение на сервере защищает сервер; страницу защищает только ограничение в браузере.
Что это значит для порогов и целей
Практическое следствие: цель по уровню обслуживания, посчитанная по данным сбора, включает вклад самого сбора.
Это нормально, если вклад мал и стабилен. И это ловушка, если сбор внезапно подорожал — например, вы добавили трассировку. Тогда показатели ухудшатся без изменений в приложении, и разбираться начнут не там.
Поэтому изменение конфигурации сбора стоит фиксировать так же, как выкат приложения: в истории, с датой. Иначе через месяц никто не свяжет ступеньку на графике с включением нового источника.