必须先点击红色录制按钮启用监听并禁用缓存，否则无法捕获真实请求；再通过XHR/fetch过滤、Timings瀑布图分析DNS/TCP/SSL/TTFB/下载各阶段耗时，结合Disable cache、Preserve log等设置提升数据可信度。
打开网络面板并确保请求被完整捕获
要在火狐浏览器中准确分析网页请求和响应各阶段耗时，必须先让Network面板处于实时监听状态，否则所有时间数据都是空的。按下 Ctrl + Shift + E（Windows/Linux）或 Cmd + Option + E（macOS），直接唤出开发者工具并自动切换到 Network 面板。
检查左上角的圆形录制按钮——若为灰色，说明捕获已暂停；【必须点击一次使其变为红色高亮】，否则后续所有操作都不会被记录。这一步操作起来很简单，但漏掉就会白忙一场。
触发请求并定位目标条目
在网页中执行你要分析的动作：比如点击“立即支付”按钮、下拉刷新列表、或在搜索框输入关键词后回车。动作完成后，Network 面板下方会立即出现一长串请求。
此时在顶部过滤栏输入 XHR 或 fetch，只显示 JavaScript 发起的异步请求——这类请求最常携带业务参数且响应结构清晰，是分析响应时间的首选目标。
找到你关心的那条请求（例如 https://api.example.com/v2/order），单击其 Name 列，右侧将展开详情视图。
查看瀑布图并解读各阶段耗时
点击任一请求后，在右侧切换到 Timings 标签页，展开 Waterfall 视图。每一条彩色横条代表一个底层网络阶段：
深绿色：DNS Lookup —— 域名解析耗时，过高说明本地 hosts 配置异常或 DNS 服务器响应慢；
橙色：TCP Connection —— 建立 TCP 连接的时间，受网络抖动或服务器连接池满影响；
紫色：SSL/TLS Negotiation —— HTTPS 握手耗时，若使用老旧 TLS 版本或证书链过长，此段会显著拉长；
绿色：Time to First Byte（TTFB）—— 从请求发出到收到首字节的时间，直接反映后端处理速度；
蓝色：Content Download —— 实际下载响应体所用时间，与资源体积、带宽及压缩率强相关。
【若 TTFB 占比超过总耗时的 70%，问题大概率在服务端逻辑或数据库查询】；若蓝色下载段异常长，优先检查是否未启用 Gzip/Brotli 压缩或返回了冗余字段。
启用关键设置提升时间分析可信度
方法一：禁用缓存以获取真实首屏耗时
点击右上角齿轮图标 → 勾选 Disable cache when DevTools is open → 刷新页面。缓存命中会使 TTFB 和 Download 时间严重失真，尤其对登录态接口和动态资源。
方法二：保留跨页日志防止请求丢失
同样在设置中勾选 Preserve log。当你需要分析“登录→跳转→拉取用户数据”这一连贯流程时，不开启此项，页面跳转后前一页的请求记录会被清空。
方法三：排除 Service Worker 干扰
右键 Network 面板空白处 → 选择 Disable Service Workers。否则部分请求会显示为 from ServiceWorker，Timing 图完全不可见，所有阶段被压缩成毫秒级假象。
排序与筛选耗时异常的请求
第一步：点击列标题 Time，按总耗时降序排列，快速聚焦最慢的几条请求；
第二步：右键顶部列标题 → 勾选 Waterfall 显示时间轴缩略图，一眼识别是否存在大量浅蓝 Stalled 或灰色 Queuing；
第三步：在过滤栏输入 largest，列出传输体积最大的资源，常与长下载时间强关联；
第四步：输入 status-code:4xx 或 status-code:5xx，单独查看失败请求的 Timing 分布——很多 401/403 是因 Token 过期导致重定向链路拉长，TTFB 反而不高。
