Цель этого отчёта — изучить реальные данные, чтобы лучше понять связь между выбором фреймворка, производительностью и фактическим пользовательским опытом в вебе. Мы попробуем ответить на несколько ключевых вопросов:
- Как современные веб-фреймворки сравниваются в реальном использовании и производительности?
- Влияет ли выбор фреймворка на Core Web Vitals сайта?
- Насколько выбор фреймворка связан с размером JavaScript payload и каков эффект?
The Data
Для этого мы изучили три публичных набора данных:
- Chrome User Experience Report (CrUX) предоставляет метрики пользовательского опыта того, как реальные пользователи Chrome воспринимают популярные сайты в вебе.
- HTTP Archive отслеживает и публикует производительность более 15 миллионов сайтов, регулярно собирая данные Lighthouse.
- Core Web Vitals Technology Report собирает полезные выводы из двух предыдущих наборов данных.
Все данные взяты из публичных независимо управляемых наборов. Команда Astro не измеряла производительность напрямую. Подробнее о методологии — в разделе ниже.
The Frameworks
Для отчёта мы выбрали шесть популярных JavaScript-фреймворков: Astro, Gatsby, Next.js, Nuxt, Remix и SvelteKit. Где возможно, мы также включили данные WordPress из-за его популярности и большой доли рынка (43,2%) в вебе.
Несколько перспективных новых фреймворков пришлось исключить из-за недостаточного реального использования в выбранных наборах данных, но мы надеемся включить больше фреймворков в следующем отчёте.
Core Web Vitals
Core Web Vitals (CWV) от Google — набор из трёх стандартизированных метрик, помогающих понять, как пользователи воспринимают веб-страницу. Каждая метрика измеряет свой аспект опыта — скорость загрузки, отзывчивость, визуальную стабильность — и вместе они количественно оценивают общую производительность сайта.
Core Web Vitals Assessment от Google — тест, который смотрит на реальные пользовательские данные (из набора CrUX) по всем трём метрикам и выставляет общую оценку pass/fail для каждого сайта. Чтобы пройти, сайт должен соответствовать порогу «good» по всем трём метрикам. Если хотя бы одна метрика не проходит порог, сайт не проходит оценку.
CWV Assessment уникален использованием реальных пользовательских данных и измерений. Это более точное отражение того, как пользователи воспринимают сайт, особенно в длительных сессиях. Lighthouse и другие лабораторные инструменты измеряют только первую загрузку страницы, что не отражает полный опыт использования сайта.
Среди всех известных сайтов на определённом фреймворке Astro и SvelteKit превосходят средний pass rate всех протестированных сайтов (40,5%), остальные фреймворки — нет. Astro — единственный фреймворк, у которого более 50% сайтов прошли CWV Assessment от Google. Next.js и Nuxt оказались внизу: примерно 1 из 4 и 1 из 5 сайтов соответственно проходят оценку.
Какова наиболее вероятная причина провала Core Web Vitals Assessment от Google? Можно разбить данные по отдельным метрикам и понять, где разные фреймворки испытывают трудности (и преуспевают) в web vitals.
First Input Delay (FID)
First Input Delay (FID) измеряет время от первого взаимодействия пользователя со страницей до момента, когда браузер может ответить на это взаимодействие. CWV Assessment от Google ожидает FID 100 миллисекунд или меньше. Всё медленнее считается требующим улучшения и не проходит оценку.
Большинство фреймворков легко проходят этот тест: более 90% сайтов. Ни один фреймворк не опускается ниже 80% pass rate. Это значит, что большинство протестированных сайтов отзывчивы на первое взаимодействие пользователя.
Cumulative Layout Shift (CLS)
Cumulative Layout Shift (CLS) измеряет визуальную стабильность страницы. Чтобы пройти оценку, нужно свести неожиданные сдвиги макета почти к нулю и дать пользователям стабильный визуальный опыт.
CLS — интересная метрика среди трёх Core Web Vitals, потому что она не строго связана со скоростью или отзывчивостью. Её включение подчёркивает важность оценки не только производительности, но и общего качества пользовательского опыта в вебе.
Все фреймворки набрали 50% и выше по этой метрике. Однако самые молодые фреймворки (Astro, SvelteKit и Remix) показали лучший результат — все три превысили 75% по этой метрике среди протестированных сайтов.
Largest Contentful Paint (LCP)
Largest Contentful Paint (LCP) — последняя из трёх Core Web Vitals и, пожалуй, самая важная для воспринимаемой производительности. Она измеряет момент, когда основной контент страницы, вероятно, загружен. LCP 2,5 секунды или меньше нужен для прохождения CWV Assessment от Google. Всё медленнее считается требующим улучшения и не проходит оценку.
LCP — самая сложная из трёх метрик. Только 52% всех протестированных сайтов проходят её. Из шести фреймворков только Astro и SvelteKit превосходят этот средний показатель. Остальные ниже среднего.
Coming Soon? Interaction to Next Paint (INP)
Interaction to Next Paint (INP) — экспериментальный web vital, оценивающий общую отзывчивость сайта, подобно First Input Delay (FID). Разница в том, что INP наблюдает задержку всех взаимодействий пользователя со страницей, а не только первого. Низкий INP означает, что страница стабильно быстро отвечала на все или большинство взаимодействий пользователя.
Хотя INP сегодня не является официальным core web vital, команда Chrome выразила надежду заменить FID на INP как более целостную и точную меру отзывчивости.
Как фреймворки выглядят по этой новой метрике отзывчивости?
Наиболее заметно, что хороший результат INP намного сложнее достичь каждому фреймворку, чем First Input Delay (FID). Хотя каждый фреймворк показал 80%+ pass rate по FID, ни один не достиг такого же 80% по INP. Astro ближе всех — 68,8% прохождения.
Стоит отметить, что средний pass rate по всем отслеживаемым сайтам удивительно высок — 60,9%. Хотя Astro и WordPress выглядят лидерами на графике выше, эти сайты лишь немного выше среднего по отрасли. Почему многие протестированные фреймворки испытывают трудности с этой метрикой?
Одна из причин — архитектура Single Page App (SPA), где вся навигация идёт через JavaScript на клиенте. Это создаёт возможность input delay, которой нет у Multi-Page Apps (MPA) без клиентской навигации. В MPA переход на новую страницу вызывает полную загрузку с сервера, что не классифицируется как input delay. Это может объяснить, почему Astro и WordPress (два MPA на графике) значительно лучше остальных фреймворков (все SPA) по этой метрике.
Anne Burnes из RebelMouse хорошо описала разницу между FID и INP:
FID quantifies a user’s experience when trying to interact with unresponsive pages, but it only measures the first interaction. According to Google, INP takes a more well-rounded measurement of a site’s responsiveness by covering a site’s entire spectrum of interactions, from the time a page first begins to load until the user leaves a page. This comprehensive measurement makes INP a more reliable indicator of a site’s overall responsiveness than FID.
The holistic nature of INP makes it more challenging to solve than FID, because your code has to be implemented in a way that protects responsiveness for the user during their entire journey, not just on first load. Since many interactions are done through JavaScript, it means your site has to be loaded carefully for optimized performance.
This is particularly difficult on mobile. We took a look at a handful of sites across the industry and within our site network, and found that on mobile INP scores are 35.5% worse than FID on average. When reviewing desktop performance across the same dataset, there was only a 14.1% drop on average.
– Anne Burnes, RebelMouse
Это будет интересная метрика для наблюдения в 2023 году, пока Google рассматривает добавление INP как официального Core Web Vital.
Lighthouse Performance
Lighthouse — ещё один инструмент для измерения пользовательского опыта сайта. HTTP Archive запускает Lighthouse в симулированных условиях мобильной загрузки. Это даёт значительно более детальный и стабильный анализ производительности загрузки страницы с точностью до долей 100 мс. Вместо больших порогов «хорошо» vs «плохо» Lighthouse выдаёт детальный балл производительности из 100.
Реальные пользовательские данные вроде Core Web Vitals по-прежнему лучше отражают реальный опыт, и на некоторых графиках ниже видно, как отличается реальный опыт от лабораторного. Однако из дополнительной детализации Lighthouse можно извлечь полезные выводы. Посмотрим на данные.
Для согласованности мы сохранили исходный порядок из предыдущего раздела. Однако Remix выглядит сильнее по производительности в Lighthouse, чем в CWV Assessment. Одно из объяснений — использование Remix startTransition и requestIdleCallback для отложенной гидратации React при загрузке страницы. Теоретически это может давать лучшую производительность в лабораторных условиях (как Lighthouse) ценой увеличенного first-input delay в реальных сценариях.
К сожалению, медианный балл Lighthouse низок повсюду. У половины фреймворков медианная производительность считалась «плохой» (49 и ниже), у другой половины — «требует улучшения» (50–89). Ни один фреймворк не достиг «хорошего» медианного балла 90+.
Среди всех отслеживаемых сайтов медианный балл производительности — 34/100. В этой связи половина протестированных фреймворков (Astro, SvelteKit и Remix) оказалась выше среднего по интернету.
Разбив данные по перцентилям, можно увидеть чуть более обнадёживающие цифры: Astro и SvelteKit достигают 90+ в p90 или p95. Однако данные ясно показывают, что все сайты и фреймворки (включая Astro) по-прежнему испытывают трудности с хорошей производительностью в реальных условиях.
The Cost of JavaScript
Последнее, что мы хотели изучить — связь между выбором фреймворка, производительностью и общим размером JavaScript payload в реальном использовании. Отправляют ли самые быстрые фреймворки меньше всего JavaScript на клиент?
Тренд в данных очевиден: сайты, отправляющие меньше JavaScript, как правило, работают лучше. Однако слишком много факторов, чтобы уверенно связать этот тренд именно с выбором фреймворка. Возможно, некоторые фреймворки по-разному поощряют или ограничивают JavaScript, но нужны дополнительные исследования, прежде чем делать выводы.
Methodology & Limitations
Отчёт составлен из нескольких публичных наборов данных. Подробнее о наборах данных и методологии: методология HTTP Archive, методология CrUX и методология CWV Technology Report.
Из-за ограничений по объёму анализ охватывает только главные страницы каждого отслеживаемого сайта. Плюс — меньше разброса в назначении и сценариях использования анализируемых сайтов. Минус — внутренние страницы (вроде /about и /admin/...) и используемые на них технологии не анализируются и исключены из анализа.
Ещё одно ограничение, не рассмотренное в отчёте — влияние возраста фреймворка на измеренную веб-производительность. У более старых фреймворков (Gatsby, Next.js, Nuxt) длинный хвост legacy-сайтов на старых версиях, включённых в набор данных. Получается, что только у более новых фреймворков (Astro, Remix, SvelteKit) можно предположить использование современных версий за последние 1–2 года. Это ограничение доступных данных, но мы надеемся исследовать его в будущих отчётах.