Производительность в Web — большая и сложная тема. В этой статье мы ее сузим до обсуждения JavaScript-фреймоврков для фронтенда и как использование одного из них может повлиять на производительность вашего приложения. В частности, мы рассмотрим две вещи: (1) сколько у фреймворка займет обновление интерфейса пользователя и (2) время, необходимое для скачивания и анализа пакетов, необходимых для функциональности фреймворка.
Уже пару лет моим ресурсом подобных данных является js-framework-benchmark от Stefan Krause. Ресурс хороший, но несколько сложный. Посмотреть подборку результатов легче, и именно это мы и сделаем в данной статье. Я вам советую обратить внимание на инструменты, которые создал Стефан, и самостоятельно углубиться в данные, особенно если ваш любимый фреймворк здесь не упомянут. Он может быть доступен на сайте Стефана (там протестировано больше 40 фреймворков).
Также, краткое предупреждение:
Эти данные не окончательные, поэтому пользуйтесь ими с осторожностью (например, они могут отличаться в разных версиях браузера).
Помня об этом предупреждении,
Давайте посмотрим на цифры
Первая группа результатов будет касаться того, сколько времени у каждого фреймворка занимают различные операции из большой таблицы – создание строк, их удаление и т. д. Также обращаю ваше внимание, что это «скрепленные» результаты, с ключом. Вот объяснение с сайта Стефана:
«Скрепленные» реализации создают ассоциацию между данными домена и dom-элемента с помощью «ключа». Если данные изменяются, dom-элемент и этим ключом будет обновлен. Вследствие вставки или удаления элемента в массиве данных происходят соответствующие изменения в dom.
В таблице, расположенной ниже, чем больше цифра, тем медленнее фреймворк справляется с задачей. В нижнем ряду значение «slowdown geometric mean» является показателем общей производительности, по которому фреймворки и расставлены, слева направо. Самый левый – «vanillajs» – означает отсутствие фреймворка и служит в качестве контрольной точки.
Как вы видите, я включил большинство популярных фреймворков, а также пару менее известных, но вызывающих интерес. У Preact (который отличается популярностью) и Inferno есть APIs, очень сходные с React, поэтому я их и включил. Они могут быть хорошим выбором, если вы в команде, использующей React, но строите приложение, для которого производительность в приоритете. Заметьте, что «скрепленные» ключами результаты обычно будут более медленными, поскольку фреймворку приходится выполнять больше работы.
Среди самых популярных фреймворков Vue выглядит чертовски хорошо. Angular и React заметно медленнее, но между собой показывают очень близкие результаты. Библиотека Inferno, однако, выделяется из группы. Кстати сказать, автор Inferno, Dominic Gannaway, недавно устроился в Facebook чтобы работать в React-команде.
А теперь давайте посмотрим на результаты без ключей:
Есть несколько моментов, на которые стоит обратить внимание. Прежде всего, мы видим, что здесь перечислено меньше фреймворков, так как результаты без ключей доступны не для каждого фреймворка. Мы также замечаем, что результаты немного смешались.
Vue в этой группе медленнее всех, а Angular – самый быстрый из популярных фреймворков. Быстрее всех оказался Svelte, интересный фреймворк с другим подходом – вам действительно стоит взглянуть на него.
Прежде чем мы двинемся дальше, я проявил бы невнимательность, если бы не упомянул фреймворк, который побил все остальные, – Surplus от Адама Хейла. Он победил в обоих тестах, с ключами и без. Есть много других, также показавших себя хорошо, включая petit-dom и dio. Я не включил их в эти таблицы, потому что хотел оставить больше места для самых популярных библиотек/фреймворков. Если вы обратитесь к таблице результатов, вы увидите, что она быстро становится слишком большой и требуется некоторая подгонка, чтобы иметь возможность применить ее для наших целей.
Startup Metrics
Результаты, показанные выше, касаются того, насколько быстрыми оказались фреймворки в полной загрузке страницы и выполнении операций из большой таблицы. Следующий набор дает нам возможность посмотреть на вещи под другим углом, оценив время скачивания, анализа и компиляции.
Эти измерения говорят нам, как долго приходится ждать пользователю прежде чем загружаемая им страница становится функциональной. В общих чертах, чем больше JavaScript вы загружаете, тем больше времени это занимает и тем больше кода браузер должен проанализировать и скомпилировать.
И снова эти результаты разбиты на группы с ключами и без. Начнем с «ключевых».
У этих измерений нет одного удобного значения, по которому они ранжируются, но в целом зеленый это хорошо, а красный – плохо. И снова Inferno выглядит достойно, так же как Svelte и Preact. Среди наиболее популярных фреймворков Vue имеет лучшую производительность, а Ember выглядит немного покрасневшим в конце списка.
А теперь давайте посмотрим на результаты без ключей.
В этой группе Svelte производит впечатление действительно быстрого и легковесного. Показатель «total byte weight» меньше, чем у vanilla JavaScript! А я говорил, что это интересный фреймворк!
Финальные размышления
Идея написать эту статью пришла ко мне примерно месяц назад, когда я прочитал «The Cost of JavaScript» Эдди Османи. Там он поделился графиком, который особенно привлек мое внимание. Он показывал, сколько времени занимает анализ gzip-пакета JavaScript весом в 250КВ (1МВ в разархивированном состоянии) на различных мобильных устройствах (выделен средний телефон). Вот этот график:
Как я уже упоминал ранее, я уже некоторое время слежу за испытаниями, проводимыми Стефаном, и я немедленно связал его работу со статьей Эдди. Когда производительность для нас становится приоритетной, мы чаще всего думаем о мобильных девайсах. Эти устройства зачастую имеют меньше возможностей, чем многие думают. Говоря «многие», я имею в виду себя и кучу других людей.
Фронтенд JavaScript фреймворки – впечатляющее достижение инженерии. Они сложны, и сделать их хорошо – непросто. Также иногда непросто выбрать, какой именно фреймворк использовать для конкретного проекта. Нужно обдумать и взвесить много аспектов.
Например, фреймворк, подобный React, имеет огромную экосистему, которая может ускорить ваш проект с помощью множества сторонних библиотек. Кроме того, среди преимуществ окажется изобилие обучающих ресурсов. Но является ли он лучшим выбором для проекта, рассчитанного на пользователей 2G-сетей? Пожалуй, нет.
Решение, какой фреймворк подойдет лучше всего, очень зависит от требований проекта и команды, которая его создает. Надеюсь, что результаты, освещенные здесь, дадут вам некоторую пищу для размышлений.
***
Подписывайтесь на наш канал в Telegram!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]