前言
最近参加了两次社招,发现社招面试都会问到性能优化以及框架原理。当中性能优化即使我知道好几种,然而我面试时总是很容易想不起来,只答出了两三种。因此,写一篇博客来对性能优化做一下研究,加深理解。
1、压缩 合并
对于 前端性能优化 自然要关注 首屏 打开速度,而这个速度,很大因素是花费在网络请求上,那么怎么减少网络请求的时间呢?
- 减少网络请求次数
- 减小文件体积
- 使用
CDN
加速
所以 压缩、合并 就是一个解决方案,当然可以用 gulp
、 webpack
、 grunt
等构建工具 压缩、合并。
使用webpack压缩js:
plugins: [
new UglifyJSPlugin(), //打包后文件压缩
]
如果是webpack4,可以直接使用:
mode: 'production'
用于生产环境,webpack会自动压缩。
使用webpack压缩css,
new OptimizeCSSAssetsPlugin({
assetNameRegExp: /\.css\.*(?!.*map)/g, //注意不要写成 /\.css$/g
cssProcessor: require('cssnano'),
cssProcessorOptions: {
discardComments: { removeAll: true },
// 避免 cssnano 重新计算 z-index
safe: true,
// cssnano 集成了autoprefixer的功能
// 会使用到autoprefixer进行无关前缀的清理
// 关闭autoprefixer功能
// 使用postcss的autoprefixer功能
autoprefixer: false
},
canPrint: true
}),
2、缓存
缓存这东西,第一次必须获取到资源后,然后根据返回的信息来告诉如何缓存资源,可能采用的是强缓存,也可能告诉客户端浏览器是协商缓存,这都需要根据响应的header内容来决定的。
浏览器缓存包含两种类型,即强缓存(也叫本地缓存)和协商缓存,浏览器在第一次请求发生后,再次请求时:
- 浏览器在请求某一资源时,会先获取该资源缓存的header信息,判断是否命中强缓存(cache-control和expires信息),若命中直接从缓存中获取资源信息,包括缓存header信息;本次请求根本就不会与服务器进行通信;在firebug下可以查看某个具有强缓存资源返回的信息,例如本地firebug查看的一个强缓存js文件。
- 如果没有命中强缓存,浏览器会发送请求到服务器,请求会携带第一次请求返回的有关缓存的header字段信息(Last-Modified/If-Modified-Since和Etag/If-None-Match),由服务器根据请求中的相关header信息来比对结果是否协商缓存命中;若命中,则服务器返回新的响应header信息更新缓存中的对应header信息,但是并不返回资源内容,它会告知浏览器可以直接从缓存获取;否则返回最新的资源内容
强缓存与协商缓存的区别,可以用下表来进行描述:
获取资源形式 | 状态码 | 发送请求到服务器 | |
强缓存 | 从缓存取 | 200(from cache) | 否,直接从缓存取 |
协商缓存 | 从缓存取 | 304(not modified) | 是,正如其名,通过服务器来告知缓存是否可用 |
1、强缓存
强缓存是直接从缓存中获取资源而不经过服务器;与强缓存相关的header字段有两个:
1)expires
当客户端第一次访问一个文件资源的时候,服务端在返回资源内容的同时也返回了:
Expires: Mon, 1 Aug 2016 22:43:02 GMT
也就是服务端告诉浏览器,先把这个文件缓存起来,在这个过期时间之前,该文件都不会变化了。
下一次浏览器又要访问这个资源,并且访问的时间在Mon, 1 Aug 2016 22:43:02 GMT
之前,那浏览器就不去服务器那边获取文件了,而是直接从缓存中取文件。
2)Cache-Control
由于Expires给定的是绝对时间,而客户端的系统时间可以由用户任意修改,比如Expires设定的过期时间是
Mon, 1 Aug 2016 22:43:02 GMT
现在用户把系统时间改为
Tue, 2 Aug 2016 22:43:02 GMT
则缓存会被判为过期(虽然实际上还没到那个时间)。因此在HTTP1.1中引入了Cache-Control,这就是一个相对时间,比如
Cache-Control: max-age=80
那就是说这份缓存的有效期是80秒,而没有给定过期的绝对时间。
由于Cache-Control是HTTP1.1中才有的,因此可能会有Expires和Cache-Control同时出现的情况,这时以Cache-Control为准。
2、协商缓存
协商缓存都是由服务器来确定缓存资源是否可用的,所以客户端与服务器端要通过某种标识来进行通信,从而让服务器判断请求资源是否可以缓存访问,这主要涉及到下面两组header字段,这两组搭档都是成对出现的,即第一次请求的响应头带上某个字段(Last-Modified或者Etag),则后续请求则会带上对应的请求字段(If-Modified-Since或者If-None-Match),若响应头没有Last-Modified或者Etag字段,则请求头也不会有对应的字段。
1)Last-Modified/If-Modified-Since
- 浏览器第一次跟服务器请求一个资源,服务器在返回这个资源的同时,在respone的header加上Last-Modified的header,这个header表示这个资源在服务器上的最后修改时间
- 浏览器再次跟服务器请求这个资源时,在request的header上加上If-Modified-Since的header,这个header的值就是上一次请求时返回的Last-Modified的值
- 服务器再次收到资源请求时,根据浏览器传过来If-Modified-Since和资源在服务器上的最后修改时间判断资源是否有变化,如果没有变化则返回304 Not Modified,但是不会返回资源内容;如果有变化,就正常返回资源内容。当服务器返回304 Not Modified的响应时,response header中不会再添加Last-Modified的header,因为既然资源没有变化,那么Last-Modified也就不会改变,这是服务器返回304时的response header
- 浏览器收到304的响应后,就会从缓存中加载资源
- 如果协商缓存没有命中,浏览器直接从服务器加载资源时,Last-Modified的Header在重新加载的时候会被更新,下次请求时,If-Modified-Since会启用上次返回的Last-Modified值
2)Etag/If-None-Match
这两个值是由服务器生成的每个资源的唯一标识字符串,只要资源有变化就这个值就会改变;其判断过程与Last-Modified/If-Modified-Since类似,与Last-Modified不一样的是,当服务器返回304 Not Modified的响应时,由于ETag重新生成过,response header中还会把这个ETag返回,即使这个ETag跟之前的没有变化。
Last-Modified与ETag是可以一起使用的,服务器会优先验证ETag,一致的情况下,才会继续比对Last-Modified,最后才决定是否返回304。