Как архитектура SPA-сайтов влияет на метрики Core Web Vitals

Команда Chrome ответила на популярные вопросы веб-мастеров о влиянии SPA на показатели CWV и рассказала, что с этим планирует делать Google.

Сначала разберёмся, что такое SPA-сайт, чтобы понять, почему возникают вопросы.

Что такое SPA-сайт

По сути, это сайт, который работает как приложение. Что это значит?

Классический сайт – это несколько HTML-страниц, связанных между собой. Вы перемещаетесь по сайту, кликая по ссылкам на страницы, и каждый раз браузер загружает нужную страницу полностью: шапку, футер, контент, скрипты. Каждая страница – это отдельный документ со своими элементами. Такую архитектуру сайта называют MPA (Multi Page Application).

А SPA-сайт работает как мобильное приложение. Когда мы открываем сайт, браузер загружает сразу весь код сайта целиком: и HTML, и CSS, и JavaScript. Разделы сайта и условные страницы на самом деле – части приложения. Поэтому когда мы переключаемся между разделами на таком сайте, то остаёмся в одной системе. Контент меняется или, если нужно, динамически подгружается с сервера. URL тоже меняется, но страница не обновляется.

Примеры SPA-сайтов: М.Видео и OZON, соцсети ВКонтакте.

Про SPA в журнале «Код» Яндекс.Практикума

Показатели CWV рассчитываются отдельно для каждой страницы. Но у SPA как таковых страниц нет. Есть только переходы маршрутизации (маршруты) по приложению. Поэтому у веб-мастеров возникают вопросы, как это отражается на метриках.

Вопросы веб-мастеров

Учитывают ли показатели Core Web Vitals переходы по маршрутам в одностраничных веб-приложениях?

Нет. Каждый из показателей Core Web Vitals измеряется относительно текущей веб-страницы, расположенной на верхнем уровне навигации по сайту. Если веб-страница динамически загружает новый контент и обновляет свой URL в адресной строке, то это не оказывает влияния на показатели Core Web Vitals. Значения показателей не сбрасываются.

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

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

На данный момент нет.

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

• Некоторые SPA обновляют URL-адрес только при загрузке нового контента, который подходит на роль целой веб-страницы. Другие – даже после незначительных изменений контента, в том числе изменений состояния пользовательского интерфейса.
  
• Некоторые SPA обновляют URL-адрес, используя History API, другие – используя изменения хэш-кода, чтобы поддерживать старые браузеры, или вовсе не обновляют URL-адрес.
  
• Некоторые SPA загружают контент, а затем обновляют URL-адрес, другие – обновляют его перед загрузкой контента.
  
• Некоторые SPA загружают сразу весь контент синхронно в рамках одной задачи в JavaScript-коде, другие – выполняют переключение на другой контент асинхронно в рамках нескольких задач без явного события, обозначающего завершение переключения.
  
• Некоторые SPA всегда грузят контент через Интернет, другие – заранее загружают его целиком, чтобы после изменения маршрута контент мгновенно загружался из памяти устройства пользователя.

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

Сложнее ли SPA-сайтам получить хорошие результаты в Core Web Vitals по сравнению с MPA-сайтами?

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

Однако у правильно оптимизированных MPA действительно есть некоторые преимущества.

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

В случае с SPA происходит следующее: контент новой «страницы» динамически подгружается и вставляется в текущую страницу. А в случае с MPA следующая страница загружается как целая отдельная веб-страница.

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

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

