Soft Navigation в Chrome DevTools: как измерять производительность динамических сайтов

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

А performance trace всё ещё продолжается как одна длинная жизнь первоначально загруженного документа.

Именно эта ситуация долго была слабым местом диагностики Single Page Applications.

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

Для пользователя различие почти незаметно.

Для старой модели performance measurement — принципиально.

Chrome решает эту проблему через Soft Navigations API и поддержку soft navigations в DevTools. Начиная с Chrome 151 функция включена по умолчанию, а в актуальном Performance panel доступны Live Metrics, markers в trace и анализ через Insights. В октябрьском DevTools recap Google назвал это полной end-to-end поддержкой soft navigation measurement.

На 4 октября 2026 года актуальная stable-ветка — Chrome 154.

Hard Navigation и Soft Navigation — это разные границы измерения

При обычной, или hard navigation, браузер загружает новый HTML-документ.

Условно:

/catalog/
→ клик
→ HTTP navigation
→ новый document
→ /product/

Новый документ естественным образом получает новый navigation timing, собственный LCP и новый жизненный цикл Core Web Vitals.

Soft navigation работает иначе:

/catalog/
→ клик
→ JavaScript
→ изменение URL
→ замена основного контента
→ /product/

Сам document при этом остаётся прежним.

Из-за этого традиционные метрики загрузки исторически гораздо естественнее работали с MPA, чем с SPA.

В SPA первоначальный экран мог иметь отличный LCP, а переход пользователя в тяжёлый каталог — занять несколько секунд.

Если измерять только первую загрузку документа, такой пользовательский опыт теряется.

Именно поэтому soft navigation важен не как новая разновидность маршрутизации, а как новая граница измерения производительности.

Не каждое изменение DOM — навигация

Здесь легко уйти в противоположную крайность и объявить soft navigation любую AJAX-операцию.

Так делать не нужно.

Текущая эвристика Chrome опирается на несколько связанных признаков:

• действие инициирует пользователь;
• видимый URL меняется;
• взаимодействие приводит к видимому paint.

Например, пользователь нажал:

«Показать ещё комментарии»

и приложение добавило двадцать элементов в DOM.

URL остался прежним.

Это обычное взаимодействие, а не soft navigation.

Другой вариант:

фильтр товара меняет URL через history.replaceState(), но пользователь по смыслу остаётся на том же экране и существенного нового представления не появляется.

Здесь уже важны конкретное поведение приложения и текущая эвристика браузера. Chrome специально использует heuristic-based detection, а не позволяет каждому framework самостоятельно объявлять любое событие «навигацией». Такой подход нужен, чтобы метрики разных сайтов оставались сопоставимыми.

History API сам по себе ничего не доказывает

pushState() или replaceState() часто участвуют в SPA routing.

Но вызов History API ещё не превращает действие в soft navigation.

Точно так же смена URL без пользовательского взаимодействия не соответствует текущему базовому определению.

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

SPA transition и Soft Navigation — не абсолютные синонимы

Framework знает собственный router.

Например, React, Vue или другое SPA-приложение может считать переходом событие, которое браузерная эвристика soft navigation не распознаёт.

Возможна и обратная ситуация — Chrome распознаёт последовательность событий как soft navigation, хотя разработчик воспринимает её как сложное изменение состояния текущей страницы.

Google прямо предупреждает о потенциальных false positives и false negatives и продолжает стандартную работу над API.

Поэтому полезно разделять два понятия:

SPA transition — понятие архитектуры конкретного приложения.

Soft Navigation — браузерно определяемая измерительная граница.

Для performance analytics второе особенно ценно, потому что не требует знать внутреннюю реализацию каждого frontend framework.

Почему больше всего страдал LCP

INP и CLS технически можно сегментировать по временным интервалам: в их основе лежат события взаимодействий и layout shifts.

С LCP ситуация сложнее.

Классический largest-contentful-paint относится к жизни первоначально загруженного документа и заканчивает обычное измерение после пользовательского взаимодействия.

Но внутри SPA после этого могут появиться совершенно новые экраны.

Chrome решает задачу через новый interaction-contentful-paint.

После взаимодействий браузер может сообщать contentful paints, а для soft navigation соответствующий SoftNavigationEntry позволяет определить крупнейший paint, относящийся именно к переходу.

Это означает, что для последовательности:

страница товара
→
клик «Каталог»
→
client-side routing
→
отрисовка большого каталога

можно оценивать новый LCP относительно момента soft navigation.

Причём элемент, оставшийся от предыдущего экрана, не становится автоматически LCP нового перехода. Для soft navigation учитываются новые paints, связанные с вызвавшим переход взаимодействием.

И это гораздо ближе к тому, что реально воспринимает пользователь.

Как Chrome распознаёт Soft Navigation

