关于 Shopify 与电商的报道与研究
Largest Contentful Paint 是 Shopify 店铺表现最明显失分的 Core Web Vitals 指标,我们自己的审计说明了原因:在 15 个官方主题演示站上,首次绘制大约在 2 到 5 秒之间出现,随后购物者还要再等最多 13.9 秒才能看到主视觉媒体。下面是其运作机制和修复清单,附带具体数据。
Largest Contentful Paint 衡量的是一个时刻:首屏中最大的可见元素完成渲染的时间。在 Shopify 店铺上,这个元素几乎总是主视觉图片、第一张商品照片,或自动播放视频的封面帧,而这恰恰是 Shopify LCP 分数不合格的原因。平台的服务器响应很快,主题的骨架也很早就绘制出来;然后购物者盯着一个占位框架,等着数兆字节的主视觉媒体在移动网络上慢慢爬下来。
我们自己的数据让这个机制变得可见。2026 年 7 月 14 日,我们对 15 个官方主题演示站运行了 45 次 Lighthouse 审计,而有意思的数字不是 LCP 本身,而是 First Contentful Paint 与 LCP 之间的距离。FCP 是骨架到位的时刻;FCP 到 LCP 的差距就是主视觉媒体让所有人干等的时间。
| 主题演示站 | FCP | LCP | 差距(等待主视觉) |
|---|---|---|---|
| Ultra | 1.91s | 1.91s | 0.0s |
| Boutique | 2.20s | 3.67s | 1.5s |
| Symmetry | 1.53s | 6.33s | 4.8s |
| Impression | 5.22s | 12.19s | 7.0s |
| Horizon | 3.57s | 12.32s | 8.8s |
| Motion | 1.88s | 15.78s | 13.9s |
再看一遍 Motion 那一行:首次绘制 1.88 秒,比我们测试的几乎所有主题都快,然后是 13.9 秒的主视觉等待。瓶颈不是主题的代码;而是媒体策略。Horizon 从另一个角度讲述了同样的故事:它的总阻塞时间是 29ms,是本次审计中 JavaScript 表现最好的之一,却伴随着 12.32 秒的 LCP。工程出色,展示很重。
而反例证明这个上限是真实存在的:在 Ultra 的演示站上,最大元素与首次绘制同时渲染完成,两者都是 1.91 秒,是 15 个演示站中唯一低于 Google 2.5 秒阈值的。这就是数据中一个有节制的首屏应有的样子。
1. 给你的主视觉称重。 用 PageSpeed Insights 打开你的首页,展开 LCP 诊断项,看清 LCP 元素到底是什么。如果它是一张 2 到 4MB 的图片或一段视频,那么在改变这一点之前,这份清单上的其他事都无关紧要。按实际渲染尺寸导出主视觉,通过 Shopify 的 image_url 宽度参数提供 WebP 或 AVIF,并把文件控制在 200KB 左右。如果主视觉是自动播放的视频,给它一个轻量的封面帧,让视频在首次绘制之后再加载,或者把它移到首屏以下。
2. 停止对 LCP 图片使用懒加载。 一个常见的 Shopify 配置错误:主题或某个应用对所有元素都应用了 loading="lazy",包括第一张主视觉图片,而这恰恰延迟了那个决定你分数的下载。LCP 图片应当以高获取优先级立即加载;首屏以下的内容才应保持懒加载。
3. 审查应用组合。 每个已安装的应用都可能注入在你的主视觉开始下载之前运行的脚本。卸载那些你并没有真正使用的应用,然后检查主题代码中应用遗留的孤立脚本标签。Shopify 自己的性能文档就把应用的体积列为影响主题速度的首要因素。
4. 精简首屏。 带五张 2MB 幻灯片的轮播、带动画的公告栏、立即启动的聊天挂件:它们每一个都在与 LCP 元素争抢资源。首屏只需要一条信息和一张图片。
5. 然后,也只有到那时,才考虑主题。 主题的选择决定了你的上限。在同一家店铺、完全相同的条件下,我们测出最快和最慢的演示站之间相差 8 倍,而差异主要在于节制:主题的默认首屏承载了多少东西。如果你已经在挑选替代方案,我们对 15 个实测演示站的完整排名是个起点,而排名第一的那家供应商 UTD 在这里列出了它的所有主题。但如果你的主视觉还有 3MB,换主题只是把同一个问题搬进了更漂亮的排版里。
前后都要测量,而且每次用同样的方法。Chrome DevTools 中的 Lighthouse 或 PageSpeed Insights、移动端配置、跑三次、取中位数,因为单次运行会有波动。盯住两个数字:LCP 本身,以及上面图表中的 FCP 到 LCP 的差距。如果你的修复有效,这个差距会先收缩,而这就是主视觉终于与页面一起到达、而不是在页面之后到达的信号。Search Console 的 Core Web Vitals 报告中的真实用户数据会在几周内跟上,因为 Google 是基于现场数据而不是实验室运行来评估 LCP 的。
几乎总是因为首屏中最大的元素是一张很重的主视觉图片或自动播放的视频,而它开始下载的时间太晚。我们的审计数据清楚地显示了这一规律:首次绘制很快的演示站,在主视觉媒体很重时,LCP 依然达到 8 到 14 秒。注入阻塞渲染脚本的应用会把这次下载的开始时间推得更晚。
Google 的阈值是:低于 2.5 秒为好,超过 4 秒为差,针对移动端真实用户测量。作为参考,我们在模拟移动端限速条件下审计的 15 个官方主题演示站中,只有 1 个低于 2.5 秒。
有可能,而且这是你只做一次的速度决策。我们测出最快的主题演示站(1.91s)与最慢的(15.78s)之间,移动端 LCP 中位数相差 8 倍。但先修好你的主视觉媒体和应用组合:一个快速主题配上 4MB 的主视觉,照样会不合格。
会。每个向你的主题注入脚本的应用,都会在首次绘制之前与 LCP 图片争夺带宽和主线程时间。检查你已安装的应用,删除不用的,并确认卸载后主题代码中是否还残留脚本标签。