Как оптимизировать время сборки webpack с помощью инструмента prefetchPlugin & analysis?

Предыдущее исследование:

Как говорит webpack wiki, для оптимизации производительности сборки можно использовать инструмент анализа:

from: https://github.com/webpack/docs/wiki/build-performance#hints-from-build-stats

Советы по построению статистики

Существует инструмент анализа, который визуализирует вашу сборку, а также обеспечивает некоторые подсказки, как можно оптимизировать размер сборки и производительность сборки.

Вы можете создать требуемый файл JSON, запустив webpack -profile --json > stats.json

Я создаю файл статистики (который можно найти здесь) загрузили его в инструмент анализа webpack и вкладку "Подсказки" Я сказал использовать prefetchPlugin:

from: http://webpack.github.io/analyse/#hints

Длинные цепи сборки модулей

Используйте предварительную выборку, чтобы увеличить производительность сборки. Предварительно выберите модуль из середины цепочки.

Я выкопал сеть наизнанку, чтобы найти единственную документацию, доступную на prefechPlugin, это:

from: https://webpack.github.io/docs/list-of-plugins.html#prefetchplugin

PrefetchPlugin

new webpack.PrefetchPlugin([context], request)

Запрос на нормальный модуль, который разрешен и построен еще до a требует этого. Это может повысить производительность. Попробовать профиль сначала создайте, чтобы определить умные точки предварительной выборки.

Мои вопросы:

Как правильно использовать prefetchPlugin?
Каков правильный рабочий процесс для использования с инструментом анализа?
Как узнать, работает ли prefetchPlugin? как я могу его измерить?
Что означает предварительная выборка модуля из середины цепочки?

Я действительно буду признателен за некоторые примеры

Пожалуйста, помогите мне сделать этот вопрос ценным ресурсом для следующего разработчика, который хочет использовать инструменты prefechPlugin и Analyze. Спасибо.

Ответ 1

Да, документация по плагину предварительного чтения практически не существует. Выяснив это для себя, он довольно прост в использовании, и там нет большой гибкости. В принципе, он принимает два аргумента, контекст (необязательный) и путь к модулю (относительно контекста). Контекст в вашем случае был бы /absolute/path/to/your/project/node_modules/react-transform-har/, предполагая, что тильда на скриншоте относится к node_modules в соответствии с разрешением webpack node_module.

Фактический модуль предварительной выборки должен быть в идеале не более трех зависимостей модулей. Таким образом, в вашем случае isFunction.js есть модуль с длинной цепью сборки, и в идеале он должен быть предварительно выбран в getNative.js

Однако, я подозреваю, что в вашем конфиге есть что-то напуганное, потому что ваши зависимости от цепочки ссылок относятся к зависимостям модулей, которые должны автоматически оптимизироваться с помощью webpack. Я не уверен, как вы это получили, но в нашем случае мы не видим никаких предупреждений о длинных цепочках сборки в node_modules. Большинство наших длинных цепочек сборки связаны с глубоко вложенными компонентами реакции, которые требуют scss. то есть:

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

plugins: [
    new webpack.PrefetchPlugin('/web/', 'app/modules/HeaderNav.jsx'),
    new webpack.PrefetchPlugin('/web/', 'app/pages/FrontPage.jsx')
];

Второй аргумент должен быть строкой для относительного расположения модуля. Надеюсь, это имеет смысл.

Ответ 2

Середина вашей цепи, вероятно, react-transform-hmr/index.js, поскольку она начинается примерно на полпути. Вы можете попробовать PrefetchPlugin('react-transform-hmr/index') и повторно запустить свой профиль, чтобы узнать, помогает ли оно ускорить ваше общее время для сборки.