Ответы на часто задаваемые вопросы о SPA, Core Web Vitals и о том, как Core Web Vitals обрабатывает эти данные.
Опубликовано: 14 сентября 2021 г., Последнее обновление: 11 августа 2026 г.
С момента запуска инициативы Web Vitals в мае 2020 года мы, команда Chrome, получили множество замечательных вопросов и отзывов о программе.
Пожалуй, тема, по которой нам задавали больше всего вопросов, и которая, вероятно, является самой сложной для ответа, — это как измерить показатели Core Web Vitals в одностраничном приложении (SPA), а также как архитектура SPA влияет на эти показатели.
На эти вопросы сложно ответить, поскольку проблема довольно сложная, поэтому в этом посте мы постараемся ответить на самые распространенные вопросы, предоставив как можно больше подробностей и контекста.
Прежде чем перейти к конкретике, важно отметить, что Google не отдает предпочтение какой-либо архитектуре или технологии, используемой для создания сайта. Мы считаем, что как одностраничные приложения (SPA), так и многостраничные приложения (MPA) способны обеспечить пользователям высококачественный опыт, и наша цель в рамках инициативы Web Vitals — предоставить метрики, измеряющие качество обслуживания независимо от используемой технологии.
Часто задаваемые вопросы
Ниже приведены некоторые из наиболее часто задаваемых вопросов по этой теме. Мы будем рады получить отзывы для дополнения этого раздела часто задаваемых вопросов в нашей группе обратной связи или путем создания соответствующей заявки .
Включают ли метрики Core Web Vitals переходы между маршрутами SPA?
При первом внедрении каждый из показателей Core Web Vitals измерялся относительно текущей навигации по странице верхнего уровня. Если страница динамически загружала новый контент и обновляла URL страницы в адресной строке, это никак не влияло на измерение показателей Core Web Vitals.
Значения метрик не сбрасывались, и URL-адрес, связанный с каждым измерением метрики, — это URL-адрес, на который пользователь перешел и который инициировал загрузку страницы.
В Chrome 151 были представлены новые API, позволяющие измерять основные показатели веб-безопасности (Core Web Vitals) при переходе между маршрутами одностраничных приложений (SPA). На момент написания статьи (август 2026 г.) эти API только начинают использоваться в библиотеках измерения, таких как web-vitals , решениях RUM и инструментах, таких как Chrome DevTools. Chrome еще не опубликовал сроки интеграции этих API в отчет Chrome User Experience Report (CrUX) . Кроме того, другие браузерные движки пока не поддерживают эти новые API, поэтому измерение основных показателей веб-безопасности (Core Web Vitals) возможно только при полной загрузке страницы в этих браузерах.
Почему эта задача оказалась сложной для решения?
Сегодня не существует стандартизированного способа создания одностраничных приложений (SPA), и даже среди популярных библиотек для SPA и маршрутизации пользовательский опыт может значительно отличаться от приложения к приложению:
- Некоторые одностраничные приложения (SPA) обновляют URL-адрес только при загрузке нового контента на всю страницу, в то время как другие сайты обновляют URL-адрес при незначительных изменениях контента или даже просто при изменении состояния пользовательского интерфейса.
- Некоторые одностраничные приложения (SPA) обновляют URL-адрес с помощью History API, другие используют изменения хеша для поддержки старых браузеров (а третьи вообще не обновляют URL-адрес).
- Некоторые одностраничные приложения (SPA) загружают контент, а затем обновляют URL-адрес, в то время как другие обновляют URL-адрес до загрузки контента.
- Некоторые одностраничные приложения (SPA) загружают контент целиком, синхронно, в рамках одной задачи JavaScript, в то время как другие асинхронно загружают контент, распределяя его между несколькими задачами (без четкого события завершения перехода).
- Некоторые одностраничные приложения (SPA) всегда загружают контент из сети, в то время как другие предварительно загружают весь контент, так что изменения маршрута мгновенно загружаются из памяти.
Эти различия значительно затрудняют определение и идентификацию того, что представляет собой изменение маршрута SPA, или даже само по себе SPA, в больших масштабах .
В некоторых случаях изменение маршрута SPA логически идентично загрузке страницы MPA, и в таких случаях было бы замечательно, если бы можно было использовать существующие метрики Core Web Vitals.
Однако без надежных эвристических методов, позволяющих достоверно отличать «реальные» изменения маршрута от всех других изменений URL-адреса, а также без четких сигналов, обозначающих начало и конец таких переходов, отчетность по метрикам Core Web Vitals в этих случаях будет искажать данные и сделает их менее полезными или репрезентативными для реального пользовательского опыта на сайте.
В рамках проекта Soft Navigation было найдено решение этой проблемы с помощью двух новых API для повышения производительности:
-
PerformanceSoftNavigationизмеряет, когда взаимодействие пользователя приводит как к отрисовке страницы, так и к изменению URL-адреса. Сочетание этих трех факторов обеспечивает стандартизированное определение «мягкой навигации» независимо от используемой платформы и некоторых упомянутых ранее различий. Это позволяет разделить временную шкалу производительности на отдельные «навигации», что позволяет измерять CLS и INP для каждой навигации. -
InteractionContentfulPaintизмеряет количество «контентных отрисовок» после взаимодействия, что позволяет измерять FCP и LCP для таких мягких навигаций.
Сочетание этих двух API позволяет измерять показатели Core Web Vitals как при полной загрузке страницы, так и при плавной навигации.
Для Core Web Vitals изменение маршрута SPA-приложения эквивалентно полной загрузке всей страницы?
Нет, между этими типами навигации по-прежнему существует множество различий, которые могут приводить к различным показателям Core Web Vital.
В режиме мягкой навигации контент уже находится на странице, и часть или весь этот контент обновляется для отображения новой «страницы». Во многом это похоже на разницу между полной загрузкой страницы без кэширования и загрузкой страницы, когда часть или все ресурсы страницы кэшируются, но в ещё более экстремальной ситуации, когда часть контента может оставаться отображенной.
Теоретически, главное отличие будет заключаться в потенциально гораздо более быстрой навигации с помощью программных средств. Но есть и другие, более тонкие различия.
Новые API для мягкой навигации учитывают только новый контент. Поэтому страница, которая обновляет заголовок <h1> и текстовое содержимое, но оставляет то же самое изображение заголовка между страницами, не будет рассматривать изображение заголовка как кандидата на LCP, если оно не было перерисовано. Это приведет к различиям в том, какие элементы используются для расчета времени LCP в зависимости от того, загружается ли одна и та же страница полностью или в виде мягкой навигации с другой существующей страницы.
Аналогично, показатель INP может быть ниже для плавной навигации, поскольку большая часть JavaScript, необходимого для работы сайта, уже будет загружена. Точно так же плавная навигация может иметь меньший (или больший!) показатель CLS, если один и тот же контент вызывает CLS при полной загрузке страницы, но не требует загрузки или перерисовки при плавной навигации.
Также наблюдаются небольшие различия во времени проведения измерений: при полной загрузке страницы (измерения после обработки взаимодействия при навигации) и при плавной навигации (измерения с момента начала взаимодействия).
Как уже говорилось ранее, многие из этих различий схожи с различиями между некэшированными и кэшированными страницами, и концепция того, что пытается измерить Core Web Vitals, по-прежнему актуальна. Однако при исследовании проблем, связанных с Core Web Vitals, стоит понимать эти тонкости.
Сложнее ли одностраничным приложениям (SPA) добиться хороших результатов по основным веб-показателям (Core Web Vitals), чем многопользовательским приложениям (MPA)?
В архитектуре SPA нет ничего, что препятствовало бы столь же быстрой загрузке страницы в SPA и получению ею столь же высоких оценок по всем показателям Core Web Vitals, как и аналогичной странице в MPA.
Однако правильно оптимизированные MPA имеют некоторые преимущества в достижении пороговых значений Core Web Vitals, которых нет у SPA. Этот недостаток в значительной степени был компенсирован ранее обсуждавшейся работой над мягкой навигацией, но он может сохраняться, даже если эти новые API еще не используются. Причина в том, что в архитектуре MPA каждая «страница» загружается как полностраничная навигация (а не динамически загружается контент и вставляется в существующую страницу), что означает, что пользователи, посещающие MPA, с большей вероятностью загрузят более одной страницы с сайта, а это, в свою очередь, означает, что большая часть всех загрузок страниц для MPA будет приходиться на кэширование некоторых или всех подресурсов.
Конечно, для того чтобы MPA показала лучшие результаты по метрикам Core Web Vitals, чем SPA, необходимо соблюдение нескольких условий:
- Для обеспечения того, чтобы загрузка страниц из одного источника действительно происходила быстрее, чем загрузка страниц из разных источников, на уровне 75-го процентиля, MPA необходимо оптимизировать кэширование подресурсов.
- Пользователям, посещающим MPA-ресурсы, необходимо просматривать несколько страниц, чтобы сайт получил преимущества кэширования, обеспечивающие более быструю загрузку страниц.
Поскольку в оценках Core Web Vitals учитывается 75-й процентиль посещений страниц, наличие большего количества посещений страниц с хорошими показателями в наборе данных повысит вероятность того, что посещение, находящееся на 75-м процентиле распределения, будет соответствовать рекомендуемым пороговым значениям.
Обратите внимание, что при сравнении показателей Core Web Vitals важно учитывать способ агрегирования данных — то есть, включает ли набор данных в дистрибутиве все страницы вашего сайта или исходного ресурса, или только загрузки страниц по конкретному URL-адресу.
При агрегировании оценок всех страниц исходного сайта, быстрая загрузка отдельных страниц может улучшить 75-й процентиль для всего сайта в целом. Однако при агрегировании оценок отдельных страниц, оценки одной страницы не повлияют на оценки следующей. Другими словами, при агрегировании оценок MPA по страницам, быстрая загрузка кэша на странице оформления заказа не улучшит оценки медленной первоначальной загрузки главной страницы сайта.
Вы можете проверить рейтинг своего сайта для различных методов агрегирования, используя PageSpeed Insights или API отчетов об опыте пользователей Chrome , которые предоставляют оценки как для отдельных URL-адресов страниц, так и для всего исходного сайта.
Еще один способ, которым архитектура SPA может влиять на показатели Core Web Vitals, — это метрики, учитывающие весь жизненный цикл страницы. Поскольку пользователи, посещающие SPA, как правило, остаются на одной и той же «странице» на протяжении всей сессии, метрики, накапливающиеся со временем, могут оказывать более негативное воздействие на SPA, чем на MPA.
Благодаря работе над плавной навигацией, мы считаем, что у одностраничных приложений (SPA) не должно быть никаких недостатков с точки зрения измерения основных показателей веб-технологий. Однако полная интеграция этих API во все инструменты и решения для отчетности займет время.
Если SPA-архитектура улучшает пользовательский опыт, разве это улучшение не должно отражаться в метриках?
Да, так и должно быть. Количественная оценка того, насколько улучшился пользовательский опыт, в больших масштабах была сложной задачей, учитывая все различные способы реализации одностраничных приложений (SPA) в современном веб-пространстве. Теперь у нас есть решение проблемы измерения, и при использовании этих новых API любые улучшения, полученные благодаря переходу на SPA, должны отражаться в метриках.
Правда заключается в том, что индустрия веб-производительности (включая Google) исторически не вкладывала столько времени и усилий в разработку ориентированных на пользователя метрик для оценки производительности страницы после загрузки, сколько в оценку производительности самой страницы. Это не потому, что производительность после загрузки не важна, а потому, что пользовательский опыт и взаимодействия после загрузки гораздо более разнообразны и менее четко определены, что затрудняет разработку метрик для них.
Но даже сейчас, когда у нас есть больше метрик для оценки производительности SPA после загрузки, мы не хотели бы игнорировать результаты загрузки только потому, что результаты после загрузки улучшились.
Одна из целей инициативы Web Vitals — продвижение и стимулирование качественного пользовательского опыта во всех аспектах загрузки и использования веб-страницы. Мы не хотим поощрять ситуации, когда плохой опыт оправдан, если можно компенсировать его достаточным количеством хорошего опыта. Пользователи хотят, чтобы страницы загружались быстро и переходы к новому контенту происходили быстро, и мы постарались разработать метрики, которые способствуют именно такому типу опыта.
Мы перевели наш сайт с MPA на SPA, и наши показатели ухудшились. Это ожидаемо?
Это зависит от ситуации. Существует ряд причин, по которым ваши результаты могут измениться после масштабной миграции архитектуры, но уменьшение количества загрузок в «горячий» кэш может частично объяснить эти изменения.
Быстрый способ проверить это — протестировать с помощью Lighthouse как MPA-, так и SPA-версию одной из ваших целевых страниц. Если оценка Lighthouse по любому из показателей Core Web Vitals для SPA-версии ниже, то, вероятно, скорость загрузки действительно ухудшилась после обновления.
Стоит ли мне перевести свой сайт с одностраничного приложения (SPA) на многопользовательское приложение (MPA), чтобы улучшить показатели в Core Web Vitals?
Скорее всего, нет. Переход с SPA на MPA оправдан только в том случае, если вас не устраивает используемая вами SPA-платформа, и у вас есть основания полагать, что MPA обеспечит лучший пользовательский опыт.
Мы считаем, что благодаря работе над программной навигацией мы решили проблемы с измерениями, поэтому переезд только по этой причине не имеет смысла.
Однако, если у вас есть основания доказать, что улучшится производительность, а не просто улучшатся показатели измерений, то это может стать причиной для перехода от SPA к MPA (или наоборот!).
Если показатели Core Web Vitals отображаются только для целевых страниц SPA, как можно отлаживать проблемы, возникающие на «страницах» после перехода на другой маршрут?
Инструменты Google, которые предоставляют данные о параметрах Core Web Vitals (например, Search Console и PageSpeed Insights), получают свои данные из отчета Chrome User Experience Report (CrUX). CrUX, в свою очередь, агрегирует данные либо по источнику, либо по URL страницы (то есть по URL страницы на момент загрузки).
Мы работаем над тем, чтобы CrUX мог включать данные по маршрутам SPA в свои агрегированные данные. Однако, как владелец сайта, вы уже сейчас можете использовать новые API для предварительного измерения показателей Core Web Vitals по маршрутам SPA, чтобы понять, как могут измениться ваши оценки.
Для получения более подробной информации и рекомендаций по этому вопросу см.: Измерение эффективности плавной навигации .
Что делает Google для того, чтобы MPA-партнеры не имели несправедливого преимущества перед SPA-партнерами?
Как уже упоминалось ранее, благодаря работе над программной навигацией, мы считаем, что проделанная нами работа не должна создать никаких недостатков для одностраничных приложений в этом отношении, хотя полная интеграция со всеми инструментами и решениями для отчетности займет время.
Проведите отдельную оценку посещений страниц из разных источников и из одного источника.
Сегодня метрики Core Web Vitals объединяют все посещения страниц в одну группу — они не различают новые и повторные посещения, целевые страницы и страницы оформления заказа, а также любые другие типы агрегации, где состояние кэша может влиять на производительность.
Один из способов нормализации различий в эффективности SPA и MPA заключался бы в применении различных весовых коэффициентов к различным типам посещений, возможно, даже с совершенно разными рекомендациями по пороговым значениям .
Хотя мы, безусловно, хотим поощрять эффективную реализацию кэширования, мы не хотим, чтобы быстрая навигация внутри сайта компенсировала медленную загрузку целевых страниц. Мы также не хотим стимулировать сайты разбивать длинные страницы на набор более коротких страниц только ради улучшения показателей.
Раздельная оценка посещений страниц из разных источников и из одного источника позволяет нам убедиться в важности обоих типов взаимодействия, не допуская при этом, чтобы относительная популярность одного типа на данном сайте искажала распределение какого-либо конкретного показателя.
Заключительные мысли
Google твердо привержен улучшению показателей Web Vitals и обеспечению того, чтобы они измеряли и стимулировали высокое качество пользовательского опыта, важного для пользователей. Тем не менее, мы признаем, что сегодня существуют пробелы в измерениях. Теперь метрики позволяют учитывать переходы между маршрутами SPA, что устраняет один из основных пробелов.
Мы также считаем, что эти новые API (в частности, InteractionContentfulPaint ) имеют дополнительные возможности применения и потенциальные преимущества, выходящие за рамки измерения Core Web Vitals для плавной навигации. Мы очень рады продолжить их разработку теперь, когда основная причина их внедрения решена.
Надеюсь, эта статья помогла прояснить этот сложный и многогранный вопрос. Как всегда, если у вас есть отзывы о текущих или будущих показателях Web Vitals, отправьте их по адресу web-vitals-feedback@googlegroups.com .