LightHouse

9分钟阅读

作为本地测前端性能，Lighthouse 的 Performance 评分，本质是一个“用户体验代理指标体系”。它并不直接测用户满意度，而是通过一组可量化的时间与行为指标，去逼近用户在“看到内容、能操作、是否流畅、是否稳定”这几个关键阶段的真实感受。

Performance 得分由 6 个核心指标加权计算：

  • FCP（First Contentful Paint）
  • LCP（Largest Contentful Paint）
  • SI（Speed Index）
  • TTI（Time to Interactive）
  • TBT（Total Blocking Time）
  • CLS（Cumulative Layout Shift）

理解这些指标，不是背定义，而是搞清楚三件事：

  1. 它衡量的是页面生命周期中的哪个阶段
  2. 它为什么会影响用户体验
  3. 工程上你可以从哪里动手优化

下面按用户体验时间线来拆解。

一、从“白屏”到“看到内容”：FCP

1. 指标本质

FCP 表示：页面第一次出现任何可见内容的时间。

注意是“任何内容”，哪怕只是一个文本节点、一段背景色，都算。

用户视角：

“页面不是白的了，我知道它在加载”

2. 典型问题

FCP 差，本质是首屏渲染被阻塞：

  • CSS 阻塞渲染
  • 同步 JS 阻塞 HTML 解析
  • 字体加载导致文本不可见（FOIT）

3. 核心优化方向

（1）消除渲染阻塞资源

关键点：

  • 同步 <script> 会阻塞 HTML 解析
  • <link rel="stylesheet"> 会阻塞渲染

优化手段：

  • JS 加 defer / async
  • CSS 提取关键 CSS + 延迟加载非关键 CSS
  • JS 代码拆分

（2）关键资源前置

核心思想：

让浏览器更早知道“最重要的资源是谁”

<link rel="preload" as="script" href="critical.js">
<link rel="preload" as="style" href="critical.css">

（3）字体策略

避免 FOIT，优先展示系统字体。

4. 本质总结

FCP 优化的核心就是一句话：

尽快让浏览器“画点东西出来”，哪怕不完整。

二、从“有内容”到“核心内容”：LCP

1. 指标本质

LCP 表示：

最大可见内容完成渲染的时间

通常是：

  • 首屏大图
  • Banner
  • 主要文本块

用户视角：

“我真正关心的内容出来了”

2. 为什么 LCP 比 FCP 更重要

FCP 可能只是一个 loading skeleton

但 LCP 才是用户真正“开始阅读”的时刻

3. 影响 LCP 的三大核心因素

（1）服务器响应时间（TTFB）

  • HTML 返回慢 → 一切都慢

（2）渲染阻塞资源

  • CSS / JS 阻塞 → LCP 延迟

（3）资源加载速度

  • 图片太大
  • 未压缩
  • 未走 CDN

4. 核心优化策略

（1）优化首屏资源加载

  • 图片压缩 + WebP
  • 使用 CDN
  • 响应式图片

（2）预加载 LCP 资源

（3）减少 JS 阻塞

  • SSR 或预渲染
  • 减少 hydration 负担

5. 本质总结

LCP 优化的核心：让“最重要的内容”尽早出现

三、页面“填充速度”：Speed Index

1. 指标本质

SI 衡量的是：

页面内容“逐步填满”的速度

它不是看某一个时间点，而是看整个过程的“视觉进度”。

2. 直观理解

两种页面：

  • A：逐渐加载（骨架屏 → 内容填充）
  • B：一直白屏 → 一次性全部出来

两者时间一样，但：

  • A 的 SI 更好
  • B 用户体验更差

3. 计算逻辑（理解即可）

SI 是对“每一帧未填充区域”的积分：

  • 填充越早 → 分数越低（越好）

4. 优化方向

本质还是：

  • 提前渲染
  • 渐进式加载
  • 优化关键渲染路径

5. 本质总结

不要让用户“干等”，要让页面“逐步变完整”

四、从“能看”到“能用”：TTI

1. 指标本质

TTI 表示：

页面什么时候可以稳定响应用户操作

条件：

  • 页面已渲染（FCP 已发生）
  • 事件监听已绑定
  • 主线程空闲（无长任务）

2. 核心问题：JS 过重

JS 会影响：

  • 下载时间
  • 解析时间
  • 执行时间（主线程）

3. 典型问题

  • 大 bundle
  • 长任务阻塞主线程
  • 复杂计算在主线程执行

4. 优化手段

（1）代码拆分

（2）减少主线程压力

  • Web Worker
  • 拆分长任务

（3）PRPL 模式

  • Preload
  • Render
  • Pre-cache
  • Lazy-load

5. 本质总结

TTI 优化的核心是：让 JS 不要“霸占主线程”

五、交互卡顿：TBT

1. 指标本质

TBT 衡量：

从 FCP 到 TTI 期间，主线程被阻塞的总时间

规则：

  • 单个任务 > 50ms → 视为“长任务”
  • 超出部分计入 TBT

2. 举例

  • 一个任务执行 70ms
  • 阻塞时间 = 20ms

3. 为什么重要

用户点击按钮没反应，本质原因就是：

主线程被 JS 占住了

4. 优化手段

（1）拆分长任务

  • requestIdleCallback
  • requestAnimationFrame

（2）减少 DOM 操作

错误：

（3）减少 JS 体积

  • Tree shaking
  • 删除无用代码
  • 控制第三方脚本

5. 本质总结

TBT 本质是在量化“页面卡不卡”

六、页面稳定性：CLS

1. 指标本质

CLS 衡量：

页面加载过程中“元素乱跳”的程度

2. 用户感知

典型场景：

  • 正要点按钮 → 页面一抖 → 点错
  • 内容突然下移

3. 计算逻辑

CLS = 影响区域 × 位移距离

4. 常见问题

（1）图片无尺寸

浏览器不知道大小 → 后加载 → 布局变化

（2）广告 / iframe

动态插入 → 挤压内容

（3）动态内容插入

在顶部插入内容 → 全部下移

5. 解决方案

（1）固定尺寸

（2）预留空间

  • skeleton
  • 占位符

（3）避免非用户触发的布局变化

6. 本质总结

CLS 本质是在衡量“页面是否稳定”

七、六大指标之间的关系

可以用一个完整的用户体验流程来理解：

  1. FCP：页面开始有内容
  2. LCP：核心内容出现
  3. SI：内容逐步填充
  4. TTI：页面可以操作
  5. TBT：操作是否流畅
  6. CLS：页面是否稳定

如果你要在面试中讲清楚 Lighthouse Performance，可以用这一段：

Lighthouse Performance 本质是围绕用户加载体验构建的一套指标体系，从“是否看到内容”到“是否可以交互”，再到“是否流畅稳定”进行全链路衡量。

FCP 和 LCP 解决的是内容呈现问题，SI 描述渲染过程的平滑性，TTI 和 TBT 衡量主线程是否被阻塞影响交互，CLS 则关注页面布局稳定性。

在工程实践中，优化路径可以抽象为三件事：优化关键渲染路径、降低 JavaScript 主线程负载、以及保证布局稳定性。

若有收获，就点个赞吧