Синтетический мониторинг производительности

[DmitryKazakov8]

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

const navigationTiming = performance.getEntriesByType('navigation')[0]

const loggedNavigationKeys = [
'domComplete',
'responseStart',
'domInteractive',
'domainLookupEnd',
'domContentLoadedEventEnd',
];

добавляя туда userAgent и информацию из роутера. При разработке на Реакте классовым методом — еще навешиваю декоратором измерение на componentDidMount и количество ререндеров. При необходимости можно из window.performance также вытянуть информацию по времени загрузки ресурсов, но эти метрики лучше вести отдельно по регионам, так как они относятся к качеству CDN. В целом этого достаточно для локализации всех проблем с производительностью. Но если есть ресурсы на отдельную команду по перфомансу — то можно и заморочиться с детальной разбивкой метрик, как в статье

[pan-alexey]

Большое спасибо за статью, обратил внимание что вы мерите производительность при наличии кешей, т.е. не сбрасываете кеш браузера перед аудитом. Почему именно так?

[geted]

По-хорошему Lighthouse должен сбрасывать кэш перед любым performance-аудитом, если в конфигурации явно не указано обратное (disableStorageReset). Подскажи как проводилась проверка сброса кэшей, devtools в headfull-режиме?