这是我参与11月更文挑战的第7天，活动详情查看：2021最后一次更文挑战
按理说，作为一名前端，浏览器控制台各项参数应该比较了解才对。但是就我而言，控制台只是用来查接口是否返回了200，返回的数据是什么。其他的几乎都没有深入了解过，直到有一天，我遇到了一个问题。
问题
我有一个dashboard页面，里面有N张图片和N个图表，平时加载、切换tab没问题，但是我发现，如果在其他tab页停留五分钟以上，再切换到dashboard，相关css包，图片会处于pending中，大概过了2.5s左右，相关内容才请求回来，页面才正常显示，平时毫秒级的请求，在这种情况下竟然达到了接近3秒，具体如下图所示。
点开waterfall，发现有很多参数与平时的请求有出入。接下来我对几个参数进行了具体的学习：
Waterfall参数介绍
Waterfall: 是瀑布流的意思，在 Waterfall 中我们可以看出时间具体花在了哪些部分。
- Queueing：浏览器将资源放入队列的时间，比如遇到更高优先级的请求或请求并发超过6了。
- Stalled：因放入队列时间而发生停滞的时间。 从上图会发现，我遇到的问题就是该阶段时间较长，避免该阶段时间长，可以做些常规优化，比如css/js合并压缩，图片压缩，使用雪碧图，静态资源上CDN。
那如果做了相关优化，时间还比较长的话，一般是Stalled阻塞了。就是说从TCP连接建立完成，到真正可以传输数据之间的时间差，
- Proxy negotiation：与代理服务器协商时间。
- DNS Lookup：DNS 解析时间，浏览器需要将域名转换成 IP。 优化措施：利用DNS缓存；利用Connection：keep-alive特性建立持久连接，可以在当前连接上进行多个请求，无需再进行域名解析。
- Initial Connection：在浏览器发送请求前，需要建立 HTTP 连接的时间。
- SSL：如果网站使用了 HTTPS，这个就是浏览器与服务器建立安全性连接的时间。
- Request sent：请求发送的时间。
- Waiting (TTFB)：等待服务端返回数据的时间，这个时间受制于服务端处理性能。
- Content Download: 浏览器下载资源的时间，这个时间受制于文件大小和带宽。 在了解了上述相关参数后，具体看下我所面临的问题及解决方案。
原因排查
有小伙伴也遇到同样的问题，他们对应问题可能的原因是浏览器对同一个主机域名的并发连接数有限制，因此如果当前的连接数已经超过上限，那么其余请求就会被阻塞，等待新的可用连接；此外脚本也会阻塞其他组件的下载。
而我不存在上述问题，服务端是进行了处理的。我是Stalled时间及Initial connection时间都相对长一些。在上面有介绍，这两个参数的含义。基于此，我将问题锁定在了接口的响应头当中。
在响应头中，对于静态资源的请求没有设置Connection，值为keep-alive：从HTTP/1.1起，浏览器默认都开启了Keep-Alive，保持连接特性，客户端和服务器都能选择随时关闭连接，则请求头中为connection:close。简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的TCP连接。但是Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。
