探究 LightHouse 工作流程

本文为来自 字节教育-智能学习-前端团队 的文章，已授权 ELab 发布。,智能学习前端团队 自创立以来，团队专注于打破大众对教育的刻板印象，突破固有的教学思维，攻破各类教学屏障。旨在为每一位学生制定最合适的学习方案，予以因材施教，使优质教育随‘触’可达。,Lighthouse analyzes web apps and web pages, collecting modern performance metrics and insights on developer best practices.,,,,通过 Chrome Debugging Protocol 和 Puppeteer[2] (提供无头浏览器环境模拟页面操作) /进行交互。,Chrome Debugging Protocol（CDP）,Chrome DevTools 协议允许使用工具来检测、检查、调试和分析 Chromium、Chrome 和其他基于 Blink 的浏览器。 在Chrome扩展中，Chrome protocol 利用 chrome.debugger Api 通过 WebSocket[3] 来建立连接。,Instrumentation 分为多个 Domains（DOM, Debugger, Network 等）。每个 Domain 定义了许多它支持的命令和它生成的事件。命令和事件都是固定结构的序列化 JSON 对象。,,CDP Domains，红色为实验性,Domain 必须 enable() 后才可以发出事件。一旦启用enable，它们将刷新表示状态的所有事件。因此，网络事件仅在 enable() 后才会发出。所有协议代理解析 enable() 的回调。比如：,调试协议：阅读更好地调试协议Better debugging of the Protocol[4]。,passes 属性控制如何加载请求的 URL，以及在加载时收集哪些关于页面的信息。pass 数组中的每个条目代表页面的一次加载,,每个 pass 都定义了基本设置，例如等待页面加载多长时间、是否记录 trace 文件。此外，每次传递都定义了要使用的 gatherer 列表。gatherer 可以从页面中读取信息以生成 artifacts，稍后 Audits 使用这些artifacts提供 Lighthouse 报告。,具体的 pass 配置示例：,决定在页面加载过程中采集哪些信息，将采集的信息输出为 artifacts。使用 Driver 采集页面信息。用 --gather-mode 指令运行可以获得3个采集产物：,artifacts.json: 所有采集器的输出。,defaultPass.trace.json: 大多数性能指标。可以在DevTools性能面板中查看。,defaultPass.devtoolslog.json: DevTools Protocol[5] 事件的日志。,每一个 gatherer继承自相同的基类 Gatherer，基类 Gatherer定义了传递生命周期的n个方法。 gatherer的artifacts是生命周期方法返回的最后一个未定义值，所有方法都可以直接返回artifacts或返回解析为该值的 Promise。子类只需实现生命周期方法即可。,比如用于js覆盖率的 gatherer：,该实例实现了 startInstrumentation 、stopInstrumentation、getArtifact 3个生命周期方法，其,当 pass 中定义的所有 gatherers 运行完后，就会生成一个中间产物 artifacts，此后 Lighthouse 就可以断开与浏览器的连接，只使用 artifacts 进行后续的分析。,core/lib/tracehouse/trace-processor.js提供了链路到更有意义对象的转换。每个原始trace event[6] 都具有以微秒为单位增长的时间戳、线程ID、进程ID、持续时间以及其他适用的元数据属性（比如事件类型、任务名称、帧等）,Example Trace Event,,Processed trace,Processed trace 可识别关键时刻的 trace 事件（(navigation start, FCP, LCP, DCL, trace end 等)，并过滤出主进程和主线程事件的视图。,,客户端根据生成 Audit 结果的 LHR.json (Lighthouse Result) 生成结果报告页。评分报告，它包含了性能（Performance），访问无障碍（Accessibility），最佳实践（Best Practice），搜索引擎优化（SEO），PWA（Progressive Web App）5 个部分，每一项下面又有若干小项（audit），还有详细诊断结果和优化建议，帮助开发者有针对性地进行优化。,例如：在 Lighthouse 8 中，性能得分由以下几项的得分按不同的权重相加而得：,,Lighthouse 8 中性能指标权重,以性能评分[7]为例，一旦 Lighthouse 收集完性能指标（主要以毫秒为单位报告），它会通过查看指标值在其 Lighthouse 评分分布中的位置，将每个原始指标值转换为从 0 到 100 的指标分数。评分分布是从 HTTP Archive[8] 上真实网站性能数据的性能指标得出的对数正态分布。,,FCP in HTTP Archive,Lighthouse 评分曲线模型使用 HTTPArchive 数据来确定两个控制点，然后设置对数正态曲线的形状。HTTPArchive 数据的第 25 个百分位数变为 50 分（中值控制点），第 8 个百分位数变为 90 分（良好/绿色控制点）。在探索下面的评分曲线图时，请注意在 0.50 和 0.92 之间，度量值和分数之间存在近乎线性的关系。0.96 左右的分数是上面的“收益递减点”，曲线拉开，需要越来越多的指标改进来提高已经很高的分数。,,探索 TTI 的评分曲线[9],指标得分和性能得分根据以下范围进行着色：,0至49（红色）：差,50至89（橙色）：需要改进,90至100（绿色）：良好,为了提供良好的用户体验，网站应该努力获得良好的分数（90-100）。,[1]原理结构: https://github.com/GoogleChrome/lighthouse/blob/main/docs/architecture.md,[2]Puppeteer: https://github.com/puppeteer/puppeteer,[3]WebSocket: https://github.com/websockets/ws,[4]Better debugging of the Protocol: https://github.com/GoogleChrome/lighthouse/issues/184,[5]DevTools Protocol: https://chromedevtools.github.io/devtools-protocol/,[6]trace event: https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview,[7]性能评分: https://web.dev/performance-scoring/,[8]HTTP Archive: https://httparchive.org/reports/state-of-the-web,[9]探索 TTI 的评分曲线: https://www.desmos.com/calculator/o98tbeyt1t