🔍 GSC Core Web Vitals 为什么与优化背离 — 四路取证报告
dogesms.com · 2026-07-17 · 取证方式: PSI field 数据实拉 / GSC 机制文献 / GA4 流量 mix / 18 份性能 PR 历史复盘（4 agent 并行, 53 万 token）
一句话结论：GSC 里 67 个 marketing URL 的差评，展示的根本不是这些页面自己的数据——它们单页样本不足，被 fallback 到 origin 聚合；origin 被 /dashboard（mobile P75 9.3s，62% 加载超 4s）拖进 Poor；7/15 一夜翻红的直接推手是慢网地区流量占比 4 倍增长（俄/尼日利亚/印度 3.3%→13%）把 origin P75 推过 4.0s 阈值。页面没有变慢，我们的优化方向没有错，而且刚上线的 #607 恰好就是治病根的药——只是 CrUX 的 28 天窗口还没开始反映它。
① 传染机制（PSI 实拉数据实证）
/blog、/service/* 等长尾页 → 单页 CrUX 样本不足 → PSI 显式提示 "insufficient real-user data → falling back to origin" → 展示 origin 聚合数据 → origin mobile P75 = 4.4s POOR（被 /dashboard 的 9.3s 拖高）→ 67 个 URL 被"连坐"标红
| URL | URL 级 mobile LCP P75 | 是否 fallback 吃 origin 数据 | 结论 |
|---|
| / （首页） | 2.4s GOOD | 否（自身样本充足） | 真实不差 |
| /zh-CN | 2.1s · CWV 整体 Passed | 否 | 真实不差 |
| /blog | 无自身数据 | ✅ fallback | 吃 origin 4.4s 差评 |
| /blog/codex-phone-verification | 无自身数据 | ✅ fallback | 吃 origin 差评 |
| /service/telegram | 无自身数据 | ✅ fallback | 吃 origin 差评 |
| /dashboard | 9.3s POOR（62% 超 4s）· desktop 7.9s | 否（样本大量） | 拖高 origin 的元凶 |
反证成立：唯二有自身数据的 / 和 /zh-CN 全是 GOOD——一旦页面有自己的样本就不吃差评，证明 marketing 页自身性能没问题。GSC 机制官方文档确认三级降级链（URL → URL group → origin，origin 按 scheme+host），且 origin 聚合"regardless of individual page discoverability"——登录后页面照样毒化 origin。
② 7/15 一夜翻红的推手：地理 mix shift（GA4 实证）
| 周（mobile-only） | China | Russia+Nigeria+India 合计 |
|---|
| 202620-24（5月中-6月中） | 51-55% | 3.3-3.5% |
| 202627（6/28-7/4） | 32% | 8.8% |
| 202628（7/5-7/11） | 37% | 13.0%（4 倍） |
- 时间与 GSC 翻 poor 的 CrUX 28 天窗口（约 6/17-7/14）精确吻合。
- 这批慢网流量来自 organic+AI 渠道涌入 programmatic SEO 页（/ru/service/telegram/ru 等，mobile SEO 页 PV 占比 2%→10%）——SEO 增长本身带来了慢网用户，反过来压 CrUX 评分，增长与评分存在结构性张力。
- 两条备选假说被证伪：organic 并未持续下滑（6 月中跌 46% 后企稳）；dashboard PV 占比反而在降（27.9%→21.8%）。
③ 灯下黑清单（这次挖出来的）
- China 流量不进 CrUX：GA 第一大国 China（mobile 32-55%）因 GFW 基本不进 Google 数据管道——CrUX 有效样本里慢网地区实际占 15-21%（表面只有 7-13%）。我们看 GA4 的直觉和 Google 看到的世界不是同一个世界。
- /dashboard 是"隐形毒瘤"：匿名访问 302 → /login，爬虫和 lab 工具默认测不到它；但真实登录用户的 RUM 照常计入 origin 聚合——看不见、却拖后腿。
- INP 是第二根刺：origin mobile INP 211ms 超阈值（首页 URL 级 228ms）——GSC 差评可能是 LCP+INP 双因素。而历史复盘发现 5/27 两个"优化" PR（#428 react-window / #430 GTM lazyOnload）把首页 INP 从 80ms 打到 278ms，潜伏 35 天才被发现——评分恶化有一部分是优化自伤。
- 仪表盘错位：Vercel RUM（全浏览器、7 天、RES 综合分）说 mobile 91 Great；GSC/CrUX（仅 Chrome、28 天、P75、origin fallback）说 67 URL poor——两个仪表盘测的人群、窗口、口径全不同，对着不同仪表盘打靶必然精神分裂。
④ 历史复盘：为什么"猛如虎 → 渣如土"（18 份 PR 记录逐份审计）
| 缺环 | 证据 |
|---|
| 1. 打靶指标与计分指标错位 | 6 月上半月火力集中在 authed dashboard 的 lab 指标；用 desktop 1x CPU 的 trace 修 mobile 4.8s 的指标；用 6 个样本的 P75 outlier 立项两个 PR。团队始终没有一份「GSC/CrUX 计分规则」的确定模型（本报告 ① 就是补这个）。 |
| 2. after 验证系统性缺席 | 18 份性能记录全部有「预期收益」，只有 3 份有实测 after（且都是下一个 PR 顺带做的）。#454 预测 LCP 10.3s→0.5-1s，实际后续 trace 仍 4.7s（偏差 5 倍），无人对账。 |
| 3. 发布密度与测量窗口错配 | CrUX 28 天窗口 vs 每周 2-3 个 perf PR——同一窗口叠加十几个正负改动，6/30 GSC Validation FAILED 时无法归因任何单个 PR。整场战役等价于开环控制。 |
| 4. 工作流结构性漏洞 | AFK 自主 PR 工作流以「CI 全绿 + Lark 通知」为完工标准——性能 after 验证一律写进无人认领的 Follow-up；文档「验证」章节 90% 是 tsc/lint/vitest 编译级检查。 |
| 正在自我修正 | #580→#583 出现生产登录态归因接力；#607 首次内置 before 基线 + D+3 承诺——方向对了，缺的是制度化。 |
⑤ 「顶级 AI 为什么解决不了」的诚实回答
AI（和 harness）从来不是瓶颈——测量体系和靶子选择才是。复盘显示每一次优化的工程执行本身几乎都是对的（lab 指标确实改善、SSR 确实落地、命中率 8/8）；错的是：打靶用的仪表盘（Vercel lab/RUM）和被打分的仪表盘（CrUX origin 聚合）不是同一个，而且没有人拥有「分数是怎么算出来的」这个模型。没有正确的反馈回路，再强的执行力只是更快地在错误的方向上积累里程。本报告第一次把计分模型钉死了——从今天起打的每一枪都能对上账。
⑥ 业界最佳实践 & 我们没用上的工具
结构性解法（业界标准）
- 拆域：登录 app 挪独立子域（如
app.dogesms.com）——CrUX origin 按 scheme+host 划分，子域是独立 origin，marketing 域立刻「解毒」。这是业界处理「登录应用拖 marketing 域 CWV」的标准做法（官方文档背书）。
- CWV 对 SEO 排名的真实权重是小的 tie-breaker：Google 官方原话「trying to get a perfect score just for SEO may not be the best use of your time」。CWV 的主要商业价值在转化率（Ray-Ban 案例 LCP+43% 伴随移动转化 +101%），不在排名——所以优先级应该由转化漏斗而非 GSC 面板颜色驱动。
没用上的工具（按优先级）
| 工具 | 回答什么 | 成本 |
|---|
| CrUX History API / CrUX Vis | URL+origin 级 40 周 P75 周趋势——精确定位「哪一周开始恶化」，本次 7/15 之谜用它 5 分钟能解 | 免费 |
| 自建 web-vitals RUM（2KB 官方库 attribution build → 自有管道） | 登录后 dashboard 的真实 LCP/INP 归因（CrUX 看不到细节、Vercel RUM 口径不同）；目前生产 browser OTel 是关的 | 免费+半天工程 |
| CrUX BigQuery | 2017 至今 origin 月度史 + 按国家拆分（验证地理假说的最后一环） | 免费 |
| DebugBear / Treo / Calibre / SpeedCurve | 商业化监控+告警+CI 卡口，$0-576/mo | 按需 |
| Speculation Rules / 103 Early Hints / bfcache | LCP 前沿武器：prerender 实测 -18~43%、Early Hints 大盘 -16%、bfcache 恢复直接计为 Good 访问 | 下阶段弹药 |
⑦ 行动清单（按 ROI 排序，等拍板，本轮不动手）
- 不动 marketing 页 ❗——它们展示的不是自己的数据，改它们对 GSC 零收益（这是本次最重要的「不做什么」）。
- 等 #607 在 CrUX 显形（已上线）：dashboard 9.3s→若降到 ~3s，origin 4.4s 将大幅回落，67 URL 差评自动解除。CrUX 按天滚动、GSC 每几天刷新——预计 2-4 周内可见趋势。用 CrUX History API 建周报盯它。
- 修 INP 自伤（小 PR）：复查 5/27 #428/#430 的 INP 回归（80→278ms）+ 首页 228ms；INP 是第二根刺，且是我们自己打进去的。
- 建免费监控闭环（半天）：CrUX History API 周报（origin+关键 URL 的 P75 趋势推飞书）+ 生产开 web-vitals RUM 上报——从此打靶和计分用同一个仪表盘。
- 流程红线：每个性能 PR 必须带「计分仪表盘名称 + before 数值 + D+N 复盘日期」才允许合并；复盘没做完不开下一个性能 PR（治发布密度 vs 测量窗口错配）。
- 评估拆域（中期）：app.dogesms.com 结构性解毒——收益确定但迁移涉及 cookie/auth/SEO 重定向，建议 #607 效果确认后再决策（若 dashboard 修好了，可能不需要拆）。
附录 · 四路取证原始报告
附录A · PSI Field 数据取证原文
# dogesms.com CrUX Field 数据取证报告 — 验证 "origin fallback 传染" 假说
**日期**: 2026-07-17 | **CrUX 采集窗口**: 2026-06-18 ~ 2026-07-15 (28 天)
## 方法说明 (与原计划的偏差)
1. **无 key PSI API 不可用**: `runPagespeed` 匿名调用直接 429 — `Queries per day` 配额 `limit_value: 0`（匿名共享项目 583797351490 当日耗尽），sleep 30s 重试仍 429（日配额，等不回来）。本机 gcloud 两个账号凭证均已失效（`invalid_grant: Account has been deleted` / `Bad Request`），无法走 Bearer token。
2. **改走 pagespeed.web.dev 网页版**（gstack browse 无头浏览器驱动，Google 前端自有配额）。该 UI 内部走 `batchexecute` RPC 而非公共 API，故拿不到 `origin_fallback` 布尔原值和精确 ms percentile；等价证据为:
- UI 显式提示 **"There is insufficient real-user data for this URL. Falling back to aggregate data for all user experiences on this origin (https://www.dogesms.com)"** = API `origin_fallback: true` 的 UI 等价物；
- LCP P75 为 UI 渲染值，粒度 0.1s。
3. 原始 dump 与解析结果存于 `/private/tmp/claude-501/-Users-yeer-go-src-github-com-athom-tuna/bd34993a-091c-45eb-8dcb-40449a236ec8/scratchpad/psi/`（`t_*.txt` + `summary.json`）。
4. lab LCP 仅 home 与 dashboard(original) 等到了 Lighthouse 完成；其余页为省时只采 field 段（field 与假说验证无关联损失）。
## 完整数据表
| URL | 策略 | URL级 LCP P75 | URL级 category | origin_fallback? | origin级 LCP P75 | origin级 category | lab LCP |
|---|---|---|---|---|---|---|---|
| `/` | mobile | **2.4 s** (78%好/13%中/9%差) | GOOD | **否** | 4.4 s | POOR | 7.0 s |
| `/` | desktop | **2.0 s** | GOOD (CWV Passed) | **否** | 3.8 s | NEEDS_IMPR. | 0.6 s |
| `/dashboard` (默认跑) | mobile | 无 — 匿名 302→**/login**，/login 无 URL 级数据 | n/a | **✅ 是** (显式 fallback 提示) | 4.4 s | POOR | n/a |
| `/dashboard` (默认跑) | desktop | 无 (同上) | n/a | **✅ 是** | 3.8 s | NEEDS_IMPR. | n/a |
| `/dashboard` (`use_original_url=true`) | mobile | **9.3 s** (20%好/18%中/**62%差**), INP 307ms | **POOR** | 否 (URL 级数据充足) | 4.4 s | POOR | 3.0 s |
| `/dashboard` (`use_original_url=true`) | desktop | **7.9 s**, INP 161ms | **POOR** | 否 | 3.8 s | NEEDS_IMPR. | 0.7 s |
| `/blog/codex-phone-verification` | mobile | 无 URL 级数据 | n/a | **✅ 是** | 4.4 s | POOR | 未采集 |
| `/blog/codex-phone-verification` | desktop | 无 | n/a | **✅ 是** | 3.8 s | NEEDS_IMPR. | 未采集 |
| `/service/telegram` | mobile | 无 URL 级数据 | n/a | **✅ 是** | 4.4 s | POOR | 未采集 |
| `/zh-CN` | mobile | **2.1 s**, INP 105ms (CWV **Passed**) | GOOD | **否** | 4.4 s | POOR | 未采集 |
| `/zh-CN` | desktop | **1.5 s** (CWV Passed) | GOOD | **否** | 3.8 s | NEEDS_IMPR. | 未采集 |
| `/blog` | mobile | 无 URL 级数据 | n/a | **✅ 是** | 4.4 s | POOR | 未采集 |
| `/blog` | desktop | 无 | n/a | **✅ 是** | 3.8 s | NEEDS_IMPR. | 未采集 |
内部一致性校验: 7 份独立页面 dump 中 origin 块数值完全一致（mobile 4.4s/INP 211ms/CLS 0.01；desktop 3.8s/INP 94ms/CLS 0.04），同一 28 天窗口，数据可信。
## 四个问题的回答
### a) 哪些 marketing URL 显示 origin_fallback=true?
受测 4 个纯 marketing URL 中 **3 个命中 fallback**: `/blog`、`/blog/codex-phone-verification`、`/service/telegram` — PSI 全部显式提示 "insufficient real-user data → falling back to ... origin"。**例外**是 `/`（首页）和 `/zh-CN`: 两者自身样本充足，URL 级 LCP 均 GOOD（2.4s / 2.1s），`/zh-CN` 甚至 CWV 整体 Passed。可外推: GSC 里 67 个被标差的 marketing URL 绝大多数是 `/service/*`、`/country/*`、`/blog/*` 这类单页流量稀薄的长尾页 → 全部吃 origin 数据。
### b) origin 级 mobile P75 LCP 是多少? 什么 category?
**4.4s (4400ms) — POOR**（>4000ms 阈值，27% 的真实加载 >4s）。与假说的 ~4.3s 吻合（窗口漂移）。desktop origin 为 3.8s，NEEDS_IMPROVEMENT。另注意 origin mobile INP 211ms 也超 200ms 良好阈值 — GSC 差评可能是 LCP+INP 双因素。
### c) /dashboard URL 级 P75 是多少? 与 origin 差值说明什么?
- mobile: **9.3s**（比 origin 4.4s 高 **+4.9s，2.1 倍**；62% 的加载 >4s）
- desktop: **7.9s**（假说引用的 "7859ms" 与之精确吻合 — 该引用值应为 desktop 端 CrUX API 精确值，UI 四舍五入即 7.9s）
差值说明: origin 4.4s 恰好落在 home 2.4s 与 dashboard 9.3s 之间。/dashboard 是登录后主工作页（高流量、高复访），其巨量慢样本把 origin 聚合从 marketing 页自身水平（2.1-2.4s，GOOD）拖进 POOR 区间。origin 的 27% poor 份额与 dashboard 62% poor + 高流量占比在数学上自洽。
### d) 假说是否成立?
**成立，机制链完整闭环，另有两处修正/补充**:
传染链实测: marketing 长尾页单页 CrUX 样本不足 → PSI/GSC fallback 到 origin 聚合 → origin mobile P75 4.4s 被 /dashboard (9.3s, 62% poor) 拖进 POOR → 67 个 marketing URL 被"连坐"标 poor/needs-improvement。**反证也齐全**: 唯二有自身 URL 级数据的 `/` 和 `/zh-CN` 都是 GOOD/Passed — 一旦页面有自己的样本就不吃差评，证明差评不是 marketing 页自身性能问题。
修正/补充:
1. **意外发现**: `/dashboard` 匿名访问 302 → `/login`。PSI 默认跑 dashboard 实测的是 /login（也 fallback 到 origin）；须 `use_original_url=true` 才能取到 dashboard 自身 URL 级数据。这也意味着 Googlebot/lab 视角永远测不到 dashboard 真身，但真实用户 RUM 数据照常计入 CrUX origin 聚合 — "爬虫看不见、数据拖后腿"的隐形组合。
2. 引用值 7859ms 对应 **desktop**；mobile 端更差（9.3s）。当前窗口 origin 为 4.4s（非 4.3s），均为正常窗口漂移。
**修复方向推论**: 把 /dashboard LCP 打下来（正在进行的 SSR popular grid 等 PR 方向正确）是解除 67 个 marketing URL 差评的唯一杠杆 — 改 marketing 页本身无效，因为它们展示的根本不是自己的数据。origin mobile INP 211ms 也建议一并关注。
附录B · GSC 机制与业界工具研究原文
# Web 性能专题调查报告
> 调查日期: 2026-07-17 | 方法: WebSearch + 一手文档抓取 (Google 官方文档为主, 业界工具商文档为辅)
---
## 1. GSC Core Web Vitals 的 URL Groups 机制
### 归组方式
Google Search Console 的 CWV 报告把 URL 归入 **"提供相似用户体验的页面组" (URL groups)** — Google 判断页面属于同一模板/类型 (如全部产品页) 就归为一组, 假设"该组有共同框架, 组内劣化行为大概率同根因"。组状态由组内**聚合数据的 P75** 决定, 而非逐 URL。
### Fallback 链: URL → URL group → origin group (官方原文确认)
官方帮助文档明确了三级降级:
1. **URL group 优先**: 组内数据达到最低门槛 (LCP 和 CLS 都要有), 按组展示;
2. **origin group 兜底**: 原文 — *"if the URL `https://m.example.com/a/b/c.html` is part of a group that doesn't have enough data to show, then Search Console will create the origin group `https://m.example.com`"*, 该 origin group 聚合 **同一 `protocol://host:port`** 下所有 URL 的数据;
3. **彻底省略**: origin 级也不够就不出现在报告里。Google **不公开**"足够数据"的具体门槛值。
### "There are only URLs with not enough usage data in this group" 的准确含义
该提示出现在组详情的 Examples 表: **组的状态是由组级聚合样本算出来的 (所以组有分数), 但组内没有任何单个 URL 自身的 CrUX 样本量达到可单独展示 URL 级指标的门槛**。官方文档写明 Examples 表只在 "if the URL has enough data to show" 时才展示单 URL 分数。即: 组分是真实的 (聚合口径), 只是无法下钻到具体 URL — 不代表数据无效, 也不代表报告在猜。
### 组分数翻转的含义
组状态规则是 **"defaults to the slowest status assigned to it"** (取最差指标的状态)。LCP 阈值: ≤2.5s Good / ≤4s Needs improvement / **>4s Poor**。因此一个组从 needs-improvement 翻转为 poor, 意味着**该组聚合分布的 P75 LCP 越过了 4.0s** (或另一指标越过其 poor 阈值: INP>500ms / CLS>0.25)。P75 语义: "75% 的页面请求耗时不超过该值" — 翻转说明该组**最慢的 25% 访问整体恶化**, 通常是组内某高流量 URL 变慢或流量结构变化 (慢设备/慢网络占比上升) 拖动分布尾部。
**来源**:
- https://support.google.com/webmasters/answer/9205520 (官方帮助文档, 以上引文出处)
- https://www.debugbear.com/blog/search-console-core-web-vitals
- https://www.searchenginejournal.com/grouped-core-web-vitals-scoring/407899/
---
## 2. 登录应用拖累 marketing 域 CWV: 拆子域是否有效
### 结论: **有效, 且有 Google 一手文档背书**。CrUX 的 origin 按完整 origin (scheme+host+port) 划分, 子域是独立 origin。
### 关键证据链
**(a) CrUX 的 origin 定义 = scheme + host**
CrUX methodology 文档: origin 代表 *"an entire website, addressable by a URL like `https://www.example.com`"*, 遵循 Web 标准 origin 定义 (scheme + host + port)。web.dev 官方文章明确: `https://www.example.com` 与 `https://app.example.com` 是 **cross-origin** — 子域即独立 origin, 与注册域 (registrable domain / eTLD+1) 无关。**因此 `app.example.com` 的 CrUX 数据与 `example.com` 完全隔离。**
**(b) 登录页/noindex 页确实在毒化 origin 级数据 (毒化机制成立)**
CrUX methodology 原文: *"eligible user experiences on **all of that origin's pages** are aggregated at the origin-level, **regardless of individual page discoverability**"* — 即只要 origin 本身可公开发现, **登录后的 dashboard、noindex 页的真实用户体验全部计入 origin 级 CrUX 分布**。慢的登录后 app 流量占比越高, origin 级 P75 被拖得越狠。
**(c) 毒化的暴露路径**
- 2022 年 7 月起, GSC CWV 报告和 Page Experience 评分**不再直接纳入 noindexed 页面** (URL 级);
- 但当 marketing URL 组数据不足触发 **origin group fallback** (见第 1 题), 或任何人用 PSI 查看 "Origin" 口径时, 被 app 流量污染的 origin 级数据就会现形;
- John Mueller 也确认: 数据不足时 Google 会把站点按更粗粒度处理, *"If you have a subdomain or subfolder that is slow... Google is more likely to just treat that section of the site as slow"*, 但能否正确切分**取决于数据量** — 数据薄的站点更容易被整体连坐。
**(d) 拆子域 = 结构性解毒**
把 app 挪到 `app.example.com` 后: app 流量进入独立 origin 的 CrUX 桶, marketing origin 的分布只剩快页面; GSC 中子域也是独立 property/独立 CrUX 口径 ("Subdomains separate domains on CrUX reports")。这是确定性的机制结果, 不依赖 Google "猜对"页面分组。
### 工程注意事项 (决策参考, 非来源结论)
拆域的代价: 跨子域 cookie/session 共享 (需 `Domain=.example.com` cookie 或 SSO 跳转)、CORS、CDN/证书配置、埋点跨域归因。另一个不拆域的替代方案是**直接优化 app 首帧** (毒源治理) — 拆域只是让报表口径干净, 不改变 app 用户的真实体验。
**来源**:
- https://developer.chrome.com/docs/crux/methodology (origin 定义 + origin 级聚合含所有页面)
- https://web.dev/articles/same-site-same-origin (子域 = 不同 origin)
- https://www.seroundtable.com/google-core-web-vitals-noindex-33830.html (2022-07 noindex 页退出 CWV 评分)
- https://www.seroundtable.com/google-slow-fast-granular-speed-urls-30283.html (Mueller: 慢区段连坐与数据量关系)
- https://groups.google.com/a/chromium.org/g/chrome-ux-report/c/gRaGM-vCJm0 (Chromium 官方论坛: noindex 页仍计入 origin 级)
---
## 3. CWV 对 SEO 排名的真实影响度 (2025-2026 共识)
### Google 官方口径 (Search Central 文档原文)
- **确认使用但非单一信号**: *"Core Web Vitals are used by our ranking systems"*; *"There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience"* (2023 年起 Google 明确废弃了"page experience 是一个独立打包信号"的说法)。
- **内容永远压过体验**: *"Google Search always seeks to show the most relevant content, **even if the page experience is sub-par**"*。
- **好分数不保排名**: *"Getting good results in reports like Search Console's Core Web Vitals report... **doesn't guarantee** that your pages will rank at the top"*。
- **官方劝退过度优化**: *"Trying to get a perfect score just for SEO reasons **may not be the best use of your time**"*。
### 业界共识
- CWV 实际扮演 **tie-breaker (同质内容间的差异化因子)**: 内容相关性/质量相近时, 体验好的一方更可能胜出; John Mueller 多次公开表示相关性和内容质量的权重远大于 CWV。
- 量化影响: Google 从未公布权重; 业界测试普遍认为是**小权重信号**。DebugBear 的结论: 达到全指标 "Good" 即触顶, **超过 Good 阈值后继续优化没有额外排名收益**。
- **"CWV 差会掉排名"的真实度**: 部分为真但常被夸大 — 从 Good 掉到 Poor 可能在竞争激烈的 query 上损失 tie-breaker 优势; 但排名大幅波动几乎总是内容/算法更新/链接层面的原因。**CWV 更大的商业价值在转化率而非排名** (Ray-Ban 案例: LCP 提升 43% 伴随移动端转化 +101%, 这是体验→转化直接因果, 不经过排名)。
**来源**:
- https://developers.google.com/search/docs/appearance/page-experience (以上官方引文出处)
- https://developers.google.com/search/docs/appearance/core-web-vitals
- https://www.debugbear.com/docs/core-web-vitals-ranking-factor
- https://www.link-assistant.com/news/core-web-vitals-guide.html
---
## 4. 业界 CWV 监控工具全景
### 免费层 (Google 官方, 数据源均为 CrUX 真实用户数据)
| 工具 | 粒度 | 更新频率 | 历史深度 | 配额/成本 | 能回答什么 |
|---|---|---|---|---|---|
| **CrUX API** | URL + origin | 每日 (28 天滚动) | 无 | 免费, 150 req/min | "此刻这个 URL/origin 的 P75 是多少" |
| **CrUX History API** | URL + origin | 每周一发布 | **40 周** (每期 28 天窗口) | 免费 | "**这个 URL 组是哪一周开始恶化的**" — 定位回归时间点的最佳免费工具 |
| **CrUX Vis** (cruxvis.withgoogle.com) | URL + origin | 每周 | 40 周 | 免费, 零代码 | History API 的官方可视化, 打开即看趋势 |
| **CrUX BigQuery** | **仅 origin** | 每月 | **2017 年至今** | 免费 (BigQuery 有 1TB/月免费查询额度) | 长周期 origin 趋势、竞品对比、按国家/设备/网络切片 |
| **PageSpeed Insights (API)** | URL + origin | 每日 (28 天滚动) | 无 | 免费, 240 req/min, 25k/天 | 字段数据 + **Lighthouse 实验室诊断**一站式; 无历史、无国家/网络维度 |
| **GSC CWV 报告** | URL group | 每日 | 3 个月 | 免费 | Google 眼中"哪些页面组不达标" (即第 1 题的口径) |
### 自建 RUM
- **web-vitals JS 库** (github.com/GoogleChrome/web-vitals): Apache 2.0 免费, 标准版 ~2KB (brotli), 测 LCP/CLS/INP/FCP/TTFB; **attribution build** (+1.5KB) 给出归因诊断 (LCP 元素 selector、INP 的 input delay/processing/presentation 拆解、Long Animation Frame); 经 `sendBeacon()` 发自有端点或 GA4/GTM。上手成本: 埋点半天, **管道+看板是大头** (需自建存储/聚合/P75 计算)。回答 CrUX 回答不了的问题: 登录用户分群、SPA 路由级指标、实时性 (CrUX 滞后 28 天窗口)、与业务指标 (转化) 关联。
### 商业工具
| 工具 | 起价 | 定位 | 差异点 |
|---|---|---|---|
| **DebugBear** | $49/mo (RUM 需 ~$149/mo Pro) | 合成监控 + RUM + Lighthouse 追踪 | 上手最快, CWV 专精, Looker Studio 报表 |
| **Calibre** | $75/mo (Starter RUM 5k sessions) | 合成 + RUM + CrUX | CI/CD 友好 (Automation API + CLI), 适合防回归卡口 |
| **Treo.sh** | 有免费层, $75/mo 解锁 API | **纯 CrUX 可视化 + 竞品对标** | 零埋点, 输入域名即出全历史趋势, 最低成本的"竞品 CWV 对比" |
| **SpeedCurve** | $90/mo 起 (Growth $576/mo) | 合成 + RUM 老牌全家桶 | 最重, 适合有专职性能团队的组织 |
| **RUMvision** | 询价 | 纯 RUM 专精 | CWV 归因细 (第三方脚本/设备分群), 无合成测试 |
### 选型建议 (针对我们这类场景)
零成本起步: **CrUX History API/CrUX Vis 看 40 周趋势定位回归点** + PSI API 做 lab 诊断; 需要登录后 dashboard 的真实数据 (CrUX 页级不含 noindex 页) 则**必须自建 web-vitals RUM** (我们已有 OTel 管道可复用); 商业工具里 Treo 免费层是性价比最高的补充。
**来源**:
- https://developer.chrome.com/docs/crux/methodology/tools (官方工具矩阵, 表格数据出处)
- https://github.com/GoogleChrome/web-vitals
- https://www.debugbear.com/blog/crux-history-api-node
- https://cubeapm.com/blog/speedcurve-pricing-review/ / https://marketraa.com/alternatives/best-speedcurve-alternatives/ (商业工具价格)
- https://www.fasterize.com/en/blog/core-web-vitals-6-measuring-methods-from-google-crux-data/
---
## 5. 2026 年 LCP 优化前沿技术
### (a) Speculation Rules API (prefetch/prerender) — 当前收益量级最大
- **机制**: 声明式 JSON 规则让 Chrome 提前 prefetch/prerender 下一跳页面, prerender 命中时 **LCP 趋近于 0**。
- **实测收益**: Monrif (新闻站) prerender 高频文章页 → **LCP -17.9%, 互动 +8.9%**; Ray-Ban → **LCP 改善 43%**, 移动转化 +101%; Google Search 自身用 eager prefetch → Android 每次点击省 67ms LCP; Shopify 全平台保守 prefetch → 桌面 -130ms / 移动 -180ms (全 paint 指标)。
- **适用**: 站内导航可预测的场景 (列表→详情、marketing→注册页)。**只对下一跳生效, 不改善着陆页 (SEO 入口) 的 LCP**。注意: 仅 Chromium 系支持 (Safari/Firefox 不支持), 需控制 eagerness 防流量/服务器开销。
- 来源: https://developer.chrome.com/docs/web-platform/prerender-pages | https://web.dev/case-studies/monrif-cwv | https://web.dev/case-studies/rayban-speculation-rules | https://developer.chrome.com/blog/search-speculation-rules
### (b) bfcache — 免费的 CWV 红利
- **机制**: 浏览器把整页 (含 JS 堆) 快照进内存, 前进/后退瞬时恢复。**桌面 1/10、移动 1/5 的导航是 back/forward** — 命中即近零 LCP、零 CLS、零 INP。
- **CWV 影响方向 (已核实)**: CrUX 把 bfcache restore **计为独立页面访问**, 这些近瞬时访问直接拉高 Good 占比 — web.dev 明确 2022 年 CLS 大盘最大改善就来自 bfcache 推广。
- **动作**: 排查 blocker — 绝不用 `unload` 监听 (用 `pagehide`)、避免页面级 `Cache-Control: no-store` (Chrome 新版已部分放宽)、关闭悬挂的 IndexedDB/WebSocket 连接; DevTools → Application → Back/forward cache 一键测试, Lighthouse 10+ 有专项 audit。
- 来源: https://web.dev/articles/bfcache | https://developer.chrome.com/docs/web-platform/bfcache-ccns | https://calendar.perfplanet.com/2025/chasing-bfcache-navigations/
### (c) 103 Early Hints — 吃掉"服务器思考时间"
- **机制**: 服务器在生成 200 响应期间先回 103 状态码, 携带 `Link: preload/preconnect` 头, 浏览器提前拉关键资源。**TTFB 越高 (SSR 重、多区域延迟), 收益越大**。
- **实测收益**: Cloudflare 10 万+ 客户大盘 — 桌面 **LCP p50 -6% / p75 -16%**; 早期理想化测试 20-30%; Shopify 黑五期间 **p50 LCP -500ms**。Chrome 103+ 支持。
- **适用**: 需要 CDN/边缘层支持 (Cloudflare 一键开启)。对 TTFB 本来就低 (<200ms) 的静态页收益有限。
- 来源: https://blog.cloudflare.com/early-hints-performance/ | https://performance.shopify.com/blogs/blog/early-hints-at-shopify | https://blog.cloudflare.com/early-hints/
### (d) Priority Hints (`fetchpriority`) — 成本最低的单行优化
- **机制**: `<img fetchpriority="high">` 把 LCP 图从默认 Low 优先级提到 High, 消除"发现晚、排队久"; 反向也可用 `low` 降级抢带宽的非关键资源。是 hint 非指令, 浏览器可覆盖。
- **实测收益**: Etsy 生产环境 **LCP -4%**; Google Flights 实验 **2.6s → 1.9s**; lab 环境最高见 20-30%。带宽竞争越激烈 (HTTP/1.x、低带宽) 收益越大。
- **现状**: 这已是 2026 年的"基本功"而非前沿 (我们 PR #462 已用); 前沿组合拳是 **fetchpriority + preload/Early Hints 保首帧着陆页, Speculation Rules + bfcache 让后续导航趋零**。
- 来源: https://web.dev/articles/fetch-priority | https://addyosmani.com/blog/fetch-priority/ | https://www.debugbear.com/blog/fetchpriority-attribute
### 收益量级速查
| 技术 | 作用对象 | 量级 (生产实测) | 上手成本 |
|---|---|---|---|
| Speculation Rules prerender | 站内下一跳 | LCP -18%~-43%, 命中时近零 | 低-中 (一段 JSON, 需防误伤) |
| bfcache | 前进/后退 (10-20% 导航) | 命中即近零 LCP/CLS/INP | 低 (排 blocker 即可) |
| 103 Early Hints | 着陆页首帧 | LCP p75 -16% (大盘), -500ms (Shopify) | 低 (CDN 层开关) |
| fetchpriority | 着陆页 LCP 图 | -4% (Etsy) ~ -27% (Flights 实验) | 极低 (单属性) |附录C · GA4 流量 Mix 取证原文
# dogesms.com CrUX mobile P75 LCP 恶化 — GA4 流量 mix-shift 假说验证报告
**背景**: GSC 2026-07-15 mobile 组 Core Web Vitals 从 needs-improvement 翻 poor。假说：不是页面变慢，而是流量 mix 变化（organic 占比降 / dashboard 占比升 / 慢网地区占比升）拖高了 origin 聚合 P75。
**方法**: GA4 Data API `runReport`（property 512790783，SA `ateam-agent@dogesms` 自签 JWT），日期范围 2026-05-10 ~ 2026-07-16，按 `yearWeek` 聚合。GA4 周从周日起算：202620=5/10-16 … 202625=6/14-20 … 202628=7/5-11，**202629=7/12-18 为不满周（数据仅到 7/16）**。因 GSC 翻 poor 的是 mobile 组（CrUX 按 form factor 分组聚合），除任务要求的 4 组全量查询外，另补跑了 mobile-only 的国家/页面桶切片。
---
## Q1: Sessions by Channel（全设备）
| 周 | 日期 | 总 sessions | Organic Search | Direct | Referral | Unassigned | **Organic 占比** |
|---|---|---|---|---|---|---|---|
| 202620 | 5/10-16 | 9,585 | 4,349 | 2,517 | 579 | 2,133 | 45.4% |
| 202621 | 5/17-23 | 12,605 | 6,317 | 2,452 | 631 | 3,173 | 50.1% |
| 202622 | 5/24-30 | 17,415 | 8,225 | 3,332 | 905 | 4,923 | 47.2% |
| 202623 | 5/31-6/6 | 18,544 | **8,913 (峰值)** | 3,182 | 748 | 5,175 | 48.1% |
| 202624 | 6/7-13 | 15,747 | 6,766 | 2,609 | 1,354 | 4,810 | 43.0% |
| 202625 | 6/14-20 | 12,581 | 4,854 | 1,723 | 949 | 3,386 | 38.6% |
| 202626 | 6/21-27 | 12,086 | 5,643 | 1,892 | 682 | 3,626 | 46.7% |
| 202627 | 6/28-7/4 | 12,399 | 5,738 | 2,314 | 694 | 3,367 | 46.3% |
| 202628 | 7/5-11 | 11,920 | 5,410 | 1,638 | 721 | 3,915 | 45.4% |
| 202629 | 7/12-18* | 7,180 | 3,011 | 1,147 | 521 | 2,390 | 41.9% |
*不满周。注：Unassigned 常年 ~28-30%（疑似后端 Measurement Protocol 事件无归因），另有少量 Display/AI Assistant/Paid Video。
**回答 a)**: Organic **绝对量**在 6 月中旬确实大跌（8,913 → 4,854，-46%，与已知 6 月 organic -43% 事件吻合），但随后**企稳**在 5.4-5.7k，7 月并未持续下滑；**占比**基本平稳（45-48%，仅 6/14-20 那周短暂跌到 38.6% 后回升）。→ 「organic 占比持续下降」**不成立**。
## Q2: screenPageViews 按 pagePath 分桶
分桶正则（经 top-25 pagePath 抽查验证覆盖 locale 前缀）：dashboard=`^(/locale)?/dashboard`，blog=`/blog(/|$)`，seo=`/(service|country)(/|$)`。
**全设备**：
| 周 | 总 PV | dashboard | dash% | blog% | seo% | 其他% |
|---|---|---|---|---|---|---|
| 202620 | 37,187 | 12,314 | 33.1% | 9.1% | 1.1% | 56.7% |
| 202623 | 87,778 | 38,761 | **44.2% (峰值)** | 9.3% | 0.9% | 45.6% |
| 202625 | 49,369 | 17,541 | 35.5% | 8.9% | 1.5% | 54.0% |
| 202627 | 52,026 | 18,778 | 36.1% | 9.0% | **3.7%** | 51.2% |
| 202628 | 47,945 | 16,960 | 35.4% | 8.2% | **4.0%** | 52.5% |
| 202629* | 28,979 | 10,738 | 37.1% | 7.2% | 3.7% | 52.0% |
**Mobile-only**（CrUX mobile 组的真正相关口径）：
| 周 | 总 PV | dash% | blog% | seo% |
|---|---|---|---|---|
| 202620-24 (5/10-6/13) 均值 | ~11,100/周 | **24-33%** | 6-8% | ~2% |
| 202625 (6/14-20) | 10,955 | 18.8% | 6.4% | 2.6% |
| 202626 (6/21-27) | 10,475 | 24.1% | 6.6% | 4.1% |
| 202627 (6/28-7/4) | 11,470 | 19.9% | 6.4% | **9.7%** |
| 202628 (7/5-11) | 11,793 | 21.6% | 5.1% | **9.3%** |
| 202629* | 6,029 | 16.2% | 5.3% | 8.5% |
**回答 b)**: **不成立，方向相反**。dashboard PV 占比 6 月初见顶（全站 44.2%），进入 CrUX 翻 poor 的 28 天窗口（约 6/17-7/14）后回落到 35-37%；mobile-only 口径更明显：27.9%（5/17-6/13）→ 21.8%（6/21-7/11）。反倒是 **programmatic SEO 页（/service、/country）mobile 占比从 ~2% 跳到 ~9-10%**。
## Q3: Sessions by Country
**全设备 top 国家占比**：China 40-43%（5 月-6 月上旬）→ 37-40%（7 月）→ 51%（202629 不满周）；US 18-20% → 12%（不满周）；Japan 11-13% → 8-9%；**Russia 0-1% → 2-3%（持续爬升）**。
**Mobile-only（关键表）**：
| 周 | mobile 总 | China | US | Nigeria | Russia | India | RU+NG+IN 合计占比 |
|---|---|---|---|---|---|---|---|
| 202620 | 2,228 | 53% | 13% | 1% | 1% | 1% | 3.3% |
| 202621 | 2,579 | 55% | 11% | 2% | 1% | 1% | 3.3% |
| 202624 | 2,946 | 51% | 12% | 2% | 1% | 1% | 3.5% |
| 202625 | 3,730 | 33% | **35%**† | 2% | 1% | 1% | 3.5% |
| 202626 | 2,621 | 43% | 13% | 2% | 1% | 2% | 5.0% |
| 202627 | 3,196 | **32%** | 10% | **4%** | **3%** | 2% | 8.8% |
| 202628 | 3,085 | **37%** | 10% | **5%** | **6%** | 3% | **13.0%** |
| 202629* | 1,712 | 48% | 8% | 4% | 6% | 3% | 12.9% |
† 202625 US mobile 一次性异常尖峰（1,307 sessions），未持续。
追查 7 月（6/28-7/16）mobile SEO 页流量构成：国家 top = Russia 354、China 336、Netherlands 212、Nigeria 192、Czechia 134、India 121、Ukraine 104、Kazakhstan 84；渠道以 **Organic Search（1,676）+ AI Assistant（451）** 为主；RU/NG/IN mobile 用户落地页 top = `/signup`、`/ru/signup`、`/ru/service/telegram/ru`、`/service/whatsapp/us` 等 signup + programmatic SEO 页。
**回答 c)**: 涨的是 **Russia、Nigeria、India + 东欧/中亚（Ukraine/Kazakhstan/Czechia）**，均为典型慢移动网络或远距/绕行路由地区。mobile 内 RU+NG+IN 合计占比从 ~3.3% 涨到 ~13%（近 4 倍）。关键 CrUX 视角修正：**China 用户（GA 里 mobile 占 32-55%）因 GFW 基本上传不了 CrUX 样本**，剔除 China 后，RU+NG+IN 占 non-China mobile 的比重从 ~10%（5/17-6/13）升到 ~14.5%（6/21-7/11），单周 202628 达 **20.7%** —— 即 CrUX mobile 有效样本里每 5 个就有 1 个来自慢网地区，此前是 1/10~1/15。
## Q4: Sessions by deviceCategory
| 周 | 总 | desktop | mobile | **mobile 占比** |
|---|---|---|---|---|
| 202620-24 (5/10-6/13) | 74,147 | 59,449 | 14,562 | **17.8-22.2%（均 ~19.6%）** |
| 202625 | 12,495 | 8,788 | 3,604 | 28.8% |
| 202626 | 12,175 | 9,623 | 2,508 | 20.6% |
| 202627 | 12,463 | 9,362 | 3,057 | **24.5%** |
| 202628 | 11,747 | 8,709 | 2,996 | **25.5%** |
| 202629* | 7,278 | 5,582 | 1,675 | 23.0% |
Mobile 占比从 5 月 ~19% 升到 7 月 ~24-26%。对 mobile 组自身的 P75 无直接影响（CrUX 按 form factor 分组），但说明 mobile 样本池在扩大且新增量主要来自上述慢网地区。
---
## 结论：回答 d) mix-shift 假说是否成立
**部分成立 —— 大方向（mix 变化拖高聚合 P75）有数据支持，但成立的是「地理 mix」腿，原设想的「organic↓/dashboard↑」两条腿均被证伪：**
1. ❌ **Organic 占比下降** — 不成立。绝对量 6 月中旬跌 46% 后企稳，占比 45-48% 平稳。
2. ❌ **Dashboard（慢页）占比上升** — 不成立，方向相反。mobile dashboard PV 占比 27.9% → 21.8%，反而在降。
3. ✅ **慢网地区占比上升** — 强成立。CrUX 翻 poor 的 28 天窗口（约 6/17-7/14）内，mobile 流量里 RU/NG/IN/东欧/中亚 organic（+AI Assistant 渠道）流量涌入 programmatic SEO 页和 signup 页，占 mobile 比重涨近 4 倍；剔除 CrUX 不可见的 China 后，这批慢网样本占有效 mobile 样本可达 ~15-21%。时间线与 GSC 7/15 翻 poor 精确吻合。marketing 页在 lab 里快，但在尼日利亚/印度移动网络上 LCP 轻易 >4s，足以把 origin 级 mobile P75 从 needs-improvement（<4s）推过 poor 线（4s）。
**综合判断**: 「不是页面变慢，而是 mix 变化」的核心主张成立，但机制是**地理 mix-shift（慢网地区 organic 新流量涌入）**，而非 page-mix / channel-mix。这与本项目既有的 mix-shift 经验（接码率、转化率均出现过 mix 假象）一致。
## 局限与建议
- GA4 mix 只是 CrUX 样本的 proxy：CrUX 只收能上传到 Google 的 Chrome 用户，China 流量（GA 第一大国）在 CrUX 里近乎缺席；Unassigned ~29%（疑似后端 MP 事件）也会干扰渠道占比。
- 本分析**不能排除页面真实变慢的叠加因素**。建一步用 CrUX API / BigQuery（`chrome-ux-report` 公开数据集）按 country 维度取 dogesms.com 的 P75 LCP：若 US/JP 等基准国家 P75 持平而 origin 整体恶化，即可坐实纯 mix-shift；CrUX API 需要 GCP API key，本机凭证仅有 analytics.readonly SA，未能直接验证。
- 202629 为不满周；202625 US mobile 尖峰为一次性异常，均不影响趋势判断。
- 若要「治」这个 GSC poor：技术上可优化 signup / programmatic SEO 页在慢网下的 LCP（这批新流量的落地页），但需先确认这批 RU/NG 流量的商业价值，避免为不转化的流量过度优化。
**数据文件**: 原始 JSON 与汇总脚本在 `/private/tmp/claude-501/-Users-yeer-go-src-github-com-athom-tuna/bd34993a-091c-45eb-8dcb-40449a236ec8/scratchpad/`（q1_channel.json、q2_*.json、q2m_*.json、q3_country.json、q3m_country_mobile.json、q4_device.json）。
附录D · 历史打靶复盘原文
# 性能优化打靶复盘 — 2026-06/07 前端性能战役取证报告
**取证范围**: `changes/` 目录 18 份性能相关实施记录 (2026-05-27 ~ 2026-07-16) + `git log origin/main` 25 个 perf/fix commit (2026-05-27 ~ 2026-07-17)。5 月末的 PR 纳入是因为它们与 6-7 月构成同一场战役（且其中两个正是后来 CrUX 恶化的直接肇因）。
**核心结论先行**: 这不是"优化没做"的问题，是**打靶指标与计分指标长期错位 + after 验证系统性缺席**。最终裁判是 GSC 上的 CrUX 28 天 P75，而团队 90% 的决策依据是 chrome-devtools lab trace 和 Vercel Speed Insights；6/30 GSC Validation FAILED 时，同一个 CrUX 窗口里叠加了十几个正负向改动，无法归因。更糟的是：5/27 的两个"性能优化" PR (#428/#430) 本身就是首页 CrUX INP 从 80ms 恶化到 278ms 的元凶，潜伏 35 天才被发现——外部评分恶化的一部分是优化自己造成的。
---
## 一、时间线总表
| 日期 | PR | 优化对象 (页面/指标) | 决策数据源 | before 基线 | after 验证 | after 结论 |
|---|---|---|---|---|---|---|
| 05-27 | #428 | 首页 mobile LCP 4.3s (虚拟化+preconnect) | Vercel SI RES 急跌 + GSC 20 URL + lab trace (Fast 4G+4x) | ✅ lab | ❌ 无主动验证 | 🔴 **反向**: 引入 126ms forced reflow, CrUX INP 80→278ms, 7/2 才发现 |
| 05-27 | #430 | 全站 mobile INP 304ms (GTM lazyOnload) | lab trace (复用 #428) | ✅ lab | ❌ 承诺"部署后复测"未执行 | 🔴 **方向错误**: 7/3 复盘认定 lazyOnload 使 GTM long task 与首次交互撞车, 被 #539 推翻重做 |
| 05-27 | #437/#442 | mobile INP (OTel browser lazy init) | lab trace | ✅ | ❌ 无 | 未知 |
| 05-27 | #441 | dashboard mobile LCP (React.memo+骨架) | Vercel SI RES 28-48 + GSC CrUX P75 9158ms + lab | ✅ | ⚠️ 被动 (下个 PR 顺带) | 失败: CrUX 仅 -70ms/3天, 文档自认"根因没改" |
| 05-29 | #451 | dashboard mobile DOM 20906 (分页) | lab trace | ✅ | ⚠️ 被动 | 部分失败: 用户反馈"desktop 没改善" |
| 06-01 | #454 | dashboard desktop LCP 10.3s (content-visibility) | lab desktop trace (1x CPU) | ✅ | ❌ **上线前 lab 验证 timeout 放弃**, "直接走 PR 让生产数据验证"; 上线后无记录 | 预测 0.5-1s; 7/16 文档披露 #460 时代 lab 仍 4.7s, **偏差 ~5 倍** |
| 06-01 | #460 | dashboard LCP (SSR catalog prefetch) | lab trace | ✅ | ✅ 用户体感 (被动) | 🔴 **上线 31 分钟 revert**: 阻塞 layout 拖全站 TTFB, "感觉更慢了" |
| 06-02 | #462 | marketing/SEO 页 LCP+CLS (GSC group mobile 4.8s) | GSC CWV group + **desktop** lab audit (1920×1080, 1x CPU) | ✅ | ✅ #464 文件记录 lab after | 部分成功: /blog 5676→3984, /services 4748→3194, **均未破 2.5s Good 线**; CLS 0.65 本 PR 撤销未修 |
| 06-02 | #464 | /blog server 化 + image dims (CLS 0.65) + service 页 grid | lab trace | ✅ | ⚠️ LCP 被 #502 顺带记录 (仍 4117ms); **CLS after 无任何记录** | 部分; CLS 修复效果至今无数据 |
| 06-16 | #502 | marketing 全线 Header hydration (预期每页 -500~800ms) | lab trace + GSC 28 天 (4.8→4.1 部分反映) | ✅ | ❌ 无 | 未知 |
| 06-21 | #518 | /service/[slug]/[country] TTFB 26s (删 mock delay) | Vercel SI **7 天仅 6 个样本** 的 P75 (文档自认"统计意义弱") | ✅ | ✅ #519 文件记录 | 🔴 **验证失败**: TTFB 仍 26.17s, 300ms delay 不是真凶 |
| 06-22 | #519 | 同上 ISR cold start (改全量 SSG, 480 页) | 同上 + 推理 | ✅ | ❌ 无 | 未知 (预期"RES 进 Great"无对账) |
| **06-30** | — | **GSC mobile "LCP > 2.5s" Validation FAILED, 42 URL 组 origin P75 3.5s; 同时发现首页 CrUX INP 80→278ms** | GSC/CrUX (外部裁判) | — | — | 🔴 6 月整月优化被打回 |
| 07-03 | #539 | 修 #428 reflow + 推翻 #430 (GTM 交互/5s 双触发) | 生产 lab trace (mobile 模拟) + CrUX INP 恶化数据 | ✅ | ❌ 计划 "CrUX ~8/1 + GSC 重新 Start Validation", 未到期 | 待定 |
| 07-05 | #558 | dashboard 4 子页假 hasInitialized 依赖 (topup/[id] 13s) | Vercel SI 30 天路由级 | ✅ | ⚠️ 被动: 7/12 生产 waterfall 显示 dashboard CrUX 9.75s 仍红 | topup/[id] 专项收益无记录 |
| 07-12 | #580 | dashboard catalog 1-2MB 全量矩阵 (CrUX mobile 9.75s) | **生产登录态** chrome-devtools waterfall + CrUX + 后端 span | ✅ | ✅ #583 文件记录: lab 9.75→6.86s | 部分成功, 暴露新瓶颈 /api/auth/me |
| 07-12 | #583 | /api/auth/me 冷连接 2.37s (pool keepAlive) | SigNoz span 三峰分析 (证据链最扎实的一次) | ✅ | ❌ 计划"上线后 SigNoz 复查", 无记录 | 未知 |
| 07-13 | #585/#590/后续 | dashboard 骨架错位 (感知性能) | 用户实测反馈 | — | ⚠️ 视觉验证反复推迟"上线后确认" | 4 次迭代才修对 (缺 loading→错配卡片→裸 spinner→shell 骨架) |
| 07-14 | #597 | i18n 懒加载 (~530KB locale 出客户端包) | bundle 分析 + **"agent 估 ~700ms 量级"** | ✅ bundle 探针 | ❌ 无性能 after | 未知 |
| 07-17 | #607 | dashboard SSR popular grid (LCP 4.5s→预期 1-1.5s) | Vercel SI 路由级 RES 64 + lab | ✅ **首次显式写"Before 基线"章节** | 承诺 D+3 复盘 (未到期) | 待定 |
---
## 二、模式 A — 打靶指标与计分指标不一致 (5 个案例)
1. **打了一整周 authed 页面, 而计分的是公开页** — #441/#451/#454/#460 (5/27-6/01) 全部火力攻 `/dashboard`，`changes/2026-06-01-marketing-seo-lcp-cls.md` 白纸黑字承认"**关键认知误判**: /dashboard 是 authed page, 不进 GSC CrUX 数据集, 真正影响 GSC 评级的是 marketing/SEO pages"。
2. **一个月后认知又翻转回来** — `changes/2026-07-05-*.md` 改口称 dashboard 占流量 45%、通过 **origin-level CrUX 兜底**"连坐"低流量 marketing 页。两个说法各对一半 (URL-group vs origin fallback)，说明团队从头到尾没有建立 GSC/CrUX 计分规则的确定模型，6 月上半月火力方向就是在这个模糊认知下选的。
3. **用 desktop lab 修 mobile 指标** — 6/01 的 5-URL audit 用 1920×1080 + 1x CPU desktop trace 定位问题，而当时红着的 GSC 指标是 **Mobile group LCP 4.8s**。
4. **用 Vercel SI 当 CrUX 的 proxy** — Vercel SI 是自家 RUM (含 authed 页、全浏览器)，CrUX 是 Chrome-only、28 天滚动、有 eligibility 门槛；#518/#519 更是直接对 **7 天 6 个样本的 P75** 开火，`changes/2026-06-21-*.md` 自己写着"P75 of 6 = 单点 outlier 主导, 统计意义弱"，仍连发两个 PR。
5. **lab 条件本身互不可比** — dashboard "基线" 在不同文档里是 10,272ms (desktop 1x)、4.7s (#460 时代 trace)、9.75s (CrUX field)、6.86s (Slow 4G+4x)。同名指标四套口径，"改善"与否取决于引用哪一套。
## 三、模式 B — 上线后从未回头验证 (预测无对账)
| PR | 承诺的验证 | 实际 |
|---|---|---|
| #430 | "部署后 trace 复测 INP" | 未做; 38 天后被 #539 定性为帮凶 |
| #454 | "上线后 CrUX/Vercel SI 验证" (上线前 lab timeout 放弃) | 无记录; 预测 0.5-1s vs 实际 ~4.7s |
| #502 | 预期每页 -500~800ms | 无任何 after |
| #519 | "P75 RES 进 Great" | 无任何 after |
| #558 | "部署后 Speed Insights + trace 验证" | topup/[id] 13s 的专项收益从未回查 |
| #583 | "上线后 SigNoz 复查 p95" | 无记录 |
| #597 | "agent 估 ~700ms" | 无性能 after (只验证了 bundle 内容) |
| #464 (CLS) | CLS 0.65 → <0.1 | **CLS 修没修好至今无一个数据点** |
共性: 每份 changes 文档的"验证"章节 90% 是 `tsc / lint / vitest`（编译级），真实性能验证一律写进 Follow-up——而 AFK 自主工作流的完工标准是"CI 全绿 + Lark 通知"，PR merge 即终结，Follow-up 无人认领。直到 7/16 #607 才第一次把 "Before 基线 + D+3 复盘" 写进文档结构。
## 四、模式 C — 验证失败 / 负向反馈 (6 个案例)
1. **GSC Validation FAILED (6/30)** — 6 月整月 marketing 优化后重新提交验证，被 GSC 判定失败 (mobile LCP 42 URL, origin P75 3.5s)。见 `changes/2026-07-03-perf-gtm-defer-and-reflow-fix.md`。
2. **#428 造成 CrUX INP 3.5 倍恶化** — react-window hydration 期 forced reflow，80ms→278ms，**潜伏 35 天** (5/27 上线, 7/2 定位)。这期间团队一直在发 LCP 优化 PR，外部评分却被自己的 INP 回归拖着。
3. **#430 GTM lazyOnload 方向性错误** — 把 long task 推到 window.load 恰好撞上用户首次交互，7/3 被推翻重做。
4. **#460 上线 31 分钟 revert** — 唯一一次"实时"负反馈闭环，代价是生产用户体感。
5. **#518 after 验证失败** — 删 300ms delay 后 TTFB 仍 26.17s (`changes/2026-06-22-*.md` 开头如实记录)——讽刺的是，这是全战役里少数认真做了 after 验证的 PR。
6. **#454 上线前验证失败被放行** — lab 注入验证反复 timeout，文档写"恰好印证主线程繁忙，直接走 PR 让生产数据验证"——把验证失败解释成了佐证。
---
## 五、观察: 这个团队的性能工程闭环缺了哪几环
1. **缺"指标合同"环**。从未定义"最终计分指标 = GSC 所用的 CrUX 28 天 P75，lab/Vercel SI 只是 proxy"这条铁律。结果是: 火力方向靠对 CrUX 计分规则的错误理解选定 (6/01 vs 7/05 两次翻转)，lab 用 desktop 修 mobile，对 6 样本 P75 outlier 认真打靶。
2. **缺 after 对账环**。18 份文档全有"预期收益"，只有 3 份 (#462→#464、#518→#519、#580→#583) 有实测 after，且全是"下一个 PR 的调查顺带充当上一个 PR 的验收"——接力式、被动式。预测数字系统性乐观 (最大偏差 5 倍)，且从无人回头统计预测命中率，导致"预期收益"章节沦为仪式。
3. **缺回归监控环**。两个 perf PR 自己把 INP 打恶化 3.5 倍，35 天无人察觉。INP 80→278ms 在 Vercel SI 里当天就应可见，但没有任何 RUM 告警或每日 synthetic trace 基线比对——性能只在"有人决定看"的时候被看。
4. **缺单变量/归因环**。CrUX 是 28 天滚动窗口，而团队节奏是每周 2-3 个 perf PR。6/30 validation 失败时，窗口里叠着 #462/#464/#502/#518/#519 的正向改动和 #428/#430 的负向回归，谁贡献了什么无法拆解。在这种发布密度下，以 CrUX 为验收指标的"优化"本质上不可归因，等价于开环控制。
5. **缺验证标准环**。"验证"一词在文档里被降级为 tsc/lint/vitest；性能验证可以因为 lab timeout 而豁免 (#454)、因为本地环境配置麻烦而跳过 (多份文档的"新 worktree 起后端卡 JWT 配置...跳过 dogfood")。骨架系列 4 次迭代全靠用户肉眼当 QA，也是同一个缺环的体现。
6. **工作流层面的结构性原因**: AFK 自主 PR 工作流把"完工"定义在 merge 时刻，天然排斥 D+N 复盘这种跨会话任务。#607 (7/16) 首次内置 Before 基线 + D+3 复盘承诺、#580→#583 出现生产登录态 waterfall + SigNoz span 级归因，说明团队已在自我修正——但截至取证日 (7/17)，尚无一个 perf PR 完成过"预测→上线→按预测口径实测→写回结论"的完整闭环。
## 六、证据文件索引
核心: `changes/2026-06-01-marketing-seo-lcp-cls.md` (认知误判自白 + desktop 修 mobile)、`changes/2026-07-03-perf-gtm-defer-and-reflow-fix.md` (Validation FAILED + #428/#430 回归定性)、`changes/2026-06-22-seo-three-layer-static-ssg.md` (#518 验证失败记录)、`changes/2026-07-16-dashboard-ssr-popular-grid.md` (首个 Before 基线 + #460 revert 复盘)、`changes/2026-07-12-dashboard-catalog-slim-first.md` + `changes/2026-07-12-db-pool-keepalive.md` (接力式验证链)、`changes/2026-06-01-dashboard-content-visibility.md` (#454 验证豁免)、`changes/2026-05-27-defer-gtm-lazyOnload-perf.md` (#430 原始决策)。