正文
还是以自己的多页面博客为例，执行
npm run build
，将打包代码部署上线后访问项目,会发现表现很糟糕，页面会出现长时间的空白等待。通过下图可以看到，总加载时长达到将近12s，这是无法忍受的性能问题，迫切需要解决。
客户端加载示意图：
![]()
从上图中可以看到，造成加载时间过慢的元凶是
vendor
文件，该文件存放的是项目中所有的第三方依赖。而且从下图可以看出，这个文件同时被管理端使用，体积有1.2M。
管理端加载示意图
![]()
通过下面的打包文件结构图中可以看到，
vendor
主要包含的依赖有
highlight
、
mavon-editor
、
vue
、
vue-moment
、
marked
、
vue-router
，
iview
等，而实际中
mavon-editor
、
iview
只有在管理端会用到，
highlight
、
marked
只会在客户端用到，因此优化的一个要点就是分离第三方依赖。但是分离的时候要考虑到，即便将依赖分离后依赖文件仍然存在服务器上，而相对来说很多成熟类库会提供cdn结点，访问cdn会比访问自己的服务器要快，因此优化的第一步是对相关依赖用cdn方式引入。
![]()
引入CDN
对
vue
、
vuex
、
vue-router
、
vue-moment
采用cdn引入，此外客户端还可以引入
highlight
的cdn，但管理端不需要。因此，需要两份不同的模板html，配置分别如下：
tpl/index.html
![]()
tpl/admin.html
![]()
由于使用了CDN，webpack就不需要再打包这几个依赖，但是webpack会默认追踪所有依赖，因此需要配置过滤的依赖项。打开webpack.base.conf.js, 增加如下配置：
externals: {
'vue': 'Vue',
'vue-router': 'VueRouter',
'vuex': 'Vuex',
'vue-moment': 'VueMoment',
'highlight.js': 'hljs',
},
其中，
key
是node模块名称，
value
是项目中对模块的引用。然后执行
npm run build --report
,再观察一下打包后的
vendor
文件，如下图，可以发现，
externals
中的依赖都没有被打包进来。由于少了
highlight.js
，
vendor
体积一下子缩减了一半多，只有500kb左右。
![]()
但是到这里还远远不够，
vendor
文件还是很大，
mavon-editor
就占到一半。因为
mavon-editor
只会在管理端用到，而
marked
更轻量，只会在客户端用到来解析
markdown
。所以还需要对
vendor
进一步分离。webpack为我们提供一个插件
CommonsChunkPlugin
，它可以收集到项目中的所有同步的依赖从而进行代码分割。
代码分割
在webpack.prod.conf.js中，修改CommonsChunkPlugin的配置，如下：
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
minChunks (module) {
return (
module.resource &&
/\.js$/.test(module.resource) &&
module.resource.indexOf(
path.join(__dirname, '../node_modules')
) === 0 && module.resource.indexOf('mavon-editor') < 0
&& module.resource.indexOf('marked') < 0
)
}
}),
默认配置会把所有依赖收集进
vendor
，通过
minChunks
这个钩子函数可以自定义被收集的模块，该函数返回一个布尔值。webpack会追踪所有依赖，并调用该钩子，对于返回是true的才进行收集，因此我们可以将非共同模块从依赖中剔除，这样打包后的vendor就是客户端页面和管理端都会用到的页面，而被剔除的
marked
和
mavon-editor
则会被收集到各自定义的
chunk
中，
marked
被打包进
client
，
mavon-editor
被打包进
manager
。如下图：
![]()
然而，这里可以看到
manage
这个文件还是很大，主要是包含
mavon-editor
，而它只需要在
article
路由中会用到，同样的，
client
中的
marked
也只会在
detail
路由中用到。那么，下一步的优化在于如何让文件按需加载。
异步加载路由
对于上面提到的问题，如果把路由引入方式改为异步引入，webpack打包的时候会单独打包异步文件作为一个新的chunk，并且在需要时才会在页面中加载。以管理端为例，修改路由引入方式为异步引入，如下：
const Catagory = () => import('../pages/Catagory');
const Avator = () => import('../pages/Avator')
const Comment = () => import('../pages/Comment')
const Detail = () => import('../pages/Detail')
const Article = () => import('../pages/Article')
采用异步路由后，再打包会发现，
manager
和
client
体积进一步减小，会对每一个异步路由多出一个打包文件，而这些文件都是动态加载的。
![]()
经过上述的一系列处理后，多页面之间的代码已经解耦，自己的依赖的大文件也成功被分离。这个时候，页面加载已经明显快了很多。但是可以看到，
mavon-editor
这一个依赖就有250多kb，不管它被打包到什么位置，都会影响对应页面的加载。接下来我们开启gzip压缩进一步缩小依赖的体积。
gzip压缩
一般来说，
gzip
的开启只要服务端去做就好，但是服务端需要先根据设置好的压缩等级去压缩文件，然后再将压缩文件返回到浏览器。而这里，webpack的
CompressionWebpackPlugin
插件可以帮我们生成
gzip
的压缩文件。可以如果提前将压缩文件存放在服务器中，服务器在处理请求的时候将节省资源的压缩时间，直接读取服务器上的.gz文件。在
vue-cli2
中，只需要将config/index.js中的
productionGzip
配置项改为
true
即可。
![]()
上图为打包后文件的部分截图，可以看到文件体积得到了进一步压缩， 0.41那个js文件包含
mavon-editor
，已经从原来的300多kb降到107kb。接下来，我们在nginx中开启gzip,如下：
gzip_static on;
gzip_min_length 5k;
gzip_buffers 4 16k;
gzip_comp_level 4;
gzip_types text/plain application/javascript text/css application/xml text/javascript application/x-httpd-php;
gzip_vary on;
keepalive_timeout 65;
其中
gzip_static
开启后，nginx就会读取预先压缩的
gz
文件，这样就可以减少每次请求进行gzip压缩的CPU资源消耗，这也就是为什么需要webpack对文件作压缩的原因。所有配置的解释可以参考
Nginx Gzip模块启用和配置指令详解_nginx
；
缓存加速
使用nginx会默认开启缓存，对静态文件的响应加上
Etag
，如下图。这样浏览器二次加载的时候只要服务器的静态文件没有发生变化，就会从缓存中读取，进一步优化了页面响应速度。
![]()
预渲染
以上方案解决的问题是缩小js资源体积以便加快加载速度，这样的方案在网络良好的情况下首屏渲染的速度已经够快了，但是终归讲，渲染依赖于js加载完成后的执行逻辑，而且这样的方式不利于SEO。那么进一步提高首屏加载的方案还有两个，一个是预渲染，一个是SSR，即服务端渲染，后者的方案较为复杂，我会在以后的文章中进行分析，服务端渲染的方式相比预渲染，最主要的优势是可以动态拼接数据，作为文档的一部分返回，从而实现更友好的SEO和动态分享等功能。我的博客因为没有这些需求，并且考虑到服务器的状况（单核1GB），不想给服务器增加负载，因此不考虑SSR，将采用预渲染的方式进一步加快首屏加载。
