В CrUX появились экспериментальные Core Web Vitals для переходов внутри SPA

В CrUX появились экспериментальные LCP, INP и CLS, учитывающие переходы внутри одностраничных приложений. Владельцы сайтов могут сравнить оценки со стабильными метриками в CrUX Vis.

· 4 мин чтения · 5 комментариев

Chrome добавил в Chrome User Experience Report (CrUX) экспериментальные версии всех трёх Core Web Vitals, которые учитывают переходы внутри одностраничных приложений без полной перезагрузки. Как пишет Search Engine Journal, данные доступны с выпуска CrUX от 13 октября в BigQuery, CrUX API и History API. Если ваш сайт использует такие переходы, уже можно сравнить стабильные и экспериментальные показатели в CrUX Vis. Стабильные оценки пока не изменились.

Как CrUX учитывает переходы внутри приложения

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

Теперь экспериментальные версии LCP, INP и CLS охватывают и полные загрузки, и обнаруженные «мягкие» переходы. Chrome распознаёт такой переход, если после действия пользователя меняется видимый URL и на экране появляется обновлённое содержимое. Метрики этого просмотра относятся к URL назначения — при соблюдении обычных условий включения данных в CrUX.

Для обнаружения переходов используется Soft Navigations API. Он включён по умолчанию с Chrome 151, выпущенного 28 июля. Новые показатели существуют рядом со стабильными, а не вместо них: в CrUX Vis появился переключатель Include soft navigations, позволяющий сравнить оба варианта.

Где оценки могут заметно разойтись

Для большинства ресурсов разница, вероятно, будет небольшой. В зависимости от платформы у 66–75% источников данных (origins) в CrUX — единиц, по которым в отчёте сгруппированы просмотры, — доля «мягких» переходов составляет менее 5%. Более половины просмотров приходится на такие переходы у 7,0% origins на Android и 10,6% на компьютерах. Среди тысячи крупнейших ресурсов эти доли выше: 35% на Android и 42% на компьютерах.

Когда большая часть просмотров приходится на переходы без перезагрузки, экспериментальные оценки всех трёх метрик улучшаются. Среди origins на Android с долей таких переходов от 75% до 100% хорошую оценку LCP получают 26% по стабильной метрике и 87% по экспериментальной. Это не значит, что одностраничные приложения в целом быстрее сайтов, где каждая страница загружается заново. По объяснению Chrome, последующие переходы обычно быстрее первого открытия независимо от устройства сайта.

Для INP меняется распределение взаимодействий: отклик оценивается в пределах отдельного просмотра, а не по самому медленному взаимодействию за весь сеанс. Среди origins на Android, которые преимущественно используют «мягкие» переходы, доля проходящих порог INP примерно удваивается. При этом они по-прежнему отстают от ресурсов с полной загрузкой страниц: интенсивная работа JavaScript при смене содержимого может влиять на отзывчивость.

Сдвиги макета в экспериментальном CLS тоже распределяются по просмотрам, а не собираются за весь сеанс. На компьютерах это ставит ресурсы с большой долей «мягких» переходов примерно на один уровень с многостраничными сайтами; на Android небольшое отставание сохраняется. В сентябрьском наборе данных доля origins с хорошими Core Web Vitals составила 55,9% без учёта «мягких» переходов и 59,5% с их учётом.

Что делать владельцу сайта и команде

Если сайт меняет содержимое и URL без полной перезагрузки, разработчикам полезно включить переключатель в CrUX Vis. Сравнение покажет, насколько отличаются оценки и какая метрика меняется сильнее всего, когда внутренние переходы рассматриваются отдельно. Если каждый переход сопровождается полной загрузкой страницы, заметной разницы ожидать не стоит.

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

Пока эти метрики остаются экспериментальными, а Chrome предупреждает о возможных изменениях результатов от месяца к месяцу по мере доработки измерений. В ноябрьском выпуске CrUX ожидаются показатели FCP и типов навигации с учётом «мягких» переходов. Chrome рассчитывает завершить экспериментальный этап в мае 2027 года, но срок зависит от обратной связи. Когда метрики выйдут из экспериментального статуса, новые данные должна начать использовать Search Console; какой статус они получат следующим, в материале не уточняется.

Моё мнение: важен не только первый экран

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

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

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

  1. Google Adds Experimental Soft Navigation Metrics To CrUX via @sejournal, @MattGSouthern www.searchenginejournal.com

Об авторе

Павел Воронов

UX/UI-дизайнер продуктовых сервисов

Проектирую интерфейсы и помогаю командам договориться о том, что действительно нужно пользователю. Люблю разбирать скорость не только по Lighthouse, но и по ощущениям человека.

Все публикации автора

SEO 4 мин чтения

После выхода GPT-6 ссылки из ChatGPT потеряли UTM-метки

После выхода GPT-6 ссылки ChatGPT, по наблюдениям, перестали передавать UTM-метки. Из-за этого часть переходов может учитываться как прямой трафик, а владельцам сайтов сложнее оценить источник визитов.

Фронтенд 3 мин чтения

Bez генерирует браузерный движок по веб-спецификациям и тестам

Bez создаёт браузерный движок по веб-спецификациям, сверяя результат с Chromium, Firefox и WebKit. Проект пока на ранней стадии, а опубликованные показатели не означают готовность движка.

Написать комментарий

Не публикуется. Пришлём ссылку, чтобы подтвердить комментарий.

Без ссылок и рекламы. Первый комментарий публикуется после проверки. Отправляя комментарий, вы соглашаетесь с политикой конфиденциальности.

  1. При сравнении проверьте, что в SPA переходы действительно меняют URL и корректно отправляют события навигации: иначе экспериментальные метрики могут не привязаться к нужному маршруту. Само улучшение оценки в CrUX ещё не означает, что каждый переход стал быстрее — важно отдельно смотреть полевые данные по маршрутам и проверять их в реальных сценариях.

    1. @tomas.seo, уточню: для привязки экспериментальных метрик достаточно изменения URL или приложение должно ещё явно отправлять событие навигации?

      1. Павел Воронов Автор публикации

        @pawel.marek, отдельное событие навигации отправлять не нужно: Chrome определяет soft navigation по совокупности признаков, и изменение URL — один из них, но само по себе его недостаточно. Поэтому стоит проверить, что переход меняет URL и сопровождается обновлением содержимого; иначе маршрут может не попасть в экспериментальные метрики как отдельная навигация.

      2. @pawel.marek, я бы не полагался только на смену URL: в SPA важно, чтобы навигация была распознана браузером как переход к новому содержимому, иначе LCP/INP/CLS могут остаться привязаны к предыдущему маршруту. В пет-проекте ещё полезно сверить это в CrUX Vis отдельно для пары URL и пройти переходы руками — адресная строка менялась, а UX всё равно мог тормозить 🙂

        1. На одном SPA-проекте смена URL сама по себе не спасала диагностику: после перехода контент появлялся с задержкой, поэтому мы отдельно проходили маршрут и сверяли его URL в CrUX Vis — адрес менялся, а пользователь всё равно ждал.