Если ты последние несколько лет проектировал сложные интерфейсы на React, Next.js, Vue или Svelte, у тебя наверняка хотя бы раз опускались руки при взгляде на отчеты Core Web Vitals в Google Search Console. Ты мог часами вылизывать производительность, оптимизировать бандлы и настраивать кэширование, но поисковая панель упрямо вешала на твои Single-Page Applications (SPA) желтые и красные плашки за просевшие задержки взаимодействия (INP) или сползающую верстку (CLS).
Самое обидное заключалось в том, что в реальной жизни интерфейс летал: пользователь кликал по вкладкам каталога, мгновенно открывал карточки товаров через клиентский роутер, не дожидаясь перезагрузки страницы, и был абсолютно счастлив. Но браузерный отчет Chrome User Experience Report (CrUX), на данных которого Google строит сигналы поискового ранжирования, упорно судил приложение по законам эпохи Web 1.0.
Наконец-то в этой многолетней драме наметился долгожданный перелом. Команда веб-платформы Google Chrome во главе с Энни Салливан официально выкатила в CrUX экспериментальный сбор метрик с полноценным учетом так называемых «мягких навигаций» (Soft Navigations). Давай разберем эту механику по винтикам: почему SPA годами находились под штрафными санкциями, как браузер научился распознавать переходы без перезагрузки и что эти изменения сулят фронтенд-разработчикам.
Архитектурный перекос: почему классический CrUX наказывал одностраничники
Чтобы понять масштаб проблемы, нужно вспомнить, как исторически собирались Core Web Vitals. Вся модель телеметрии CrUX строилась вокруг концепции жесткой навигации (Hard Navigation). Это классический сценарий многостраничных сайтов (MPA): пользователь кликает по ссылке, браузер отправляет новый HTTP-запрос на сервер, получает свежий HTML-документ, заново парсит стили, строит DOM-дерево и производит первичную отрисовку.
Каждая такая загрузка считалась отдельным изолированным просмотром страницы (Page View), для которого браузер аккуратно замерял три заветных показателя:
- Largest Contentful Paint (LCP) — время до появления самого крупного видимого контентного блока;
- Interaction to Next Paint (INP) — задержка реакции интерфейса на клики и нажатия клавиш;
- Cumulative Layout Shift (CLS) — суммарный сдвиг элементов верстки при загрузке.
Но в Single-Page Applications жизнь устроена принципиально иначе. После первой загрузки базовой оболочки переход между страницами происходит целиком на клиенте: роутер перехватывает клик, меняет URL в адресной строке через History API (pushState или replaceState), подгружает небольшую JSON-порцию данных и монтирует новые компоненты прямо в существующее дерево документа. Браузер не перезагружает вкладку.
И вот здесь старый CrUX совершал фатальную логическую ошибку: он продолжал считать всю 20-минутную пользовательскую сессию одним-единственным просмотром страницы! Из этого вытекали чудовищные искажения:
- Задержки взаимодействия (INP) накапливались со всей сессии. Если пользователь открыл 50 товаров в каталоге, и на 49-м товаре сложный селект задумался на 250 мс, этот худший клик пришивался к первичному посадочному экрану.
- Сдвиги верстки (CLS) суммировались снежным комом. Каждый переход в корзину или открытие шторки фильтров добавляли крошечные сдвиги в общую копилку, превращая зеленую зону в безнадежно красную.
- Самое главное — LCP последующих экранов полностью игнорировался. Скорость открытия второй, третьей и десятой страниц внутри SPA вообще не существовала для Core Web Vitals: фиксировалась только первая, самая тяжелая холодная загрузка приложения со всеми скриптами и стилями.
Многие команды из-за этого были вынуждены бросать привычный клиентский рендеринг и спешно переписывать архитектуру на Server-Side Rendering (SSR) или чистый MPA только ради того, чтобы ублажить роботов Google Search Console.
Эвристика Soft Navigations: как Chrome научился видеть переходы
Чтобы исправить эту несправедливость, инженерам Chrome потребовалось разработать формальный платформенный стандарт. В Chrome 151 стабилизировался Soft Navigations Web Platform API, который научил браузерный движок автоматически детектировать смену экрана.
Но как отличить реальный переход пользователя в новый раздел от простого открытия модального окна, переключения вкладки в табах или смены темы оформления? Для этого рабочая группа W3C сформулировала строгую цепочку эвристик. Переход признается мягкой навигацией только тогда, когда строго соблюдаются три условия:
- Инициатором выступает прямое действие пользователя: клик мышью, тап по тачскрину или нажатие клавиши на клавиатуре.
- В процессе обработки этого действия происходит изменение URL в адресной строке через методы
history.pushState(),history.replaceState()или нативный Navigation API. - В структуре DOM-дерева происходят значимые изменения: старый содержательный узел удаляется, а вместо него монтируется новый контентный блок с реальным текстом или графикой.
Как только цепочка замкнулась, браузер объявляет границу новой навигации: счетчики CLS сбрасываются для нового экрана, окно ожидания LCP открывается заново, а задержки INP начинают замеряться в контексте конкретного нового маршрута.
В нашем разборе того, как практическое руководство по панели Performance в Chrome DevTools помогает разбирать Core Web Vitals, мы уже видели, как эти границы наглядно отображаются на шкале Interaction & Timings. Теперь эта же логика пришла в глобальную телеметрию миллионов пользователей.
Эксперимент в CrUX: цифры, которые меняют все
С октября 2026 года в отчете Chrome User Experience Report (CrUX) появились три новые экспериментальные метрики:
experimental_largest_contentful_paint_with_softnavsexperimental_interaction_to_next_paint_with_softnavsexperimental_cumulative_layout_shift_with_softnavs
По данным официальной публикации в блоге Chrome for Developers, первые замеры на реальном пользовательском трафике произвели эффект разорвавшейся бомбы.
Для веб-сайтов с высокой долей мягких навигаций (где на клиенте происходит более 75% всех переходов) доля сайтов с хорошим («Good») показателем LCP на мобильных устройствах под управлением Android подскочила с 26% до потрясающих 87%! Вдумайся в эту разницу: почти три четверти мобильных SPA-сайтов годами считались поисковиком «медленными» исключительно из-за того, что измерительный инструмент игнорировал скорость их реальной работы. Ведь при повторных переходах в SPA браузеру больше не нужно загружать и парсить заново тяжелый общий CSS, шрифты и ядро JavaScript-фреймворка — они уже прогреты в оперативной памяти, и новый экран рендерится за доли секунды.
Не менее впечатляющие подвижки произошли и в метриках отзывчивости. Поскольку длинные пользовательские сессии перестали накапливать штрафы за все клики подряд, процент сайтов, успешно укладывающихся в зеленый норматив INP, практически удвоился. А разбивка по целевым URL в CrUX API наконец-то позволила разработчикам локализовать тормоза: если раньше Search Console ругалась на главную страницу, то теперь в отчете четко видно, что спайк задержки вызван конкретным тяжелым компонентом корзины по адресу /checkout.
Инструменты доступа и дорожная карта до мая 2027 года
Как фронтенд-инженер может пощупать эти метрики прямо сейчас? В распоряжении разработчиков появилось сразу несколько каналов:
- CrUX API: экспериментальные поля уже отдаются в стандартных ответах API по запросу конкретного домена или URL.
- Публичный датасет Google BigQuery: таблица
chrome-ux-report.experimental.soft_navigationsпозволяет строить когортные срезы и сравнивать свои показатели с прямыми конкурентами по отрасли. - Инструмент визуализации CrUX Vis: на портале
cruxvis.withgoogle.comпоявился удобный переключатель, позволяющий в один клик увидеть разрыв между текущей официальной оценкой и реальной картиной с учетом soft navigations. - Библиотека
web-vitals: актуальная версия 4.x поддерживает атрибуцию мягких навигаций, позволяя отправлять эти события в собственные аналитические платформы (Google Analytics 4, Sentry, Datadog).
В материале о том, какие новинки Chrome 156 и веб-стандартов меняют фронтенд-платформу, мы обсуждали тренд на сближение браузерных примитивов и фреймворков. Soft Navigations — ярчайший пример этого движения.
Однако важно сохранять холодную голову: сейчас эти метрики носят статус экспериментальных. По официальному графику команды Chrome, экспериментальный период продлится до мая 2027 года. До этого момента Google Search Console и базовые алгоритмы поискового ранжирования продолжат использовать старую формулу без мягких навигаций.
Но у тебя и твоей команды появляется полуторагодовой запас времени, чтобы спокойно провести аудит своих веб-приложений, проверить корректность работы History API и встретить май 2027 года с безупречными зелеными показателями.