大家好，我是Neo。

9月15日，Chrome 团队做了一件在SEO圈和广告圈都算得上“静悄悄地震”的事：在 CrUX（Chrome 用户体验报告）里上线了4个全新的广告体验指标。

CrUX 是什么，做独立站的老板应该都不陌生——它就是 PageSpeed Insights 里那份“真实用户数据”的来源，也是 Google 评判 Core Web Vitals 的底层数据集。现在，同一个数据集里，多了一个维度：广告。

Neo的判断先放前面：这件事短期内不会影响你的排名，谷歌也明确说了它不是 Core Web Vitals。但它可能是过去三年里，广告体验第一次有了全球统一、浏览器原生、且公开可查的度量口径。这件事的长期影响，比它上线时看起来要大得多。

下面我把它拆开讲清楚。

谷歌这次到底加了什么

四个指标，全部标注为实验性（experimental）：

指标	官方口径	说人话
Ad Count	视口内广告的平均数量	用户一眼看到几个广告
Ad Density	广告占据视口面积的平均比例	广告占了屏幕多大一块
Ad Weight: CPU	广告帧和 worker 的累计 CPU 执行时间（毫秒）	广告吃掉了多少算力
Ad Weight: Network	广告帧和资源累计传输的压缩字节（KB）	广告吃掉了多少流量

四个指标合起来，覆盖的是三件不同的事：数量、视觉占比、资源开销。

八个必须搞清楚的口径，不然你会误读数据

这部分比新闻本身重要，因为同一份数据，读错口径结论就完全反了。

1. 报告的是 P75，不是平均值

Chrome 报告的是第75百分位。含义是：75%的用户会话，这个指标值不高于这个数。

官方给的例子很直观：如果某个站的 Ad Density 的 p75 是 23%，意味着75%的访问里广告视觉占比在23%以下，剩下25%的访问高于这个数。

为什么不用平均值？因为平均值会被极端会话带偏——一个用户在地铁里用慢速网络打开你的页面，就能把整个平均值拉坏。P75 描述的是分布，不是平均体验。

2. CPU 只算广告帧，不含主框架的广告脚本

这一条是最容易被忽略的坑。官方文档明确写了：CPU 时间只为广告帧测量，不包含主框架（main frame）中的广告脚本。

也就是说，如果你在页面主文档里直接挂了一段广告/AI推荐/联盟脚本，那部分开销可能不在这个指标里。别看到 ad_cpu 数字不高就以为万事大吉。

3. 每秒采样一次视口

计算 Ad Count 和 Ad Density 时，Chrome 每秒对视口采样一次并取快照。只要广告有任意一个像素在这一秒的采样点落在视口内，就算“可见”。

• 重叠广告：算 Density 时，重叠部分按并集只算一次；算 Count 时，每个广告各算一个；
• 部分可见：Density 只算实际落在视口内的那部分面积，Count 只要有一个像素在视口内就计入；
• 不渲染的广告（比如 display: none）不计入 Count 和 Density——但 CPU 和 Network 开销照样统计。

最后这条特别值得记住：把广告位藏起来不算优化，资源该消耗还是消耗。

4. SPA 的软导航不会重置统计窗口

如果你的独立站是单页应用（SPA）架构，客户端路由切换页面不会重置统计，所有软导航产生的采样会平均进同一个会话分数，直到一次硬跳转或关闭标签页。

5. 后台标签页会暂停采样

切换到后台、锁屏时采集暂停，回到前台自动恢复。画中画视频被忽略，避免后台运行污染数据。

6. 28天滚动窗口，按日更新

CrUX 用的是28天滚动平均，反映不同设备和网络条件下真实用户的体验。API 数据每天更新，History API 则是每周一发布一次，返回最近40个28天周期（约6个月）的时间序列。

7. 数据来自哪些平台

覆盖 Chrome 在 Windows、macOS、Android、ChromeOS、Linux 上的用户。不包含 Chrome on iOS，也不包含 Android WebView 内嵌应用和其他 Chromium 内核浏览器。

这一条对你的判断很重要：如果你的主要流量来自 iOS 用户，这份数据对你是失真的。

8. 只有 ads.txt 合规的站点才会被公开统计（这条最关键）

CrUX 的广告指标只对符合条件的站点公开：在有 ads.txt 文件、且其中至少包含一条已授权卖方（authorized seller）记录的源站上采集。

这意味着两件事：

