Core Web Vitals：让网站真正快起来

「在我机器上没问题」远远不够

经典陷阱：开发者用光纤、一台新款 MacBook、带着热缓存来测试。而真实用户，却是从一部中端手机、在时好时坏的 4G 上、带着空缓存到来。两者的体验，毫无共同之处。

Core Web Vitals 的存在，就是为了衡量用户真正经历的东西。Google 把它变成了排名因素——而更重要的是，它预示着转化：每多一秒的加载，都在赶走访客。

三个真正重要的指标

• LCP（Largest Contentful Paint） — 主要元素（常是首屏大图或标题）出现之前的时间。目标：低于 2.5 秒。
• INP（Interaction to Next Paint） — 响应性：点击与可见响应之间的延迟。目标：低于 200 毫秒。在 JavaScript 繁重的站点上，这是胜负手。
• CLS（Cumulative Layout Shift） — 稳定性：当图片或广告加载时，让你点错位置的那些布局跳动。目标：低于 0.1。

一个漂亮却缓慢的网站，是一个失败的网站。性能不是设计的敌人——它是一条迫使你做出干净选择的约束。

我使用的手段

让网站变快没有任何魔法，它是一连串决策的总和：

• 图片 — 现代格式（AVIF/WebP）、正确的尺寸、首屏以下的 lazy loading，以及为避免跳动（CLS）而预留的空间。
• 字体 — font-display: swap、预加载真正用到的字重，而最重要的是：只加载这些。
• JavaScript — 尽可能少地下发。最快的代码，是你根本不发给浏览器的代码。服务器组件、非关键内容的延迟加载。
• 渲染 — 内容允许时优先静态（在构建时预生成）：没有什么比一个已经就绪的文件更快。
• 持续测量 — 一份性能预算与监控（Lighthouse、Speed Insights），让退化在上线之前、而非之后被发现。

到现场去测，而非在实验室

测量有两种方式：实验室数据（Lighthouse，受控环境）与现场数据（真实用户，经由 Chrome UX Report）。两者都有用，但只有后者反映现实。一个网站可能在实验室里得 100 分，却因为一条慢速连接或一台普通设备，在现场令人失望。

我的纪律：在实验室里优化以求快，但在宣布胜利前到现场去验证。

为什么这对客户很重要

一个快速的网站不只是技术上的讲究。它意味着更多愿意停留的访客、更好的 Google 排名，以及更多的转化。速度是少有的、能同时服务于用户、排名与营收的改进之一。正因如此，我把它当作要求，而非附赠。