Soft Navigations API в Chrome 151 наконец-то позволяет одностраничным приложениям (SPA) сообщать показатели Core Web Vitals для каждой навигации внутри приложения, но набор данных Google CrUX по-прежнему фиксирует только первую «жесткую» загрузку (hard load), из-за чего разработчики получают две разные картины производительности.

Почему метрики SPA отставали

Core Web Vitals — Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) и Cumulative Layout Shift (CLS) — были определены с расчетом на «жесткую» навигацию (hard navigation). При жесткой навигации загружается совершенно новый документ, а состояние предыдущей страницы сбрасывается.

SPA, созданные на React, Vue, Next.js или аналогичных фреймворках, редко инициируют жесткую навигацию. Клик по ссылке обновляет URL через History API, подгружает данные в фоновом режиме и заменяет контент без полной перезагрузки страницы. Существующий Performance API фиксирует только начальную загрузку страницы, поэтому LCP и INP не учитывают задержки, которые пользователи ощущают при переходе с одного маршрута на другой.

Это «слепое пятно» искажает данные в дашбордах, которые используют Performance Timeline или Google Chrome User Experience Report (CrUX). Они часто показывают отличный LCP для страницы-«оболочки» (shell page), игнорируя более медленные загрузки внутри приложения, что создает ложное ощущение стабильной производительности.

Chrome’s Soft Navigations API

В Chrome 151 представлен Soft Navigations API — набор эвристик, которые рассматривают определенные взаимодействия в SPA как полноценную навигацию. API отслеживает три сигнала:

  • взаимодействие, инициированное пользователем (клик, нажатие, событие клавиатуры)
  • изменение URL через History API
  • последующие события отрисовки (paint events), отображающие новый контент

Когда все три условия соблюдены, Chrome регистрирует «мягкую» навигацию (soft navigation) в Performance Timeline, и Core Web Vitals рассчитываются для этого перехода так же, как и для жесткой навигации. Open-source библиотека web-vitals добавила поддержку этого API 21 июля, так что разработчики уже могут извлекать эти данные с помощью привычного инструментария.

На практике теперь можно увидеть значение LCP для каждого изменения маршрута, показатель INP, отражающий реальную задержку последнего действия пользователя, и CLS, фиксирующий сдвиги макета после мягкой навигации.

Разрыв в данных: Chrome против CrUX

Данные CrUX (Chrome User Experience Report) от Google лежат в основе PageSpeed Insights, Search Console и, косвенно, влияют на сигналы ранжирования. CrUX по-прежнему агрегирует данные только по жесткой навигации.

В результате вы получаете два согласованных, но разных потока данных:

  • Внутренние инструменты, считывающие Performance Timeline, теперь показывают LCP, INP и CLS на уровне маршрутов, давая реалистичное представление о том, что на самом деле испытывают пользователи SPA.
  • Публичные наборы данных Google продолжают показывать метрики только для первой загрузки страницы — именно те данные, которые отображаются в Search Console и на которые опираются алгоритмы ранжирования Google.

Оба варианта верны; они просто измеряют разные моменты. Опора исключительно на Search Console может скрыть регрессии производительности, возникающие после начальной загрузки, в то время как одни лишь внутренние дашборды не будут отражать базовые показатели, используемые Google для SEO.

На что стоит обратить внимание разработчикам

  • Поддержка браузеров — на данный момент Soft Navigations API доступен только в браузерах на базе Chromium. В Safari и Firefox аналога пока нет, поэтому необходимо сохранять логику отката (fallback logic) для части вашей аудитории.
  • Ограничения эвристик — API определяет мягкую навигацию на основе набора признаков. Если ваше приложение обновляет контент без изменения URL (например, модальные окна или бесконечная прокрутка/infinite scroll), API может пропустить такие переходы, создавая пробелы в данных.
  • Тестирование перед внедрением — поскольку обнаружение основано на эвристиках, запустите набор реальных взаимодействий в вашем приложении и сравните полученные метрики с ручным измерением времени (например, с помощью performance.mark). Принимать решения по оптимизации на основе новых цифр стоит только после подтверждения их точности.

Итог

Chrome 151 дает разработчикам SPA долгожданную возможность измерять LCP, INP и CLS при каждом изменении маршрута внутри приложения, но данные Google для ранжирования по-прежнему отражают только первую жесткую загрузку. Пока CrUX не догонит Chrome, командам придется работать с двумя параллельными наборами данных: одним, который показывает реальную картину пользовательского опыта, и другим, который влияет на позиции в поиске. Баланс между ними — и подготовка к расширению поддержки браузеров — станет ключом к поддержанию высокой производительности SPA в конкурентной веб-среде.