浏览器请求响应慢，该从哪些方面分析（转）

原文链接：https://segmentfault.com/a/1190000017715100

查看网络面板

响应比较慢可以从两个层次去考虑

1. 连接初始化阶段耗时
2. 请求和响应耗时

查看关键指标：

• 排队

  • 达到浏览器最大并发数量限制
  • 有更高优先级的请求插队，低优先级的任务被延后
  • 系统内存空间不足，浏览器使用磁盘空间
• 拥堵 原因和排队中类似
• DNS查询 花在DNS查询上的时间
• Proxy negotiation. 代理协商
• Request sent. 请求被发送
• Request to ServiceWorker. 请求被发送到ServiceWork
• Waiting (TTFB). 等待收到响应的第一个字节
• Content Download. 内容下载
• Receiving Push. 浏览器通过HTTP/2 Server Push接受数据
• Reading Push. 浏览器读取之前收到的数据

常见问题现象及解决方法

出现长时间的排队或者拥堵

原因 浏览器对同一域名最大的TCP链接数有限制，超过限制的请求会被排队。

参见浏览器同域名请求的最大并发数限制。

为什么会达到最大并发数？

1. 一次性获取的资源数量太多
2. 资源体积太大，很多都在下载中
3. 有些请求响应太慢或者无响应。例如1分钟之内，每隔10秒钟发送一个无响应的请求，随着可用的请求慢慢被占满，正常的请求排队数量会越来越多。

解决方法

问题1和问题2比较容易发现，也比较好处理。主要从两个角度解决

1. 减少请求数量。可以移除不必要的请求，或者将多个请求合并成1个。例如雪碧图
2. 使用域名分片。例如使用不同的域名指向相同的资源，从而突破单域名的限制。例如img1.tt.cc/1.jpg和img2.tt.cc/1.jpg
3. 前端给每个ajax请求设置超时 防止过多的无响应请求占据着连接资源，可以在超时之后释放连接。有些ajax库，例如jQuery的ajax, 默认是没有设置超时时长的，当你在使用这些库时，最好明确的设置
4. 后端设置请求处理超时 后端接口应当设置最大超时时长

长时间的TTFB

出现这种问题要从两个方面排查

1. 客户端到服务端之间的网络通信比较慢
2. 服务端的响应比较慢，可能是服务端压力太大，到达带宽上线，内存溢出，高CPU, IOwait高, Recv-Q高，或者sql查询慢等各种原因。

注意：对于同一个源的请求，如果有些请求很快，有些请求很慢。那么问题一般是服务端的问题。因为如果是出现网络通信比较慢，那么则所有的请求都会变慢。

解决方案

知道问题的真实原因，其实问题也就解决了一半了。