Soft navigations и Core Web Vitals: почему SPA больше нельзя мерить по старинке
Chrome готовит финальный origin trial для Soft Navigations API: это важно для сайтов, где переходы происходят без полной перезагрузки.
SPA давно ведут себя как сайты: пользователь кликает ссылку, URL меняется, контент меняется. Но для браузера это часто не настоящая навигация, а изменение текущей страницы через JavaScript. Из-за этого метрики производительности могут быть менее честными.
Soft Navigations API нужен, чтобы браузер лучше понимал такие переходы.
Почему это важно
Core Web Vitals исторически проще измерять на обычных страницах: загрузилась страница, посчитали LCP, INP, CLS. В SPA пользователь может провести десять переходов без reload, и старые метрики не всегда ясно показывают, где именно стало медленно.
Для больших React/Vue/Next-приложений это проблема. Первая загрузка может быть нормальной, а второй или третий экран — тяжелым. Пользователь видит задержку, а отчет может сгладить картину.
Что делать уже сейчас
- не полагаться только на Lighthouse;
- собирать RUM-метрики с реальных пользователей;
- логировать route change;
- проверять тяжелые переходы отдельно;
- не превращать каждую страницу в гигантский клиентский bundle.
Для статичного блога
Для простого блога с обычными ссылками проблема меньше. Классические переходы проще для браузера, поисковиков и метрик. Это один из аргументов в пользу простых HTML-страниц там, где не нужен сложный клиентский интерфейс.
Вывод
Soft navigations — это не просто новая браузерная API-история. Это признание того, что современные сайты часто живут между документом и приложением. И измерять их надо честнее.
Источник: Final Soft Navigations origin trial.