Как измерять время загрузки страницы
Что проверяют
Понимаете ли вы, что «время загрузки» это не одна цифра, а набор метрик, и чем лабораторный замер отличается от данных реальных пользователей. Следом обычно просят назвать пороги Core Web Vitals и рассказать, как вы собираете их с продакшена.
Как отвечать
Разделите ответ на три части: что меряем, где меряем, чем.
- TTFB: время до первого байта ответа, отражает сервер, CDN и сеть;
- FCP: первый отрисованный контент;
- LCP: отрисовка самого крупного элемента в видимой области, хорошо до 2,5 с;
- INP: задержка реакции на действия пользователя, хорошо до 200 мс. В 2024 году заменила FID в Core Web Vitals;
- CLS: сдвиги вёрстки, хорошо до 0,1.
Пороги считаются по 75-му перцентилю визитов, а не по среднему.
Лабораторные замеры: Lighthouse и вкладка Performance в Chrome DevTools, WebPageTest для прогона из разных регионов и с медленной сетью. Это удобно для отладки и для бюджета производительности в CI через Lighthouse CI, но это одна машина и один сценарий.
Полевые данные (RUM): библиотека web-vitals с функциями onLCP, onINP, onCLS отправляет значения в вашу аналитику через navigator.sendBeacon. Сырые тайминги берутся из PerformanceNavigationTiming через performance.getEntriesByType('navigation'), остальные записи удобно получать через PerformanceObserver. Сводную статистику по реальным посетителям показывают CrUX и Search Console.
Для SPA отдельно скажите, что переход между маршрутами не вызывает событие load, его меряют своими метками performance.mark и performance.measure.
Где спотыкаются
Называют главной метрикой событие load или TTI. load ждёт все картинки и слабо связан с тем, что видит человек, а TTI убран из оценки Lighthouse.
Путают лабораторные цифры с реальными. Оценка 95 в Lighthouse на ноутбуке разработчика не значит, что на бюджетном телефоне с мобильной сетью LCP в норме.
Меряют один раз и смотрят на среднее. Нужны многократные прогоны и перцентили: хвост медленных визитов среднее прячет, а жалуются как раз эти пользователи.