Сказать, что существует довольно много JS-фреймворков на выбор, было бы преуменьшением.

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

Дошло до того, что нам почти нужен фреймворк для выбора нашего следующего фреймворка (Йо Дог).

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

Фронтенд-разработчик ищет новый фреймворк javascript

Новые фреймворки часто привносят инновации в экосистему JS. Это может быть связано с тем, как мы создаем приложения и/или насколько они эффективны.

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

Но теперь забавный вопрос — действительно ли существует такая большая разница в производительности в разных фреймворках? Это вопрос, на который мы хотели ответить.

Однако, как гласит довольно жуткая поговорка: «С кота можно содрать шкуру не одним способом» 🙀

Поскольку заголовок этого поста мог уже испортиться, мы решили проверить, какой фреймворк был самым быстрым, когда дело дошло до SSR — рендеринга на стороне сервера.

Результаты были интересными, но, как и в Формуле 1, часто миллисекунды отделяли хорошее от отличного.

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


🔔 ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ — ВАШ ПРОБЕГ МОЖЕТ ИЗМЕНЯТЬСЯ!

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

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

Если вы считаете, что что-то могло быть по-другому и/или лучше, оставьте комментарий или отправьте нам электронное письмо по адресу info@enterspeed.com. Исходный код каждой демонстрации можно найти в нашем демо-репозитории:


Знакомьтесь с 6 участниками

Шесть участников, которых мы выбрали, представляют собой смесь некоторых из самых популярных фреймворков и некоторых из более новых, более разрекламированных.

Мы протестировали следующие фреймворки:

  • Астро: 18,2 тыс. звезд на Github, создано в марте 2021 г.
  • Гэтсби: 53,4 тыс. звезд на Github, создано в мае 2015 г.
  • Next.js: 91,8 тыс. звезд на Github, создано в октябре 2016 г.
  • 3: 8,7 тыс. звезд на Github, создано в марте 2021 г.
  • Ремикс: 19 тысяч звезд на Github, создано в октябре 2020 г.
  • SvelteKit: 10,1 тыс. звезд на Github, создано в октябре 2020 г.

Все 6 фреймворков были настроены с использованием SSR.


Что такое ССР?

SSR означает рендеринг на стороне сервера и представляет собой стратегию рендеринга, которая преобразует ваше приложение в HTML на сервере.

Некоторые другие стратегии рендеринга:

  • CSR — рендеринг на стороне клиента, который рендерится в браузере.
  • SSG — генерация статического сайта, которая генерирует HTML при сборке (и, следовательно, извлекает данные только один раз).
  • ISR — добавочная статическая регенерация, представляющая собой комбинацию SSG и SSR, которая позволяет создавать или обновлять статические страницы после того, как вы создали свой сайт.

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


Что мы строим

Скриншот одной из демонстраций<br />» loading=»lazy» width=»880″ height=»968″/></a></p><p>Наш демонстрационный сайт, который мы воспроизвели для каждого фреймворка, представляет собой <strong>красивая</strong> блог, содержащий 6 сообщений в блоге.</p><p>Он использует Tailwind для стилизации и извлекает содержимое из Enterspeed (высокопроизводительного хранилища данных).</p><p>Бонусная информация — все миниатюры были сгенерированы с использованием <a rel=Из Е 2 с этими фразами:

  • «Кошка за рулем автомобиля Формулы-1, цифровое искусство»
  • «Лама летит на истребителе, пиксель-арт»
  • «Крутая, бесстрашная пчела на мотоцикле»
  • «Сокол, летящий по космосу в фотореалистичном стиле»
  • «Человек, обгоняющий гепарда, цифровое искусство»
  • «Фото плюшевого мишки на ракете»

Все демонстрации общедоступны и размещены на Netlify:

Репозиторий GitHub для всех демонстраций можно найти здесь:


Что мы измеряли и как

Для измерения производительности SSR наших фреймворков JS мы использовали Google Lighthouse (здесь Web.dev/мера). Каждый аудит мы проводили 5 раз и рассчитывали среднее значение для каждой метрики.

💡 Объяснение каждой метрики (и аббревиатуры) будет приведено ниже.

Google Lighthouse измеряет основные веб-жизненные показатели (LCP, FID, CLS), которые стали фактором ранжирования в алгоритме поиска Google, а также другие веб-жизненные показатели (FCP, индекс скорости, TTI, TBT и CLS).

Мы не измеряли FID (First Input Delay), так как это невозможно измерить в лаборатории. Однако TBT (общее время блокировки) хорошо коррелирует с FID в полевых условиях.

CLS (Cumulative Layout Shift) также не включен в результаты, так как все демонстрации получили 0 баллов в этой категории.

Наконец, мы хотели измерить TTFB (время до первого байта), так как это может помочь измерить скорость отклика веб-сервера, что очень важно, когда речь идет о SSR.

Для измерения TTFB мы использовали Приветгде мы отправляем по 250 запросов на каждое демо и измеряем среднее значение TTFB.

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

Мы также решили сократить количество одновременных воркеров с 50 до 1, поскольку наше приложение Nuxt 3 продолжало падать при отправке нескольких запросов.


Что означает каждый показатель?

