火狐network面板请求耗时≠真实网络延迟，因包含dns、tcp、tls等前端阶段且受js阻塞、service worker、扩展干扰；需通过timing瀑布图分析queuing/stalled占比、禁用service worker、无痕模式对比及修改about:config参数（如network.http.speculative-parallel-limit=0）来精准定位。
火狐浏览器开发者工具Network面板中显示的请求耗时与真实网络延迟存在偏差，常见于首屏加载、AJAX重试或Service Worker介入场景，根本原因在于面板默认将DNS解析、TCP连接、TLS握手等前期阶段计入“等待时间”，而实际业务逻辑可能卡在前端渲染或JS阻塞上，导致你误判后端响应慢。
确认耗时统计口径是否被干扰
Network面板顶部时间轴默认显示的是“从请求发起至响应完成”的总耗时（Total），但它不等于后端处理时间，也不包含JS执行阻塞——这个数值受页面主线程繁忙程度影响极大。
点击任一请求 → 查看右侧Timing标签页 → 展开“Waterfall”视图 → 注意各色块分布：灰色（Queuing）表示排队等待，浅蓝（Stalled）表示资源竞争或DNS缓存未命中，深蓝（DNS Lookup）和绿色（Connecting）才是真正网络链路耗时。
【若Queuing或Stalled占比超过30%，说明问题不在服务器，而在浏览器自身调度】——此时刷新页面并勾选“Disable cache”和“Preserve log”，再对比两次Timing，若Stalled显著减少，则证实是缓存复用策略或扩展干扰所致。
排除Service Worker对Timing的篡改
Service Worker一旦激活，会接管fetch请求并返回缓存响应，Network面板中该请求的Timing将丢失真实网络阶段，仅显示“from ServiceWorker”，所有耗时压缩为毫秒级，完全无法反映真实链路延迟。
方法一：右键Network面板空白处 → 选择“Disable Service Workers” → 刷新页面 → 观察Timing是否恢复分段显示。
方法二：在地址栏输入about:debugging#/runtime → 找到当前页面所在Runtime → 点击“Inspect” → 切换到“Service Workers”标签 → 勾选“Unregister”并确认 → 关闭调试页后重启火狐。
注意：禁用后需手动清除已缓存资源，否则仍可能走旧缓存；可在Storage → Cache Storage中删除对应域名缓存。
验证是否受扩展或后台进程拖累
广告拦截器、密码管理器、隐私保护类扩展常在请求发出前注入脚本或重写fetch，导致主线程阻塞，使Network面板记录的“Start Time”严重滞后于实际HTTP请求发出时刻。
第一步：按下Ctrl+Shift+P → 新建无痕窗口 → 访问同一网页 → 按Ctrl+Shift+E打开开发者工具 → 切换到Network面板 → 刷新页面。
第二步：对比无痕模式与普通模式下相同请求的Timing瀑布图，重点比对“Start Time”与“Request Sent”之间的时间差。
第三步：若无痕模式中Stalled/Qeueuing消失且各阶段分布均匀，说明问题出在某个扩展上；回到普通模式 → 地址栏输入about:addons → 逐个禁用可疑扩展 → 每次禁用后刷新验证Timing变化。
强制启用高精度计时并禁用优化干扰
火狐默认启用的一些性能优化机制会合并或延迟请求调度，造成Timing失真，尤其在低速网络或高负载设备上更明显。
在地址栏输入about:config → 点击“I'll be careful, I promise” → 搜索并修改以下三项：
network.http.speculative-parallel-limit → 设为0（禁用预连接，避免虚假排队）
dom.enable_performance_api → 设为true（确保Performance API可用，Timing数据来源可靠）
devtools.netmonitor.har.enableAutoExportToFile → 设为false（防止HAR导出过程干扰主线程计时）
重启浏览器后，再次捕获请求，Timing视图将更贴近真实链路行为。
