网页加载慢测试：HTML 已返回，首屏为什么还在等

网页加载慢测试里，常见一种情况：HTML 已经返回，页面仍白着，或者只有一部分文字。此时继续盯服务器响应时间，可能找不到真正的等待。需要沿页面后续的资源、脚本和渲染过程查下去。

先确认 HTML 是正确页面

200 响应可能只是应用外壳，也可能是错误模板或验证页面。检查正文、最终网址和控制台错误。若页面依赖接口填充内容，主文档成功还不能证明文章、商品或列表已经取得。

然后保存一次浏览器加载记录。用 Network 面板查看主文档后请求，配合截图或录屏找到用户实际等待的内容。

样式、字体和主图是否挡在显示之前

关键样式迟到会影响页面显示；首屏图片可能很大，也可能直到脚本执行后才被发现；字体加载策略可能影响文字显示与布局。把这些资源的开始时间、完成时间和画面对应，而不是见到大文件就认定它拖慢所有内容。

对于 LCP 元素，重点检查它何时可被发现、何时取得资源、何时真正呈现。LCP 文档解释了指标与元素的关系。主图已经下载完成仍迟迟不显示，原因还可能在渲染和页面逻辑。

接口与脚本有没有形成串行等待

一些页面需要先载入脚本，再请求配置，配置返回后再请求内容，最后才插入首屏图片。单个请求都不算特别慢，串在一起仍会让用户等待。沿请求发起者查依赖，看看哪些工作确实必须先完成，哪些可以提前、并行或延后。

调整顺序应保持业务正确性。不能为了首屏数字跳过权限校验，也不应把需要的错误处理删掉。先处理有明确证据的依赖，再复测相同路径。

下载结束，主线程可能仍很忙

脚本解析、执行和框架初始化都会占用浏览器工作时间。网络面板安静了，并不意味着 CPU 已空闲。录制 Performance，观察白屏或卡顿期间的任务，再定位具体脚本与调用。

如果页面能看见，但用户点击后迟钝，要另查交互处理。INP关注交互响应，不能仅凭一次文档下载快就认定交互体验良好。

第三方资源按实际影响处理

统计、客服、广告或嵌入模块可能来自不同域名。先确认失败资源是否阻挡核心内容；对可选功能评估延后加载和失败降级，对核心依赖则查其可达性与替代方案。浏览器提示跨域、证书或脚本异常时，按具体错误处理，别全部归因于带宽。

每改一处，比较同设备、同网络下的请求链和首屏画面。若主文档本身仍慢，回到DNS 到首字节的计时；需要整理关键资源，则看瀑布图分析方法。