Экспериментируем с измерением мягкой навигации

Barry Pollard

Michal Mocny

Опубликовано: 1 февраля 2023 г., Последнее обновление: 30 марта 2026 г.

С момента своего запуска инициатива Core Web Vitals стремилась измерить реальный пользовательский опыт работы с веб-сайтом, а не технические детали его создания или загрузки. Три показателя Core Web Vitals были созданы как ориентированные на пользователя метрики — эволюция по сравнению с существующими техническими метриками, такими как DOMContentLoaded или load , которые измеряли время загрузки, часто не связанное с тем, как пользователи воспринимали производительность страницы. Поэтому технология, используемая для создания сайта, не должна влиять на оценку, если сайт работает хорошо.

Реальность всегда немного сложнее идеала, и популярная архитектура одностраничных приложений (Single Page Application , SAP) никогда не получала полной поддержки от метрик Core Web Vitals . Вместо загрузки отдельных веб-страниц по мере перемещения пользователя по сайту, эти веб-приложения используют так называемую «мягкую навигацию», при которой содержимое страницы изменяется с помощью JavaScript. В таких приложениях иллюзия традиционной архитектуры веб-страницы поддерживается путем изменения URL-адреса и добавления предыдущих URL-адресов в историю браузера, чтобы кнопки «назад» и «вперед» работали так, как ожидает пользователь.

Многие JavaScript-фреймворки используют эту модель, но каждый по-своему. Поскольку это выходит за рамки того, что браузер традиционно понимает как «страницу», измерение этого всегда было сложной задачей: где проходит граница между взаимодействием на текущей странице и рассмотрением её как новой страницы?

Команда Chrome уже некоторое время рассматривает эту задачу и стремится стандартизировать определение того, что такое «мягкая навигация», и как можно измерять основные показатели веб-безопасности (Core Web Vitals) для этого — аналогично тому, как измеряются веб-сайты, реализованные в традиционной многостраничной архитектуре (MPA).

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

Что такое мягкая навигация?

Мы пришли к следующему определению мягкой навигации :

• Навигация инициируется действием пользователя.
• В результате перехода по ссылке пользователь увидит видимое изменение URL-адреса.
• В результате взаимодействия образуется видимый слой краски.

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

Поддержка программной навигации в инструментах разработчика

В панели «Производительность » инструментов разработчика в режиме трассировки добавлена ​​поддержка плавной навигации:

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

На данный момент в режиме трассировки отображаются только временные метки мягкой навигации и LCP. Другие метрики (например, LCP) и поддержка в режиме просмотра метрик в реальном времени будут добавлены позже.

Как Chrome реализует удобную навигацию для веб-разработчиков?

После включения эвристических алгоритмов мягкой навигации (подробнее об этом в следующем разделе) Chrome изменит способ отображения некоторых показателей производительности:

• Событие PerformanceTiming soft-navigation будет генерироваться после обнаружения каждой мягкой навигации.
• Эта запись soft-navigation будет включать navigationId , новый URL-адрес в атрибуте name , а также interactionId инициирующего взаимодействия.
• После взаимодействий, вызывающих отображение содержимого, будет сгенерировано одно или несколько событий interaction-contentful-paint . Это можно использовать для измерения Largest Contentful Paint (LCP) для плавной навигации, когда взаимодействие генерирует плавную навигацию.
• Атрибут navigationId добавляется к каждому из показателей производительности ( first-paint , first-contentful-paint , largest-contentful-paint , interaction-contentful-paint , first-input-delay , event и layout-shift ). Он соответствует записи навигации, для которой было сгенерировано событие. Обратите внимание, что если эти записи охватывают несколько этапов мягкой навигации, они могут содержать previous или next navigationId в зависимости от того, когда была сгенерирована запись. Подробнее об этом см. в разделе «Отчет о метриках по соответствующему URL» .
• soft-navigation будет включать в себя запись largestInteractionContentfulPaint содержащую самую большую запись interaction-contentful-paint сгенерированную в рамках навигации. Затем это можно использовать в качестве начального значения LCP для данной навигации, и это значение LCP может обновляться по мере обнаружения новых записей interaction-contentful-paint для данного взаимодействия.
• Возможно, некоторые записи interaction-contentful-paint произошли до выполнения мягкой навигации (если обновление URL-адреса происходит только после этих отрисовок). В таких случаях наибольшая запись largestInteractionContentfulPaint позволяет избежать необходимости буферизации и просмотра старых записей. Обратите внимание, что largestInteractionContentfulPaint является точной копией наибольшей записи interaction-contentful-paint , поэтому эта запись будет использовать предыдущий navigationId поскольку именно тогда произошла отрисовка, но эти отрисовки следует сравнивать с новым navigationId .
• В поле soft-navigation также будут указаны paintTime и presentationTime в качестве FCP для этой навигации.
• Обратите внимание, что записи interaction-contentful-paint будут также генерироваться после дальнейших взаимодействий, но LCP для URL-адреса следует ограничивать записями interaction-contentful-paint , которые соответствуют interactionId мягкой навигации, чтобы исключить их.