Все показатели (кроме TTFB) основаны на инициативе Google: Веб-жизненные показатели. Google создал эти показатели, чтобы предоставить унифицированное руководство по качественным сигналам.

✂️ Пояснения заимствованы из Web.dev


Оценка производительности Google Lighthouse

Оценка производительности в Google Lighthouse представляет собой оценку от 0 до 100. Это средневзвешенная оценка Web Vitals. Каждый Web Vital взвешивается следующим образом:

  • Первая содержательная краска: 10%
  • Индекс скорости: 10%
  • Самая большая содержательная краска: 25%
  • Время до интерактивности: 10%
  • Общее время блокировки: 30%
  • Совокупный сдвиг макета: 15%

Оценка производительности сгруппирована по трем категориям («Плохо», «Требует улучшения» и «Хорошо»): «Требуется улучшение»,

  • от 0 до 49 (красный): плохо
  • От 50 до 89 (оранжевый): нуждается в улучшении
  • от 90 до 100 (зеленый): хорошо

Примечание. Набрать «отлично» 100 баллов чрезвычайно сложно, и этого не следует ожидать.


Первая содержательная краска (FCP)

Метрика First Contentful Paint (FCP) измеряет время с момента начала загрузки страницы до момента отображения какой-либо части содержимого страницы на экране.


Индекс скорости

Индекс скорости измеряет, насколько быстро контент визуально отображается во время загрузки страницы.


Самая большая содержательная краска (LCP)

Метрика Largest Contentful Paint (LCP) сообщает о времени рендеринга самого большого изображение или текстовый блок видны в области просмотра, относительно того, когда страница сначала начал загружаться.


Время до интерактивности (TTI)

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


Общее время блокировки (TBT)

Метрика «Общее время блокировки» (TBT) измеряет общее количество времени между первой отрисовкой контента (FCP) и временем до взаимодействия (TTI), когда основной поток был заблокирован достаточно долго, чтобы предотвратить реакцию ввода.


Время до первого байта (TTFB)

TTFB — это метрика, которая измеряет время между запросом ресурса и началом поступления первого байта ответа.


Результаты, достижения

Барабанная дробь, пожалуйста… Результаты приведены ниже.


Оценка производительности Google Lighthouse

1. 🏆 Астро — 99,2

  1. СвелтеКит — 99

  2. Nuxt 3 и ремикс — 98,8

  3. Next.js — 98,6

  4. Гэтсби — 95,6


Первая содержательная краска (FCP)

1. 🏆 Астро, Гэтсби и Ремикс — 0,8с

  1. Next.js и SvelteKit — 0,9

  2. Нуст 3 — 1,1


Индекс скорости

1. 🏆 SvelteKit — 2,3с

  1. Астро и Ремикс — 2,8с

  2. Нуст 3 — 2,9с

  3. Next.js — 3,2 с

  4. Гэтсби — 5,6 с


Самая большая содержательная краска (LCP)

1. 🏆 Астро — 0,8 с

  1. СвелтеКит — 0,9с

  2. Next.js, Nuxt 3, ремикс — 1,2 с

  3. Гэтсби — 1,9с


Время до интерактивности (TTI)

1. 🏆 Астро — 0,8 с

  1. SvelteKit — 1.0s

  2. Нуст 3 — 1,2с

  3. Ремикс и Гэтсби — 1,5 секунды

  4. Next.js — 1,7 с


Общее время блокировки (TBT)

1. 🏆 Астро — 0 мс

  1. Следующий 3 – 20 мс

  2. Гэтсби — 28 мс

  3. Ремикс — 30 мс

  4. SvelteKit — 36 мс

  5. Next.js — 54 мс


Время до первого байта (TTFB)

1. 🏆 SvelteKit — 62 мс

  1. Next.js — 63 мс

  2. Гэтсби — 133 мс

  3. Ремикс — 136 мс

  4. Астро — 137 мс

  5. Нуст — 438 мс


Вывод

Разъяренная толпа JS-фреймворков

Теперь, прежде чем вы начнете сжигать это место, вспомните, что мы говорили в начале — ваш пробег может отличаться!

Основываясь на наших результатах, кажется, что Astro действительно новый и быстрый ребенок в классе, хотя и не так сильно в TTFB.

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

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

Означает ли это, что вам следует пропустить другие фреймворки и выбрать один из этих двух? Точно нет.

Каждый фреймворк имеет свой вариант использования и свои преимущества. Лично мы большие поклонники всех фантастических функций, которые предоставляет Next.js.

Более того, многие люди используют комбинацию стратегий рендеринга, например, SSG для своей домашней страницы, SSR/ISR для своих страниц блога и так далее.

Поэтому выберите фреймворк, который лучше всего соответствует вашим потребностям.

🩸🔥 Кровь еще кипит и нужно успокоиться? Не волнуйся, мы получили тебя.


Что такое Энтерспид? 🏎

Энтерскорость — это высокопроизводительное хранилище данных, позволяющее повысить скорость и гибкость за счет объединения ваших услуг.

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

Enterspeed используется в этой статье, чтобы обеспечить высокую и стабильную производительность уровня данных (сообщений в блоге) во всех тестах.