跳到主要内容

浏览器性能指标与观察能力

浏览器与网络这一层，很多优化讨论最后都会落到一个问题：到底是哪里慢。

如果没有一套观察手段，优化很容易变成“感觉页面快了一点”。

这篇更适合配合渲染流程、缓存、连接建立一起看，重点放在：

  • Performance API
  • PerformanceObserver
  • Navigation Timing
  • Resource Timing
  • Core Web Vitals

先看最常见的几类指标​

1. TTFB​

从请求开始到收到首字节的时间。

更偏网络和服务端链路。

2. FCP​

First Contentful Paint，首次内容绘制。

表示用户第一次看到实际内容的时间。

3. LCP​

Largest Contentful Paint，最大内容绘制。

通常更接近用户“页面主要内容出现”的感受。

4. CLS​

Cumulative Layout Shift，累计布局偏移。

更适合判断页面是否乱跳。

5. INP​

Interaction to Next Paint，交互到下一次绘制的延迟。

更适合反映交互响应是否拖沓。

PerformanceObserver 为什么值得前端会用​

它能持续监听性能条目，而不是每次都手动去 timing 对象里翻。

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(entry.name, entry.entryType, entry.startTime)
  }
})

observer.observe({ entryTypes: ['navigation', 'resource', 'paint'] })

这层很适合：

  • 上报性能指标
  • 调试资源加载顺序
  • 观察关键页面渲染

PerformanceNavigationTiming 常见能看出这些阶段：

  • 重定向
  • DNS
  • 建连
  • TLS
  • 请求发送
  • 首字节返回
  • DOM 解析
  • load 完成

如果页面慢，先拆清楚慢在网络还是渲染，排查会快很多。

resource 这一层能看到什么​

PerformanceResourceTiming 更适合看单个资源：

  • JS
  • CSS
  • 图片
  • 字体
  • 接口请求

能看这些信息：

  • 发起时间
  • 阻塞时间
  • DNS / 连接 / SSL
  • 请求时间
  • 下载时间
  • 资源大小

最常见的观察例子​

监听 paint​

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(entry.name, entry.startTime)
  }
})

observer.observe({ entryTypes: ['paint'] })

通常能看到：

  • first-paint
  • first-contentful-paint

监听 LCP​

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries()
  const lastEntry = entries[entries.length - 1]
  console.log('LCP', lastEntry.startTime)
})

observer.observe({ entryTypes: ['largest-contentful-paint'] })

监听布局偏移​

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('layout shift', entry)
  }
})

observer.observe({ entryTypes: ['layout-shift'] })

什么情况下最该先看指标​

  • 首屏慢
  • 页面跳动
  • 资源请求很多
  • 某些页面在弱网下体验很差
  • 交互卡顿但 bundle 体积看起来不大

web-vitals 这类库为什么常见​

很多项目不会手写全部指标监听逻辑，而是直接用：

  • web-vitals

原因很简单：

  • 浏览器差异处理更成熟
  • 上报逻辑更省事
  • 和真实用户监控更容易接起来

网络层和渲染层怎么一起看​

一个比较稳的排查顺序通常是：

  1. 先看 TTFB
  2. 再看 FCP / LCP
  3. 再看 CLS
  4. 最后看 INP

这样更容易先区分：

  • 慢在网络
  • 慢在主线程
  • 慢在资源加载
  • 慢在布局和绘制

常见误区​

1. 只看 Lighthouse 分数​

分数可以看，但排查问题时还是得回到具体指标和具体资源。

2. 只看 bundle 体积，不看请求链路​

有些页面慢，不是 JS 体积太大，而是：

  • DNS 多
  • 连接多
  • 字体或图片拖慢 LCP

3. 只在本地看，不看真实用户环境​

本地开发机和真实用户网络差异会非常大。

4. 收到指标后不区分页面类型​

文章页、后台页、营销页、实时面板，性能重点本来就不一样。

和这组其他文章怎么配合看​

  • 想看连接建立和 TTFB：看 URL、DNS 与连接建立
  • 想看渲染阶段：看 浏览器渲染流程
  • 想看缓存对资源加载的影响：看 浏览器缓存

参考来源​