Core Web Vitals 不是玄学：一次端到端的前端性能体检

六月给某公司官网做了一次性能“体检”，目标很明确：把 LCP 压到 2.5s 内，把 INP 控制在 200ms 内。以下是完整的拆解，包含指标采集、CDN 调参、前端代码改造以及回归验证。

---

1. 现状扫描：指标先于直觉

• 数据来源：Chrome UX Report、WebPageTest、自建 RUM（埋点来自 Boomerang）
• 真实数据（改造前）：

指标	P75	目标	备注
LCP	3.4s	≤ 2.5s	首屏 hero 图 800KB，CDN 未开启预拉取
INP	320ms	≤ 200ms	首页分类切换产生同步渲染阻塞
CLS	0.12	≤ 0.1	字体异步加载导致标题跳动

结论：问题主要集中在“资源体积”和“交互阻塞”两侧。

---

2. 平台与基础设施调优

2.1 CDN 策略

服务商：Cloudflare + 自建 Nginx。针对静态资源做了三件事：

1. 分域名：static.example.com 独立 cookie 域；
2. Cache Key 调整：对 .js/.css/.webp 使用版本化文件名，cache TTL 提升到 7 天；
3. Early Hints：开启 103 Early Hints，把关键 CSS/字体预拉取到浏览器排队前。

配置片段：

location ~* \.(js|css|webp)$ {
	add_header Cache-Control "public, max-age=604800, immutable";
	add_header Early-Data 1;
	try_files $uri =404;
}

2.2 图片管线

• 原 hero 图 800KB → WebP + 按需裁剪后降到 230KB；
• 使用 preload + fetchpriority="high" 明确告知浏览器；
• 引入 react-wrap-balancer 控制标题折行，避免 CLS。

---

3. 前端代码层面的手术

3.1 组件分层

• 把“首屏展示”和“互动组件”拆成两个 bundle；
• 使用 import('...') 动态加载互动面板，配合 React.Suspense；
• 构建后 main.js 从 420KB 压到 268KB。

3.2 交互去抖

分类面板原来在 onChange 里直接发 3 个请求 + 同步 setState，渲染锁死。改造：

const load = useMemo(() => debounce(fetchCategory, 120), [])

同时把请求并发交给后台 BFF，由服务端聚合。

3.3 字体策略

• 切换为 font-display: optional，预加载首屏所需字体；
• 通过 @font-face 的 unicode-range 拆字库，首屏仅加载拉丁字形。

---

4. 回归验证与监控上墙

改造后的指标：

指标	P75（改造后）	收益
LCP	2.1s	-1.3s
INP	165ms	-48%
CLS	0.05	稳定

• WebPageTest 首屏渲染截图差异显著，TTFB 下降 120ms，Start Render 提前 0.8s；
• 自建 RUM 配置了 Slack 告警，P75 超过 2.5s 时自动提醒；
• 在 Grafana 上做了一个“性能 Dashboard”，放在团队晨会大屏。

---

5. 经验复用

1. 指标要分“真实用户”与“实验室”两套，后者负责定位，前者负责回归；
2. CDN 调优前先确认缓存命中率，不命中谈不上性能；
3. fetchpriority 对 LCP 影响很大，但要避免滥用；
4. 前端拆包要结合路由访问频率，别把热点模块拆凉了；
5. 性能是长期工程，把监控挂墙比写日报更有效。

性能优化到这一层，重点不在“写了多少代码”，而是把指标当产品做，把每次调整都纳进流水线。下一步会考虑引入 Server Components 与 Edge Cache 做增量实验。