问题继续

“还没发现我？”一个昏暗的旮旯，一个悄然咪咪的动静伴随着尖尖的讥笑声传递了开来…一个激灵，小树醒了过来，原来是噩梦。难得午休了一次居然做了一个噩梦，小树心说，显然他还没有缓过神来。去厕所洗了把脸，回到座位上。“滴滴滴~”，突然一个了解的H哥头像在办公聊天东西中闪了起来，音讯那头提到，“大佬，上星期好了没两天，这礼拜又感觉很慢了，体系运用起来很煎熬啊”，还不忘贴了个图。小树看着图片，心里也是一震，什么状况一个前端文件有3.6m，加载时刻一共用了55秒。这个渠道还能用？彻底便是用户群体人美心善，不然小树早就拜拜了。顶着巨大的压力，小树仍是用非常安静的口气回了一句，“本周内我把这个大文件紧缩到1.5m以内，加载速度至少提高一倍”，尽管此时心里仍是很忐忑。H哥仅仅象征性的回了一句，谢谢大佬，然后就没了动静。

怎么做

彻底没有方向，尽管也是写了段时刻vue的人了，运用webpack打包也用了很屡次了，但是真要说如何去优化打包逻辑，把公共模块包从原来的3.6m紧缩到1.5m，小树心里是真没有多少条理。

作为一个老职场人，小树深知团队的力量大无量，目光迅速确定了公司的前端大佬J哥。所以小树就向J哥描绘了下诉求，J哥轻快的答应了协助一起进行优化，经过大约3分钟的前端架构状况，J哥突然两眼放光，思绪如潮，唰唰唰，给出了一个计划。在前端中许多时分，会走cdn，比方许多公共依靠比较大的，不需要每次都用webpack 打进common-chunk里边，能够用外部引证的方法进行替换，这样一个是减小根底包的巨细，又能减轻客户端服务器的压力，还能添加用户的体验（公共部分能够直接经过缓存获取，不用每次构建都从头下载一次）。

迅速的，运用html-webpack-plugin，就把一些比较大的公用库直接外部引证（asserts）。总算功夫不负有心人，小树的第一次构建开端了。成果出来从3.6m紧缩到了2.43m，使命完成度50%。2.43m的公共包的实践加载体感，根据小树公司的网络环境的特殊性，成果仍是很不稳定，有所提高但是体感不明显。细心想想其实是因为，尽管用了外部依靠，但是第一次全新加载的时分，整个根底包仍是没有缩小的，仅仅被分割成多份了罢了。所以继续找J哥，计划多少有点作用，J哥因为业务项目忙的没法解开，占线状况严重，小树只能自己想想方法了。

还能怎么做

度娘，科学谷歌左右开弓，如何优化前端打包逻辑，是否当时打包的依靠中存在不合理性，是否有东西能够剖析打包的力度和作用，有没有webpack插件能够进一步紧缩打包成果，只见小树的查找栏飞速的运作着。

总算功夫不负有心人，让小树查到了点东西，能够运用一个插件剖析打包详情。webpack-bundle-analyzer，经过该插件，能够有一个打包成果剖析图从而了解实践的组成，而且操作比较简单。

// vue.config.js， 需要npm install webpack-bundle-analyzer 添加插件依靠
...
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
...
 plugins:  [
      new BundleAnalyzerPlugin(
        {
                  analyzerMode: 'server',
                  analyzerHost: '127.0.0.1',
                  analyzerPort: 8888,
                  reportFilename: 'report.html',
                  defaultSizes: 'parsed',
                  openAnalyzer: true,
                  generateStatsFile: false,
                  statsFilename: 'stats.json',
                  statsOptions: null,
                  logLevel: 'info'
                    }
           )]
...
// package.json
...
"scripts":{
...
    "analyz": "NODE_ENV=production npm_config_report=true npm run build"
...
}
...
// 执行后页面 127.0.0.1:8888 会主动翻开
npm run analyz

这个包经过紧缩今后，其实细心看下就能发现问题。单单一个brace的依靠紧缩后，还需要1.22m。好奇这个brace到底是干嘛的。

//Edit.vue
...
editorInit: function (editor) {
          require('brace/ext/language_tools') //language extension prerequsite...
          this.modes.forEach(mode => {
            require('brace/mode/' + mode); //language
          });
          require('brace/theme/' + this.theme)
          require('brace/snippets/javascript') //snippet
          if (this.readOnly) {
            editor.setReadOnly(true);
          }
          if (this.init) {
            this.init(editor);
          }
        },
...

看起来，自身渠道也有按需加载，那为什么最终，仍是加载了悉数brace资源呢？转念一想，会不会是因为动态拼接的写法webpack不能准确定位，类似于代码方法的动态引证，必须要先悉数加载完今后，才能够支撑。如果是全限定名直接引证的话，那webpack应该能够准确定位并按需进行打包了。所以小树就直接用实践来说话，把这部分代码改成了

...
 editorInit: function (editor) {
          require('brace/ext/language_tools') //language extension prerequsite...
          require('brace/mode/java')
          require('brace/mode/javascript')
          require('brace/mode/python')
          require('brace/mode/text')
          require('brace/mode/json')
          require('brace/mode/xml')
          require('brace/mode/html')
          require('brace/mode/sql')
          require('brace/theme/chrome')
          require('brace/theme/eclipse')
          // this.modes.forEach(mode => {
          //   require('brace/mode/' + mode); //language
          // });
          // require('brace/theme/' + this.theme)
          require('brace/snippets/javascript') //snippet
          if (this.readOnly) {
            editor.setReadOnly(true);
          }
          if (this.init) {
            this.init(editor);
          }
        },
...

随后从头用之前的打包剖析插件再跑了下成果。

小树原想去渠道的开源库上也提交个pr，协助开源社区也做点事情。成果上github一看，就在同一周里，开源库也进行了该问题的优化，从原先的方法改成了和小树自己相同的方法。小树只能淡淡一笑，关掉了github，心想，看来自己的思路已经跟上了大团队的方向。

故事的最终

小树在当天夜里直接上线了最新的调整，并和H哥说明晰更新状况，第二天的反馈，H哥也肯定了小树的改造。

后边还会有怎样的挑战，小树此时不清楚，到现在为止每次都是正面刚问题，小树心中莫名的有些担忧…