Настройка бюджетов производительности с помощью веб-пакета

Милица Михайлия
Milica Mihajlija

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

Чтобы увидеть это в действии, вот приложение, которое считает дни до Нового года. Оно создано на React и moment.js . (Как и реальные приложения, которые всё больше полагаются на фреймворки и библиотеки. 😉)

Приложение, которое считает дни, оставшиеся до Нового года

Мера

В этой лабораторной работе уже содержится приложение, связанное с Webpack.

  1. Нажмите «Ремикс для редактирования», чтобы сделать проект редактируемым.
  2. Нажмите «Терминал» (примечание: если кнопка «Терминал» не отображается, возможно, придется использовать опцию «Полноэкранный режим»).
  3. Чтобы получить цветовой список ресурсов и их размеров, введите в консоли webpack .
webpack

Основной пакет выделен желтым цветом, поскольку его размер превышает 244 КБ (250 КБ).

Вывод Webpack показывает размер пакета 323 КБ
Webpack предупреждает о громоздком JS-пакете ⚠️

Эти предупреждения включены по умолчанию в режиме производства , а пороговое значение по умолчанию составляет 244 КБ в несжатом виде как для активов, так и для точек входа (комбинация всех активов, используемых во время первоначальной загрузки страницы).

Предупреждение Webpack о том, что размер актива превышает рекомендуемый предел
Webpack предупреждает о громоздком JS-пакете ⚠️

Webpack не только предупредит вас, но и предоставит рекомендации по уменьшению размера пакетов. Подробнее о рекомендуемых методах можно узнать на сайте Web Fundamentals .

Рекомендации по оптимизации производительности Webpack
Рекомендации по оптимизации производительности Webpack 💁

Установите индивидуальный бюджет производительности

Подходящий бюджет производительности будет зависеть от характера вашего проекта. Всегда лучше провести собственное исследование . Хорошее практическое правило — предоставлять не более 170 КБ сжатых/минифицированных ресурсов критического пути .

Для этой простой демонстрации попробуйте действовать ещё более консервативно и установите бюджет в 100 КБ (97,7 КиБ). В webpack.config.js добавьте следующее:

module.exports = {
  //...
  performance: {
    maxAssetSize: 100000,
    maxEntrypointSize: 100000,
    hints: "warning"
  }
};

Новый бюджет производительности задается в байтах :

  • 100000 байт для отдельных активов (maxAssetSize)
  • 100000 байт для точки входа (maxEntrypointSize)

В этом случае есть только один пакет, который также служит точкой входа.

Возможные значения подсказок :

  1. warning (по умолчанию): отображает жёлтое предупреждение, но сборка проходит успешно. Рекомендуется использовать в средах разработки.
  2. error : отображает красное сообщение об ошибке, но сборка всё равно выполняется. Этот параметр рекомендуется для производственных сборок.
  3. false : предупреждения и ошибки не отображаются.
Ошибка производительности Webpack выделена красным шрифтом
Подсказка о производительности Webpack "ошибка" 🚨

Оптимизировать

Цель бюджета производительности — предупредить вас о проблемах с производительностью до того, как их станет слишком сложно исправить. Всегда существует несколько способов создания приложения, и некоторые методы помогут ускорить загрузку. (Многие из них описаны здесь, в разделе «Оптимизация JavaScript» . 🤓)

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

В реальном мире крупные клиентские фреймворки обычно сложно заменить, поэтому важно использовать их с умом. Немного поискав, можно найти более компактные альтернативы популярным библиотекам, которые справляются с задачей не хуже ( например, date-fns — хорошая альтернатива moment.js ). Иногда разумнее вообще не использовать фреймворк или библиотеку, если это существенно влияет на производительность.

Удаление неиспользуемого кода — хороший способ оптимизировать приложения, содержащие большие сторонние библиотеки. В руководстве «Удаление неиспользуемого кода» подробно описан этот процесс, а ниже представлен быстрый способ переписать код обратного отсчёта без использования moment.js.

В app/components/Countdown.jsx удалите:

const today = moment();
const yearEnd = moment().endOf('year');
const daysLeft = yearEnd.diff(today, 'days');

И удалите эту строку:

const moment = require('moment');

Это потребует немного математики, но вы можете реализовать тот же обратный отсчет с помощью обычного JavaScript:

const today = new Date();
const year = today.getFullYear();
const yearEnd = new Date(year,11,31); //months are zero indexed in JS
const timeDiff = Math.abs(yearEnd.getTime() - today.getTime());
const daysLeft = Math.ceil(timeDiff / (1000 * 3600 * 24));

Теперь удалите moment.js из package.json и снова запустите webpack в консоли, чтобы собрать оптимизированный пакет.

Та-да! Вы сэкономили 223 КБ (230 КБ), и приложение укладывается в бюджет.🎉

Размер выходного пакета Webpack после оптимизации составляет 97,7 КБ.

Монитор

Настройка бюджета производительности в Webpack занимает всего пару строк кода, и система предупредит вас, если вы (случайно) добавите крупную зависимость. Как говорится, «с глаз долой — из сердца вон», но Webpack всегда будет держать вас в курсе влияния на производительность.