В начале эпохи веб-разработки основным ориентиром производительности
страниц была скорость загрузки HTML-документа. Метрики, такие как
time to first byte (TTFB) и onload,
позволяли оценивать базовую скорость ответа сервера и полной загрузки
страницы. TTFB измерял время от отправки HTTP-запроса до получения
первого байта данных, что давало представление о задержках на сервере и
сети. Событие onload фиксировалось, когда весь HTML, CSS,
JavaScript и изображения были загружены и обработаны браузером. Эти
показатели были просты, но не отражали реального опыта пользователей:
страница могла визуально загрузиться быстро, но оставаться неполностью
интерактивной.
С появлением Navigation Timing API в HTML5 появилась
возможность детализированного анализа производительности на стороне
клиента. API предоставляло объект performance.timing,
который включал ключевые отметки времени жизненного цикла страницы:
navigationStart, responseStart,
domInteractive, domContentLoadedEventEnd и
другие. Это позволило разбивать процесс загрузки на этапы:
Хотя Navigation Timing давал подробные данные, он был ограничен агрегацией на уровне документа и не учитывал реальное восприятие скорости пользователем. Страницы могли быть визуально готовыми к взаимодействию, но показатели показывали лишь среднее время загрузки ресурсов.
Для измерения субъективного восприятия скорости
браузеры начали внедрять User Timing API и
Paint Timing API. User Timing позволял разработчикам
создавать собственные метрики с помощью performance.mark()
и performance.measure(), что давало гибкость при замере
времени выполнения скриптов или рендеринга отдельных компонентов. Paint
Timing добавлял события first-paint и
first-contentful-paint, фиксируя момент, когда браузер
начал отрисовку и когда появился первый контент на экране. Это стало
первым шагом к пониманию критических визуальных событий
и переходу от чисто серверных или сетевых метрик к визуальному
восприятию.
Несмотря на развитие API, возникла необходимость стандартизированных метрик опыта пользователя, которые учитывали бы:
Событие onload и TTFB не отражали этих аспектов. Метрики
Paint Timing фиксировали визуальные события, но игнорировали задержки от
скриптов и пользовательские действия. В результате производительность
оставалась технической, а не
человеческой, что вызывало разрыв между показателями
разработчиков и ощущением реальных пользователей.
Google инициировала проект Web Vitals, цель которого – создать стандартизированные, измеримые и понятные метрики пользовательского опыта. В основе Web Vitals лежат три ключевых показателя:
Web Vitals используют современные API браузеров, включая PerformanceObserver, Paint Timing и Layout Instability API, чтобы собирать данные в реальном времени. Это позволило перейти от анализа загрузки ресурсов к измерению реального пользовательского опыта.
С появлением Web Vitals изменился подход к мониторингу и оптимизации.
В Chrome DevTools появились встроенные панели для измерения LCP, FID и
CLS, а на стороне сервера начали внедряться RUM-решения (Real
User Monitoring), которые собирают данные с реальных
пользователей в браузере. Современные библиотеки, такие как
web-vitals.js, упрощают интеграцию метрик в проекты и
позволяют автоматически отправлять показатели на аналитические платформы
для дальнейшего анализа и улучшения производительности.
Исторический путь – от TTFB и onload до LCP, FID и CLS – демонстрирует постепенный переход от технической оценки загрузки к оценке пользовательского опыта. Каждое новое API добавляло глубину анализа, помогало выявлять узкие места в рендеринге и взаимодействии, а Web Vitals обеспечили единый стандарт, понятный как разработчикам, так и аналитикам.
Этот процесс сформировал современные практики оптимизации веб-приложений: приоритет визуальной стабильности, минимизация задержек реакции на действия пользователя и ускорение появления ключевого контента на экране. Метрики Web Vitals стали неотъемлемой частью жизненного цикла веб-страниц, интегрируясь как в инструменты анализа, так и в стратегии оптимизации фронтенда.