1. 没有 ads.txt，或者 ads.txt 里只有占位记录的站点，不会出现在公开的 CrUX 广告数据里。 这几天肯定会有很多人跑到 CrUX Vis 上搜自己的域名，然后说“怎么没数据”——大概率就是这个原因；
2. DevTools 的 Ad 面板仍然可以在本地看到你自己页面的广告指标，即使你不符合公开统计的条件。

怎么查自己的数据

官方给了三个通道。我建议先做最简单的那一步。

第一步：看本地的（不需要任何配置）

打开 Chrome DevTools，找到 Ad 面板，可以立刻看到当前页面的广告测量结果。这一步用来确认“Chrome 到底把什么算成了广告”。

第二步：用 CrUX Vis 看趋势

CrUX Vis 是官方的可视化管理面板，不需要写代码，能看最近40周的滚动趋势，支持来源级/URL级切换，也能按设备筛选。每周一更新。这是给非技术同学看的最省事的方式。

第三步：用 CrUX API 拉数据

如果你想把广告指标接进监控或告警，用 queryRecord 接口，一次请求就能拿到四个指标的 p75 值。命令如下（把 [YOUR_API_KEY] 换成你在 Google Cloud Console 里生成的密钥）：

curl -s -X POST \
  --header "Content-Type: application/json" \
  --data '{
    "origin": "https://example.com",
    "metrics": [
      "experimental_ad_density",
      "experimental_ad_count",
      "experimental_ad_cpu",
      "experimental_ad_kilobytes"
    ]
  }' \
  "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=[YOUR_API_KEY]"

返回的 JSON 长这样（官方示例）：

{
  "record": {
    "key": { "origin": "https://example.com" },
    "metrics": {
      "experimental_ad_count": { "percentiles": { "p75": "3.00" } },
      "experimental_ad_density": { "percentiles": { "p75": 23 } },
      "experimental_ad_cpu": { "percentiles": { "p75": 1093 } },
      "experimental_ad_kilobytes": { "percentiles": { "p75": 33 } }
    }
  }
}

翻译一下这组示例数字：75%的会话里，视口内不超过3个广告、广告占屏面积不超过23%、广告脚本吃掉不超过1093毫秒CPU时间、广告资源传输不超过33KB。

想把来源级换成页面级，把请求体里的 origin 字段换成 url 就行。如果 metrics 字段留空，接口会把所有指标都返回给你。

另外，官方说正在把广告指标加进 BigQuery 的 CrUX 数据集，之后就能用 SQL 做大规模分析了。等它上线，第三方工具大概率会第一时间跟进——就像当年 Core Web Vitals 一样。

谷歌明确说了什么，又刻意没说什么

这部分同样重要，因为能看出谷歌的试探姿态。

说了的：

• 四个指标共享 CrUX 的采集管道和资格标准，但不属于 Core Web Vitals；
• 没有“良好/需要改进/较差”的分级，也没有建议阈值。Chrome 的产品经理 Alex Cone 对媒体的说法是：目前“没有计划”设定基准；
• 全部标注实验性，官方在收集反馈，指标口径可能继续演进；
• Google 的 DV360 表态支持这个方向，但 DV360 和 Google Ads 不会获得优先访问 CrUX 数据的权限；
• 早期站台的生态方包括 The Guardian、Mediavine、Index Exchange、Adelaide 等。

没说但很关键的：

• 生态方到底会不会真的用这些数据做媒体采购决策？ 谷歌拒绝代表合作方发言，只说“早期沟通显示生态有需求”；
• 会不会哪天变成搜索质量信号？ 谷歌没说会，也没说不会。

Alex Cone 有一句话我觉得很诚实：这些指标的用途是**“更好地理解它们对做决策是否有价值”**，并期待生态反馈。

Neo的解读：这句话翻译过来就是——我们先把尺子做出来，怎么用还没想好。 这恰恰是需要警惕的地方：一把已经公开的尺子，迟早会有人拿去量人。

Neo的解读：为什么我觉得这件事不能只看排名

如果你只看“会不会影响排名”，那这件事确实可以放到明年再看。但我觉得有三个更值得关注的角度。

角度一：搜索质量和广告质量的边界在变薄

CrUX 原本是性能数据的来源，是 Core Web Vitals 的底座。现在同一个数据集里开始装广告体验。这并不是说广告指标马上会变成排名因素，而是说——谷歌正在用同一套真实用户测量体系，去度量“页面质量”这个更宽的概念。

