Please enable JavaScript.
Coggle requires JavaScript to display documents.
经典的性能优化最佳实践 (消除或减少不必要的网络延迟, 将需要传输的数据压缩至最少 (减少DNS查找 (每一次主机名解析都需要一次网络往返,从而增…
经典的性能优化最佳实践
消除或减少不必要的网络延迟,
将需要传输的数据压缩至最少
减少DNS查找
每一次主机名解析都需要一次网络往返,从而增加请求的延迟时间,同时还会阻塞后续请求。
重用TCP连接
尽可能使用持久连接,以消除TCP握手和慢启动延迟;参见2.2.2节“慢启动”
减少HTTP重定向
HTTP重定向极费时间,特别是不同域名之间的重定向,更加费时;这里面既有额外的DNS查询、TCP握手,还有其他延迟。最佳的重定向次数为零。
使用CDN
把数据放到离用户地理位置更近的地方,可以显著减少每次TCP连接的网络延迟,增大吞吐量。这一条既适用于静态内容,也适用于动态内容;参见4.7.2节中的“不缓存的原始获取”。
去掉不必要的资源
任何请求都不如没有请求快。
针对HTTP 1.x的优化建议
利用 HTTP 管道
采用域名分区
打包资源以减少HTTP请求
嵌入小资源
延迟
延迟是瓶颈,最快的速度莫过于什么也不传输。
在客户端缓存资源
应该缓存应用资源,从而避免每次请求都发送相同的内容
消除不必要的请求开销
减少请求的HTTP首部数据(比如HTTP cookie),节省的时间相当于几次往返的延迟时间。
应该认真对待和监控cookie的大小,确保只传输最低数量的元数据,比如安全会话令牌
传输压缩过的内容
传输前应该压缩应用资源,把要传输的字节减至最少:确保对每种要传输的资源采用最好的压缩手段。
并行处理请求和响应
HTTP 1.x支持有限的并行机制,要求打包资源、跨域分散资源,等等
针对HTTP 2.0的优化建议
HTTP 2.0的主要目标就是提升传输性能,实现客户端与服务器间较低的延迟和较高的吞吐量。
去掉对1.x的优化
每个来源使用一个连接,
HTTP 2.0通过将一个TCP连接的吞吐量最大化来提升性能。事实上,在HTTP 2.0之下再使用多个连接(比如域名分区)反倒成了一种反模式,因为多个连接会抵消新协议中首部压缩和请求优先级的效用。
去掉不必要的文件合并和图片拼接
打包资源的缺点很多,比如缓存失效、占用内存、延缓执行,以及增加应用复杂性。。有了HTTP 2.0,很多小资源都可以并行发送,导致打包资源的效率反而更低。
关于合并文件和拼接图片的负面影响,
11.6节“连接与拼合”
计算图片对内存的需求
所有编码的图片经浏览器解析后都会以RGBA位图的形式保存于内存当中。每个RGBA图片的像素需要占用4字节:红、绿、蓝通道各占1字节,Alpha(透明)通道占1字节。这样算下来,一张图片占用的内存量就是图片像素宽度×像素高度×4字节。
举个例子,800×600像素的位图会占多大内存呢?
800 × 600 × 4 B = 1 920 000 B ≈ 1.83 MB
为什么执行速度还会受影响呢?
浏览器是以递增方式处理HTML的,而对于JavaScript和CSS的解析及执行,则要等到整个文件下载完毕。JavaScript和CSS处理器都不允许递增式执行。
CSS文件越大,浏览器在构建CSSOM前经历的阻塞时间就越长,从而推迟首次绘制页面的时间。类似地,JavaScript文件越大,对执行速度的影响同样越大;小文件倒是能实现“递增式”执行。
1 more item...
利用服务器推送
之前针对HTTP 1.x而嵌入的大多数资源,都可以而且应该通过服务器推送来交付。这样一来,客户端就可以分别缓存每个资源,并在页面间实现重用,而不必把它们放到每个页面里了。
总结: 收敛
要获得最佳性能,应该尽可能把所有资源都集中在一个域名之下。域名分区在HTTP 2.0之下属于反模式,对发挥协议的性能有害:分区是开始,之后影响会逐渐扩散。打包资源不会影响HTTP 2.0协议本身,但对缓存性能和执行速度有负面影响。
http://slides.com/sunng/http09-to-quic
换一个协议