После определения soft navigation браузер создаёт soft-navigation performance entry.

Она содержит:

• новый URL в name;
• уникальный navigationId;
• interactionId пользовательского действия;
• timing-данные, связанные с новым переходом.

Связанные performance entries также получают navigationId.

Это позволяет инструментам понять:

вот это interaction, layout shift и paint относятся уже к новому виртуальному экрану, хотя физически browser document не перезагружался.

Для LCP есть дополнительная тонкость: часть paints может произойти до момента, когда браузер окончательно подтвердил soft navigation. Поэтому для привязки interaction-contentful-paint Chrome рекомендует учитывать interactionId, а не слепо группировать всё только по navigationId.

Для обычной работы через DevTools знать эту механику необязательно.

Для собственного RUM — уже полезно.

Что теперь видно в Chrome DevTools

В Chrome 152 Soft Navigation появился в Live Metrics и trace views.

В октябрьском обновлении DevTools анализ был добавлен и в Insights, после чего Chrome описал поддержку как full end-to-end soft navigation support в Performance panel.

Практически разработчику доступны три уровня.

Live Metrics

Live Metrics теперь может показывать Core Web Vitals для клиентских soft navigations в SPA.

То есть можно открыть приложение, пройти несколько экранов и наблюдать, как метрики относятся уже не только к первоначальной загрузке. Поддержка основана в том числе на web-vitals 6.0.0.

Performance trace

В записанном trace soft navigation имеет собственный marker.

Это особенно полезно, когда нужно понять не просто итоговую метрику, а причину задержки:

• долгий event handler;
• тяжёлая client-side маршрутизация;
• fetch;
• большой JavaScript task;
• layout;
• render;
• поздняя отрисовка основного контента.

Insights

Soft navigation теперь учитывается и при автоматическом анализе trace через Insights.

То есть performance investigation больше не заканчивается на первой загрузке документа: DevTools способен анализировать последующие пользовательские навигации внутри SPA.

Практический trace: где искать проблему

Представим SPA-каталог.

Первая страница открывается быстро.

Пользователь нажимает карточку категории.

URL меняется:

/catalog/

на:

/catalog/notebooks/

но полного reload нет.

В Performance trace видна цепочка:

Click
→
router handler
→
fetch
→
JavaScript
→
DOM
→
layout
→
paint
→
LCP

Если новый LCP поздний, само число ещё не говорит о причине.

Например, fetch может закончиться быстро, но после него приложение 900 мс обрабатывает большой JSON и строит тысячи DOM-узлов.

Или JavaScript лёгкий, но основной hero/image для нового экрана запрашивается слишком поздно.

Или данные уже находятся в памяти, но тяжёлая синхронная работа блокирует main thread сразу после клика.

Именно поэтому DevTools нужен не только для получения новой метрики, а для разложения пользовательской задержки на реальные этапы.

Похожий принцип действует и при обычной диагностике медленного сайта: общий PageSpeed score редко объясняет корень проблемы. На Vagizov.com это подробнее разобрано в материале «Медленный сайт: 15 частых причин и что делать».

INP после перехода тоже имеет значение

Soft Navigation нельзя сводить только к LCP.

Представим переход:

клик пользователя обрабатывается быстро, новый экран появляется через 400 мс, но сразу после этого приложение на несколько секунд занимает main thread.

Первый визуальный результат выглядит приемлемо.

Следующее взаимодействие пользователя уже тормозит.

Поэтому после client-side перехода нужно смотреть как минимум:

• исходное взаимодействие;
• новые long tasks;
• LCP нового экрана;
• INP последующих взаимодействий;
• layout shifts внутри нового состояния.

Soft Navigation API предоставляет стандартизированную границу, относительно которой INP и CLS можно начинать считать как для нового пользовательского представления. Chrome рекомендует при начале новой soft navigation сбрасывать соответствующие метрики и рассматривать новый сегмент отдельно.

Что происходит с FCP, LCP, INP и CLS

Модель немного отличается от обычной загрузки.

TTFB для soft navigation не имеет обычного смысла новой HTML-навигации, поскольку новый документ не запрашивается.

FCP определяется относительно нового soft navigation через paint timing соответствующего перехода.

LCP строится на новых contentful paints, связанных с interaction, инициировавшим navigation.

INP можно измерять внутри временной области нового перехода.

CLS также сегментируется относительно новой навигации.

Важно и другое: новый LCP может быть совсем не тем элементом, который был бы LCP при холодной загрузке URL.

Например, общий большой banner остаётся на странице между переходами.

При hard load именно он может стать LCP.

Но при soft navigation banner не перерисовывается, а меняется большой заголовок и список карточек.

