页面速度 playbook
速度优化的失败方式是优化一次实验室分数就宣布胜利。可持续的版本度量真实用户、按层修复，并把回归当默认要防的事。
店铺速度是收入输入——转化、广告效率和排名都会计价——而且随着应用、脚本、图片累积，它默认就在衰退。这份 playbook 跑的是纪律：按模板建立实测数据基线，在正确的层（边缘配置对页面结构）按影响顺序修复，装上让改善变成永久（而非每季度一次的英雄主义）的回归绊线。
阶段一：按模板、按实测数据建基线
实验室分数两个方向都会骗人。采集按模板——商品、分类、首页、结账——和按设备细分的真实用户 LCP、INP、CLS。按收入加权的视图告诉你从哪开始：移动端的慢商品模板通常在影响上碾压其他一切。
按模板与设备档的真实用户 Core Web Vitals
模板 × 收入加权，排定工作顺序
完整的第三方脚本清单，逐脚本计成本
实验室与实测的落差，本身就指向原因
阶段二：在拥有问题的层修复
边缘层问题——缓存规则、图片格式与尺寸、压缩、分发——在配置里修，一次全店生效。页面层问题——渲染阻塞脚本、超大首屏媒体、迟加载挂件的布局偏移、应用膨胀——在模板里修。先做边缘工作，常常在碰任何模板之前就把问题砍掉一半。
阶段三：让它保持修好
未来每次装应用、加活动脚本都是一次待发生的回归。保持按模板的基线常亮、新脚本按实测成本审查、按计划重审第三方清单——去年值回票价的脚本今年未必还值。
运行方式
建基线并排序
按模板的实测指标、按收入加权、脚本清单计完成本。
先边缘后模板
配置级修复立即全店生效；模板修复按影响顺序跟上。
守住成果
基线常亮、脚本成本审查、计划性重审，让店不再重新衰退。
你会得到什么
在真正付钱的用户身上度量的速度
在拥有各自问题的层实施的修复
为成本逐一负责的第三方脚本
回归在落地当周被抓住，而非下个季度
由这些 Agent 负责
常见问题
Core Web Vitals 该定什么目标？
公开的良好阈值——LCP 低于 2.5 秒、INP 低于 200 毫秒、CLS 低于 0.1——按模板、取真实用户第 75 百分位。但方向比阈值重要：从糟糕到及格的店已经拿到大部分转化收益。
光做边缘层能提多少？
在从未调过的店上，边缘工作——正确的缓存、现代图片格式、压缩——常常不碰模板就交付大半改善。所以它排第一。
主题就是问题所在，重建还是打补丁？
先度量：模板修复清单短而有边界，就补；主题架构跟每个修复对着干，重建才回本——这是拿证据做的决定，不是拿情绪。
哪些 Agent 跑这个？
Ops 负责基线、边缘层与回归监控；Builder 带着证据上线模板修复。审计日志记录改了什么、对指标做了什么。