Shopify已经提供CDN和多项传输优化，主题与应用仍会影响用户体验。先确认慢在哪里、发生在哪些页面和设备，再决定改图片、Liquid、脚本还是布局。不要看到一个低分就同时安装多款加速应用，也不要因平台有CDN就停止查页面。
三个核心指标，各自回答不同问题
| 指标 | 主要衡量 | 良好 | 差 |
|---|---|---|---|
| LCP | 视口内最大合格内容元素的呈现时间 | ≤2.5秒 | >4秒 |
| INP | 页面访问期间交互到下一帧反馈的延迟，考虑异常值处理 | ≤200毫秒 | >500毫秒 |
| CLS | 整个页面生命周期内最大布局偏移会话窗口的累计分数 | ≤0.1 | >0.25 |
这些等级按CWV阈值说明使用，Web Vitals规定现场评估看第75百分位并区分移动与桌面，不是把几次本地测试求平均。三个指标都满足良好条件，才可在相应数据范围谈CWV通过；“没有数据”不能写成通过或失败。
LCP不只可能是主图，也可能是文字或其他合格元素；INP覆盖点击、轻触和键盘交互，不是页面加载时间或滚动流畅度分数。一次没有实际交互的加载测试不能产生完整现场INP，TBT只能提供相关诊断线索。CLS没有秒或毫秒单位，也不等于加载时所有移动简单相加。
平台自动完成什么，主题还要决定什么
Shopify主题性能文档列出平台CDN、压缩、协议及响应优化；不能说原厂没有说明这些能力。主题仍决定输出哪些内容、调用多少Liquid工作、何时发现主图、如何分配尺寸，以及应用在何处执行。使用image_url和image_tag有助于生成合适图片地址及属性，但实际参数与输出还要核。
HTML响应快也不保证主内容马上可见：流式响应中，首字节可能先到而section仍在渲染。应用脚本也可能来自第三方域名，不能把平台自动优化的结论推广到每一个外部请求。
一份可比较的基线应该记录什么
- 页面URL、类型、主题/应用版本、市场语言、商品状态和测试时间。
- 设备、浏览器、视口、网络与CPU模拟条件、冷/热缓存和同意状态。
- 原始测试结果、LCP元素与请求、主线程长任务、布局偏移记录及实际交互步骤。
- 现场数据的时间窗口、URL或源站范围、设备分组与是否有足够样本。
首页、集合和产品可作为起点，但还要覆盖实际差异：长商品页、带评价的页面、不同模板和关键购买操作。次数由波动和问题决定，不把单次最好分数当最终成绩。PSI显示源站级数据时，要明确它不只代表当前URL。
按证据选择下一步
| 观察 | 继续查 | 完成后怎么确认 |
|---|---|---|
| LCP资源开始得晚 | HTML可发现性、懒加载、优先级与请求依赖 | 同条件比较请求时机和LCP，而非只看文件变小 |
| 交互反馈慢 | 输入延迟、处理工作与下一帧绘制 | 实际操作记录与后续现场INP |
| 内容跳动 | 尺寸、字体、异步内容及偏移发生时间 | 加载及后续滚动/操作都检查 |
| 服务端内容到达慢 | Liquid渲染、循环与实际响应 | 结合服务端诊断和浏览器时序，不全归咎网络 |
首屏图见LCP图排查，页面跳动见CLS定位，第三方代码见脚本与像素审计。修改前保留基线，修改后既核性能也核商品、交互和统计功能；跑分改善不能替代这些功能检查。
持续观察应跟随主题、内容和应用变化安排。实验室结果、真实用户体验、索引排名与成交是不同结果；没有对应数据时，不把“已优化代码”写成“已提高转化”。