彻底掌握基于HTTP网络层的 “前端性能优化”
产品性能优化方案
-
HTTP网络层优化
-
代码编译层优化 webpack
-
代码运行层优化 html/css + javascript + vue + react
-
安全优化 xss + csrf
-
数据埋点及性能监控
-
……
CRP(Critical [ˈkrɪtɪkl] Rendering [ˈrendərɪŋ] Path)关键渲染路径
从输入URL地址到看到页面,中间都经历了啥
第一步:URL解析
-
地址解析
-
编码
第二步:缓存检查
缓存位置:
Memory Cache : 内存缓存
Disk Cache:硬盘缓存
打开网页:查找 disk cache 中是否有匹配,如有则使用,如没有则发送网络请求
普通刷新 (F5):因TAB没关闭,因此memory cache是可用的,会被优先使用,其次才是disk cache
强制刷新 (Ctrl + F5):浏览器不使用缓存,因此发送的请求头部均带有 Cache-control: no-cache,服务器直接返回 200 和最新内容
强缓存 Expires / Cache-Control
浏览器对于强缓存的处理:根据第一次请求资源时返回的响应头来确定的
Expires:缓存过期时间,用来指定资源到期的时间(HTTP/1.0)
Cache-Control:cache-control: max-age=2592000第一次拿到资源后的2592000秒内(30天),再次发送请求,读取缓存中的信息(HTTP/1.1)
两者同时存在的话,Cache-Control优先级高于Expires
协商缓存 Last-Modified / ETag
协商缓存就是强制缓存失效后,浏览器携带缓存标识向服务器发起请求,由服务器根据缓存标识决定是否使用缓存的过程
数据缓存
第三步:DNS解析
-
递归查询
-
迭代查询
每一次DNS解析时间预计在20~120毫秒
减少DNS请求次数
DNS预获取(DNS Prefetch)
<meta http-equiv="x-dns-prefetch-control" content="on">
<link rel="dns-prefetch" href="//static.360buyimg"/>
<link rel="dns-prefetch" href="//misc.360buyimg"/>
<link rel="dns-prefetch" href="//img10.360buyimg"/>
<link rel="dns-prefetch" href="//d.3"/>
<link rel="dns-prefetch" href="//d.jd"/>
服务器拆分的优势
-
资源的合理利用
-
抗压能力加强
-
提高HTTP并发、
-
……
第四步:TCP三次握手
seq序号,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记
ack确认序号,只有ACK标志位为1时,确认序号字段才有效,ack=seq+1
标志位
ACK:确认序号有效
RST:重置连接
SYN:发起一个新连接
FIN:释放一个连接
……
三次握手为什么不用两次,或者四次?
TCP作为一种可靠传输控制协议,其核心思想:既要保证数据可靠传输,又要提高传输的效率!
第五步:数据传输
-
HTTP报文
-
请求报文
-
响应报文
-
-
响应状态码
-
200 OK
-
202 Accepted :服务器已接受请求,但尚未处理(异步)
-
204 No Content:服务器成功处理了请求,但不需要返回任何实体内容
-
206 Partial Content:服务器已经成功处理了部分 GET 请求(断点续传 Range/If-Range/Content-Range/Content-Type:”multipart/byteranges”/Content-Length….)
-
301 Moved Permanently
-
302 Move Temporarily
-
304 Not Modified
-
305 Use Proxy
-
400 Bad Request : 请求参数有误
-
401 Unauthorized:权限(Authorization)
-
404 Not Found
-
405 Method Not Allowed
-
408 Request Timeout
-
500 Internal Server Error
-
503 Service Unavailable
-
505 HTTP Version Not Supported
-
……
-
第六步:TCP四次挥手
为什么连接的时候是三次握手,关闭的时候却是四次握手?
-
服务器端收到客户端的SYN连接请求报文后,可以直接发送SYN+ACK报文
-
但关闭连接时,当服务器端收到FIN报文时,很可能并不会立即关闭链接,所以只能先回复一个ACK报文,告诉客户端:”你发的FIN报文我收到了”,只有等到服务器端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送,故需要四步握手。
Connection: keep-alive
长链接
第七步:页面渲染
性能优化汇总
/*
* 1.利用缓存
* + 对于静态资源文件实现强缓存和协商缓存(扩展:文件有更新,如何保证及时刷新?)
* + 对于不经常更新的接口数据采用本地存储做数据缓存(扩展:cookie / localStorage / vuex|redux 区别?)
* 2.DNS优化
* + 分服务器部署,增加HTTP并发性(导致DNS解析变慢)
* + DNS Prefetch
* 3.TCP的三次握手和四次挥手
* + Connection:keep-alive
* 4.数据传输
* + 减少数据传输的大小
* + 内容或者数据压缩(webpack等)
* + 服务器端一定要开启GZIP压缩(一般能压缩60%左右)
* + 大批量数据分批次请求(例如:下拉刷新或者分页,保证首次加载请求数据少)
* + 减少HTTP请求的次数
* + 资源文件合并处理
* + 字体图标
* + 雪碧图 CSS-Sprit
* + 图片的BASE64
* + ......
* 5.CDN服务器“地域分布式”
* 6.采用HTTP2.0
* ==============
* 网络优化是前端性能优化的中的重点内容,因为大部分的消耗都发生在网络层,尤其是第一次页面加载,如何减少等待时间很重要“减少白屏的效果和时间”
* + LOADDING 人性化体验
* + 骨架屏:客户端骨屏 + 服务器骨架屏
* + 图片延迟加载
* + ....
*/
HTTP1.0和HTTP1.1的一些区别
-
缓存处理
,HTTP1.0中主要使用 Last-Modified,Expires 来做为缓存判断的标准,HTTP1.1则引入了更多的缓存控制策略:ETag,Cache-Control… -
带宽优化及网络连接的使用
,HTTP1.1支持断点续传,即返回码是206(Partial Content) -
错误通知的管理
,在HTTP1.1中新增了24个错误状态响应码,如409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除… -
Host头处理
,在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域,且请求消息中如果没有Host头域会报告一个错误(400 Bad Request) -
长连接
,HTTP1.1中默认开启Connection: keep-alive,一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点
HTTP2.0和HTTP1.X相比的新特性
-
新的二进制格式(Binary Format)
,HTTP1.x的解析是基于文本,基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性,要做到健壮性考虑的场景必然很多,二进制则不同,只认0和1的组合,基于这种考虑HTTP2.0的协议解析决定采用二进制格式,实现方便且健壮 -
header压缩
,HTTP1.x的header带有大量信息,而且每次都要重复发送,HTTP2.0使用encoder来减少需要传输的header大小,通讯双方各自cache一份header fields表,既避免了重复header的传输,又减小了需要传输的大小 -
服务端推送(server push)
,例如我的网页有一个sytle.css的请求,在客户端收到sytle.css数据的同时,服务端会将sytle.js的文件推送给客户端,当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到,不用再发请求了
// 通过在应用生成HTTP响应头信息中设置Link命令
Link: </styles.css>; rel=preload; as=style, </example.png>; rel=preload; as=image
多路复用(MultiPlexing)
- HTTP/1.0 每次请求响应,建立一个TCP连接,用完关闭
- HTTP/1.1 「长连接」 若干个请求排队串行化单线程处理,后面的请求等待前面请求的返回才能获得执行机会,一旦有某请求超时等,后续请求只能被阻塞,毫无办法,也就是人们常说的线头阻塞;
- HTTP/2.0 「多路复用」多个请求可同时在一个连接上并行执行,某个请求任务耗时严重,不会影响到其它连接的正常执行;
第一步:URL解析和第二步缓存检查
第一步:URL解析
URI:URL+URN
+ URI统一资源标识符
+ URL统一资源定位符
+ URN统一资源名称
传输协议:
+ HTTP 超文本传输协议
+ HTTPS HTTP+SSL(加密证书),相对于HTTP来讲会更加安全
+ FTP 文件的传输,例如:FTP上传工具、FTP资源共享...
域名:服务器有一个外网IP,基于外网IP找到服务器,而域名就是给外网IP设置一个好记忆的名字
端口号:区分同一台服务器上的不同服务(或项目)的
+ 取值范围:0~65535
+ 默认值:我们自己不写端口号,浏览器默认加的 HTTP->80 HTTPS->443 FTP->21
编码问题:如果URL地址或者问号传参的信息中,出现中文或者某些特殊符号,传输中可能会乱码,此时需要客户端先进行编码,服务器端再解码..
+ encodeURI / decodeURI:一般用于对整个URL的编码,它只编码中文和部分特殊符号,对于URL地址中的有效符号不编码
+ encodeURIComponent / decodeURIComponent:一般用于对URL问号传参的值进行部分编码,因为除了encodeURI可以编码的东西外,对于URL地址中的有效符号也能编码,所以不适合整个URL
+ escape / unescape:不是所有后端语言都支持这个API,所以只用于客户端两个页面间数据传输的编译
第二步:缓存检查
“缓存”存储在哪了?
+ 虚拟内存(内存条):页面关闭,存储的东西会消失 Memory Cache
+ 物理内存(硬盘):持久存储 Disk Cache
关于“静态资源文件”的缓存有两种:强缓存、协商缓存
+ 不论哪一种都是服务器设置规则,客户端浏览器会自动配合完成,无需我们写代码
+ 一般真实项目中,强缓存、协商缓存都会设置「也可以只设置一个」,强缓存失效的情况下,再去走协商缓存的机制
强缓存:Cache-Control(HTTP/1.1)、Expires(HTTP/1.0) 服务器设置的“响应头”信息
+ cache-control: max-age=2592000
+ expires: Sun, 15 May 2022 20:14:22 GMT
+ 不论是从服务器获取,还是从缓存中读取,HTTP状态码都是200
问题:如果本地缓存生效,但是服务器更新了这个资源,如何保证客户端可以获取最新的?
+ HTML页面资源“绝对不能”做强缓存,因为其实页面渲染的入口,所有其它资源也是在渲染解析HTML代码的时候,再去请求的!!
// let url = `http://www.xx/首页.html?lx=0&name=珠峰@培训`;
// console.log(encodeURI(url)); //'http://www.xx/%E9%A6%96%E9%A1%B5.html?lx=0&name=%E7%8F%A0%E5%B3%B0'
// let url = `http://www.xx/?lx=0&name=${encodeURIComponent('珠峰@培训')}&from=${encodeURIComponent('http://www.wx/')}`;
// console.log(url); //'http://www.xx/?lx=0&name=%E7%8F%A0%E5%B3%B0%40%E5%9F%B9%E8%AE%AD&from=http%3A%2F%2Fwww.wx%2F'
// console.log(escape('珠峰@培训://')); //'%u73E0%u5CF0@%u57F9%u8BAD%3A//'
// console.log(unescape('%u73E0%u5CF0@%u57F9%u8BAD%3A//')); //'珠峰@培训://'
url解析----页面渲染
第一步:URL解析
URI:URL+URN
+ URI统一资源标识符
+ URL统一资源定位符
+ URN统一资源名称
传输协议:
+ HTTP 超文本传输协议
+ HTTPS HTTP+SSL(加密证书),相对于HTTP来讲会更加安全
+ FTP 文件的传输,例如:FTP上传工具、FTP资源共享...
域名:服务器有一个外网IP,基于外网IP找到服务器,而域名就是给外网IP设置一个好记忆的名字
端口号:区分同一台服务器上的不同服务(或项目)的
+ 取值范围:0~65535
+ 默认值:我们自己不写端口号,浏览器默认加的 HTTP->80 HTTPS->443 FTP->21
编码问题:如果URL地址或者问号传参的信息中,出现中文或者某些特殊符号,传输中可能会乱码,此时需要客户端先进行编码,服务器端再解码..
+ encodeURI / decodeURI:一般用于对整个URL的编码,它只编码中文和部分特殊符号,对于URL地址中的有效符号不编码
+ encodeURIComponent / decodeURIComponent:一般用于对URL问号传参的值进行部分编码,因为除了encodeURI可以编码的东西外,对于URL地址中的有效符号也能编码,所以不适合整个URL
+ escape / unescape:不是所有后端语言都支持这个API,所以只用于客户端两个页面间数据传输的编译
第二步:缓存检查
“缓存”存储在哪了?
+ 虚拟内存(内存条):页面关闭,存储的东西会消失 Memory Cache
+ 物理内存(硬盘):持久存储 Disk Cache
关于“静态资源文件”的缓存有两种:强缓存、协商缓存
+ 不论哪一种都是服务器设置规则,客户端浏览器会自动配合完成,无需我们写代码
+ 一般真实项目中,强缓存、协商缓存都会设置「也可以只设置一个」,强缓存失效的情况下,再去走协商缓存的机制
强缓存:Cache-Control(HTTP/1.1)、Expires(HTTP/1.0) 服务器设置的“响应头”信息
+ cache-control: max-age=2592000
+ expires: Sun, 15 May 2022 20:14:22 GMT
+ 不论是从服务器获取,还是从缓存中读取,HTTP状态码都是200
问题:如果本地缓存生效,但是服务器更新了这个资源,如何保证客户端可以获取最新的?
+ HTML页面资源“绝对不能”做强缓存,因为其实页面渲染的入口,所有其它资源也是在渲染解析HTML代码的时候,再去请求的!!
协商缓存:哪怕本地有缓存也要去和服务器进行协商
第一次请求页面,本地没有缓存,向服务器发送请求,如果需要设置协商缓存,服务器会在响应头中返回:Last-Modified(记录资源最后一次更新的时间) / ETag(记录资源最后一次更新的标识);客户端浏览器看到标识后,把标识和资源都缓存起来!!
第二次请求,也会向服务器发送请求,并且在请求头中,基于If-Modified-Since/If-None-Math分别把存储的Last-Modified/ETag值传递给服务器;服务器获取标识后,和本地资源(最新更新时间/标识)做对比;
+ 如果资源没有更新过,则时间/标识是一致的,服务器返回304;客户端发现是304,则从本地缓存中获取;
+ 如果资源更新了,则时间/标识是不一样的,服务器返回200和最新的内容以及最新的Last-Modified/ETag;客户端在把最新的信息存储起来!!
......
===>真实项目开发,建议大家:HTML页面只设置协商缓存、其余的静态资源强缓存和协商缓存都去设置!!
数据缓存:前端开发者,基于本地存储方案,对于“不经常更新”的数据请求,做的缓存处理
+ 第一次从服务器获取数据,存储在本地「设置一个有效周期」
本地存储方案:受“源”和“浏览器”的限制
+ cookie
具备有效期,设置cookie的时候自己设置
最多只允许存储4KB的内容
cookie和服务器有猫腻:在非跨域请求下,如果本地有cookie,不论服务器是否需要,每一次发送请求,都默认把cookie基于请求头传递给服务器「利:如果需要把cookie传递给服务器,我们比较省心;弊:cookie比较多,每一次请求都携带大量的信息进行传递,把请求变慢!」
cookie不稳定:清除历史记录、安全卫士清理垃圾可能会清除掉cookie;浏览器的隐私或者无痕模式,不记录cookie!
+ localStorage
持久化存储,除非自己手动删除或者卸载浏览器
最多允许存储5MB的内容
localStorage默认和服务器是没有关系的,除非自己手动把它存的信息传递给服务器!!
localStorage相对比较稳定一些!!
+ sessionStorage
会话存储,页面刷新存储的信息会在;页面关闭,存储的信息会消失;
+ 虚拟内存存储「例如:全局变量、vuex、redux」
页面刷新或者关闭,存储的信息都会释放!!
+ ...
+ 以后再发送请求,我们校验本地是否有此数据的缓存(而且是否在有效期内)
+ 如果没有:向服务器发送新的请求,获取最新的数据
+ 如果有:直接从本地存储的数据中拿出来渲染
第三步:DNS解析「域名解析」
浏览器地址栏输入域名,会去DNS服务器上找到对应的外网IP,然后基于服务器的外网IP,找到服务器!!
DNS解析记录也会有缓存「谷歌浏览器大概记录1min」
----
前端优化:尽可能减少DNS解析需要的时间
+ 正常:减少DNS解析的次数(也就是所有资源,尽可能都部署到,相同服务器的相同服务下)
+ 真实:我们会把不同资源分不同的服务器部署「Web服务器、图片服务器、数据服务器...」
+ 合理使用资源
+ 提高并发数
+ ...
导致域名解析的次数增加,DNS解析需要的时间也会增加
DNS Prefetch:DNS预解析,利用<link>的异步性,在GUI渲染过程中,同时去解析域名
第四步:TCP的三次握手「让客户端和服务器端建立一个“稳定可靠”的传输通道」
+ TCP:稳定可靠,因为经过三次握手确定传输的稳定性,消耗时间久!! ---> 常规业务都是用它
+ UDP:快速传输,省略三次握手的步骤,直接进行传输;可能存在丢包的情况!! ---> 一般用于直播的业务中
第五步:数据传输
+ HTTP请求报文:请求头、请求起始行、请求主体
+ HTTP响应报文:响应头、响应起始行、响应主体
-----在控制台的NetWork中都可以看到
第六步:TCP的四次挥手「断开客户端和服务器端的连接通道」
+ HTTP/1.1版本开始,默认开启了Connection: keep-alive长连接;当前请数据传输完成后,建立的通道不会被立即释放,下一次请求,继续基于这个通道传输,减少TCP三握四挥的规程,加快数据传输的速度!!
+ 我们在Nginx配置的时候,可以设置keep-alive的周期「根据传输的数量 或者 设置时间」
+ 在客户端把信息传递给服务器之后,四次挥手就已经开始了!!
第七步:页面渲染
+ DOM TREE
+ CSSOM TREE
+ RENDER TREE
+ Layout「回流/重排」
+ 分层
+ Painting
let package_storage = _.storage.get('package_storage', 10000);
if (package_storage) {
// 本地缓存生效,直接从本地获取即可
console.log('成功「缓存」:', package_storage);
} else {
// 本地没有获取失效,则从服务器获取
axios.get(`./package.json?_=${+new Date()}`)
.then(response => {
console.log('成功「服务器」:', response.data);
// 获取后存储到本地
_.storage.set('package_storage', response.data);
});
}
/* 设定具备有效期的localStorage存储方案 */
const storage = {
set(key, value) {
// 存储的时候,记录存储的时间
localStorage.setItem(key, JSON.stringify({
time: +new Date(),
value
}));
},
get(key, cycle = 60000) {
// 默认有效期是1分钟
cycle = +cycle;
if (isNaN(cycle)) cycle = 60000;
let data = localStorage.getItem(key);
if (!data) return null;
let { time, value } = JSON.parse(data);
if ((+new Date() - time) > cycle) {
// 超过有效期,也不获取值
storage.remove(key);
return null;
}
// 在有效期内,才获取值
return value;
},
remove(key) {
localStorage.removeItem(key);
}
强缓存和协商缓存都是在nginx上配置,数据缓存是前端自己写代码
更多推荐
HTTP网络知识
发布评论