从零搭建webpack前端类库脚手架[5]-优化

, , ,

优化目标包括但不仅限于性能。

可视化工具

https://webpack.docschina.org/guides/code-splitting

加快webpack模块搜索速度

配置resolve

防止多bundle中公共依赖模块的重复打包

如果应用有多个entry，那么webpack默认情况下会对每个entry单独构建互相隔离；进而会导致一旦多个entry有共同依赖的模块(例如A和B都依赖C), 那么公共依赖C会被分别打包到A和B的bundle里面。

解决方法: 使用CommonsChunkPlugin插件将公共依赖提取出来；可以提取到某个entry的bundle，也可以提取到一个新的bundle.

1

复杂一点的多入口多页应用，有些页面公用a.js，有些页面公用b.js，还有些交叉页面，而CommonChunkPlugin都可以做到:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
module.exports = {
    entry: {
        p1: "./page1",
        p2: "./page2",
        p3: "./page3",
        ap1: "./admin/page1",
        ap2: "./admin/page2"
    },
    output: {
        filename: "[name].js"
    },
    plugins: [
        new CommonsChunkPlugin("admin-commons.js", ["ap1", "ap2"]),
        new CommonsChunkPlugin("commons.js", ["p1", "p2", "admin-commons.js"])
    ]
};
// page1.html: commons.js, p1.js
// page2.html: commons.js, p2.js
// page3.html: p3.js
// admin-page1.html: commons.js, admin-commons.js, ap1.js
// admin-page2.html: commons.js, admin-commons.js, ap2.js

由于admin-commons.js被抽出了一些跟别人公共部分，所以凡是用到admin-commons.js的页面，都必然要用上common.js.

单页应用最佳实践

对于单页应用来说，可能没有多页应用那么多的入口entry；但是可能会存在主逻辑中调用了一些第三方库lodash、jquery等。那么这个时候是没有多个入口的(单页应用只有一个入口)，那么就不存在所谓的公共依赖。那么此时应该如何把这些常用库提取出来以便于在客户端长期cache呢?

其实可以取巧一点，把这些库在entry里当做一个入口即可.

Refer