速度是收入输入，以真实用户度量
慢的店转化更差、排名更低、每次广告点击更贵。而店铺速度默认就会衰退——每次装应用、每个活动脚本都在把它往错的方向推。
速度优化常见两种失败：优化一个真实用户从未经历的实验室分数，以及修一次就完事而衰退的原因还在继续运转。Ops 把速度当持续学科来跑——真实用户 Core Web Vitals 按模板与设备细分、找原因而非治症状、在边缘修或交给 Builder、用基线在回归到来时抓住它。
度量顾客真实经历的
测试服务器上的合成分数说明不了蜂窝网络上中端手机用户的体验。按模板拆分的真实用户数据，才能把问题定位到可修的东西上。
按模板（商品、分类、首页、结账）的真实用户 LCP、INP、CLS
设备与网络拆分——真正的损失通常集中在这里
第三方脚本成本，逐脚本归因而非笼统汇总
实验室分数与实测数据的差距，本身就是诊断线索
在正确的层修正确的因
有些是边缘问题——缓存、图片分发、压缩——Ops 直接修。有些是页面问题——渲染阻塞脚本、超大媒体、迟加载元素造成的布局偏移——这些带着证据作为具体任务交给 Builder。
回归是默认值；要防
三月很快的店到八月就慢了，因为应用和脚本在累积。基线让衰退立即可见：新应用或主题更新拖低某模板的指标时，当周就被标记、附上原因，而不是等季度审计才发现。
运行方式
按模板建基线
Ops 按模板与设备记录真实用户指标——之后每次变化的评判参照。
按层修复
边缘问题在配置里修；页面问题带着具体证据交给 Builder。
盯住衰退
新脚本、应用与主题变更对照基线检查，拖慢速度时被标记。
你会得到什么
按模板与设备的实测指标，而非一个实验室分数
第三方脚本为其成本逐一负责
修复应用在拥有该问题的层
回归发生当周即被抓住，原因随附
由这些 Agent 负责
常见问题
店铺最该看哪个指标？
商品与分类模板的 LCP 通常是收入敞口最大的，交互密集页面的 INP 紧随其后。但诚实的答案是：你的真实用户在真实设备上最差的那一个。
删应用会不会弄坏功能？
审计会区分「值回成本」和「不再值」的脚本。移除是带证据提议、分步执行的，真正承重的东西会在出事前被拦下。
速度对转化影响到底多大？
大到在你自己的数据里就能看见——这才是要紧的度量，而不是行业统计。基线让你看到自己的弹性，不用引用别人的。
这对 SEO 也有帮助吗？
有——页面体验信号参与排名，更快的页面爬取也更高效。但转化收益通常在排名收益到来之前就把工钱挣回来了。