Ответы на распространенные вопросы о SPA, основных веб-показателях и планах Google по устранению текущих ограничений в измерениях.
С момента первого представления инициативы Web Vitals в мае 2020 года мы, команда Chrome, получили множество замечательных вопросов и отзывов о программе.
Возможно, тема, по которой мы получили больше всего вопросов и на которую, вероятно, самый трудный вопрос, на который можно ответить, — это как измерить Core Web Vitals в одностраничном приложении (SPA), а также как архитектура SPA влияет на показатели Core Web Vitals. .
На эти вопросы сложно ответить, поскольку проблема весьма тонкая, поэтому в этом посте мы постараемся ответить на наиболее распространенные вопросы, предоставив как можно больше деталей и контекста.
Однако, прежде чем углубляться в подробности, важно заявить, что у Google нет никаких предпочтений относительно того, какая архитектура или технология используется для создания сайта. Мы считаем, что SPA и многостраничные приложения (MPA) способны предоставлять пользователям высококачественный опыт, и наша цель в рамках инициативы Web Vitals — предоставить метрики, которые измеряют качество обслуживания независимо от технологии. Хотя сегодня это возможно не во всех случаях (из-за ограничений веб-платформы), мы активно работаем над устранением этих пробелов .
Часто задаваемые вопросы
Включают ли метрики Core Web Vitals переходы маршрутов SPA?
Нет. Каждый из показателей Core Web Vitals измеряется относительно текущей навигации по страницам верхнего уровня. Если страница динамически загружает новый контент и обновляет URL-адрес страницы в адресной строке, это не окажет никакого влияния на измерение показателей Core Web Vitals. Значения показателей не сбрасываются, а URL-адрес, связанный с каждым измерением показателя, — это URL-адрес, на который перешел пользователь и инициировал загрузку страницы.
Могут ли метрики Core Web Vitals обрабатывать изменения маршрутов SPA так же, как традиционные загрузки страниц?
К сожалению нет. Во всяком случае, пока нет.
Сегодня не существует стандартизированного способа создания 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 в этих случаях исказят данные и сделают их менее полезными. или представитель реального пользовательского опыта на сайте.
SPA-компаниям труднее преуспеть в основных веб-показателях, чем MPA?
В архитектуре SPA нет ничего такого, что мешало бы странице в SPA загружаться так же быстро (и получать такие же высокие оценки по всем показателям Core Web Vitals), как аналогичная страница в MPA.
Однако правильно оптимизированные MPA имеют некоторые преимущества в достижении пороговых значений Core Web Vitals, которых в настоящее время нет у SPA. Причина в том, что в архитектуре MPA каждая «страница» загружается как полностраничная навигация (а не динамически извлекает контент и вставляет его в существующую страницу), что означает, что пользователи, посещающие MPA, с большей вероятностью загрузят больше, чем одна страница с сайта, что, в свою очередь, означает, что больший процент распределения всех загрузок страниц для MPA будет включать в себя некоторые или все кэшируемые подресурсы.
Конечно, для того, чтобы MPA работал лучше по показателям Core Web Vitals, чем SPA, необходимо соблюдение нескольких правил:
- MPA должен иметь оптимизированное кэширование подресурсов, чтобы гарантировать, что загрузка страниц из одного источника действительно происходит быстрее, чем загрузка страниц из разных источников на 75-м процентиле.
- Пользователям, посещающим MPA, необходимо посещать несколько страниц, чтобы сайт мог воспользоваться преимуществами кэширования, которые приводят к более быстрой загрузке страниц.
Поскольку оценки Core Web Vitals учитывают 75-й процентиль посещений страниц, наличие большего количества эффективных посещений страниц в наборе данных увеличит вероятность того, что посещение 75-го процентиля распределения будет находиться в пределах рекомендуемых пороговых значений.
Обратите внимание, что при сравнении показателей Core Web Vitals важно учитывать, как агрегируются данные, то есть включает ли набор данных в распределении все страницы с вашего сайта или источника или только загрузки страниц для определенного URL-адреса страницы.
При агрегировании оценок всех страниц источника отдельные быстрые страницы могут повысить 75-й процентиль для источника в целом. Однако при агрегировании по отдельным страницам оценки одной страницы не повлияют на оценки следующей. Другими словами, при агрегировании оценок MPA по страницам быстрая загрузка кэша, наблюдаемая на странице оформления заказа, не улучшит оценки медленных начальных загрузок, наблюдаемых на целевой странице сайта.
Вы можете проверить оценку вашего сайта для различных методов агрегирования с помощью PageSpeed Insights или API отчета об опыте пользователя Chrome , который сообщает оценки как для отдельных URL-адресов страниц, так и для всего источника.
Еще один способ, которым архитектура SPA может повлиять на показатели Core Web Vitals, — это метрики, учитывающие полный срок службы страницы. Поскольку пользователи, посещающие SPA, как правило, остаются на одной и той же «странице» в течение всего сеанса, метрики, которые накапливаются с течением времени, могут быть более жесткими для SPA, чем для MPA.
В апреле 2021 года мы объявили об изменениях в метрике CLS , которые частично решили эту проблему. Раньше CLS накапливался в течение всего срока службы страницы, тогда как теперь он накапливается только в течение определенного периода времени — по сути, это худший всплеск изменений макета на данной странице.
Однако даже с новым определением CLS SPA по-прежнему находятся в невыгодном положении, поскольку значение CLS не «сбрасывается» после перехода маршрута, как это происходит при полной загрузке страницы в MPA. Это также может привести к путанице, поскольку сдвиги макета, возникающие после смены маршрута, будут связаны с URL-адресом страницы при ее загрузке, а не с URL-адресом в адресной строке во время смещения ( подробнее ниже ).
Если архитектуры SPA улучшают взаимодействие с пользователем, не должно ли это улучшение отражаться в показателях?
Да, так и должно быть. Хотя, как упоминалось ранее, количественно оценить, насколько улучшился опыт, сложно в масштабе, учитывая множество различных способов реализации SPA в Интернете сегодня.
Правда в том, что индустрия веб-производительности (включая Google) исторически не тратила столько времени и усилий на разработку ориентированных на пользователя показателей производительности страницы после загрузки, сколько на саму загрузку страницы. Это не потому, что производительность после загрузки не важна, а потому, что UX и взаимодействия после загрузки гораздо более разнообразны и менее четко определены, что затрудняет разработку для них показателей.
Но даже если бы у нас были четко определенные метрики после загрузки для измерения производительности SPA, мы бы не хотели игнорировать процесс загрузки только потому, что опыт после загрузки стал лучше.
Одна из целей инициативы Web Vitals — продвигать и стимулировать хороший пользовательский опыт в максимально возможном количестве аспектов загрузки и использования веб-страницы. Мы не хотим поощрять сценарии, в которых плохой опыт оправдан, если у вас есть достаточно хорошего опыта, чтобы его компенсировать. Пользователи хотят, чтобы страницы загружались быстро и быстро переходили к новому контенту, и мы постарались разработать показатели, благоприятствующие этим типам взаимодействия.
Таким образом, хотя это правда, что версия сайта MPA может показывать лучшие результаты по показателям Core Web Vitals на 75-м процентиле, чем версия SPA того же сайта, версия SPA все равно должна стремиться соответствовать «хорошему» порогу. Если версия SPA не соответствует порогу «хорошо» для большинства пользователей, то первоначальная загрузка, вероятно, все равно не будет восприниматься как хорошая, даже если последующая навигация по странице будет превосходной.
В будущем мы планируем разработать метрики, которые будут способствовать получению отличных впечатлений после загрузки, и мы считаем, что это лучший способ стимулировать высококачественные SPA таким образом, чтобы не ставить под угрозу качество первоначальной загрузки. Мы уже представили новую метрику под названием «Взаимодействие с следующей отрисовкой» (INP) , которая измеряет задержку взаимодействия на протяжении всего жизненного цикла страницы, а также активно работаем над другими метриками после загрузки, включая метрики, которые измеряют переходы маршрутов SPA ( см. ниже). ).
Мы перевели наш сайт с MPA на SPA, и наши оценки снизились. Ожидается ли это?
Это зависит. Существует ряд причин, по которым ваши оценки могут измениться после серьезной миграции архитектуры, но часть изменений может объясняться уменьшением количества загрузок «теплого» кэша.
Быстрый способ проверить — протестировать версию MPA и SPA одной из ваших целевых страниц с помощью Lighthouse . Если оценка Lighthouse ниже по любому из показателей Core Web Vitals для версии SPA, то вполне вероятно, что после обновления качество загрузки действительно ухудшилось.
Должен ли я перевести свой сайт с SPA на MPA, чтобы получить более высокие оценки по Core Web Vitals?
Возможно нет. Вам следует переходить с SPA на MPA только в том случае, если вы недовольны своим стеком SPA и у вас есть основания полагать, что MPA обеспечит лучший пользовательский опыт.
Со временем, когда показатели Core Web Vitals улучшатся и будут охватывать все больше возможностей просмотра, команды с хорошо построенными SPA, которые обеспечивают отличный UX, должны ожидать, что их оценки Core Web Vitals отразят это.
Если показатели Core Web Vitals сообщаются только для целевых страниц SPA, как можно устранить проблемы, возникающие на «страницах» после перехода маршрута?
Инструменты Google, которые сообщают данные полей для метрики Core Web Vitals (например, Search Console и PageSpeed Insights), получают данные из отчета об опыте пользователя Chrome (CrUX). А CrUX агрегирует данные либо по источнику, либо по URL-адресу страницы (то есть URL-адрес страницы во время загрузки).
По всем причинам, уже перечисленным выше, CrUX не может агрегировать данные по маршруту SPA. Однако, как владелец сайта, знакомый с вашей собственной архитектурой, вы можете измерить это самостоятельно, и многие аналитические инструменты позволяют вам сигнализировать об изменении маршрута SPA и соответствующим образом обновлять ваши данные измерений.
Измеряя показатели Web Vitals с помощью аналитического инструмента, убедитесь, что вы измеряете как текущий URL-адрес маршрута, так и URL-адрес исходной страницы. Это позволит вам как отлаживать отдельные проблемы, возникающие на протяжении жизненного цикла страницы, так и агрегировать их по исходному URL-адресу страницы, чтобы соответствовать тому, как инструменты Google измеряют показатели и сообщают о них.
Дополнительные сведения и рекомендации по этой теме см. в разделе Отладка производительности в полевых условиях .
Что делает Google, чтобы гарантировать, что MPA не будет иметь несправедливого преимущества по сравнению с SPA?
Как упоминалось выше, правильно оптимизированный MPA в некоторых случаях может сообщать о более высоких показателях Web Vitals на 75-м процентиле из-за того, что у него, вероятно, будет более высокий процент посещений кэшированных страниц. И наоборот, реальные улучшения пользовательского опыта в правильно оптимизированных SPA в настоящее время не отражаются ни в одной из метрик Core Web Vitals.
В Google мы понимаем, что это создает стимулы, которые не полностью соответствуют целям инициативы Web Vitals, и активно ищем способы исправить это. В настоящее время мы изучаем два потенциальных решения: одно краткосрочное и одно долгосрочное:
- Оценивайте посещения страниц из разных источников и из одного источника отдельно.
- Разработайте новые API, которые позволят лучше измерять SPA.
Оценивайте посещения страниц из разных источников и из одного источника отдельно.
Сегодня метрики Core Web Vitals объединяют все посещения страниц в один сегмент — они не делают различий между новыми и повторными посещениями, целевыми страницами и страницами оформления заказа или любым другим типом агрегирования, где состояние кэша может влиять на производительность.
Одним из способов нормализации различий между эффективностью SPA и MPA было бы применение разных весовых коэффициентов к разным типам посещений, возможно, даже с совершенно разными пороговыми рекомендациями .
Хотя мы определенно хотим вознаграждать эффективные реализации кэша, мы не хотим, чтобы быстрая навигация внутри сайта могла скрыть медленную загрузку целевой страницы. Мы также не хотим побуждать сайты разбивать длинные страницы на набор более коротких только ради улучшения показателей.
Раздельно оценивая посещения страниц из разных источников и из одного источника, мы можем помочь гарантировать, что оба типа опыта важны, не позволяя относительной популярности одного типа на данном сайте искажать распределение какого-либо конкретного показателя.
Разрабатывайте новые API, которые позволят лучше измерять SPA.
Еще одно решение, над которым активно работают (параллельно вышеописанному), — это новый API истории приложений , который поможет стандартизировать текущие шаблоны SPA и упростит измерение и понимание использования SPA в масштабе.
API истории приложений представляет новое событие navigate , которое имеет две ключевые функции, характерные для измерения SPA:
- Флаг
userInitiated, для которого будет установлено значение true только в том случае, если навигация была инициирована посредством щелчка ссылки, отправки формы или пользовательского интерфейса браузера «Назад» или «Вперед». - Метод
transitionWhile(), который принимает обещание, позволяющее разработчику сигнализировать, когда работа, которую он инициировал для выполнения навигации, завершена.
Флаг userInitiated можно использовать для определения семантической начальной точки перехода маршрута SPA, указывая на четкое намерение пользователя. Разрешение обещанийtransitionWhile transitionWhile() может помочь браузеру сопоставить отрисовку с конкретным переходом маршрута, так что он сможет определить наибольшую содержательную отрисовку, связанную с этим переходом.
Основываясь на идее, представленной в предыдущем разделе, возможно, даже можно будет объединить время перехода маршрута SPA в тот же сегмент, что и загрузки страниц того же источника в MPA. Это интересно, потому что это позволит сайту, переходящему с MPA на SPA, реально сравнить производительность до и после.
Конечно, необходимы дополнительные исследования, прежде чем мы узнаем, сможем ли мы точно сделать эти выводы. Если у вас есть предложения или отзывы по этим предложениям, отправьте электронное письмо по адресу web-vitals-feedback@googlegroups.com .
Последние мысли
Google стремится улучшить показатели Web Vitals, а также гарантировать, что они измеряют и стимулируют высококачественный опыт, который важен для пользователей. При этом мы признаем, что сегодня существуют пробелы в измерениях. В настоящее время метрики не охватывают все аспекты взаимодействия с пользователем, но мы активно работаем над устранением этих пробелов.
Несмотря на текущие ограничения, мы считаем, что области, которые охватывают существующие показатели, имеют решающее значение для здоровья и успеха Интернета, и в той степени, в которой сайты (независимо от архитектуры) не соответствуют рекомендуемым пороговым значениям, мы считаем, что есть возможности для улучшения. .
Я надеюсь, что этот пост помог пролить свет на эту сложную и тонкую тему. Как всегда, если у вас есть отзывы о текущих или будущих показателях Web Vitals, отправьте электронное письмо по адресу web-vitals-feedback@googlegroups.com .