Web Vitals从2020年正式推出到现在，我已经在很多项目中优化过这些指标，踩过很多坑也积累了很多经验。今天聊聊用了三年Web Vitals才明白的一些道理，包括对指标的理解、优化的方法论、常见的误区、团队协作等，希望能帮助大家少走弯路。

一、先说说我的经历

我是一个做了快十年的前端开发，一直很关注性能优化。Web Vitals推出之前，我就在做页面加载速度优化、减少HTTP请求、压缩资源、懒加载这些工作。

2020年Google正式推出Web Vitals，把LCP、FID、CLS三个指标作为衡量用户体验的核心指标，并且宣布会纳入搜索排名因素。那时候我正好在做一个电商项目，对性能和SEO都很关注，于是开始深入研究Web Vitals并在项目中实践。

这三年里我在电商、SaaS、内容站、企业官网等很多不同类型的项目中优化过Web Vitals，有成功的经验也有失败的教训。今天把这三年才明白的一些道理分享出来，有些是踩坑踩出来的，有些是反复实践总结出来的。

二、道理一：Web Vitals不是数字游戏，而是用户体验

我明白的第一个道理就是Web Vitals不是数字游戏，而是用户体验。

刚开始做Web Vitals优化的时候，我很痴迷于数字，总想把LCP做到1.5秒、FID做到50毫秒、CLS做到0.05，觉得数字越好就越厉害。于是我会用各种技巧去刷数字，比如为了LCP好看把首屏内容都内联或者用骨架屏占位，让LCP元素很快出现，但用户真正想看到的内容还是很晚才出来；为了FID好看把所有JavaScript都延迟到用户交互之后才加载，但用户点击之后要等很久JS加载完才能响应；为了CLS好看给所有图片都设置固定宽高，哪怕图片变形了或者留白很多。

那时候我觉得自己优化得很好，因为数字很漂亮。但后来发现用户并不买账，还是觉得页面慢、不好用。

有一次我做用户调研，问用户觉得这个页面快不快，用户说感觉还是有点慢，点了按钮半天没反应。但我看Web Vitals数字FID只有30毫秒，很好啊。后来才明白FID只衡量第一次交互的延迟，而且只衡量到浏览器开始处理交互的时间，不包括处理之后渲染更新的时间。用户点击了按钮，浏览器很快开始处理了，但处理完要等很久才能看到页面更新，用户还是觉得慢。而且FID只衡量第一次交互，后面的交互再慢FID也不管，但用户会和页面交互很多次。

那时候我才真正明白，Web Vitals只是用户体验的代理指标，不是用户体验本身。数字好看不代表用户体验好。我们优化Web Vitals的最终目的是提升用户体验，而不是刷数字。

所以后来我再做性能优化的时候，不再只看数字，而是更多地关注真实的用户体验，比如自己用这个页面感受一下快不快顺不顺，做用户调研听听用户的真实感受，看真实用户的数据比如跳出率、转化率、停留时间，看看性能优化有没有真正带来业务提升。

数字只是手段不是目的，这是我明白的第一个也是最重要的道理。

三、道理二：性能优化要从项目一开始就做

第二个道理是性能优化要从项目一开始就做，而不是等项目做完了再来补。

刚开始做Web Vitals优化的时候，我经常是等项目开发完要上线了才开始做性能优化，用Lighthouse跑一下看看哪些指标差，然后针对性地优化。但后来发现这样做效率很低效果也不好，因为项目已经开发完了，架构已经定了，代码已经写了，这时候再优化很多问题已经根深蒂固，改造成本很高甚至改不了。

比如有个项目用了一个很重的UI组件库而且全量引入，导致JavaScript很大FID很差。这时候要优化要么换成更轻的组件库要么按需引入，但项目已经开发完了所有页面都用了这个组件库，要换成本很高几乎要重写，最后只能做一些表面优化比如压缩代码、懒加载，效果有限。

还有个项目架构上用了客户端渲染，首屏要等JS加载完执行才能渲染内容，LCP很差。这时候最好的优化方法是改成服务端渲染或者预渲染，但项目已经开发完了要改架构成本很高，最后只能做一些妥协比如加骨架屏、预加载关键资源，LCP还是不理想。

这些教训让我明白性能优化不能等项目做完了再来补，而要从项目一开始就考虑性能，把性能作为架构设计和开发过程中的一个重要考量因素。

所以后来我在项目开始的时候就会做性能规划：技术选型时考虑性能，选更轻的技术栈和组件库；架构设计时考虑性能，用SSR还是CSR、怎么拆代码、怎么缓存；制定开发规范时加入性能要求，比如图片要设宽高、用WebP、懒加载，JS要按需引入；设定性能预算，在开发过程中持续监控；把性能测试集成到CI/CD，每次提交自动跑性能测试。

从项目一开始就把性能考虑进去，后面就不会有太多性能问题，即使有也比较容易优化。性能优化不是最后一步而是第一步。

四、道理三：不要过度优化，要权衡投入产出比

第三个道理是不要过度优化，要权衡投入产出比。

刚开始做Web Vitals优化的时候我有点完美主义，总想把所有指标都做到最好，哪怕已经达到了良好的标准还想继续优化做到极致。比如有个项目LCP已经做到2.0秒了，已经是良好了，但我还想做到1.5秒，于是花了很多时间去优化，换更好的CDN、优化服务器响应时间、预加载更多资源，最后花了一周时间才把LCP从2.0秒降到1.8秒，提升很小。

