Lighthouse不直接分析JS运行时行为，但通过TBT、TTI等指标间接反映JS对主线程的影响，并结合诊断建议定位问题，需配合Chrome DevTools Performance面板深入分析。
Lighthouse 不直接分析 JavaScript 运行时行为（比如函数执行耗时、内存分配、事件循环阻塞），但它能通过关键性能指标间接反映 JS 对运行时体验的影响，并结合诊断建议定位典型 JS 问题。实际使用中，需配合 Chrome DevTools 的 Performance 面板做深度运行时分析。
理解 Lighthouse 在运行时性能中的角色
Lighthouse 是一个“场景化审计工具”，它在模拟受限网络和 CPU 条件下加载页面，测量用户可感知的性能里程碑。它不录制单次函数调用栈，但会捕获 JS 执行对主线程的总体影响，例如：
- TBT（Total Blocking Time）：统计 FCP 到 TTI 之间，主线程被长任务（>50ms）阻塞的总时长——这直接暴露了 JS 执行过久的问题；
- TTI（Time to Interactive）：依赖 TBT 和 CPU 空闲时间推算页面何时真正可响应，JS 优化不到位会显著推迟该时间点；
- Diagnostics 中的提示：如 “Reduce JavaScript execution time”、“Remove unused JavaScript”、“Minimize main-thread work” 等，都指向运行时瓶颈。
用 Lighthouse 发现 JS 运行时问题的操作步骤
在 Chrome 浏览器中打开目标页面 → 按 F12 打开开发者工具 → 切换到 Lighthouse 标签页 → 勾选 Performance 分类 → 取消勾选其他无关项（如 SEO、Accessibility）以聚焦核心指标 → 点击 Generate report。
关键操作建议：
立即学习“Java免费学习笔记（深入）”；
- 务必在 隐身模式 下运行，避免扩展干扰；
- 勾选 Clear storage，确保测试基于首次加载场景；
- 保持默认的 Simulated throttling（4x CPU slowdown + 3G 网络），这对暴露 JS 主线程压力更真实；
- 若页面需登录，先手动登录再运行，或改用 CLI + Puppeteer 方式控制流程。
从报告中解读 JS 相关运行时线索
生成报告后，重点关注以下三处内容：
- Performance 分数下方的指标卡片：LCP、TBT、CLS 数值偏低或标红，往往与 JS 渲染逻辑、动态插入 DOM、未优化的动画或第三方脚本有关；
- Diagnostics → “Avoid enormous network payloads”：大体积 JS 文件会延长解析/编译时间，拖慢 TTI；
- Diagnostics → “Minimize main-thread work” 展开项：列出各资源的脚本评估（Script Evaluation）、脚本解析（Script Parse）和脚本执行（Script Execution）耗时，点击可跳转到对应 Performance 面板的火焰图位置。
配合 DevTools Performance 面板做深入运行时分析
Lighthouse 报告里的 “View original trace” 按钮会导出并打开完整的 Performance 录制记录。这时可：
- 在 Main 轨道中查找红色长任务（Long Tasks），展开看具体执行了哪些 JS 函数；
- 用 Bottom-up 或 Call Tree 视图定位耗时最高的函数及其调用链；
- 检查 Memory 轨道是否伴随内存持续增长，辅助判断是否存在闭包泄漏或未清理的事件监听器；
- 对比优化前后同一交互的录制，验证防抖、虚拟滚动、代码分割等措施的实际效果。
不复杂但容易忽略：Lighthouse 是运行时性能的“体检报告”，不是“手术刀”。它告诉你“哪里不舒服”，而真正“查病因、动手术”，还得靠 Performance 面板+代码审查+User Timing 打点。