Эти изменения позволят измерять основные показатели веб-доступа (Core Web Vitals) — и некоторые связанные с ними диагностические метрики — для каждой страницы навигации, хотя есть некоторые нюансы, которые необходимо учитывать.

Какие последствия влечет за собой включение плавной навигации в Chrome?

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

• Мониторинг элементов soft-navigation позволяет «разделить» элементы, отражающие производительность, на каждый «участок навигации».
• Показатели CLS и INP уже можно сегментировать по вашему усмотрению, а не измерять на протяжении всего жизненного цикла страницы, но API Soft Navigation предоставляет стандартизированный способ измерения момента, когда это происходит, независимо от используемой базовой технологии.
• largest-contentful-paint , завершается при взаимодействии (что необходимо для запуска мягкой навигации), поэтому его можно использовать только для измерения LCP при начальной «жесткой» навигации. Это означает, что это не изменится при измерении мягкой навигации, поэтому LCP для начальной загрузки страницы при жесткой навигации можно измерять так же, как и всегда.
• Новый параметр interaction-contentful-paint , который будет генерироваться при взаимодействии, можно использовать для измерения LCP (Limited Point Class — стоимость литра) для мягкой навигации, но есть некоторые нюансы в использовании этого параметра, которые мы обсудим в этой статье.
• Обратите внимание, что не все пользователи будут поддерживать этот API для плавной навигации, особенно в старых версиях Chrome и для тех, кто использует другие браузеры. Имейте в виду, что некоторые пользователи могут не сообщать метрики, основанные на плавной навигации, даже если они сообщают метрики Core Web Vitals.
• Поскольку это экспериментальная новая функция, которая не включена по умолчанию, сайтам следует протестировать её на предмет непредвиденных побочных эффектов.

Уточните у своего поставщика RUM, поддерживают ли они измерение основных показателей веб-доступа (Core Web Vitals) с помощью мягкой навигации. Многие планируют протестировать этот новый стандарт и учтут предыдущие соображения. Тем временем некоторые поставщики также разрешают ограниченное измерение показателей производительности на основе собственных эвристических алгоритмов.

Для получения дополнительной информации о том, как измерять метрики для плавной навигации, см. раздел «Измерение основных показателей веб-доступа для каждой плавной навигации» .

Как включить мягкую навигацию в Chrome?

В Chrome по умолчанию не включена функция плавной навигации, но её можно попробовать, явно активировав эту функцию.

Разработчикам эту функцию можно включить, активировав соответствующий флаг по адресу chrome://flags/#soft-navigation-heuristics . В качестве альтернативы, её можно включить, используя аргументы командной строки --enable-features=SoftNavigationHeuristics при запуске Chrome. Включение флага chrome://flags/#enable-experimental-web-platform-features также активирует мягкую навигацию.

Для веб-сайта, желающего обеспечить доступ к этой функции для всех своих посетителей, будет запущена пробная версия Chrome 147, которую можно активировать, зарегистрировавшись в пробной версии и добавив мета-элемент с токеном пробной версии в заголовок HTML или HTTP. Более подробную информацию см. в статье «Начало работы с пробными версиями» .

