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

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

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

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

Мера

Эта лаборатория кода уже содержит приложение, включенное в веб-пакет.

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

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

Вывод веб-пакета показывает размер пакета 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"
  }
};

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

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

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

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

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

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

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

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

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

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

В приложении/компоненты/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 может гарантировать, что вы всегда будете осведомлены о последствиях для производительности.