Тогда LCP soft navigation будет определяться уже новым контентом. Chrome прямо описывает такую разницу между cold load и soft load как ожидаемое поведение.

А что с реальными пользовательскими данными

Здесь особенно важно не сделать преждевременный вывод.

Soft Navigations API уже включён по умолчанию в Chrome начиная с версии 151. Его можно обнаружить через:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
    // Soft Navigation API поддерживается
}

и слушать события:

const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
        console.log(entry);
    }
});

observer.observe({
    type: 'soft-navigation',
    buffered: true
});

Chrome рекомендует использовать PerformanceObserver, особенно для долгоживущих SPA, потому что обычный buffered lookup имеет ограничения на количество сохранённых записей.

Это открывает путь к RUM:

реальный пользователь
→
soft-navigation
→
navigationId / interactionId
→
LCP / INP / CLS
→
конкретный виртуальный URL

Но есть два ограничения.

Во-первых, API пока не является кроссбраузерным решением. Пользователи старых Chrome и других браузеров могут не отдавать аналогичные данные. Chrome рекомендует учитывать это при анализе и уточнять поддержку у RUM-провайдера.

Во-вторых, Google пока не определил окончательно, как soft navigations будут представлены в CrUX. Цель состоит в использовании технологии для более точного Core Web Vitals measurement, но утверждать, что Search Console или CrUX уже сейчас автоматически считают каждый SPA-переход полноценной отдельной страницей, нельзя.

Поэтому разумная схема на переходный период:

обычные field metrics
+
отдельный RUM soft-navigation слой
+
DevTools laboratory diagnostics.

Не нужно смешивать их в один временной ряд без учёта браузерной поддержки.

Soft Navigation полезна не только для классического SPA

Хотя основная проблема исторически связана с SPA, архитектура сайта не обязана укладываться в ярлык React/Vue.

Современная MPA может использовать client-side navigation между отдельными URL.

Framework может выполнять partial navigation.

WordPress-проект может поверх обычных серверных страниц получить сложную AJAX-навигацию.

Важно не название технологии, а пользовательская модель:

человек совершает переход, URL и основной экран меняются, но browser document остаётся тем же.

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

Общую техническую проверку после подобных изменений полезно совмещать с обычным аудитом URL, рендеринга, Core Web Vitals и JavaScript. На Vagizov.com для этого есть отдельный чек-лист технического аудита сайта.

Что Soft Navigation не решает автоматически

Наличие поддержки в Chrome не делает SPA быстрым.

DevTools только лучше показывает реальное состояние.

Soft Navigation API не:

• уменьшает JavaScript bundle;
• ускоряет API;
• устраняет long tasks;
• оптимизирует изображения;
• исправляет hydration;
• уменьшает DOM;
• устраняет layout shifts;
• улучшает архитектуру router.

Она убирает важную слепую зону измерения.

Раньше разработчик мог проверить начальную страницу, увидеть хороший LCP и считать задачу законченной.

Теперь намного проще увидеть:

первая страница — 1,3 секунды, а переход в каталог после клика ощущается совершенно иначе.

И тогда оптимизация становится конкретной.

Что проверять после внедрения клиентской маршрутизации

Для реального проекта я бы разделял аудит на четыре уровня.

Первый — navigation detection.

Правильно ли Chrome считает пользовательские переходы soft navigations?

Второй — loading experience.

Как быстро после interaction появляется основной новый контент?

Третий — runtime performance.

Не блокируют ли router, JavaScript и rendering следующие действия?

Четвёртый — field data.

Повторяется ли проблема у реальных пользователей на разных устройствах и соединениях?

Если изменить только первый уровень — например, добиться появления красивого marker в DevTools — сайт быстрее не станет.

Marker нужен, чтобы правильно поставить границу измерения.

Почему это особенно важно для Core Web Vitals SPA

Идея Core Web Vitals всегда заключалась в измерении того, что воспринимает человек, а не только технического события load.

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

Soft Navigation API приближает измерение к реальному пользовательскому пути:

перешёл
→
дождался нового главного контента
→
взаимодействовал
→
перешёл дальше.

Каждый такой сегмент теперь можно анализировать значительно точнее.

Но на 4 октября 2026 года важно разделять уже готовые возможности и следующие этапы.

Уже работает: распознавание soft navigations в Chrome, Performance API, Live Metrics, trace markers и Insights в DevTools.

Ещё развивается: стандартизация между браузерами и окончательная модель включения таких данных в CrUX.

Поэтому практический вывод для разработчика простой:

перестаньте тестировать производительность SPA только при F5.

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

И смотрите не только на то, сколько времени занял первый HTML, а на весь путь:

interaction → router → data → JavaScript → rendering → новый LCP → дальнейший INP.

Именно там у динамического сайта часто находится производительность, которую действительно чувствует пользователь.