Владельцы сайтов могут включить пробную версию Chrome для всех пользователей или только для части из них. Обратите внимание на описанные выше последствия, которые могут повлиять на отчетность по вашим метрикам, особенно если пробная версия включена для значительной части пользователей. Следует отметить, что CrUX продолжит сообщать метрики существующим образом независимо от этой настройки плавной навигации, поэтому эти последствия на него не влияют. Также следует отметить, что пробная версия Chrome ограничена включением экспериментальных функций максимум для 0,5% всех загрузок страниц Chrome в среднем за 14 дней, но это должно стать проблемой только для очень крупных сайтов.

Поддержка API программной навигации для определения особенностей местности

Для проверки поддержки API можно использовать следующий код:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

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

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

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

Как измерить эффективность программной навигации?

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

Сообщить о несложной навигации

Для отслеживания плавных переходов можно использовать PerformanceObserver . Ниже приведён пример кода, который выводит записи о плавных переходах в консоль, включая предыдущие плавные переходы на этой странице с использованием опции buffered :

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Это можно использовать для окончательной настройки метрик страницы за весь период её существования для предыдущей навигации.

Сообщите показатели по соответствующему URL-адресу.

При появлении плавной навигации необходимо завершить обработку данных Core Web Vitals предыдущей страницы, затем отобразить отчет для предыдущего URL-адреса и запустить новый мониторинг для нового URL-адреса.

Атрибут name соответствующей записи soft-navigation будет содержать новый URL-адрес для сбора метрик, а navigationId будет уникальной ссылкой на эту навигацию (поскольку один и тот же URL-адрес может посещаться несколько раз в течение жизненного цикла приложения на одной странице). Его можно получить с помощью API PerformanceEntry :

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

Укажите правильный URL-адрес для interaction-contentful-paint

При вычислении LCP на основе записей interaction-contentful-paint необходимо учитывать дополнительные факторы, поскольку не все записи interaction-contentful-paint должны сопоставляться с использованием navigationId и отображаться как LCP для данного URL:

• Первая проблема заключается в том, что записи interaction-contentful-paint могут быть сгенерированы до выполнения мягкой навигации, если отрисовка происходит до обновления URL-адреса. В таких случаях navigationId будет соответствовать старому URL-адресу. Если URL-адрес обновляется первым, то отрисовка завершит мягкую навигацию, и в этом случае запись soft-navigation будет сгенерирована первой, а interaction-contentful-paint будет содержать новый URL-адрес.
• Вторая проблема заключается в том, что записи interaction-contentful-paint будут продолжать генерироваться для более новых взаимодействий, поскольку область применения этого показателя производительности выходит за рамки простого LCP для мягкой навигации. Мы хотим учитывать только отрисовки для загрузки мягкой навигации для LCP, а не для последующих взаимодействий.

Следовательно, для сопоставления записей interaction-contentful-paint с soft-navigation-entries и получения правильного URL-адреса следует использовать interactionId , а не navigationId . Это позволит обработать любые записи со старыми navigationId , а также отфильтровать записи interaction-contentful-paint , которые не следует учитывать для LCP.

Кроме того, следует рассмотреть возможность обработки также largestInteractionContentfulPaint записи InteractionContentfulPaint в элементах soft-navigation , чтобы упростить обработку записей interaction-contentful-paint которые возникают до того, как будет сгенерирована soft-navigation entries .

Получение startTime программной навигации

Все показатели производительности, включая показатели плавной навигации, а также данные, используемые для расчета метрик Core Web Vitals, отображаются как время, отсчитываемое от времени начальной «жесткой» навигации по странице. Поэтому время начала плавной навигации следует вычесть из времени загрузки метрик плавной навигации (например, LCP), чтобы отобразить результаты относительно времени плавной навигации.

Время начала навигации можно получить аналогичным образом, сопоставив его с соответствующей записью soft-navigation и используя ее startTime .

