Граница между собственными приложениями и веб-сайтами стирается. Google продвигает прогрессивные веб-приложения. Ожидания пользователей растут, в то время как терпимость к задержкам / медлительности падает. В декабре 2016 года использование мобильного Интернета превысило использование настольных компьютеров (http://gs.statcounter.com/press/mobile-and-tablet-internet-usage-exceeds-desktop-for-first-time-worldwide). Несмотря на это, средняя скорость мобильной сети в США составляет около 12 Мбит / с. В пределах этого среднего значения существуют огромные колебания скорости от 1 до 30 Мбит / с - средняя скорость Verizon в сети 3G составляет ничтожные 0,83 Мбит / с.
В то же время кажется, что разработка веб-приложений все дальше отдаляется от конечного пользователя. По сети рассылается мир, далекий от прекрасного кода, над созданием которого мы тратим часы. Приложение в разработке состоит из требуемых модулей, загрузки пакетов, библиотек и фреймворков. Мы мало думаем о HTML, который в конечном итоге отображается на странице пользователя, или о JavaScript, который его создает.
Разработчики могут иногда думать об инструментах связывания модулей, таких как Webpack, как о черном ящике - если он работает, то отлично, а если есть горячая перезагрузка - даже лучше. Учитывая, что большую часть времени мы сидели на рендеринге наших приложений с локального сервера или через оптоволоконный Интернет и на мощных настольных машинах, 3 МБ JS не создают такой проблемы, которая заставит будущего пользователя уйти и никогда не вернуться .
Оптимизация так же привлекательна, как и тестирование, но, к сожалению, не менее важна. Итак, о чем нам нужно думать?
Ознакомьтесь с проектом Google Lighthouse, чтобы узнать, что следует учитывать при оптимизации. Это становится больше искусством, чем наукой, поэтому, вместо фиксированных целей по времени и размеру файла, думайте о загрузке страницы как о пути пользователя:
Это происходит! - начало пути просто подтверждает, что пользователь подключился к вашему серверу и приложение приходит. Если это не происходит раньше, чем через секунду, люди уходят в другое место.
Это полезно! - здесь пользователь начинает потреблять контент, принимает решение о полезности и намерении остаться. Это то, что Lighthouse подразумевает под «Первой осмысленной краской», и это обязательно субъективный показатель. Вы должны учитывать момент, когда нагрузка становится значимой. Цель здесь должна быть от 0,5 до 2 с.
Это можно использовать! - Сайт становится интерактивным. Необходимо не только загрузить и отобразить достаточное количество кода, но и обеспечить достаточную мощность ЦП для обеспечения беспрепятственного взаимодействия с пользователем. Это «Время до интерактивности», и вы должны стремиться менее 5 секунд, а желательно менее 3 секунд.
Имейте в виду, что ваши фактические цели будут зависеть от приложения. Но что бы вы ни выбрали, загрузка должна быть постепенной и прогрессивной. Таким образом, единый монолитный JS, сгенерированный по умолчанию Webpack, никуда не годится. Вместо этого вам нужно будет использовать некоторые дополнительные настройки.
Прежде чем мы рассмотрим более сложные методы оптимизации. Давайте рассмотрим контекст, чтобы заложить основу для повышения производительности вашего приложения. Webpack - это сборщик файлов javascript. Преимущества использования сборщика заключаются в том, что вы можете контролировать, сколько запросов на получение должен выполнить ваш клиент, чтобы загрузить ваше приложение. С помощью Webpack можно объединить несколько ресурсов, файлов, библиотек и даже изображений в один файл, чтобы ваш клиент мог загрузить все ваше приложение в одном запросе на получение, избавляя вашего клиента от необходимости выполнять несколько циклических обращений к серверу.
Как я уже упоминал ранее, Webpack - это черный ящик, который многие разработчики не тратят времени на глубокое понимание. Понятно, что большинство разработчиков и команд хотят сосредоточиться на основных функциях своего приложения. Некоторые команды рассмотрят конфигурацию своего пакета после развертывания и обнаружат, что их пакет содержит мегабайты посторонних библиотек, файлов, изображений и т. Д. Потратьте время на изучение Webpack и постоянную оптимизацию вашего пакета на протяжении всего процесса разработки - это очень мощный инструмент для создания потрясающего пользовательского опыта. Итак, с учетом сказанного, давайте углубимся в сферу понимания Webpack и оптимизации пакетов. Начнем с…
Минификация. Минификация - это процесс удаления всех ненужных символов из источника без изменения его функциональности. Все пробелы, символы новой строки и комментарии удаляются. Некоторые минификаторы также сокращают имена переменных и превращают ваши операторы if else в нескольких строках в один тернарный оператор в одной строке. Все эти аспекты вашего кода используются для удобства чтения, но не имеют никакого значения для компьютера. Минимизация кода - отличный способ убедиться, что размер вашего пакета как можно меньше.
Встряхивание дерева. Встряхивание дерева означает «удаление мертвого кода» в Javascript. Webpack 2 поставляется со встроенной поддержкой модулей ES2105, а также с функцией обнаружения экспорта неиспользуемых модулей. Для всех модулей, которые не были импортированы / использованы, Webpack пометит их как «неиспользованный экспорт гармонии». Функция / модуль будет по-прежнему включаться в комплект, пока вы не используете минификатор, поддерживающий удаление мертвого кода, упомянутый ранее UglifyJSPlugin. Как при минификации, так и при встряхивании дерева наш пакет должен быть на несколько байтов меньше!
Определите, не является ли ваш код доставки неожиданным для пользователей. Используя анализатор пакетов веб-пакетов, вы можете визуализировать свой пакет и размер каждой части вашего пакета. Это позволит вам определить части вашего пакета, которые могли попасть туда, чего вы не ожидали. При масштабной разработке более крупных веб-приложений это становится особенно важным, поскольку вы хотите проверить, что вы или ваши коллеги установили и что требуется в ваших пакетах. Эти визуализации будут отображать каждый файл в вашем пакете и отображать визуальное представление их относительных размеров. Так что вы можете поискать какие-нибудь низко висящие фрукты, которые вы можете достать оттуда.
Очистить CSS. Очистка CSS удаляет неиспользуемые селекторы из вашего CSS. Ваши файлы сценариев и представлений будут сканироваться на предмет классов, а те, которые не используются, будут удалены из CSS.
Разделение кода. Webpack отлично подходит для объединения ваших файлов в один файл js, поэтому клиенту не нужно выполнять несколько HTTP-запросов, чтобы получить все ресурсы, чтобы объединить взаимодействие с пользователем. Клиенту нужно будет выполнить только один HTTP-запрос, чтобы получить все файлы пользовательского интерфейса. Однако это может привести к очень большому размеру пакета. Было бы здорово иметь возможность разделить пакет и загрузить часть его для начала, только то, что необходимо для первоначального взаимодействия с пользователем при последующей загрузке остальных, пока пользователь просматривает исходное представление.
Разделение кода поставщика. Разделение кода поставщика разделяет ваш код поставщика и основные файлы веб-приложения на отдельные пакеты, обычно называемые bundle.js и vendor.js. Например, компоненты React, которые визуализируют ваши представления, будут находиться в bundle.js, отдельно от библиотеки React, Bootstrap и узловых модулей в vendor.js. Разделение вашего кода таким образом заставит пользователя собрать несколько файлов при первоначальном рендеринге вашего приложения, но при каждом последующем рендеринге вашему пользователю нужно будет загрузить только файл bundle.js, только основные файлы, которые формируют ваше приложение. . Библиотеки и модули в vendor.js уже будут кешированы в браузере пользователя. Такое разделение пакета позволяет приложению достичь безумно быстрой загрузки.
Реагирование на разделение кода маршрутизатора. Другой способ разделения кода - это разделение кода между разными маршрутами. Если вы используете React и React Router, это еще одна оптимизация производительности, которую вы можете рассмотреть. Этот метод дополнительно разделит ваш пакет, по одному файлу для каждого маршрута. Клиент будет выполнять запрос «получить» только для контента, необходимого для рендеринга представления, по которому перемещается пользователь. Если у вас небольшое приложение, не нужно переусердствовать и разделять приложение на каждом маршруте. Однако, если ваше приложение большое, разделение кода React Router дополнительно минимизирует то, что отправляется клиенту с каждым запросом на получение, что обеспечивает практически беспроблемный пользовательский интерфейс.
Автоматическое сжатие изображений. Используйте плагин image-webpack-loader для автоматического сжатия изображений. Кроме того, если ваши изображения достаточно малы, вы можете использовать «url-loader», чтобы дать вам возможность кодировать ваши изображения как строку base 64 и включать изображение в bundle.js как необработанные данные. Определенно есть некоторый прирост производительности за счет включения изображений в ваш пакет. Точно так же url-loader обрабатывает большие изображения, включая их в выходной каталог. Хотя это может добавить дополнительный запрос на получение, большое изображение будет отставать от первоначального рендеринга представления, если оно будет связано со всем остальным.
Посмотрите, что находится в вашем пакете. Возможно, самая большая оптимизация производительности, которую вы можете сделать для вашего пакета, - это удалить из него ненужные файлы. Вы можете сделать это, визуализировав свой пакет в одном из немногих анализаторов пакетов webpack, например webpack-bundle-analyzer. Обычно с помощью этих инструментов вам нужно будет экспортировать файл stats.json вашего Webpack. Вы можете сделать это, запустив «webpack - json› stats.json »в своем терминале. Затем импортируйте файл stats.json в инструмент визуализации, и он визуализирует визуализацию вашего пакета. Просмотр этой визуализации позволит вам принять решение, какие файлы оставить, а какие удалить. Вы обнаружили, что у вас установлен дополнительный lodash или d3? Удалите это, и вы значительно повысите производительность своего приложения.
Веб-производительность - это постоянный процесс улучшения. Так же, как ваши веб-приложения будут постоянно улучшаться, вам необходимо постоянно следить за производительностью и учитывать ее. Постоянно отслеживайте размер и структуру пакета веб-пакетов, и постоянное внесение корректировок при каждой итерации вашего приложения является ключом к созданию отличного пользовательского опыта.
