一份针对 2025 年福布斯 Cloud 100 的真实用户数据抓取显示，一百家里只有 23 家的手机端三项核心指标全过，掉分的不是加载速度，而是交互响应 INP。
一份针对 2025 年福布斯 Cloud 100 的真实用户数据抓取显示，一百家里只有 23 家的手机端三项核心指标全过，掉分的不是加载速度，而是交互响应 INP。
一份针对 2025 年福布斯 Cloud 100 的真实用户数据抓取显示，一百家里只有 23 家的手机端三项核心指标全过，掉分的不是加载速度，而是交互响应 INP。
这份数据是怎么来的
做法不复杂但很扎实：把 Cloud 100 全部一百家公司的最终落地域名取出来，从 Chrome 用户体验报告里拉手机端、75 分位的 LCP、INP、CLS 三项，取截至 2026 年 10 月 24 日那一周的采集周期。判定标准照 Google 的口径：LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1，三项全达标才算通过。
结果是一百家过 23 家。中位数是 LCP 2.48 秒、INP 235 毫秒、CLS 0.02——也就是说，中位那家正好压在 LCP 合格线上，却已经越过了 INP 的红线。
卡点为什么偏偏是 INP
三项里，LCP 是被解决得最好的问题：CDN、图片格式、服务端渲染，行业在这件事上砸了五年。CLS 也基本解决了，一百家里 88 家达标。INP 是另一回事——它衡量的不是页面什么时候出来，而是页面出来之后，用户点菜单、敲表单、切标签时，主线程要多久才给回应。
而这一刻，正是所有第三方脚本争抢主线程的时刻：统计代码、在线客服、A/B 测试、同意管理弹窗。一个营销站可以两秒加载完，但用户点定价页时卡住 300 毫秒，INP 就已经不合格了。这次的数字很直白：LCP 达标 51 家、CLS 达标 88 家，而 INP 达标只有 37 家；单看 INP 一项挂掉的站点有 21 个——如果只把响应速度修好，通过率能从 23 家翻到 44 家。
四个最见效的改法
- 把非必要的第三方往后放。客服、热力图、社交像素，统一延到首次交互之后或浏览器空闲时再加载。
- 拆长任务。自己写的 JavaScript 里，凡是超过 200 毫秒的任务都要切段，别让事件处理排在它后面等。
- 去掉客户端 A/B 测试的闪烁脚本，改成服务端或边缘分流。
- 审一遍标签管理器。一个被遗忘的容器在每次点击时触发十几个标签，是这类问题的常见元凶。
对站长的实际影响
先说结论的分寸：Google 的文档原话是，好的 Core Web Vitals 分数“与其他页面体验一起”，与核心排序系统想奖励的东西一致。这和“决定性排名因素”差得很远——相关但慢的页面，仍然能赢过快但不相关的页面。所以修它的理由不该是“为了排名”，而是更朴素的那条：一个每次点击都迟疑的页面，转化率会掉，A/B 测试的噪音也会变大。
还有个方法上的坑要点出来：这份数据是按域名聚合的，产品后台和营销官网在同一个域名下的公司，分数被混在一起算。这类站点排名靠后不能全怪营销页。对你自己的站，同样成立——如果后台和前台共用一个域名，看 CrUX 数据时要意识到这是混合结果；想分开看，得自己做真实用户监测。
本文根据公开报道整理，主要参考：Flux 的 Cloud 100 Core Web Vitals 实测报告（2026-10-28）。