Время startTime — это время первоначального взаимодействия (например, нажатия кнопки), инициировавшего мягкую навигацию. Это несколько отличается от «жесткой навигации», где «время начала» — это момент «фиксации» новой страницы в браузере и после выполнения части кода обработчика событий. Время начала мягкой навигации также включает в себя этот код обработчика событий, поскольку мы измеряем время от момента начала взаимодействия.

Измерение основных показателей веб-технологий (Core Web Vitals) для каждого элемента мягкой навигации.

Для измерения Core Web Vitals отслеживайте записи soft-navigation и сбрасывайте метрики при их получении. FCP может генерироваться на основе presentationTime , а LCP может быть инициализирован значением largestInteractionContentfulPaint . INP и CLS следует инициализировать значением 0, как и при загрузке страницы.

Затем показатели LCP, INP и CLS можно измерять и отслеживать как обычно (за исключением использования interaction-contentful-paint для LCP при условии совпадения interactionId ). interactionId и navigationId можно использовать для именования записей в URL-адресе, как обсуждалось ранее .

Время по-прежнему будет возвращаться относительно исходного времени начала «жесткой» навигации. Таким образом, чтобы рассчитать LCP, например, для мягкой навигации, вам нужно будет взять время interaction-contentful-paint и вычесть соответствующее время начала мягкой навигации, как было описано ранее, чтобы получить время относительно мягкой навигации.

Традиционно некоторые метрики измеряются на протяжении всего жизненного цикла страницы: например, LCP может изменяться до тех пор, пока не произойдет взаимодействие. CLS и INP могут обновляться до тех пор, пока страница не будет закрыта, независимо от каких-либо взаимодействий. Поэтому метрики предыдущей навигации должны быть окончательно определены при каждой новой мягкой навигации. Это означает, что первоначальные метрики «жесткой» навигации могут быть окончательно определены раньше, чем обычно, при измерении Core Web Vitals с помощью мягкой навигации.

Аналогично, при начале измерения метрик для новой мягкой навигации, эти долгосрочные метрики необходимо будет «сбросить» или «переинициализировать» и рассматривать как новые метрики, без памяти о значениях, установленных для предыдущих «страниц». То есть, понимание того, что такое «самая большая» отрисовка, взаимодействие со следующей отрисовкой или изменение макета, сбрасывается, чтобы позволить провести измерения заново с нуля.

Как следует обрабатывать контент, остающийся неизменным при переходе между навигационными меню?

LCP для мягких навигаций (рассчитываемый на основе interaction-contentful-paint ) будет измерять только новые перерисовки и только те, которые связаны с взаимодействием, вызвавшим навигацию. Это может привести к изменению LCP, например, при переходе от холодной загрузки этой мягкой навигации к её полной загрузке.

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

Аналогично, анимация может постоянно обновлять часть страницы — независимо от какой-либо плавной навигации. Любые новые отрисовки, вызванные этой фоновой анимацией, не будут учитываться для LCP при новой плавной навигации. Однако они могут быть учтены для LCP, если страница была перезагружена с этого URL.

Как показывают эти примеры, элемент LCP для мягкой навигации может отображаться по-разному в зависимости от способа загрузки страницы — аналогично тому, как загрузка страницы с якорной ссылкой, расположенной ниже по странице, может привести к отображению другого элемента LCP для жесткой навигации.

Как измерить TTFB?

Время до получения первого байта (TTFB) при обычной загрузке страницы представляет собой время, когда возвращаются первые байты исходного запроса.

Для плавной навигации это более сложный вопрос. Следует ли измерять первый запрос к новой странице? Что если весь контент уже существует в приложении и дополнительных запросов нет? Что если этот запрос сделан заранее с помощью предварительной выборки? Что если запрос не связан с плавной навигацией с точки зрения пользователя (например, это запрос аналитики)?

Более простой метод — сообщать значение TTFB, равное 0, для плавных переходов — аналогично тому, как мы рекомендуем это делать при восстановлении кэша при переключении между предыдущим и следующим шагом . Именно этот метод используется библиотекой web-vitals для плавных переходов, и именно его мы рекомендуем для этого показателя на данный момент.

