移动端还有一半站点过不了 CWV

移动端只有 49.1% 的站点三项指标全过，卡点在加载。这篇给出从真实数据定位到修复的完整顺序，包括删第三方脚本、拆长任务和首图处理，并附各指标及格线与当前达标率。

一半的移动端站点，三个指标一个都没过

CrUX 5 月的数据：移动端全过 Core Web Vitals 的站点占 49.1%，桌面 58.0%。看着像"差不多一半及格"，但把三项拆开，问题集中在哪很清楚——移动端 LCP 只有 64.4% 达标，INP 82.5%，CLS 80.9%。最先崩的是加载。

还有个反直觉的发现：访问量最大的前 1000 个站点，移动端 INP 只有 72.5% 达标，而排名一百万以外的长尾站点是 84.0%。越热门的站，响应越慢。原因不神秘——CDN 和图片优化能买到，标签管理器、A/B 测试、客服组件、同意管理这些 JS 也在同一个主线程上跑，买不到。

配图由 AI 生成，仅作示意

先在真实数据里找病，别在 Lighthouse 里猜

顺序错了会白干一周。Lighthouse 测不出 INP，它需要一个真人去点。先看 Search Console 的 Core Web Vitals 报告，找出失败的 URL 组，再用 CrUX 或自己的真实用户监控定位到具体指标。装了 web-vitals 的话打开 attribution，能直接告诉你是哪个元素、哪个阶段慢了。

定位之后再进实验室复现：Chrome DevTools 里把 CPU 降到 4 倍或 6 倍——这步最容易被跳过。你的笔记本不是用户的手机，一台两百美元的安卓机 CPU 比 MacBook 慢将近十倍，桌面上跑 50 毫秒的脚本，在它上面要 500 毫秒。

修复按这个顺序，回报最高

1. 删第三方脚本

每次审计都能翻出几个没人说得清用途的标签，为两年前结束的活动挂在每一页上。删脚本这件事即时、免费、永久有效，比任何代码分割技巧都管用。

2. 拆长任务

超过 50 毫秒的任务就会挡住输入。把耗时逻辑切片，中间让出主线程，新浏览器有 scheduler.yield()，没有的话用宏任务让出去也比一整块强。

3. 别在事件处理里干重活

每敲一个键过滤一万行数据、每次滚动写一次 localStorage、写完布局属性立刻读回来——在自己机器上都是毫秒级，在中端安卓上是灾难。输入做防抖，读写批量处理，真正的重计算丢给 Web Worker。

4. 先渲染结果，再干活

用户不需要操作在 200 毫秒内真的完成，他需要看到界面有反应。乐观更新能救回不少感知性能。

加载慢的话，先看首图

移动端 LCP 失败的多数原因就那么几个：首图太大、渲染阻塞资源、服务器响应慢。最省事的四步——首图转 AVIF 或 WebP 并按容器尺寸给多倍图，别给首图加 loading="lazy"，给首图加 fetchpriority="high"，关键 CSS 内联。这四步做完，LCP 一般能挪进 2.5 秒。

顺便看一眼趋势：移动端全过的比例从 2022 年的 28.6% 涨到今年的 49.1%，五年涨了 20 个点，但最近一年的涨幅在收窄。好改的已经改完了，剩下的都是架构层面的账。