现代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则是把首屏速度再度进行提高。