Следует ли измерять основные показатели веб-безопасности (Core Web Vitals) с помощью обеих методик?

В ходе этого эксперимента рекомендуется продолжать измерять основные параметры веб-сервера текущим способом, основываясь на «жесткой» навигации по страницам, поскольку новая реализация может иметь проблемы или измениться до окончательного выпуска. Это также будет соответствовать тому, что сейчас измеряет CrUX (подробнее об этом позже).

Помимо этого, следует измерять и плавную навигацию, чтобы понять, как её можно будет измерять в будущем, а также предоставить команде Chrome обратную связь о том, как эта реализация работает на практике. Это поможет вам и команде Chrome в дальнейшем совершенствовать API.

В контексте LCP это означает рассмотрение только записей largest-contentful-paint для текущего способа, и записей largest-contentful-paint и записей interaction-contentful-paint для нового способа.

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

Используйте библиотеку web-vitals для измерения показателей Core Web Vitals для плавной навигации.

Простейший способ учесть все нюансы — использовать JavaScript-библиотеку web-vitals , которая имеет экспериментальную поддержку плавной навигации в отдельной soft-navs branch (также доступной в npm и unpkg ). Это можно измерить следующим образом (заменив doTraditionalProcessing и doSoftNavProcessing по мере необходимости):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

Библиотека web-vitals также гарантирует, что метрики будут передаваться по правильному URL-адресу, как отмечалось ранее , поскольку она включает в себя как navigationId , так и navigationURL в записях, предоставляемых в функцию обратного вызова.

Библиотека web-vitals предоставляет следующие метрики для плавной навигации:

Будут ли эти изменения включены в показатели Core Web Vitals?

Мы хотим оценить эвристические методы и посмотреть, насколько точно они отражают пользовательский опыт, прежде чем принимать решение об их интеграции в инициативу Core Web Vitals. Конечная цель — предоставить средства для более точного измерения производительности на основе опыта реальных пользователей. Поэтому, да, цель состоит в том, чтобы включить эти данные в измерения Core Web Vitals, которые будут доступны во всех инструментах, если этот эксперимент окажется успешным.

Мы ценим отзывы веб-разработчиков об эксперименте, используемых эвристических методах и о том, насколько точно он отражает реальный пользовательский опыт. Лучшее место для таких отзывов — репозиторий GitHub с мягкой навигацией , хотя отдельные ошибки в реализации этой функции в Chrome следует сообщать в системе отслеживания ошибок Chrome .

Как будут отображаться данные о плавной навигации в CrUX?

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

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

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

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

Обратная связь

Мы активно собираем отзывы об этом эксперименте в следующих местах:

• Отзывы об API следует оставлять в виде запросов на GitHub .
• Если эта проблема еще не известна , о ней следует сообщать в систему отслеживания ошибок Chrome .
• Общую обратную связь по показателям работы веб-сайта можно отправлять по адресу web-vitals-feedback@googlegroups.com .

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

Список изменений

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

Заключение

Эксперимент с мягкой навигацией — это захватывающий подход к тому, как инициатива Core Web Vitals может развиваться для измерения распространенного шаблона в современном интернете, который отсутствует в наших метриках. Хотя этот эксперимент находится еще на ранней стадии — и многое еще предстоит сделать — предоставление результатов его проведения более широкому веб-сообществу для экспериментирования является важным шагом. Сбор отзывов в рамках этого эксперимента — еще одна важная его часть, поэтому мы настоятельно рекомендуем всем заинтересованным лицам использовать эту возможность, чтобы помочь сформировать API и убедиться, что он отражает то, что мы надеемся измерить с его помощью.

Благодарности

Миниатюрное изображение предоставлено Джорданом Мадридом на Unsplash.

Эта работа является продолжением работы, начатой ​​Йоавом Вайсом, когда он работал в Google. Мы благодарим Йоава за его усилия по созданию этого API.