网页加载时浏览器有请求队列限制导致TTFB时间过长

问题现象：

        Web页面加载时接口请求的等待时间过长，发现调试界面里瀑布上灰色和绿色的占用的时间比较长，实际上获取数据的时间比较短，单独请求某个接口也比较快。

两种时间在调试中的表示：

TTFB解释：Time to First Byte 到第一个字节接收到的时间

分析过程：

通过了解各阶段含义，导致绿色时间条（Waitinng for server response），过长有以下几种情况：

1. 网络延迟：如果网络延迟较高，例如网络连接不稳定、高延迟或带宽受限，会导致 TTFB 时间增加。
2. 接口性能：服务器的性能问题可能导致 TTFB 时间过长。如果服务器负载过高、处理请求的线程或进程不足，或者数据库查询等后端操作耗时较长，都会影响 TTFB 时间。
3. 缓存问题：如果接口响应没有进行适当的缓存配置或缓存策略不合理，每次请求都需要重新生成响应结果。这将导致 TTFB 时间较长，因为服务器需要处理完整的请求并生成响应。
4. 第三方服务延迟：如果 web 页面加载接口依赖于其他的第三方服务，而这些服务的响应时间较长或存在故障，会导致 TTFB 时间延长。

        通俗得说是，传输和服务链路中某一个环节出现了问题，如果是多人反馈基本不是传输问题，某个人反馈则可能是网络传输问题。所以如果切换网络还是有问题，基本是服务链路中出现问题。

        导致出现灰色时间条（Queueing）时间长的原因是，页面中同时对某一个相同域名发出了很多请求，浏览器本身有限制，默认的并发连接数限制通常在 4 到 8 之间。这意味着对于同一域名的请求，浏览器会同时发送 4 到 8 个请求，而其他请求需要等待前面的请求完成后才能发送。这样的限制是为了避免过多的并发请求对服务器和网络带宽造成过大的负载。

        如果页面资源过多不可避免得会出现加载等待的过程，只能通过以下解决方式去优化加载速度和避免出现限制的情况。

排查方向：

        常用的K8S的接口链路基本是 域名DNS ==> 负载均衡网关 ==> nginx反向代理（ingress） ==> 服务 ==> 缓存（如有） ==> 数据库

1. 接口或者存储后端是否有资源使用率的报警
2. 接口并发能力是否足够支撑页面同时请求
3. 代理节点是否正常（检查upstream或者相关配置）

        经排查，接口服务只用单个线程启动，对并发请求的支撑不够，而且页面对同一域名接口的并发请求又多，在处理多个并发请求时导致了接口有等待的情况，导致部分接口绿色时间条过长。而且页面对同一域名的接口请求过多，上一批发送的请求又在等待，导致灰色时间条过长。

        通过调整接口资源，增加进程数量后，并于前端开发告知浏览器该机制，针对请求方式进行优化，页面加载符合项目要求。

以下为几种常见的减少TTFB的方法，主要思路是减少服务器压力和提升后端的处理能力：

1. 域名分片：将资源（如图片、脚本、样式表等）分散到多个子域名下。浏览器对同一域名的并发连接数有限制，但对不同域名的连接数限制是独立的。通过将资源分散到多个子域名下，可以增加浏览器的并发连接数。
2. 合并资源：将多个小的资源文件合并为一个大的资源文件。例如，将多个CSS文件合并为一个CSS文件，将多个JavaScript文件合并为一个JavaScript文件。这样可以减少浏览器发起的请求数量，从而降低并发连接数的压力。
3. 延迟加载：对于不是首次加载必需的资源，可以延迟加载。例如，页面上的图片可以使用懒加载技术，在用户滚动到可见区域时再加载图片。这样可以减少页面初始加载时的并发请求数量。
4. 使用CDN：将静态资源部署到内容分发网络（CDN）上。CDN将资源分发到全球各个节点，使用户从就近的节点获取资源。这样可以减少请求的距离和网络延迟，提高并发连接的效率。
5. 控制并发请求数量：在前端代码中，可以通过控制并发发起的请求数量来避免浏览器的并发连接数限制。可以使用异步加载、延迟加载等技术控制请求的触发时机，确保同时发起的请求数量在浏览器并发连接数的限制范围内。
6. 使用HTTP/2协议：HTTP/2协议支持多路复用，可以在同一个连接上同时发送多个请求和接收多个响应。这样可以避免浏览器并发连接数的限制，并提高请求的效率。
7. 提升接口并发能力：通过提升接口并发处理能力，减少相同接口的处理时间。

        以下是我自己的公众号实用运维，会经常更新我实践过的内容，欢迎大家关注。