回想一下 Core Web Vitals 的演化路径：2019年提出、先作为建议、再进入排名信号、再迭代指标（INP 替换 FID）。它当年也是从“实验性、没有阈值”开始的。

角度二：广告体验第一次有了“浏览器原生、全球可比”的口径

以前讨论“这个页面广告是不是太多了”，靠的是各家广告位自己算的指标、各家联盟平台自己的政策、以及人的主观判断。现在浏览器直接替你算了一遍，而且口径统一、公开可查、按来源和页面都有。

对买方（广告主、媒体采购）来说，这是一个巨大的议价工具。对卖方（媒体、内容站）来说，这是一份你可能还没准备好就被摆上台面的体检报告。

角度三：对独立站的影响分两类，别混着看

第一类：靠内容站 + AdSense/联盟广告变现的独立站。

这一类是最直接受影响的。以前“广告密度”是个模糊的概念，现在它有了一个公开的 p75 数字。哪怕谷歌不设定阈值，广告主、联盟平台、广告代理也完全可能用自己的标准去筛站。

第二类：以卖货为目的的电商独立站。

这一类表面上影响小——站内广告位不多。但请注意两件事：

1. 第三方的推广位、联盟模块、AI推荐组件，也可能被 Chrome 的广告检测逻辑识别为广告，一样会进统计；
2. Ad Weight: CPU 和 Network 是真实性能开销。你的 INP（交互到下一次绘制的响应时间）如果被广告/推荐组件拖慢，那即使这个指标不算排名因素，它的“兄弟指标”Core Web Vitals 是会算的。

现在就该做的四件事（实操清单）

不用等谷歌定阈值。这四件事今天做和明年做，收益都成立。

1. 先确认你有没有资格

检查站点根目录下的 ads.txt：

• 文件是否存在；
• 是否至少包含一条**已授权卖方（authorized seller）**记录，而不是只有占位注释。

没有的话补上。这不是为了排名，是为了让你的数据能被看见——否则你连自己的广告体验基线都拿不到。

2. 建立你自己的基线

用 CrUX API 或 CrUX Vis 记下这四组数：

要记的	为什么
Ad Count 的 p75	首屏广告位是不是太多了
Ad Density 的 p75	视觉上的“广告感”有多强
Ad Weight: CPU 的 p75	广告对交互响应的影响
Ad Weight: Network 的 p75	移动端/弱网用户的真实代价

一定要按设备分开看。 移动端的 p75 和桌面端往往差一个量级，而你的大部分流量通常来自移动端。

3. 按“开销”而不是“位置”来优化广告

传统的做法是“首屏只放一个广告位”，这仍然是好习惯，但不够。新的视角是看资源开销：

• 广告脚本延迟加载，至少推迟到首屏内容渲染之后；
• 清理闲置和重复的广告位——尤其是 A/B 测试留下的、已经不出量的位置，这些位置的资源消耗常常是纯浪费；
• 限制同一时间发起的广告请求数，把竞价请求合并或错峰；
• 检查联盟/推荐组件，它们通常比正规广告位更重，而且更不受你控制。

4. 把广告指标和 Core Web Vitals 放在同一张表里看

这是我认为最有价值的一步。把你现在的 CWV 数据和这四组广告数据放在一起，你大概会看到很强的相关性——广告密度高的页面，INP 通常也更差。

一旦你看到这个相关性，整改的优先级就自然出来了：不是为了迎合一个还没有阈值的实验指标，而是为了你已经知道会影响排名的那个指标。

最后

我特别喜欢 CrUX 团队这次的一个做法：他们先做尺子，先不给分数。

没有“Good / Needs improvement / Poor”的分级，没有阈值，标着实验性，等生态反馈。这比一上线就定死标准要克制得多。

但对做独立站的人来说，克制不等于可以无视。因为这份数据的摆放位置很微妙——它和 Core Web Vitals 坐在同一个数据集里，用同一套真实用户采集管道，还取了个和 CWV 高度对称的名字（Ad Weight）。

当一份数据的“兄弟”是排名因素的时候，这份数据迟早会被讨论成排名因素。

你不需要为此恐慌。你只需要现在就知道自己的广告体验长什么样——等它哪天真的变成指标的时候，你不至于第一次见到那张体检报告。

---

顺便说一句，如果你在 CrUX Vis 里搜自己的域名搜不到广告数据，先别急着骂谷歌。先去确认一下 ads.txt。

---