Опубликовано: 31 июля 2025 г.
Chrome запускает новый пробный период использования API Soft Navigations, начиная с версии Chrome 139. Этот пробный период позволяет сайтам протестировать API на своих ресурсах с реальными пользователями, чтобы предоставить команде Chrome обратную связь.
Что такое мягкая навигация?
Мягкая навигация — это когда JavaScript перехватывает навигацию (например, клик по ссылке) и обновляет содержимое существующей страницы, а не загружает новую страницу с последующим обновлением URL-адреса в адресной строке (с сохранением истории для возможности мягкой навигации вперед и назад). Для пользователя это выглядит так же, как и обычная навигация, но с точки зрения браузера страница остается исходной.
Зачем нужен API мягкой навигации?
API для мягкой навигации — это предлагаемый API, позволяющий эвристически определять так называемые «мягкие навигации», используемые на сайтах с одностраничными приложениями (SPA). Поскольку при мягкой навигации фактическая навигация по страницам не происходит, это означает, что некоторые действия, которые обычно выполняются при навигации, должны управляться вручную с помощью JavaScript. Некоторые действия, такие как управление историей навигации, возможны с помощью существующих API. Однако другие действия, такие как измерение Core Web Vitals , для этих навигаций невозможны.
API мягкой навигации позволяет отслеживать мягкие переходы. Хотя JavaScript-код, инициирующий мягкую навигацию (обычно это JavaScript-фреймворк), знает о моменте перехода, другие JavaScript-коды и сам браузер об этом не знают.
Основные параметры веб-разработки и SPA
Одна из главных целей создания API Soft Navigation — обеспечить возможность измерения основных параметров веб-приложения (Core Web Vitals) для одностраничных приложений (SPA). Эти параметры измеряются как самим браузером (для отображения в таких инструментах, как отчет Chrome о пользовательском опыте ), так и библиотеками JavaScript для мониторинга реальных пользователей (RUM).
Фреймворки JavaScript могут измерять некоторые аспекты основных параметров веб-разработки. В частности, показатели Interaction to Next Paint (INP) и Cumulative Layout Shift (CLS) основаны на примитивах ( API Event Timing и API Layout Instability соответственно), которые можно измерять в течение любого временного промежутка для расчета метрик INP и CLS. Однако, поскольку браузер сообщает и завершает расчет Largest Contentful Paint (LCP) на основе навигации по страницам и взаимодействий, фреймворки JavaScript не имеют доступа ни к чему, кроме производительности первоначальной загрузки для одностраничных приложений (SPA).
Как API мягкой навигации позволяет измерять основные показатели веб-технологий для одностраничных приложений (SPA).
В первой версии API мягкой навигации эвристические алгоритмы мягкой навигации были объединены со сбросом LCP. После сброса LCP может быть повторно сгенерирован для мягкой навигации при новой отрисовке контента, что позволяет измерять этот показатель для мягкой навигации.
В этой последней версии используется другой подход, который разделяет эти концепции на API мягкой навигации и новый параметр производительности «Взаимодействие — отрисовка контента». Параметр interaction-contentful-paint измеряет «отрисовку контента» после взаимодействий. На данный момент это значение генерируется только для мягкой навигации, но включение этой функции для всех взаимодействий открывает другие потенциальные возможности использования, помимо LCP.
API также расширил каждую из записей производительности largest-contentful-paint , interaction-contentful-paint , event-timing и layout-shift включив в нее идентификатор навигации, к которой относится запись. Записи производительности генерируются после события, которое они измеряют, — обычно во время простоя. Это означает, что URL-адрес часто уже изменится к моменту генерации записи производительности. Включение навигации в запись значительно упрощает измерение Core Web Vitals для данного URL-адреса без необходимости сопоставлять время генерации записей производительности со временем генерации записей мягкой навигации.
Почему именно эвристический метод?
API мягкой навигации считает навигацию мягкой, если происходит следующее:
- Происходит взаимодействие с пользователем (обновления URL-адресов без взаимодействия с пользователем не учитываются).
- … что приводит к изменению DOM-структуры и отрисовке.
- …и происходит обновление URL-адреса
- Обновление URL-адреса, включая изменение истории.
API использует эвристический подход, а не позволяет JavaScript-фреймворку «генерировать» мягкую навигацию или строить на основе Navigation API, поскольку это обеспечивает согласованное понимание того, что представляет собой мягкая навигация, независимо от фреймворка или способа его использования разработчиком.
Разработчики или фреймворки могут обновлять URL-адрес для плавной навигации даже без взаимодействия с пользователем или обновления DOM, которое мы считаем навигацией для пользователя. Они также могут обновлять URL-адрес в разное время — в начале взаимодействия или только в конце, когда оно завершено, — или на любом промежуточном этапе.
Вместо того чтобы полагаться на выбор фреймворков, встраивание функции обнаружения плавной навигации в браузер устанавливает канонические «эвристики» (с учетом ваших отзывов, полученных в ходе этого первоначального тестирования), которые позволят нам измерять показатели Core Web Vitals для плавной навигации в больших масштабах и делать такие измерения сопоставимыми в больших масштабах.
Разработчики и фреймворки также могут игнорировать эвристические алгоритмы API Soft Navigations и использовать базовые API Event Timing, Layout Instability и Interaction to Contentful Paint для измерения дополнительных показателей производительности по своему усмотрению, но мы рекомендуем использовать эвристические алгоритмы в Core Web Vitals для измерения производительности на разных сайтах.
Требуется помощь в тестировании API программной навигации.
Нам нужна помощь в тестировании API мягкой навигации, чтобы проверить, соответствует ли эвристический алгоритм вашим ожиданиям относительно того, когда произошла мягкая навигация. Бывают ли случаи, когда API не сообщает о мягких навигациях, когда вы считаете, что они произошли? И наоборот, повторяет ли API слишком часто навигации, которые вы не считаете мягкими навигациями?
Примеры проблем, которые мы наблюдали, включают в себя ситуации, когда URL-адрес обновляется с помощью replaceState вместо добавления истории, или когда происходит навигация, не инициированная пользователем (например, выход из системы по истечении времени ожидания). Оба случая объясняются несоответствием эвристическим алгоритмам, и команда Chrome считает допустимым не включать их в описание, но мы хотели бы услышать мнение веб-разработчиков, согласны ли они с этим. В частности, нас интересуют случаи, когда эвристические алгоритмы, по-видимому, выполняются, но API всё ещё не распознаёт мягкую навигацию.
Кроме того, мы хотим понять, решает ли этот API и новый примитив «Взаимодействие с Contentful Paint» основную задачу — измерение основных веб-показателей для одностраничных приложений (SPA).
Мы хотим, чтобы API был максимально полезным, и этого гораздо проще добиться до его запуска и начала зависимости сайтов от его реализации. Поэтому мы просим разработчиков SPA-приложений и тех, кто заинтересован в измерении производительности веб-сайтов, протестировать этот API и сообщить нам о своих впечатлениях.
Как проводить тестирование
API можно протестировать локально с помощью флагов Chrome или параметров командной строки . Кроме того, его можно протестировать в полевых условиях с помощью пробной версии Origin .
Для получения более подробной технической информации об API, и в частности о том, как измерять показатели Core Web Vitals , обратитесь к нашей документации или репозиторию GitHub. Кроме того, доступна экспериментальная версия библиотеки web-vitals с мягкой навигацией .
Обратная связь
Мы активно собираем отзывы об этом эксперименте в следующих местах:
- Отзывы об API следует оставлять в виде запросов на GitHub .
- Если эта проблема еще не известна , о ней следует сообщать в систему отслеживания ошибок Chrome в Chromium.
- Общую обратную связь по показателям работы веб-сайта можно отправлять по адресу web-vitals-feedback@googlegroups.com .
Если у вас возникнут сомнения, не стоит слишком беспокоиться, мы предпочтем получить обратную связь в любом из двух мест и с удовольствием рассмотрим проблемы в обоих местах и перенаправим их в нужное место.