Почему решение замедлить работу веб-приложений - это не более сложный набор инструментов
Некоторое время назад я работал над приложением Angular. Что меня поразило, так это то, что Angular на самом деле не просто фреймворк, это скорее целая платформа, построенная поверх веб-платформы. Причина в том, чтобы дать разработчикам унифицированный способ создания приложений для разных платформ. Но какова стоимость использования этой абстракции?
Для вас, как веб-разработчика, это означает, что для большинства вещей, которые вы умеете делать в Интернете, существует (немного) другая версия выполнения этого в Angular. Это также означает, что у вас нет прямого доступа к новым веб-технологиям по мере их появления, вам нужно дождаться, пока команда Angular добавит для них поддержку. Поддержка ServiceWorker - хороший тому пример.
Возможно, самое главное, это означает, что между кодом вашего приложения и браузером, работающим на платформе Angular, неизбежно будет существовать уровень JavaScript. Как это влияет на производительность?
Angular уделял большое внимание производительности в Angular 2 и последующих выпусках. Производительность создает модульную архитектуру, опережающий компилятор (AOT) и предварительный рендеринг. Однако при написании приложения Angular я не мог избавиться от ощущения, что я мог бы создать такое же компонентное приложение с использованием веб-компонентов и запустить его прямо в браузере. Неужто так будет быстрее?
Можем ли мы сделать вещи проще… и быстрее?
Я получил поддержку своей идеи на саммите разработчиков Chrome, когда слушал Алекса Рассела, который очень самоуверенно говорил о производительности веб-приложений. Он пошел еще дальше, заявив, что если вы используете фреймворк, вы по умолчанию терпите неудачу, когда дело касается производительности. Фреймворки ориентированы на разработчиков, часто за счет конечных пользователей. Разработчику необходимо сознательно работать (иногда вокруг фреймворка), чтобы обеспечить быстрое взаимодействие с пользователями. Я встретился с Алексом после его выступления, и у нас был интересный разговор о том, как эти проблемы усугубляются в реальных устройствах и сетях.
В этот момент я был заинтригован и хотел посмотреть, смогу ли я воссоздать Angular только с помощью Polymer, и будет ли это приложение быстрее, чем оптимизированное приложение Angular.
Чтобы сосредоточить внимание, я разделил свои выводы на два поста. В этом первом посте будет рассмотрен мой первоначальный вопрос: можно ли использовать веб-компоненты для ускорения работы в Интернете с меньшим количеством инструментов? Во второй части мы рассмотрим реальный опыт разработчиков при создании приложения этими двумя способами и способы их улучшения.
Приложения и апельсины
Некоторые из вас могут подумать, что сравнение Angular, фреймворка, с Polymer, библиотекой, немного похоже на сравнение яблок и апельсинов. В конце концов, один предназначен для создания приложений, а другой занимается только сборкой компонентов.
Что ж, как оказалось, вы создаете приложения из компонентов, комбинируя более мелкие компоненты во все более и более сложные композиции, пока не получите приложение. Итак, чтобы создать приложение на основе компонентов, все, что вам нужно, - это способ создания компонентов.
И Angular, и Polymer поставляются со своим собственным набором инструментов, чтобы помочь разработчикам. В частности, оба включают инструмент командной строки (CLI), который можно использовать для начальной загрузки новых проектов и создания приложения для развертывания. Polymer также включает в себя некоторые фреймворки, такие как поддержка маршрутизации.
Моя тестовая установка
Чтобы сравнить два подхода к созданию приложений, мне нужно было создать одно и то же приложение с обоими. Приложение, которое я разработал, представляет собой фиктивный список приложений портала и показывает статистику для пациентов. Он состоит из трех представлений: 1) представления входа в систему, 2) представления списка с редактированием основных / подробных данных и 3) представления аналитики, показывающего данные диаграммы.
Приложение Angular использует Kendo Grid и Charts в дополнение к основному фреймворку Angular. Приложение Polymer, в свою очередь, использует Vaadin Grid и Charts. Хотя компоненты не идентичны, они достаточно близки по сложности и функциональности, чтобы работать для этого сравнения.
Я создал приложения, следуя инструкциям для производственных сборок. Для Angular 2 это означало использование опережающей компиляции (AOT) и режима производства в сборке (ng build --aot --prod). Для Polymer я использовал polymer build для создания объединенной сборки (объединение зависимостей в как можно меньшее количество файлов). Оба приложения использовали отложенную загрузку зависимостей для каждого представления. В процессе сборки приложения Polymer дополнительно был создан Service Worker, который предварительно загружает последующие представления в кеш, пока пользователь входит в систему.
Оба приложения обслуживались с включенным Gzip и обменивались данными с одним и тем же REST API, размещенным на localhost. Чтобы получить более реалистичные измерения, я использовал моделирование «Хорошего 3G» соединения с «Высокопроизводительным устройством» в Chrome Dev Tools.
Все тесты я проводил с Chrome. Я также провел сравнительный тест на webpagetest.org с версиями, развернутыми на страницах GitHub.
Как быстро эта штука идет?
С точки зрения начальной скорости загрузки был явный победитель. Приложение на основе полимера было визуально завершено и готово к работе всего за 0,8 секунды. Приложение Angular заняло колоссальные 4 секунды, чтобы завершить работу (4,8 секунды). Для начальной загрузки Polymer был в 6 раз быстрее, чем Angular.
Почему это? Даже с компиляцией AOT Angular 2 имеет два явных недостатка по сравнению с Polymer. Во-первых, поскольку все написано на JavaScript, его необходимо загрузить, проанализировать и оценить, прежде чем что-либо будет показано пользователю. Polymer, с другой стороны, может использовать встроенные в браузер возможности потоковой передачи, чтобы отображать приложение во время его загрузки. Во-вторых, веб-компоненты - это конструкции, встроенные в браузер. Независимо от того, насколько оптимизирован JS, который выводит Angular, некоторые вещи просто быстрее запускаются непосредственно в самом браузере.
Для начальной загрузки Polymer был в 6 раз быстрее, чем Angular.
При последующих загрузках страниц разница будет гораздо менее существенной. Есть некоторые различия, но я подозреваю, что они в основном сводятся к компонентам, используемым на этих страницах (диаграммы и сетка данных), чем к используемой технологии. В таблице ниже приведены результаты измерений производительности для всего приложения.
Интересно, что приложение загружается быстрее при использовании Safari и полифилла веб-компонентов:
Оба приложения были примерно одинакового размера с точки зрения загрузки (Polymer: 630kB, Angular: 689kB) и строк кода (Polymer: 1999 строк, Angular: 1953 строк).
Полный тест можно найти здесь.
Так что насчет предварительного рендеринга?
Я мог бы использовать предварительный рендеринг в приложении Angular, чтобы улучшить воспринимаемую скорость. Я говорю «воспринимаемая», потому что, хотя предварительный рендеринг позволяет пользователю увидеть (точную оценку) готовой страницы намного быстрее, добавленная сложность может фактически замедлить интерактивность страницы. Пока скрипты загружаются, страница выглядит завершенной, но ничего не происходит, когда пользователь пытается взаимодействовать со страницей.
Есть и другие причины, такие как SEO, по которым вы можете захотеть выполнить предварительный рендеринг, но что касается производительности, я хотел сосредоточиться на том, сколько времени требуется, чтобы привести приложение в рабочее состояние.
Следует отметить, что Polymer не поддерживает предварительный рендеринг. Вместо этого команда Polymer выступает за использование PRPL-шаблона для достижения скорости, сравнимой с предварительным рендерингом, без дополнительной сложности запуска приложения как на сервере, так и в браузере.
Выводы
Веб-компоненты работают быстро. Для начальной загрузки мне удалось добиться увеличения скорости в 6 раз по сравнению с тем же приложением, реализованным в Angular. И мне удалось добиться этого ускорения с помощью гораздо более простого набора инструментов - без компиляции AOT, без предварительного рендеринга.
Но остается еще один вопрос - можно ли создавать настоящие сложные приложения, используя только веб-компоненты? Для нас не очень хорошо то, что веб-компоненты работают быстро, если мы не можем использовать их для создания приложений. Сила Frameworks заключается в структуре, которую они предлагают, чтобы помочь разработчикам создавать большие поддерживаемые приложения. Это то, чего вообще не предлагают Polymer или веб-компоненты.
Во второй части этой статьи я расскажу об опыте разработчиков при создании этих приложений и о том, что мы могли бы сделать, чтобы облегчить разработчикам создание невероятно быстрых веб-интерфейсов.
Исходники обоих приложений размещены на GitHub:
Первоначально опубликовано на vaadin.com.
