Soft Navigations API: как измерять Core Web Vitals в SPA и динамических переходах

В одностраничном приложении пользователь может открыть несколько экранов, не загружая новый документ. Обычная проверка первой загрузки не показывает, как быстро открылся каталог после фильтра или карточка после клика. Soft Navigations API предназначен для более точного описания таких переходов, но на момент подготовки материала его нужно считать экспериментальным направлением.

Браузер видит один документ, а пользователь — несколько состояний. Первое отображение может быть быстрым, но переход внутри приложения заблокирован тяжёлым JavaScript. Если измерять только старт, команда будет улучшать не тот участок.

Маршрутизатор меняет URL и часть DOM. Для посетителя это новая страница, а для инструмента аналитики — событие внутри старой. Поэтому в отчёте разделяйте холодный запуск, повторный переход и возврат назад.

Пользователю важны реакция на нажатие, появление заголовка, доступность фокуса и исчезновение индикатора загрузки. Показатель должен быть связан с этим сценарием, а не с красивым числом в DevTools.

К переходу можно отнести изменение URL, основного содержимого и состояния навигации без полной загрузки документа. Не каждое изменение DOM нужно считать новой страницей: раскрытие подсказки или сортировка в таблице может быть отдельным взаимодействием.

Зафиксируйте, какой маршрут меняется и какой элемент становится новым основным заголовком. Если URL не меняется, договоритесь о событии, которое обозначает значимый экран. Это должно быть воспроизводимо и понятно аналитике.

Открытие модального окна не всегда равно навигации. Фильтр может менять список, но не создавать новый экран. Не добавляйте всё подряд в метрики: иначе отчёт перестанет помогать принимать решения.

Выберите один путь: открыть главную, перейти в каталог, применить фильтр и открыть карточку. Проведите его на новой загрузке, после кэша и на мобильном устройстве. Отметьте время клика, состояние загрузки и момент, когда можно продолжить.

При холодном запуске учитываются DNS, соединение, загрузка ресурсов и JavaScript. Повторный переход показывает работу приложения после начальной загрузки. Эти показатели нельзя сравнивать без пояснения.

Тестируйте с ограниченной скоростью и на устройстве, близком к нижнему сегменту аудитории. Если переход технически быстрый, но интерфейс не отвечает на касание, проблема относится к INP и главному потоку.

LCP помогает оценить появление главного содержимого, INP — реакцию на взаимодействие, CLS — неожиданные сдвиги. В SPA важен контекст перехода: один экран может иметь большой главный блок, другой — только небольшой список.

Назовите маршруты и группы пользователей. Средняя цифра по приложению может скрыть один проблемный экран. Для редактора полезнее сказать «карточка товара долго реагирует на фильтр», чем «INP приложения вырос».

Если задержка не меняет путь и незаметна в сценарии, приоритет может быть ниже. Если она блокирует заявку, поиск или переход к оплате, исправление важнее косметического улучшения первого экрана.

Поддержка и форматы могут измениться. Не стройте единственную систему мониторинга на экспериментальном интерфейсе. Сохраняйте ручные сценарии, обычные измерения и логи маршрутизатора.

Если API отсутствует, сайт должен работать. Условно подключайте наблюдение через feature detection, а не по имени браузера. В отчёте отмечайте, где использовался fallback.

Только человек может понять, когда интерфейс действительно готов к продолжению: появился ли заголовок, сохранился ли фокус, понятно ли сообщение об ошибке. Метрика — сигнал, а не окончательный вердикт.