FCP指标优化实战：提升首屏加载速度的关键技巧

核心代码就这几行，但别小看它

上周上线一个新项目，老板盯着 Lighthouse 报告问：“FCP 为什么 2.8 秒？首页不是就几张图加个标题吗？”我心想，这不就是白屏时间嘛，赶紧查。折腾了半天，发现根本不是资源加载慢，而是关键渲染路径被 JS 阻塞了。后来用 Performance API 直接打点，定位问题快得一批。所以今天不讲大道理，直接上代码。

最简单、最直接的 FCP 获取方式，用 PerformanceObserver：

if ('performance' in window) {
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      if (entry.name === 'first-contentful-paint') {
        console.log('FCP:', entry.startTime);
        // 这里可以发到你的监控系统
        // sendToAnalytics('FCP', entry.startTime);
      }
    }
  });

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

亲测有效，Chrome、Edge、新版 Safari 都支持。但注意，这段代码必须放在 head 里尽早执行，否则可能错过 FCP 事件。我一开始把它放到底部，结果经常收不到数据，还以为是浏览器兼容问题，结果纯属自己写错位置。

这个场景最好用：配合 Web Vitals 库

如果你不想自己处理兼容性，或者项目里还要测 LCP、CLS 等其他指标，强烈建议直接用 Google 官方的 web-vitals 库。安装简单，API 清晰，还帮你处理了各种边缘情况。

npm install web-vitals

import { getFCP } from 'web-vitals';

getFCP((metric) => {
  console.log('FCP:', metric.value);
  // 上报逻辑
  fetch('https://jztheme.com/api/metrics', {
    method: 'POST',
    body: JSON.stringify({
      name: metric.name,
      value: metric.value,
      id: metric.id,
    }),
  });
});

这个库的好处是，它会自动判断是否支持 FCP，不支持的浏览器直接不执行，不会报错。而且它用的是“异步上报”策略，不会阻塞主线程。我之前自己手写的时候，有一次在低端机上触发了长任务，反而影响了性能，后来换成这个库就稳了。

踩坑提醒：这三点一定注意

1. **FCP 不等于“用户看到内容”**。FCP 是指浏览器首次渲染文本、图片、非白色背景等任意内容的时间。但如果你的首屏是全白背景 + 一个 loading 动画（比如 spinner），那 FCP 可能发生在 loading 出现时，而不是真实内容出现时。我之前就误判过，以为 FCP 1.2 秒很快，结果用户反馈“白屏好久”。后来发现，loading 动画触发了 FCP，但真实数据还没回来。所以尽量让关键内容尽早进入 DOM，哪怕只是骨架屏，也比纯白或 spinner 更利于 FCP 表现。

2. **不要在 SPA 的路由切换后测 FCP**。FCP 是页面生命周期事件，只在首次加载时触发一次。如果你用 React/Vue 做单页应用，切换路由后页面没刷新，那不会再有新的 FCP。这时候你想测“新页面”的渲染速度，应该用 LCP 或者自定义指标（比如组件 mount 时间）。我曾经试图在 Vue Router 的 afterEach 里重新监听 FCP，结果永远收不到，浪费半天时间。

3. **本地开发环境数据不准**。FCP 受网络、CPU、缓存影响极大。你在本地 localhost 开发，资源秒开，FCP 可能 0.3 秒；但用户用 3G 网络 + 低端机，可能 3 秒以上。所以<strong一定要在真实设备或模拟弱网环境下测试。Chrome DevTools 的 Network Throttling 和 CPU Throttling 功能很实用，建议每次优化后都跑一遍。另外，Lighthouse 报告里的 FCP 是模拟值，和真实用户数据（RUM）可能有差异，两者都要看。

高级技巧：把 FCP 当作性能水位线

我们团队现在有个约定：FCP 超过 1.8 秒就要 review。怎么实现自动监控？很简单，在上报 FCP 的同时，加个阈值判断：

getFCP((metric) => {
  const isSlow = metric.value > 1800;
  if (isSlow) {
    // 打个特殊标记，方便后端筛选
    metric.attribution = { isSlowFCP: true };
  }

  // 统一上报
  navigator.sendBeacon?.('https://jztheme.com/api/metrics', JSON.stringify(metric));
});

这里用 navigator.sendBeacon 而不是 fetch，是因为页面快关闭时，fetch 可能被取消，而 sendBeacon 会尽力保证数据发出。不过要注意，sendBeacon 不能传复杂对象，得先 JSON.stringify。

另外，如果你用的是 Next.js、Nuxt 这类框架，记得检查是否开启了 SSR。SSR 页面通常 FCP 更快，因为 HTML 里已经有内容了。但如果你用了动态导入（dynamic import）或者客户端水合（hydration）太重，也可能拖慢 FCP。我们有个页面用了大量客户端组件，FCP 从 1.1 秒飙到 2.5 秒，后来把首屏关键组件改成同步引入，立马降下来。

最后说两句

FCP 看似简单，但背后涉及资源加载、关键渲染路径、服务端渲染等多个环节。我的经验是：先用 web-vitals 快速接入监控，再结合 DevTools 的 Performance 面板分析具体瓶颈。别一上来就优化图片，有时候问题出在 JS 阻塞或 CSS 加载顺序上。

以上是我踩坑后的总结，希望对你有帮助。这个技术的拓展用法还有很多（比如结合 RUM 做分地域/设备分析），后续会继续分享这类博客。有更优的实现方式欢迎评论区交流。