Shopify 店铺的 Core Web Vitals（CWV）是一场预算游戏，不是“把它弄快一点”的游戏。LCP、INP、CLS 各分得有限性能包络里的一块，被一小撮杠杆消耗：应用加载了什么、多少 JavaScript 上了船、图片怎么生产和分发、主题如何渲染首屏。不能测量就无法优化，不拥有就无法预算。这篇文章讲 CWV 在 Shopify 上在哪里出问题、如何设一套站得住脚的预算、以及撬动 LCP 和 INP 的杠杆。
CWV 在 Shopify 上到底在哪里出问题
先诊断再优化。我们审计过的店铺模式相当一致：
- LCP 被图片主导，而图片被过度投放。 2400px 的源图渲染成 400px、用 PNG 交付、懒加载用错、或与一张比整页还重的首屏 hero 抢占预加载。Shopify 的图片 CDN（
cdn.shopify.com）能按需缩放和转码，但前提是你要求它——?width=参数、srcset、loading="lazy"的纪律。 - INP 被 JavaScript 主导，而大部分是应用的。 第三方脚本、跟踪像素、聊天挂件、upsell 库，各带自己的运行时，共享一条主线程。你自己的代码还没跑，预算就已经花光。
- CLS 通常是主题问题。 图片没有显式尺寸、web 字体切换、应用区块注入动态高度。CLS 最好修，也最常被无视。
主题本身——纯 Liquid 渲染——很少是 LCP 的瓶颈。这意味着杠杆主要在于你允许什么进入页面，而不是渲染引擎。
设置一套能站得住脚的预算
CWV 阈值是地板，不是目标（LCP ≤ 2.5s、INP ≤ 200ms、CLS ≤ 0.1，75 分位）。店铺前端要留余量：字段数据很吵、移动网络毫不留情。一份针对内容密集商品页的务实预算：
- LCP 目标 2.0s：首字节到首次图片请求 ≤ 1.0s，图片请求到 LCP 绘制 ≤ 400ms。
- INP 目标 150ms（交互 p75），页面第三方 JS（gzip 后）硬上限约 500KB，规则是“用不到它的页面不允许出现”。
- CLS 目标 0.05，基本意味着“为一切晚到的内容预留空间”。
把预算写下来、发布到仓库。每次应用接入和主题改动都对着它评审——像给依赖做漏洞评审一样。性能是一项约束，只有评审时执行才会存活。
真正撬动 LCP 和 INP 的杠杆
LCP：图片管线与关键路径
- 图片管线。 按展示尺寸生产图片，
cdn.shopify.com变换出 WebP/AVIF，srcset做响应式密度。用fetchpriority="high"和正确的sizes预加载 LCP 图片，绝不对首屏以上图片懒加载。LCP 元素由测量决定，不是猜。 - 关键路径上的应用 JS。
theme.liquid里每个 script tag 都在消耗 LCP，逐个审计：干什么、什么时候跑、该不该在这页上？非关键脚本延迟加载，应用代码推进 Theme App Extensions，让 Shopify 按区块控制资源加载。 - 服务器响应时间。 Shopify 的基础设施又快又充裕，杠杆是你加在上面的东西——重型应用、自定义字体、过量的 metafield 查询。关键路径保持薄。
- 字体。 自托管、只预加载实际用到的字重，其余
font-display: swap，文件压小。字体是经典的隐形 LCP 消耗者。
INP：主线程是共享资源
用 PerformanceObserver 做真实用户监控（RUM）拿交互数据，Lighthouse 做实验室快照——两者都要，前者调试、后者求真。消灭长任务：300ms 的主线程任务拖慢之后的每次交互，用 profiler 找到后推迟、拆分或移出主线程（requestIdleCallback、web worker）。给第三方 JS 设 gzip 字节上限并按应用执行——这是 Shopify 上杠杆最高的 INP 修复。事件处理器里避免 layout thrash，DOM 变更批量做，滚动时读布局要谨慎。
什么时候需要外部帮助
如果 Lighthouse 分数不错但 Search Console 的 CWV 报告是红的，或你正要接入重型应用却说不出它会花掉多少——一次性能审计可以产出预算、测量设施和按优先级排序的杠杆清单，再用前后字段数据验证改动。诊断若是应用过重，产出往往是一小撮零成本、却移动一切的删除或延迟加载。如果你希望预算写进路线图而不是事后补救，可以预约一次 Commerce Architecture Review。