必须用开发者工具network面板查看真实请求瀑布流：f12打开→切network→提前启动录制→过滤域名并按waterfall排序→重点查stalled和ttfb异常值→导出.har文件协同分析。
要精准定位百度浏览器中网页加载慢的性能瓶颈，必须直接查看真实请求的网络瀑布流，而不是依赖测速工具或主观感知——瀑布流能暴露DNS延迟、连接阻塞、资源排队、首字节过长等肉眼不可见的卡点。
打开开发者工具并切换到Network面板
按 F12 或右键页面空白处选择“检查” → 顶部标签页中点击 Network；若未自动开始录制，点击左上角圆形录制按钮（红色●）启动捕获。
这一步必须在新标签页中打开目标网页前就完成，否则会漏掉HTML主文档请求——而首页HTML延迟是白屏最常见原因。
过滤并聚焦首屏关键请求
在Network面板上方过滤框输入 domain:baidu.com（替换成你要分析的实际域名），只保留该域下的请求；再点击 Waterfall 列标题，按耗时从长到短排序。
重点看排在前5–8位的请求：它们大概率是HTML、首屏CSS、关键JS、LCP图片。如果其中某个请求的Stalled时间明显偏长（比如＞200ms），且紧接在Initial connection之后，说明它正卡在浏览器并发连接限制上。
识别典型并发阻塞模式
方法一：观察同域名请求的启动时间轴
① 找出所有协议为 http/1.1 的同域名请求（如 static.example.com 下的12个JS）
② 看前6个是否基本同步发起（起始时间差＜50ms）
③ 第7个及之后是否在前一批任一请求的Content Download结束瞬间才开始Stalled→Initial connection——这就是【浏览器强制限6连接】的铁证
百度热榜监控 | Baidu Hot Topics Monitor. 获取百度热搜榜、搜索趋势、关键词热度 | Get Baidu trending searches, trends, keyword popularity. 触发词：百度、热搜、baidu.
方法二：用Connection ID列交叉验证
右键Network表头 → 勾选 Connection ID → 若多个请求共享同一ID且时间连续，说明复用成功；若ID频繁变化且Stalled后立刻新建连接，说明HTTP/1.1下反复建连开销过大。
定位首字节（TTFB）异常请求
点击任意一个耗时最长的HTML或API请求 → 查看Timing标签页 → 关注 Waiting (TTFB) 数值。
若TTFB ＞ 800ms，且DNS、Initial connection、SSL都正常（均＜100ms），问题一定出在服务器端：可能是后端逻辑阻塞、数据库慢查询、未命中CDN缓存或动态渲染超时。这时候优化前端资源毫无意义。
导出瀑布图用于跨团队协作分析
右键Network面板空白处 → 选择“Save all as HAR with content” → 保存为.har文件。
这个文件可直接拖进Chrome或Edge的Network面板中还原完整瀑布流，方便发给后端或运维同事复现问题——注意不要勾选“Include screenshots”，否则文件体积暴增且无实际分析价值。
