Shopify 的 Core Web Vitals 基线：先分清平台负责什么

在 Shopify 上谈性能，第一件该做的事是把「平台已经处理掉的」和「主题里做错的」分开。别人发来的一个分数里，很多失分点根本不在你能改的范围；反过来，主题里给首屏大图加上懒加载、用淡入动画盖住首屏，又常常是真正的元凶。分不清这两类，优化就会一直做在不对的地方。

平台给了什么，剩下的才是你的活

Shopify 的主题文档专门花了几页讲首屏大图该怎么加载：不要让 LCP 图懒加载（Never lazy-load the LCP image）、给它标记高优先级（fetchpriority 文档）、别把它藏在动画后面（动画与 LCP 文档）。这些页面存在本身就说明了一件事：首屏图片的加载方式属于主题层面，要由改主题的人来管，不是装上平台就自动解决的。

平台确实承担了一部分：主题里用图片过滤器输出图片时，平台会按你指定的宽度生成对应尺寸的文件，不需要自己准备几套图；官方文档里 image_tag 在按位置自动决定加载方式上也有一套默认行为。但这套默认只在主题没有绕过它的时候才生效——自己写 img 标签、用脚本懒加载库、或者由应用注入的图片，都会脱离这套默认。

至于分发链路和压缩这类平台侧的机制，官方文档没有给商家一份可以逐项核对的清单。与其猜，不如把浏览器 Network 面板里的实际请求当成依据：谁发起的请求、什么时候开始、响应多大、由哪个域名返回。能看到的东西才谈得上优化，看不到的部分就不要写进报告里当结论。

三个指标各自在说什么

Core Web Vitals 由三个指标组成，分别对应加载、交互和视觉稳定（Web Vitals 说明）。它们的目标值按页面加载的第 75 百分位衡量，并且移动端和桌面端要分开看，一个平均值说明不了大多数用户的体验。

指标	衡量什么	目标
LCP	首屏最大内容元素的加载时间	2.5 秒以内
INP	页面整体对点击、轻触、键盘输入的响应延迟	200 毫秒以内，超过 500 毫秒算差
CLS	页面生命周期内最大的一波意外布局偏移	0.1 以内，超过 0.25 算差

这三个数字来自官方文档，记下来是为了有共同的判断标准，不是说达到就万事大吉。指标本身也在演进，官方写明这套组合会随时间调整。

在 Shopify 上，它们各自最常被什么拖住

LCP：首屏图片的加载方式

最常见的是三类写法。给 LCP 图加了懒加载，浏览器要等交互动画触发才开始下载；用了脚本懒加载库（把图片地址挪到自定义属性里），图片地址对预加载扫描器不可见，必须等脚本执行；图片拿到了高优先级，却被 CSS 的淡入或页面过渡藏在透明度为零的状态里，浏览器要等它重新绘制才记 LCP。主题设置里如果有「页面之间的过渡动画」这类开关，关掉它可能是整件事里最省力的一步。具体改法见首屏图与懒加载的处理。

CLS：没有尺寸的东西，和后来才插进来的东西

布局偏移的来源在官方文档里列得很清楚：尺寸未知的图片和视频、字体渲染出来的尺寸和备用字体不一致、第三方广告或小组件自己改变尺寸（CLS 说明）。同一页也解释了为什么本地测试常常看不出问题：测试图片已经在开发者的浏览器缓存里、本地接口调用快到看不出延迟、个性化内容在开发和线上的行为不一样。所以偏移问题通常要等线上用户反馈或者字段数据才暴露，排查顺序见布局偏移的来源排查。

INP：主线程被占住的时候

INP 衡量的是交互到下一次画面反馈之间的时间，跟页面多快加载完不是一回事。官方文档给了一条背景：用户在一个页面上的时间有九成花在加载完成之后（INP 说明）。所以变体切换、加购、筛选这些动作慢半拍，感受到的是「网站卡」，不是「网站慢」。常见来源是长任务占用主线程、大量第三方脚本、滚动监听和没有节流的处理逻辑，排查思路见主线程与交互延迟。

建立基线：字段数据和实验室数据分开记

基线的作用是让「改完有没有变好」这个问题有答案。做法比工具重要：

