Измерение эффективности мягкой навигации

Барри Поллард
Михал Мокны

Опубликовано: 1 февраля 2023 г., Последнее обновление: 24 июня 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 для повышения производительности, которые помогут решить эту проблему, начиная с Chrome 151.

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

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

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

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

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

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

Мягкий навигационный маркер на панели «Производительность» с трассировкой с сайта youtube.com.

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

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

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

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

  • Событие PerformanceTiming soft-navigation будет генерироваться после обнаружения каждой мягкой навигации.
  • Эта запись soft-navigation будет включать navigationId , новый URL-адрес в атрибуте name , а также interactionId инициирующего взаимодействия.
  • После взаимодействий, вызывающих отображение контента, будет сгенерировано одно или несколько сообщений interaction-contentful-paint . В них будет содержаться запись largestContentfulPaint , которая может использоваться для измерения 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 будет реализована функция getLargestInteractionContentfulPaint() которая будет получать самую большую запись interaction-contentful-paint для данного взаимодействия. Эта запись может использоваться в качестве начальной таблицы действий для данного взаимодействия, и её можно будет обновлять по мере появления новых записей interaction-contentful-paint для этого взаимодействия. Обратите внимание, что это заменяет атрибут largestInteractionContentfulPaint доступный в предыдущих версиях.
  • Возможно, некоторые записи interaction-contentful-paint произошли до выполнения мягкой навигации (если обновление URL-адреса происходит только после этих отрисовок). В таких случаях функция getLargestInteractionContentfulPaint() позволяет избежать необходимости буферизации и просмотра старых записей после завершения мягкой навигации. Обратите внимание, что запись, возвращаемая функцией getLargestInteractionContentfulPaint() является точной копией самой крупной записи interaction-contentful-paint на момент ее генерации, поэтому эта запись могла использовать предыдущий navigationId поскольку отрисовка произошла именно тогда, но эти отрисовки следует сравнивать с новым navigationId .
  • В поле soft-navigation также будут указаны paintTime и presentationTime в качестве FCP для этой навигации.
  • Обратите внимание, что записи interaction-contentful-paint будут также генерироваться после дальнейших взаимодействий, но LCP для URL-адреса следует ограничивать записями interaction-contentful-paint , которые соответствуют interactionId мягкой навигации, чтобы исключить их, а также только свойствами largestContentfulPaint внутри них.

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

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

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

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

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

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

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

Функция плавной навигации предназначена для включения по умолчанию в Chrome версии 151, но для тестирования её можно явно включить, предварительно активировав эту функцию.

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

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

Поддержка 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-адрес может посещаться несколько раз в течение всего времени существования приложения на одной странице).

Этот параметр следует устанавливать для каждой записи soft-navigation и использовать для отправки метрик до получения следующей записи soft-navigation .

Укажите правильный 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.

Кроме того, следует рассмотреть возможность обработки функции getLargestInteractionContentfulPaint() элементов 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 может быть инициализирован значением из getLargestInteractionContentfulPaint() . Значения INP и CLS следует инициализировать значением 0, как это было бы при загрузке страницы.

Затем показатели LCP, INP и CLS можно измерять и отслеживать как обычно (за исключением использования interaction-contentful-paint для LCP при условии совпадения interactionId ). interactionId можно использовать для именования записей в 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) с помощью обеих методик?

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

В контексте 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 предоставляет следующие метрики для плавной навигации:

Метрика Подробности
TTFB Сообщено как 0.
ФКП Время первого отображения контента относительно времени начала мягкой навигации, с момента взаимодействия, которое запустило мягкую навигацию. Существующие отображения, оставшиеся от предыдущей навигации или не связанные с взаимодействием, не учитываются.
ЛКП Время наибольшего отображения контента относительно времени начала мягкой навигации, исходя из взаимодействия, которое инициировало мягкую навигацию. Существующие отображения контента из предыдущей навигации, не связанные с взаимодействием, не учитываются. Как обычно, это может продолжать обновляться до тех пор, пока страница (или мягкая навигация) не будет закрыта, поскольку только тогда LCP может быть окончательно сформирован.
CLS Наибольший интервал изменений между моментами навигации. Как обычно, это может продолжаться до тех пор, пока страница (или программная навигация) не будет закрыта, поскольку только тогда можно завершить формирование CLS.
ИНП INP (Interval Counselive Proof) — время между моментами навигации. Как обычно, это значение может обновляться до тех пор, пока страница (или программная навигация) не будет закрыта, поскольку только тогда INP может быть окончательно сформирован. Значение 0 не отображается, если нет взаимодействий.

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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