访问页面时queueing为5秒的问题

最新推荐文章于 2025-10-24 11:51:40 发布
原创 最新推荐文章于 2025-10-24 11:51:40 发布 · 6.9k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文探讨了网页加载过程中出现长时间空白的原因。通过浏览器调试工具发现.html请求存在5秒的挂起问题，进一步研究揭示这是由浏览器活动连接数限制导致。

在访问页面时候，偶尔会出现页面空白很久没有显示的情况，但是看到加载的时间都很短，那这个空白的时间哪来的呢？

看了调试工具，发现是.html的请求有一个queueing为5秒的挂起。

最后看了谷歌对这个的解释，是由于浏览器的活动连接数的问题，具体如下：


chrome network 一次timing分析
娃哈哈_的博客
09-11 5152
一、背景 在chrome浏览器运行前端项目时 ，发现页面渲染很慢，F12打开控制台- network，发现有些请求响应时间长达7s多的时间，点击查看timing如下： 如上图所示，该http请求的 waiting(TTFB)时间很长~ 二、几个重要的概念(加粗为重点) 1、Queueing（队列） 【资源调度】期间，浏览器有自己的线程限制，所有的请求不可能都能够同时发送，一般chrome的最大并发连接数为6，根据请求顺序，会将所有请求加入队列中，此概念表示在队列所耗费等待的时间。 2、Stalled（阻塞
聊聊运行时监控方案
老司机的后备箱
09-17 952
在 Web 监控场景中，除了常见的如 FP、FCP、LCP 等都属于页面加载时的性能指标，而页面运行时同样存在一些性能问题导致不好的用户体验，比如丢帧卡顿、内存泄露页面崩溃等。为了能及时发现、定位到这些问题，因此探索运行时的性能监控方案。若内容存在谬误，请帮忙指正。下一篇准备更新《使用 Chrome DevTools Performance 进行长任务归因的详细步骤》
页面性能优化总结
avcpdop2295的博客
09-05 327
页面性能优化总结 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　页面性能优化总结 由于本人前几天一直在解决页面性能、加载慢等问题。解决后，对于该方面知识有一定的认识与理解，现将经验码出来，与大家分享；由于单纯讲解知识点会造...
CentOS搭建Zookeeper
Button的博客
06-02 1327
CentOS搭建zookeeper
网络请求响应慢?到底是前端/后端原因?前/后端又该如何解决?
最新发布
hyy的博客
10-24 398
摘要： 在大屏渲染echarts时，接口响应时间在浏览器中（10s）比Postman（2s）显著延迟。通过开发者工具分析网络请求时间线，发现可能原因包括： Queueing（排队）：浏览器并发请求限制或线程忙碌，建议减少并发请求并使用HTTP/2。 Stalled（阻塞）：TCP/TLS连接问题，建议复用连接（HTTP/2）或优化后端连接池。 TTFB（服务器响应）：后端查询慢、线程阻塞或CORS预检延迟，需优化数据库、缓存或接口逻辑。 下载慢：响应体过大，建议压缩（gzip）或分页返回数据。 解决方案：前
网页加载时浏览器有请求队列限制导致TTFB时间过长
pwk_888的博客
05-30 1935
生产环境中遇到TTFB加载时间过长的问题处理
chrome 接口请求等待时间(installed 已停止)过长问题定位
汤一飞
07-26 2130
消息通知有个接口, 最长有可能等 1 分钟再返回, 而浏览器对同一个域名的并发请求数限制为最多 6 个(针对 http1.1 而言), 导致开 6 个标签页后, 6 个并发请求基本全被这个接口占着了, 其他接口只能排队等某个标签页的这个接口请求完毕退出并发后才能请求, 因此速度变慢。推测是并发请求窗口数量的问题, 屏蔽部分一直 pending 的接口, 发现速度正常了, 搜到上面的参考文章, 看接口请求协议, 果然是 http1.1。测试反馈系统开 6 个标签页后, 反应变的很慢。
queueing 优化_页面性能优化总结
weixin_39628339的博客
12-20 1570
页面性能优化总结由于本人前几天一直在解决页面性能、加载慢等问题。解决后，对于该方面知识有一定的认识与理解，现将经验码出来，与大家分享；由于单纯讲解知识点会造成知识点认识混乱，故将知识分模块讲解；由于项目中主要使用chrome浏览器，故仅讲解以webkit为内核的浏览器机制1.浏览器加载时间：当浏览器对页面进行加载并且解析时，会产生如下几个主要时间：1)、queueing 时间该时间为等候时间，也可...
Head Unit性能优化实战：5招解决Android Auto连接卡顿与资源争抢问题
本文针对车载Head Unit在运行Android Auto时面临的性能瓶颈问题，系统分析了其根源所在，涵盖硬件资源限制、系统调度策略及多任务干扰等因素。通过深入解析Android Auto的通信架构与AOA协议机制，揭示了USB/无线连接...
ConnectUtility性能瓶颈诊断术：5类监控指标精准锁定问题源头（一线专家亲授）
ConnectUtility在高并发场景下面临复杂的性能瓶颈，其问题常表现为连接堆积、延迟升高与资源耗尽。本文系统梳理了连接层、网络传输层、应用处理层及系统资源层的关键监控指标，深入解析TCP握手效率、连接池状态、RTT...
eMMC与SD卡协议深度对比：为什么eMMC成为工业应用首选？5大优势揭晓
[eMMC与SD卡协议深度对比：为什么eMMC成为工业应用首选？5大优势揭晓](https://blog.westerndigital.com/wp-content/uploads/2020/06/sd-card-history-1.png) # 摘要 本文系统探讨eMMC与SD卡的技术演进、协议架构...
基于时间缓存优化浏览器轮询阻塞问题
禅与计算机程序设计的艺术
10-02 502
笔者最先开始排查时以为是后端服务的性能瓶颈，排查是否是当前功能非常耗时有关，查看日志发现接口的耗时基本是毫秒级，不存在性能瓶颈。得出前端轮询不可靠以及websocket方案被驳回之后，笔者采用时间缓存的方案，即将第一次请求的时间缓存下来，后续前端发起的请求都会基于缓存的数据加1s，确保时间不会错误，尽管前端可能会出现延迟，但是页面渲染的时间是不会错的。实际上，随着轮询请求的增加后，响应结果变成了这样，1:00时的数据得到1:01的数据，而1:01的数据得到的也是1:01数据，请求和响应会出现偶发的延迟。
wx.chooseimage 超过了最大请求长度_从Timing看HTTP请求的优化方向
weixin_39634900的博客
12-06 486
1、背景在Chrome开发者工具中，有一个Timing菜单，可以查看每一个HTTP请求耗时分布，如下2、内容Queued at 8.4 msStarted at 8.4 msResource Scheduling DURATIONQueueing 2.98 msConnection Start DURATIONStalled ...
Chrome浏览器Timing研究说明
小小默：进无止境
12-08 4925
DNS查询的时间，当本地DNS缓存没有的时候，这个时间可能是有一段长度的，但是比如你一旦在host中设置了DNS，或者第二次访问，由于浏览器的DNS缓存还在，这个时间就为0了。浏览器得到要发出这个请求的指令，到请求可以发出的等待时间，一般是代理协商、以及等待可复用的TCP连接释放的时间，不包括DNS查询、建立TCP连接等时间等。请求发出后，到收到响应的第一个字节所花费的时间(Time To First Byte)，发送请求完毕到接收请求开始的时间；注意：网页重定向越多，TTFB越高，所以要减少重定向。
开发者工具network里请求pending状态耗时长是为什么？（项目部分页面的请求）
weixin_46917162的博客
11-17 7235
在开发一个数字化大屏项目的时候遇到问题：某个大屏接口请求10多秒才能拿到响应数据，其他大屏页面接口响应很快。
Chrome浏览器Network面板http请求时间分析
weixin_34000916的博客
08-31 1638
Chrome浏览器开发者工具Network窗口下，可以查看下载各组件所需的具体时间 根据上表进行简要分析—— Stalled（阻塞） 　　浏览器对同一个主机域名的并发连接数有限制，因此如果当前的连接数已经超过上限，那么其余请求就会被阻塞，等待新的可用连接；此外脚本也会阻塞其他组件的下载； 　　优化措施： 　　1、将资源合理分布到多台主机上，可以提高并发数，但是增加并行下载数量也会增大...
排队时延(Queuing delay)
weixin_30847939的博客
01-21 1317
网络时延的构成 Network delay including four parts: Processing delay - time routers take to process the packet header. Queuing delay - time the packet spends in routing queues Transmission delay - ...
chrome network分析
weixin_43924896的博客
01-27 1106
转载自chrome network 一次timing分析 一、背景 在chrome浏览器运行前端项目时 ，发现页面渲染很慢，F12打开控制台- network，发现有些请求响应时间长达7s多的时间，点击查看timing如下： 如上图所示，该http请求的 waiting(TTFB)时间很长~ 二、几个重要的概念(加粗为重点) 1、Queueing（队列） 【资源调度】期间，浏览器有自己的线程限制，所有的请求不可能都能够同时发送，一般chrome的最大并发连接数为6，根据请求顺序，会将所有请求加入队列中，此
关于network中timing详解
qq_43121828的博客
09-29 3136
参数具体含义： Queueing：请求文件顺序的排序。浏览器是有线程限制的，发请求也不能所有的请求同时发送，会将请求加入队列中（Chrome的最大并发连接数是6）。此参数表示从添加到待处理队列，到实际开始处理的时间间隔标示。 Stalled（阻塞）：浏览器得到要发出这个请求的指令，到请求可以发出的等待时间，一般是代理协商、以及等待可复用的TCP连接释放的时间，不包括DNS查询、建立TCP连接等时...
解决RabbitMQ安装前必须安装的OTP问题
但由于描述中提到的网站无法访问的问题，我们需要采取替代方法来安装 Erlang/OTP。这通常包括手动下载源代码压缩包，然后使用编译安装的方式在本地环境中构建 Erlang/OTP。 4. 源代码包的编译安装： 从源代码安装...
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值