1. 先定页面。首页、一个集合页、一个产品页各选一个当代表，分开记录。用全站一个分数代表所有页面，后面就没法判断某个改动是否有效。
2. 字段数据优先看真实用户结果。这类数据来自实际设备和网络，是你自己测不出来的。它也有盲区：嵌入页面的交互未必被统计进来，工具之间口径不一致时对不上是正常的。
3. 实验室数据固定条件再跑。同一页面、同一设备模拟、同一网络与地区设置，跑完把原始结果存下来，不要只抄一个分数进表格。
4. 看分位数不看平均值。官方建议按第 75 百分位衡量，平均值会被快的那一半拉高。
5. 一次只改一类。改完用同一条件复测，隔几天再看一次，避免把正常的波动当成成果。
6. 记录改了什么：动了哪个文件、改了哪个设置、装了或卸了哪个应用。没有这行记录，下次数据对不上时只能重来。

测之前先确认你测的是同一种页面状态

同一页面在不同状态下性能差别很明显，比较之前先把状态统一：是否带缓存（第一次访问和第二次访问的结果不一样）、是否登录、是否切换过市场或币种、是否弹出过同意管理提示、站点是否正在跑 A/B 测试。这些状态里任何一个变了，前后两次数据就没有可比性。做法是在记录里写清楚条件，而不是只写页面地址。设备也要分开：手机端模拟的 CPU 和网络限制与桌面端不是一套，两边各记一份。

工具方面不需要求新。浏览器开发者工具里的网络面板看请求顺序和时间线，性能面板录一次加载看 LCP 发生的时间点与图片下载完成时间的差距——差距很大说明有东西在拖延绘制，而不是图片本身慢。这个判断方式比单看分数更能指向具体的那一行代码。

一次跑分为什么不能当结论

实验室测试是单次、固定条件下的结果，字段数据是成千上万次真实访问的汇总，两者本来就不该相等。常见的差距来源有：测试设备与网络和用户实际使用的差得远；测试地区不是主要买家所在地区；测试时页面命中了缓存或者第三方脚本没加载完；字段数据受样本量影响，流量小的站点波动明显。把这几种情况分开写在报告里，比盯着两个数字为什么不一样更有用。用单次分数宣称「性能提升」是最容易被打回来的说法——同一页面连跑两次都可能给出不同的结果。

改动优先级：先做影响大、风险低的

• 关掉主题设置里的页面过渡与首屏淡入。这一步通常不需要改代码，先做。
• 把首屏图的懒加载去掉，给它加高优先级提示（写法见下）。

{{ section.settings.image
  | image_url: width: 1000
  | image_tag: loading: 'eager', fetchpriority: 'high'
}}

高优先级只给一张图。官方文档提醒过，过度使用会干扰浏览器自己的优先级判断，把本来该先下的资源挤到后面。

• 图片容器给出固定比例，让位置在图片到达之前就占住。
• 迁移掉基于脚本的懒加载库，改成原生的加载属性。
• 延迟或去掉不必要的第三方脚本，这一类要和应用方确认归属后再动，做法见第三方脚本审计。
• 每完成一类就复测一次，别攒着一起改。站点级的抓取与索引检查是另一条线，可以对照技术自查清单分开安排。

基线之外，几件不能承诺的事

不承诺分数提升到某个值，也不承诺指标达标后排名会变。Core Web Vitals 是体验指标，官方把它列为页面体验相关的参考，不是排名公式里的独立开关。第三方脚本造成的瓶颈归属应用方，你能做的是延迟加载、替换或移除，改不了别人的代码。移动端和桌面端的结论不能互相套用，手机上的首屏尺寸和网络条件决定了优先级不一样。流量小的站点拿不到足够样本，字段数据只能当参考，结论里要说清楚这是判断而不是数据。平台已经处理的部分不要再做一遍，重复的优化动作很多时候是负收益。

最后一点和站点结构有关：性能工作通常和内容、收录一起排在改版队列里。如果站点里还有 WordPress 部分，两边的技术栈和优化手段不同，可以参考我们在WordPress 速度优化里的处理顺序，但不要把一边的结论直接搬到另一边。选平台时对性能的预期差异，之前在这篇Shopify 与 WordPress 的对比里也提过。

给做决定的人一句实在话：性能基线值得建，但别指望它成为项目里最亮的那件事。真正的收益体现在买家不再因为按钮点不动、图片跳来跳去而离开，订单和询盘才是最终要看的数。指标是过程记录，不是成绩单。