共计 1014 个字符，预计需要花费 3 分钟才能阅读完成。
查看网络面板
响应比较慢可以从两个层次去考虑
连接初始化阶段耗时
请求和响应耗时
查看关键指标：
排队
达到浏览器最大并发数量限制
有更高优先级的请求插队，低优先级的任务被延后
系统内存空间不足，浏览器使用磁盘空间
拥堵 原因和排队中类似
DNS 查询 花在 DNS 查询上的时间
Proxy negotiation. 代理协商
Request sent. 请求被发送
Request to ServiceWorker. 请求被发送到 ServiceWork
Waiting (TTFB). 等待收到响应的第一个字节
Content Download. 内容下载
Receiving Push. 浏览器通过 HTTP/2 Server Push 接受数据
Reading Push. 浏览器读取之前收到的数据
常见问题现象及解决方法
出现长时间的排队或者拥堵
原因 浏览器对同一域名最大的 TCP 链接数有限制，超过限制的请求会被排队。
参见浏览器同域名请求的最大并发数限制。
为什么会达到最大并发数？
一次性获取的资源数量太多
资源体积太大，很多都在下载中
有些请求响应太慢或者无响应。例如 1 分钟之内，每隔 10 秒钟发送一个无响应的请求，随着可用的请求慢慢被占满，正常的请求排队数量会越来越多。
解决方法
问题 1 和问题 2 比较容易发现，也比较好处理。主要从两个角度解决
减少请求数量。可以移除不必要的请求，或者将多个请求合并成 1 个。例如雪碧图
使用域名分片。例如使用不同的域名指向相同的资源，从而突破单域名的限制。例如 img1.tt.cc/1.jpg 和 img2.tt.cc/1.jpg
前端给每个 ajax 请求设置超时 防止过多的无响应请求占据着连接资源，可以在超时之后释放连接。有些 ajax 库，例如 jQuery 的 ajax, 默认是没有设置超时时长的，当你在使用这些库时，最好明确的设置
后端设置请求处理超时 后端接口应当设置最大超时时长
长时间的 TTFB
出现这种问题要从两个方面排查
客户端到服务端之间的网络通信比较慢
服务端的响应比较慢，可能是服务端压力太大，到达带宽上线，内存溢出，高 CPU, IOwait 高, Recv- Q 高，或者 sql 查询慢等各种原因。
注意：对于同一个源的请求，如果有些请求很快，有些请求很慢。那么问题一般是服务端的问题。因为如果是出现网络通信比较慢，那么则所有的请求都会变慢。
解决方案
知道问题的真实原因，其实问题也就解决了一半了。
参考
network-performance
network issue guide
浏览器同域名请求的最大并发数限制
