学习契约与正确模型
先明确为什么学、学完能做什么，以及如何证明自己真的掌握。
B2B 落地页的标签、聊天、视频与表单常让交互迟钝，直接损伤演示申请和试用完成率。
- 能区分 field 与 lab data
- 能解释 LCP、INP、CLS 与 75 分位
- 能把指标拆成工程根因
精读 30 分钟 → 引导练习 20 分钟 → 实战任务 70 分钟。实战时间单列，不再把浏览页面和项目操作混成一个数字。
- 它是什么
- CWV 是真实用户指标：LCP 衡量主要内容加载，INP 衡量交互响应，CLS 衡量视觉稳定。
- 为什么重要
- 总分和单次测试会隐藏长尾；按设备与模板观察更接近实际体验。
- 什么时候使用
- 模板发布、转化下降、CrUX/GSC 变差或引入大型第三方脚本时。
- 什么时候不要套用
- 不要把 Lighthouse 单次分数当排名承诺，也不要不测转化就删除业务功能。
- 边界与不确定性
- CWV 只是体验和搜索信号之一；达标不保证排名，未达标也非所有流量问题根因。
机制精讲
先读完整因果链，再看每个环节留下什么可观察信号。
Core Web Vitals 用一组面向真实用户体验的指标描述加载、交互和视觉稳定性，其中 INP 关注页面生命周期内用户交互到下一帧呈现之间的响应延迟。它不是“JavaScript 执行总时间”，也不是某次 Lighthouse 测试的单一分数。学习时必须同时理解字段数据与实验室数据：字段数据反映真实用户、设备和网络分布，实验室追踪帮助复现主线程、事件处理和渲染过程，两者回答的问题不同。
优化应从用户任务和慢交互出发，而不是为了让数字变绿而删掉必要功能。公开阈值与 Chrome UX Report 的统计口径可以核对，但某次改动是否改善业务需要自己的实验和行为证据。SEO 结果也不能由 CWV 单独解释；性能是页面体验与技术质量的一部分，需求、内容和竞争仍同时作用。本课训练你从分位数和页面组定位，到 DevTools 复现，再到任务级验收。
交互延迟分解
一次交互的呈现延迟可理解为输入等待、事件处理和下一帧呈现三部分。长任务会占住主线程，使用户输入先排队；处理器或渲染也可能是瓶颈。
字段分布与分位数
CWV 评估依赖真实用户样本和统计窗口，通常关注较高分位而非平均值。URL 可能被归入页面组，数据也有时间滞后和样本门槛。
任务级性能预算
优化要保护演示表单、筛选、导航等关键任务。拆分长任务、减少第三方阻塞或延后非关键工作，都需确认功能和可访问性未退化。
关键概念
掌握术语之间的关系，才能迁移到不同网站、行业和工具。
良好阈值
第 75 百分位 LCP ≤2.5 秒、INP ≤200 毫秒、CLS ≤0.1 通常视为良好。
现场与实验室
CrUX/RUM 反映真实用户；Lighthouse 和 DevTools 帮助复现与归因。
模板聚合
GSC 按相似 URL 分组；修复要落到共享模板、组件和脚本。
完整示范
跟随一次“输入 → 分析 → 中间产物 → 结论”，看见专家是怎样做判断的。
优化演示申请页的国家选择器
教学用合成数据：移动端字段 INP p75 为 420ms，桌面为 170ms；实验室记录国家下拉首次点击出现 680ms 长任务，营销聊天脚本和表单校验在同一时刻初始化。
- 字段样本覆盖主要移动用户
- 表单提交正确性不能为了性能被牺牲
限定问题群体
- 输入
- CrUX/GSC 页面组、设备和时间窗。
- 分析
- 确认退化集中在移动端演示模板，而非全站；平均值不用于替代 p75，近期发布后留足字段窗口。
- 输出
- 受影响模板、设备和基线说明。
复现具体交互
- 输入
- 中低端设备配置与 Performance trace。
- 分析
- 点击国家选择器，标出输入等待、处理和呈现；发现聊天初始化占 310ms、同步校验占 220ms，避免只凭 bundle 大小猜测。
- 输出
- 带时间线和调用栈的慢交互证据。
分离工作
- 输入
- 脚本所有者与任务依赖。
- 分析
- 将聊天脚本延后到空闲或真实意图，拆分初始化长任务，校验只处理当前字段并让出主线程；保留键盘和错误提示行为。
- 输出
- 改动清单、性能预算与可访问性测试。
双层验证
- 输入
- 预发布实验室测试与发布后字段数据。
- 分析
- 先确认目标交互 trace 改善且提交无错误，再观察完整字段窗口中的移动 p75、表单完成率与异常。不能由一次 Lighthouse 分数宣告业务或排名提升。
- 输出
- 前后证据、置信限制和是否扩大方案。
决策规则与证据边界
把“看到什么、意味着什么、下一步做什么”连起来，同时区分公开事实、实践推断和未知项。
- INP 定义、字段统计口径和浏览器 trace 中任务时序可依据公开文档与记录核对。
- 拆分特定长任务可能改善该交互，需同条件复测和字段数据确认。
- 无法把若干毫秒改善换算成固定排名或收入增量。
引导练习
先独立完成，再按提示修正，最后展开参考解法并用 0–4 级量规评分。
解释教学用合成数据：产品筛选页移动 INP p75=380ms；实验室点击“应用筛选”时，分析脚本 180ms、筛选计算 140ms、DOM 更新 90ms，改动后实验室总延迟降至 190ms。
给定材料
- 字段窗口仍包含改动前 20 天和改动后 8 天。
- 改动同时把筛选结果数量提示从 aria-live 移除，键盘用户反馈不再得到结果确认。
需要提示时再展开
- 区分机制验证、字段验证和业务/可访问性验收。
- 当前字段窗口不足以独立反映改动后状态。
完成后核对参考解法
实验室证据支持改动减少了目标交互中的分析、计算或 DOM 工作，总延迟从教学用合成的 410ms 降到 190ms，可说明机制方向有效；但字段窗口仍以改动前数据为主，不能据此声称真实用户 p75 已改善，应等待足够完整窗口并按设备/模板观察。同时移除 aria-live 破坏了关键任务反馈，属于发布阻断问题：恢复可访问提示并重新测量，不能用性能收益抵销功能损害。最终报告应并列呈现 trace、字段 p75、错误/完成率和可访问性验收，且不推断固定 SEO 增益。
自评分量规
真实项目实战
把理解变成一个可以检查、复核和复用的工作产物。
优化演示申请页
移动端演示页 INP 较差，用户点击表单字段后明显卡顿。
- 记录 CrUX/GSC/RUM 基线
- 定位最长交互与主线程任务
- 按自有代码和第三方归因
- 拆长任务并延后非关键脚本
- 灰度发布并观察 CWV 与转化
验收条件
- 报告明确数据窗口与样本限制
- 第 75 分位 INP 和转化不恶化
- 最长交互关联具体处理器
- 回归预算进入发布检查
诊断练习
目标不是猜中答案，而是提出竞争假设并选择能区分它们的证据。
Lighthouse 95 分，但 GSC 显示 INP 较差。
竞争假设
- 实验室未触发复杂交互
- 真实设备更慢
- 第三方只在同意后加载
- URL 组含其他差模板
应该检查的证据
- 查看 CrUX 设备和历史分布
- 采集 interaction attribution
- 复现同意/表单/聊天流程
- 拆分 URL 组样本
常见陷阱：重复跑首页 Lighthouse，忽略真实用户和交互。
完成后用本页决策规则复核
- 若观察到：字段 INP 差但实验室默认点击正常
应优先：按模板与设备找慢交互，补充 RUM 或代表性 trace。
不要用一次快速设备结果否定字段分布。 - 若观察到：单个长任务与慢交互时间重合
应优先：拆分、延后或减少工作，并在相同交互下做前后对照。
时间重合不是充分因果证明。 - 若观察到：性能数字改善但表单完成率下降
应优先：暂停扩大，检查错误与用户路径，必要时回滚。
绿色指标不能覆盖业务退化。
自测与误区
先口头回答，再展开检查。无法给出例外与证据，说明还没真正掌握。
你应该能回答
1. 哪个数据源、时间窗、设备和分位数？
参考答案：必须同时写数据源、28 天等统计窗口、移动/桌面、页面组或 URL，以及采用的 p75；否则数字无法比较。
为什么：CWV 是分布和口径指标，不是脱离样本的单点值。
2. 最慢交互由什么造成？
参考答案：用真实关键交互的 Performance trace 分解输入等待、事件处理和呈现，再从长任务调用栈定位脚本、计算或 DOM 工作。
为什么：总分只能提示问题，时间线才能连接具体执行机制。
3. 优化是否改善业务任务？
参考答案：同时验证错误率、完成率、可访问性和用户反馈，并在发布后观察任务表现。
为什么：性能服务于任务，不能以牺牲功能换取指标；否则分数改善只是把成本转移到正确性、可访问性或完成率。
需要避开的误区
- FID 仍是当前交互指标
- Lighthouse 等同真实用户 CWV
- 三项变绿就一定提升排名
术语与复盘
用自己的话复述术语和结论；如果只能认出、不能解释，就还没有形成可调用的知识。
- INP
- 衡量页面交互响应延迟分布的 Core Web Vital。
- p75
- 约 75% 观测值不高于该数值的分位统计。
- 长任务
- 长时间占用主线程、可能延迟输入处理的任务。
- 字段数据
- 由真实用户环境汇总形成的体验观测。
- 实验室数据
- 在受控设备、网络和操作下产生的可复现诊断数据。
离开本页前记住
- INP 关注交互到下一帧，不是总脚本时间。
- 字段与实验室数据承担不同职责。
- 从真实任务定位慢交互。
- 优化后必须做功能与可访问性回归。
- 性能改善不能换算成固定排名收益。
资料与证据
优先采用官方和一手资料。实践材料用于补充工作方法，不替代机制证据。