Firefox中网页“启动耗时”即页面加载过程，通过Network面板的Finish时间获总下载耗时，Performance面板分析DOMContentLoaded、load、长任务及脚本执行等关键阶段，并结合performance.mark/measurement自定义业务节点以精准定位瓶颈。
Firefox DevTools 本身不直接提供“应用启动耗时”这一抽象指标（如移动端的冷启动/热启动），但对 Web 应用而言，页面加载过程就是它的“启动过程”。你可以通过 Firefox 的开发者工具精准拆解从导航开始到内容可交互的完整耗时链条，定位瓶颈所在。
? 查看网页首次加载总耗时（类比“启动时间”）
打开 Network 面板是最直接的方式：
- 按 Ctrl+Shift+E（Windows/Linux）或 Cmd+Option+E（macOS）打开 Network 面板
- 勾选 Disable Cache（禁用缓存），模拟真实用户首次访问
- 刷新页面（F5 或 Ctrl+R）
- 观察底部状态栏显示的 Finish 时间 —— 这是所有网络请求完成的总耗时
- 点击任意请求 → 右侧 Timing 标签页，可查看分段耗时：
- DNS Lookup
- Initial connection（含 TCP + SSL/TLS 握手）
- Request sent / Waiting (TTFB)
- Content Download
⚠️ 注意：“Finish” ≠ 用户感知的启动完成。它只反映资源下载结束，不包含 JS 执行、渲染、首屏绘制等关键体验阶段。
? 分析主线程执行与首屏渲染（真正影响“启动感”的环节）
Performance 面板用于深入分析页面加载期间的主线程行为：
- 按 Shift+F5 打开 Performance 工具（或菜单：工具 → Web 开发者 → 性能）
- 确保 Enable JavaScript profiler 已勾选（在设置中）
- 点击录制按钮 → 刷新页面 → 自动停止录制
- 查看时间轴中的关键标记：
- DOMContentLoaded（蓝色竖线）：HTML 解析完成，DOM 构建就绪
- Load（紫色竖线）：所有资源（JS/CSS/图片等）加载完毕
- First Paint / First Contentful Paint（FCP）：需结合页面实际渲染判断（Firefox 当前不原生标出 FCP，但可通过帧截图+时间轴估算）
重点关注以下区域：
- 长任务（Long Tasks）：持续 > 50ms 的 JS 执行会阻塞渲染，直接拖慢“可交互时间”
- Layout / Recalculate Style：样式重计算或布局抖动，常见于 JS 动态操作 DOM
-
Script Evaluation：JS 文件解析与执行耗时，尤其注意
main.js、框架初始化代码
? 结合 Timing API 补充自定义启动节点
DevTools 不自动埋点，但你可以主动注入关键时间戳，让分析更贴近业务逻辑：
// 在 HTML head 中尽早插入
performance.mark('app-start');
// 在应用入口（如 React.render / Vue.createApp）前打点
performance.mark('framework-init-start');
// … 初始化后
performance.mark('framework-init-end');
performance.measure('framework-init', 'framework-init-start', 'framework-init-end');
// 最终可交互时
performance.mark('app-interactive');之后在 Performance 面板录制中，点击右上角 ⋯ → Show Timeline Events，即可看到这些 mark 和 measure 标记，与主线程活动对齐分析。
? 对比与回归：识别启动变慢的根源
Firefox 支持导出性能数据（JSON 格式），可用于版本间对比：
- 录制完成后，点击右上角 ⋯ → Save recording
- 将不同版本、不同环境（如 dev vs prod）的记录导入对比工具（如 Perfume.js 可视化器，或本地脚本解析）
- 关注变化显著的指标：
- TTFB 增加 → 后端或 CDN 问题
- Script Evaluation 增加 → 新增逻辑或依赖膨胀
- Layout 时间突增 → 意外触发强制同步布局（如读取 offsetTop 后立即修改 class）
不复杂但容易忽略
