现代WEB前端的性能优化
现代web前端的性能优化
前言：这只是一份学习笔记。
什么是web前端
潜在的优化点：
dns是否可以通过缓存减少dns查询时间？
网络请求的过程走最近的网络环境？
相同的静态资源是否可以缓存？
能否减少http请求的大小？
减少http请求数
服务端渲染
涉及层面
网络层面
构建层面
服务端层面
浏览器渲染层面
基础优化：图片的编码原理、选择图片的格式、资源的合并与压缩。
进阶优化：浏览器渲染层面的优化、重绘与回流层面的优化、浏览器存储的选择与使用、浏览器端结合服务端的缓存机制。
结合服务端的优化：基于nodejs的vue-ssr解决首屏渲染的问题。
知识点
资源的合并与压缩
目的：减少http请求数量、减少请求资源大小、减少带宽消费。
原理：通过一个入口文件（依赖的顶层），分析所有依赖，得到依赖树，最后按照依赖树，对文件进行压缩、混淆、合并、语法转换。
a) html压缩
在前端的源代码里，有些东西，只在代码里有意义，但是对于浏览器却毫无意义的。
例如：代码对齐的回车、空格、tab，代码注释。
这些东西在发布的时候可以去掉。
b) css压缩
删除回车、空格、tab，删除代码注释，css语义合并。
c) js压缩与混淆（必须）
删除回车、空格、tab，删除代码注释，代码命名和语义的缩减与优化，达到代码保护。
d) 文件合并
· 公共库合并（合并成为vendor.js）
· 分页面合并（按路由合并）
· 按实际情况合并
e) 开启gzip
将js和css文件压缩为gzip。
图一为普通模式的请求状况
“传输”：http请求大小 + 文件传输过程大小
“大小”：文件的实际大小
图二为gzip模式的请求状况，gzip的压缩阈值为10k
“传输”：http请求大小 + 文件传输过程大小（即gzip压缩后大小）
“大小”：文件的实际大小（浏览器收到gzip，解压之后的大小）
举个例子，vendor.js，原大小6.5m（echarts的源码太大了），
经过代码压缩后，成果是770k，
最后部署到nginx，启用nginx的gzip功能，浏览器请求时变成200k
6.5m->770k->200k
图片压缩
小图片转换为base64嵌入到代码里。
大图片将肉眼无法识别的色彩去除，达到压缩。
浏览器渲染
本质就是：js和css的加载顺序问题，把css放在head，js按实际需要放（尽可能放底部），而且，访问对应路由的时候才加载需要的js和css。
懒加载与预加载
懒加载：在没有进入可视区域的时候，img的src是一个很小的占位图片或者直接是空的，进入可视区域的时候，才变成有效的src。
上面代码是手工实现的，另有开源的zepto.lazyload.js，vue-cli架构下也有专门的库。
预加载：在最开头的部分，使用隐藏的img加载需要的图片，后面需要使用的时候，其它的img就会从缓存读图片。直接在js里面new一个image对象，也能实现预加载。用ajax的get方法去加载也行，但是ajax有跨域问题。
开源的有preloadjs
重绘与回流
浏览器渲染的时候，css的运行会阻塞js的运行。
频繁触发重绘与回流，会导致ui频繁渲染，最终导致js变慢。
尽量少触发重绘与回流可以提升性能。
重绘的代价比回流要小的多，所以，尽可能只触发重绘，而减少触发回流，就能提高性能。
在浏览器的开发者工具栏里面，性能（performance）那一项，有重绘与回流的记录。
如果无法避免重绘与回流，则尽量把重绘回流的范围限制在一个图层之内，例如video、canvas、有特定样式的div。（在谷歌浏览器的开发者工具栏的layers里面，有表明哪些元素是图层，以及那些元素之所以是图层的原因）
重绘（代价比较小）：
回流（即重布局，代价比较大）：
上面两个图看不懂没关系，可以直接看下面这个图：
.class1 { margin-left : 10px; padding-left: 10px;}
.class2 { margin-left : 20px; padding-left: 20px;}
关于第三点，修改元素样式的时候，用class的话，只回流1次，但是如果直接改style，则回流2次
关于第四点，先把元素隐藏起来，然后修改各种样式，改完再显示出去，就只回流两次。
如果直接是显示状态下改n种样式，就会回流n次。
（ps：如果用了第三点，就可以忽略第四点）
关于第五点，不要在循环里面取值，要在循环外面事先取出来
举个反例：
正确例子：
浏览器存储
在现代web前端，
cookie用于标识用户，现在的人都不再用于存储数据
localstorage，仅用于存储数据，永久性的
sessionstorage，仅用于存储数据，生命周期跟session有关
indexdb，前端的nosql数据库，永久性的，大量数据时候会用到
serviceworker，控制浏览器的离线缓存，通过编写serviceworker的js代码，可以直接控制浏览器去读缓存里的js、css、html文件，而且是完全离线的，也就是说，即使断网了，也一样可以访问网站。（如果缓存里面没有该文件，才会发请求出去拿文件）
关于cookie的一个优化点：
cookie是作用于一个域的，请求里面携带cookie会有一定的损耗，但是一般只有调接口的时候才需要cookie，调js和css是不需要cookie的，所以，一般把前端静态文件放在cdn（即另一个域），这样子访问js和css就不会携带cookie了。对于京东来说，这样子每年可以节省上亿元的带宽消费。
缓存策略
区别于上一节，http、https自身也有缓存策略：通过控制cache-control、last-modified、etag，可以达到*控制缓存。
状态对比：
（200）> （304） > （200已缓存）
举个例子 10ms > 5ms > 0ms
pwa
pwa（progressive web app）是一种全新的网页技术，让网站的离线体验变得更好，特别适用于断断续续的网络。现在非常火，对于前端性能的优化，效果很显著。它的本质就是用了serviceworker。
前后端分开部署
前端，只要有html、css、js、图片就是完整的了。
后端，则有php、java等语言。
php依赖于apache，java依赖于tomcat，而前端可以放在任意的web服务容器上运行。
前端放在tomcat、apache、nginx的性能比是 1：5：15。
vue-ssr
vue-cli跟vue-ssr做出来的都是单页面应用，由于用了vue-router来实现各个tab，所以每个tab的性能都是超乎想象的优越。
而vue-ssr则是把首屏速度再度进行提升。