• В многостраничном приложении должно быть оптимизированное кэширование подресурсов, чтобы загрузки веб-страниц из одного и того же источника (origin'а) в самом деле выполнялись быстрее, чем загрузки веб-страниц из разных источников на 75-м процентиле.
• Пользователям многостраничных веб-приложений нужно посетить несколько веб-страниц, чтобы сайт мог применить кэширование для ускорения их загрузки.

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

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

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

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

Вы можете посмотреть на оценку своего сайта при разных методах агрегации, используя PageSpeed Insights или Chrome User Experience Report API, который предоставляет результаты оценки как по URL-адресам отдельных страниц, так и по всему источнику в целом.

Еще один фактор отрицательного влияния SPA на оценки по Core Web Vitals – показатели, которые принимают во внимание полное время просмотра веб-страницы.

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

В апреле 2021 года мы сообщили об изменениях в показателе CLS, которые частично решили эту проблему. Ранее значение показателя CLS накапливалось на протяжении всего «срока жизни» веб-страницы, а теперь оно накапливается только в течение определённого периода времени – по сути, оценивая худшую серию сдвигов макета на веб-странице.

Но даже с новым CLS одностраничные веб-приложения всё равно находятся в невыгодном положении, потому что значение CLS не «сбрасывается» после перехода на другой маршрут приложения, как это выполняется при полной загрузке страниц в MPA.

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

Если архитектура SPA улучшает взаимодействие с пользователем, то не должно ли это улучшение прослеживаться и в показателях?

Да, должно. Хотя, как упоминалось ранее, посчитать, в какой степени улучшилось взаимодействие пользователя с сайтом, – это сложная в широких масштабах задача.

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

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

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

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

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

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

Поэтому, несмотря на то, что многостраничная версия сайта действительно может показывать более высокие показатели Core Web Vitals на 75-м процентиле по сравнению с SPA, одностраничная версия всё же должна стремиться соответствовать «хорошему» пороговому значению.

Если SPA-сайт не дотягивает до «хорошего» порогового значения относительно большинства пользователей, то, скорее всего, пользователи всё ещё не в восторге от того, как осуществляется первоначальная загрузка веб-страницы, даже если с дальнейшими переходами пользователя на странице всё отлично.

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

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

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

Быстрый способ проверить влияние смены архитектуры на показатели – это протестировать как многостраничную, так и одностраничную версии одной из ваших посадочных страниц с помощью Lighthouse. Если результаты в Lighthouse по любому из показателей Core Web Vitals хуже в случае одностраничной версии, то, скорее всего, после обновления вашего веб-приложения скорость загрузки страниц действительно снизилась.

Стоит ли мне переносить свой сайт с архитектуры SPA на MPA, чтобы улучшить показатели Core Web Vitals?

Скорее всего нет. Переходить от SPA на MPA стоит только в случае, если вы недовольны своим стеком технологий, используемых для реализации SPA, и у вас есть повод считать, что MPA позволит обеспечить более качественное обслуживание пользователей.

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

Если показатели Core Web Vitals предоставляются только для посадочных страниц SPA-сайтов, как выполнять отладку проблем, которые возникают на «страницах» после смены маршрута?

Инструменты Google, которые предоставляют полученные в рабочих условиях данные по набору показателей Core Web Vitals, такие как Search Console и PageSpeed Insights, получают эти данные из Chrome User Experience Report (CrUX). И CrUX выполняет агрегацию данных либо по источнику, либо по URL-адресу веб-страницы, с которой пользователь попал на сайт.

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

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

Чтобы изучить эту тему подробнее и узнать о лучших подходах, можете обратиться к материалу «Отладка Web Vitals в полевых условиях».

Почему значения метрик в лабораторных и полевых данных могут отличаться

Что делает Google для того, чтобы у многостраничных веб-приложений не было необоснованного преимущества перед одностраничными веб-приложениями?

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

Напротив, реальные улучшения опыта использования правильно оптимизированных SPA в настоящее время не учитываются ни в одном из показателей Core Web Vitals.

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

1. Оценивать посещения веб-страниц, на которых осуществляется обращение к различным источникам, отдельно от посещений веб-страниц, на которых используется один и тот же источник.
   
2. Разработать новые API, которые позволят более эффективно оценивать одностраничные веб-приложения.

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

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

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

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

Еще одно решение, которое активно прорабатывается параллельно предыдущему, – это новый App History API, который поможет стандартизировать нынешние реализации одностраничных веб-приложений и облегчит оценку и понимание использования SPA в широких масштабах.

App History API привносит новое событие «navigate», у которого есть две возможности, непосредственно связанные с измерением эффективности SPA:

• Метка userInitiated, которому будет присвоено значение true, если переход по сайту был вызван щелчком по ссылке, отправкой формы или нажатием кнопок «Назад» либо «Вперёд» в браузере.
  
• Метод transitionWhile(), который принимает промис, позволяющий разработчику подавать сигнал о том, что работа, которую он запланировал для выполнения перехода по сайту, завершена.

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

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

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

Конечно, нужно провести больше исследований, прежде чем мы узнаем, сможем ли мы правильно реализовать эти решения. Если у вас есть идеи или комментарии к описанным выше предложениям, пожалуйста, напишите на web-vitals-feedback@googlegroups.com.

Заключительные соображения

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

Надеемся, этот пост помог разобраться в сложной теме и разъяснить некоторые нюансы. Если вам есть что сказать о нынешних или будущих показателях Web Vitals, пожалуйста, напишите на web-vitals-feedback@googlegroups.com.