后来我才意识到这其实是过度优化，投入产出比很低。LCP从4秒降到2.5秒用户能明显感觉到变快了，业务也能明显提升；但从2.0秒降到1.8秒用户几乎感觉不到区别，业务提升也很小，但是投入的时间和精力却很多。

而且过度优化还可能带来副作用，比如为了极致性能写了很多复杂的优化代码，增加了代码复杂度和维护成本；或者用了一些很新的技术兼容性不好，在一些浏览器上出问题；或者为了性能牺牲了一些功能和用户体验。

所以后来我再做性能优化的时候，会先权衡投入产出比，把时间和精力花在最有价值的地方。先解决大的问题，比如JS太大、图片太大、服务器响应太慢，这些优化了性能能明显提升。达到良好就够了，对于大部分项目不需要追求极致。关注业务价值，性能优化最终是为业务服务的，要看能带来多少转化率提升、跳出率降低。考虑维护成本，不要为了一点点性能提升写很多复杂难维护的代码。

当然也不是说不要追求极致性能，对于一些对性能要求很高的项目比如大型电商、搜索引擎，极致性能能带来很大业务价值，那还是值得投入的。但对于大部分普通项目，达到良好就够了。

五、道理四：性能优化是全团队的事，不是前端一个人的事

第四个道理是性能优化是全团队的事，不是前端一个人的事。

刚开始我以为性能优化就是前端的事，HTML、CSS、JS、图片这些都是前端管的。但做了很多项目之后发现，性能问题往往不只是前端的问题，涉及到后端、运维、设计、产品等多个角色。

比如LCP差可能是因为服务器响应时间太长，这是后端的问题，需要后端优化接口响应速度、加缓存。也可能是因为图片太大没有压缩，这可能是设计或运营上传的图片没有经过压缩处理，需要建立图片上传的自动化压缩流程。FID差可能是因为第三方脚本太多，这可能是产品或市场加的各种统计、广告、客服脚本，需要和他们沟通治理。CLS差可能是因为广告位没有预留空间，这需要和广告团队配合。

所以性能优化需要全团队的参与，前端要做的是建立性能意识、提供工具和规范、推动各个角色一起优化。我后来在项目中会做这些事情：在项目启动时给全团队做性能培训，让大家都了解Web Vitals和性能的重要性；制定性能规范，包括图片上传规范、接口响应规范、第三方脚本接入规范等；建立性能监控看板，让所有人都能看到性能数据；把性能指标纳入项目验收标准，不达标不上线。

只有全团队都重视性能，性能优化才能真正做好。靠前端一个人单打独斗，效果有限。

六、道理五：真实用户数据比实验室数据更重要

第五个道理是真实用户数据比实验室数据更重要。

刚开始我很依赖Lighthouse这种实验室工具，每次优化完跑一下Lighthouse看分数。但后来发现实验室数据和真实用户体验差距很大。Lighthouse是在特定的网络条件（通常是慢4G）、特定的设备（通常是中低端手机）、无缓存的情况下测的，而真实用户的设备、网络、缓存状态千差万别。

比如有个项目Lighthouse分数很高，但真实用户的LCP中位数很差，因为很多用户用的是比Lighthouse模拟的更差的设备和网络。还有个项目Lighthouse分数一般，但真实用户数据很好，因为大部分用户用的是好设备和好网络。

所以后来我更重视真实用户监控（RUM），用web-vitals库在用户浏览器中收集真实的性能数据，按页面、设备、网络、地区等维度分析。有了RUM数据，才能知道真实用户的体验到底怎么样，瓶颈在哪里，优化有没有效果。

实验室数据也有用，适合在开发过程中快速验证优化效果、做对比测试。但最终要以真实用户数据为准，因为那才是用户真正体验到的。

七、道理六：性能优化没有银弹，要具体问题具体分析

第六个道理是性能优化没有银弹，要具体问题具体分析。

很多人问我有没有一套通用的性能优化方案，我做了这么多项目之后发现没有。每个项目的情况不一样，技术栈不一样，架构不一样，用户群体不一样，性能瓶颈也不一样。同样的优化方法在这个项目有效，在另一个项目可能没用甚至有害。

比如SSR对内容站的LCP提升很大，但对需要登录的SaaS应用可能没用，因为内容是用户个性化的，SSR的缓存效果不好。图片懒加载能减少首屏加载，但如果首屏图片本身就不多，懒加载的收益就很小。代码分割对大应用很有效，但对小页面可能增加额外的请求开销。

所以性能优化一定要先分析，找到自己项目的瓶颈在哪里，然后针对性地优化。不要盲目套用别人的优化方案，也不要看到一个优化技巧就往项目里加。先用数据说话，找到瓶颈，再对症下药。

我现在做性能优化的流程是：先收集数据（RUM和实验室），分析瓶颈在哪里，然后针对瓶颈做优化，优化后再收集数据验证效果，不断迭代。这个流程虽然慢，但每一步都有数据支撑，不会做无用功。

八、写在最后

用了三年Web Vitals，最大的收获不是学会了多少优化技巧，而是对性能优化有了更深刻的理解。性能优化不是数字游戏而是用户体验，要从项目一开始就做，不要过度优化要权衡投入产出比，是全团队的事不是前端一个人的事，真实用户数据比实验室数据更重要，没有银弹要具体问题具体分析。

这些道理看起来简单，但都是踩了很多坑、花了很多时间才真正明白的。希望分享出来能帮助大家少走弯路，在性能优化的路上走得更顺。

最后想说，性能优化是一个持续的过程，不是一次性的项目。技术在变，用户在变，业务在变，性能优化也要跟着变。保持对性能的关注，持续监控、持续优化，才能给用户带来越来越好的体验。