Подпакет CacheGroups webpack4 [полное значение]

Webpack
Подпакет CacheGroups webpack4 [полное значение]

последовательность

Недавно, столкнувшись с упаковкой проекта, я написал статью. Для того, чтобы поделиться, все приобретается.

помещение

Есть два предварительных условия, которые требуют вашего одобрения:

  1. [Система управления Backstage] Самая сильная комбинация фреймворка и библиотеки компонентов пользовательского интерфейса — это vue-element-admin + Element UI! (●'◡'●)

  2. Основная функция webpack4 — это [splitChunks], а основная конфигурация splitChunks — это cacheGroups!

Исходя из этих двух предпосылок, мы переходим к следующему шагу.

инструмент для анализа

Для анализа упаковки webpack достаточно:webpack-bundle-analyzer

  • Установить
npm install --save-dev webpack-bundle-analyzer
  • Конфигурация: поскольку vue-element-admin основан на vueCli4, он устанавливается в vue.config.js chainWebpack.
 config.plugin('BundleAnalyzerPlugin').use(BundleAnalyzerPlugin).tap(() => [
      {
        rel: 'BundleAnalyzerPlugin',
        analyzerMode: 'server', // 'server': 启动端口服务；'static': 生成 report.html；'disabled': 配合 generateStatsFile 使用；
        generateStatsFile: false, // 是否生成stats.json文件
        analyzerHost: '127.0.0.1',
        analyzerPort: '8877',
        reportFilename: 'report.html',
        defaultSizes: 'parsed',
        openAnalyzer: false,
        statsFilename: 'stats.json',
        statsOptions: null,
        excludeAssets: null
      }

вanalyzerModeнастройки важнее.

  • бегать:
npm run dev 或 npm run build
  • доступ:
http://127.0.0.1:8877

Текущая ситуация, проблема

Посмотрите на нашу диаграмму анализа упаковки:

Полученный выше субконтракт на фиг не представляет сложности, vue-element-admin несет эти конфигурации.

config.optimization.splitChunks({
        chunks: 'all',
        cacheGroups: {
          libs: {
            name: 'chunk-libs',
            test: /[\\/]node_modules[\\/]/,
            priority: 10,
            chunks: 'initial' // only package third parties that are initially dependent
          },
          elementUI: {
            name: 'chunk-elementUI', // split elementUI into a single package
            priority: 20, // the weight needs to be larger than libs and app or it will be packaged into libs or app
            test: /[\\/]node_modules[\\/]_?element-ui(.*)/ // in order to adapt to cnpm
          },
          commons: {
            name: 'chunk-commons',
            test: resolve('src/components'), // can customize your rules
            minChunks: 3, //  minimum common number
            priority: 5,
            reuseExistingChunk: true
          }
        }
      })

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

Вам нужно только знать сначала: он дизассемблирует изначально загруженные сторонние пакеты, дизассемблирует библиотеку Element UI и дизассемблирует src/components.

всепохоже наНеплохо, но мы не удовлетворены.

Собственно, побежалиnpm run build:testТакже будет выдано предупреждение.

Итак, какие еще моменты можно продолжить оптимизировать? Сочетая приведенную выше диаграмму анализа и тестовое предупреждение, становится очевидным, что нам нужно подумать о:

  1. Размер Echarts нельзя игнорировать, как с этим бороться? Загружается ли домашняя страница или загружается асинхронно? Хотите импортировать по требованию?
  2. Можно ли снова разобрать такие библиотеки, как vue.js?
  3. Можно ли оптимизировать пакеты, от которых зависят домашние точки входа?
  4. В каком диапазоне следует контролировать объем мешка? Пакет слишком большой и загрузка будет слишком медленной! Пакет слишком мал и будет потреблять соединения HTTP-запросов!Подробнее: Имеет ли смысл объединять HTTP-запросы?
  5. Более......

Ган! Упаковка или что-то еще, нажмите еще несколько раз, и все готово. Если вы не можете сделать это десять раз, вы можете сделать это сто раз, если вы не можете сделать это сто раз, вы можете сделать это тысячу раз.

оптимизированные результаты

После завершения анализа получается следующая диаграмма анализа пакета:

Bengua успешно уменьшила размер пакета с3.1MBстал2.36MB, количество файлов из68упакованный43 ! ! !, оба понялиРаспаковка(снос публичной библиотеки), также реализованои пакет(объединить очень маленькие пакеты).

Хотя это не будет окончательным результатом, Бенгуа может сначала сделать вывод:

Настройка cacheGroups, взвешивающая два между распаковкой и слиянием, является частью пакета webpack.Конечная загадка!

Вот конфигурация cacheGroups:

 config.optimization.splitChunks({
        chunks: 'all',
         cacheGroups: {
            vue: {
              name: 'chunk-vuejs',
              test: /[\\/]node_modules[\\/]_?vue(.*)/,
              priority: 20
            },
            elementUI: {
              name: 'chunk-elementUI', // split elementUI into a single package
              priority: 30, // the weight needs to be larger than libs and app or it will be packaged into libs or app
              test: /[\\/]node_modules[\\/]_?element-ui(.*)/ // in order to adapt to cnpm
            },
            commons: { // split async commons chunk
              name: 'chunk-async-commons',
              minChunks: 2,
              priority: 40,
              chunks: 'async'
            },
            echarts: { // split echarts libs
              name: 'chunk-echarts',
              test: /[\\/]node_modules[\\/]_?echarts(.*)/,
              priority: 50,
              chunks: 'async'
            },
            zrender: { // split zrender libs
              name: 'chunk-zrender',
              test: /[\\/]node_modules[\\/]_?zrender(.*)/,
              priority: 55,
              chunks: 'async'
            },
            'manage-sendMsg': { // resolve src
              name: 'chunk-manage-sendMsg',
              test: resolve('src/views/manage/sendMsg'),
              priority: 80,
              chunks: 'async'
            },
            'manage-packageLink': { // resolve src
              name: 'chunk-manage-packageLink',
              test: resolve('src/views/manage/packageLink'),
              priority: 80,
              chunks: 'async'
            }，
            ......
      })

По сути, мы делаем оптимизацию только из конфигурации, и места для манипуляций не так много.Мы также должны оглянуться назад на детали нашего кода из результатов анализа упаковки., Корректировка бизнес-кода для оптимизации результатов упаковки может быть одной из самых прямых и эффективных идей оптимизации. В том числе: как интегрировать или разделить бизнес? Как сделать компонентизацию? Как импортировать компоненты? Как импортировать плагины? Сколько? ...Каждой точкой можно управлять снова!

  • Обратите особое внимание
CommonJs(require) ES6(import)
Вывод - это копия значения Вывод является ссылкой на значение
загружать во время выполнения интерфейс вывода времени компиляции

cacheGroups

Давайте подробнее рассмотрим наиболее критическую конфигурацию cacheGroups:

【важный】

  • name

имя файла чанка

  • test

Модули фильтрации, по умолчанию все модули, которые могут соответствовать пути к модулю или имени чанка.При совпадении имени чанка будут выбраны все модули, представленные в этом чанке;

  • priority

Вес, чем выше число, тем выше приоритет. Модуль может удовлетворять регулярному сопоставлению нескольких групп cacheGroups, и какая группа кэша применяется к этому модулю, зависит от приоритета;

  • chunks(очень очень важно)

Есть три значения: все, асинхронное, начальное.

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

//app.js
import "my-statis-module";

if(some_condition_is_true){
  import ("my-dynamic-module")
}
console.log("My app is running")

asyn : (default)

Генерируются два файла пакета:

  1. bundle.js (включает в себя app.js + модуль my-statis)
  2. chunk.js (только мой динамический модуль)

initial :

Генерируются три упаковочных файла:

  1. app.js (только app.js)
  2. bundle.js (включает только my-static-module)
  3. chunk.js (только мой динамический модуль)

all :

Генерируются два файла пакета:

  1. app.js (только app.js)
  2. bundle.js (включает в себя мой статический модуль + мой динамический модуль)

Установка размера «все» будет наименьшим, разница между использованием трех — это ядро ​​​​ядра.

【К пониманию】
  • minSize

Указывает минимальное значение объема разделяемого пакета перед разделением, будут разделены только пакеты >= minSize;

  • maxSize

Указывает максимальное значение объема разделяемого пакета перед разделением, значение по умолчанию равно 0, что означает отсутствие верхнего предела объема пакета перед разделением;Если maxSize ненулевое значение, оно не может быть меньше minSize;

  • minChunks

Указывает минимальное значение того, сколько чанков можно разделить перед разделением.

  • reuseExistingChunk

Указывает, следует ли использовать существующий фрагмент, значение true означает, что если модуль, содержащийся в текущем фрагменте, был извлечен, новый не будет регенерирован, то есть несколько фрагментов повторно используют модуль, который был разделен;

неожиданная удача

Уровень кода: Таким образом, user.png будет упакован отдельно. Упаковывать 148B действительно не нужно!

<img v-show="imageUrl" :src="imageUrl" class="sort-img">
<img v-show="!imageUrl" src="~@/assets/user.png" class="sort-img">

Если это изменить, он больше не будет упаковываться отдельно.

 <img :src="imageUrl?imageUrl:'~@/assets/user.png'" class="sort-img">

Оглядываясь назад на другие коды, Bengua обнаружил, что все файлы, представленные в условном решении, будут упакованы отдельно. Однако некоторые из них можно изменить в письменной форме, и на самом деле нет необходимости упаковывать несколько файлов KB в пакетный файл с несколькими B.

Проверка кода по результатам упаковки — тоже хороший метод оптимизации!

Резюме стратегии

На основе этого субподряда Бенгуа кратко определяет стратегию:

  1. Публичная библиотека должна быть удалена в максимально возможной степени.
  2. Публичная библиотека должна максимально загружаться по требованию, что также требует внимания к оптимизации загрузки первого экрана.
  3. Подпакет не должен быть слишком маленьким. Пакеты от 0 КБ до 10 КБ очень малы и должны рассматриваться для слияния. Пакеты от 10 КБ до 100 КБ являются небольшими пакетами, которые больше подходят, пакеты от 100 КБ до 200 КБ могут быть только основными и важными пакетами, на которые необходимо обратить внимание Пакеты больше 200 КБ необходимо распаковать. Конечно, не исключены и некоторые частные случаи.
Размер посылки Стратегия
от 0 КБ до 10 КБ объединить пакет
от 10 КБ до 100 КБ Правильный размер
от 100 КБ до 200 КБ основной пакет, сосредоточиться на
Больше 200 КБ Подумайте о распаковке
Особый случай особый уход

На этот раз я буду здесь первым, сбору вещей нет конца, пусть в этом мире не будет стай осадных львов.

Обратите внимание на общественный номер [Наггетс Энтони], ваши три подряд, моя мотивация! ! !

Категории