Shopify 速度优化：修复真正的性能瓶颈
- 原文链接：www.debugbear.com/blog/shopif…
- 原文作者：Saurabh Shukla
Saurabh Shukla（Shopify 开发者）
发布时间：2026 年 4 月 20 日；更新于 2026 年 4 月 21 日；预计阅读时长 22 分钟。
大多数 Shopify 速度优化建议都聚焦在提升 Lighthouse 分数和 Core Web Vitals。这些指标固然重要，但即使分数看起来还不错，它们仍然无法解释为什么很多店铺依旧感觉缓慢、卡顿或不稳定。
真正的问题不在指标本身，而在底层性能瓶颈：过大的首屏 Hero 区域、失控的应用脚本、低效的资源加载，以及糟糕的执行策略。
在这篇指南里，我们会跳出表层技巧，聚焦那些真正拖慢 Shopify 店铺的结构性问题，以及如何正确修复它们。
首屏优化：控制第一印象
首屏内容对 Shopify 店铺“体感速度”的影响最大。用户加载页面时首先看到的就是它，它会在瞬间塑造用户对速度的感知。
即使页面其余部分加载很快，一个沉重或未优化好的 Hero 区域也会让整个店铺显得很慢。
Hero 区域通常是你最大的性能成本
Hero 区域是网页顶部的大块区域，通常位于页头或菜单下方。它是用户加载页面后首先看到的部分，通常包含主图、标题和行动按钮（CTA）。
优化 Hero 区域的第一步，是在不牺牲视觉质量的前提下尽可能减小 Hero 图片大小。很多缓慢的 Shopify 店铺会使用 300KB 到 400KB 的 Hero 图，甚至超过 900KB。这会显著延迟初始渲染，并影响 Largest Contentful Paint (LCP)（即屏幕中主要可见内容加载完成的速度）。
为了获得更好的性能，建议在保持清晰与锐度的同时，把 Hero 图片控制在 180KB 以下。
你可以使用 Chrome DevTools 或 DebugBear 的免费网站速度测试来检查 Hero 图片大小。
轮播、背景视频，以及它们为何会伤害性能
许多现代 Shopify 品牌会把视频作为 Hero 横幅，以增强视觉冲击。这样确实提升了叙事和互动感，但也带来了性能挑战。视频文件明显比静态图片更重，而且在首屏使用时，它往往会成为 LCP 元素，直接影响加载时间。
如果实现不当，Hero 视频会拖慢初始渲染。不过，只要采用正确的加载策略，就能在保留视频视觉效果的同时，尽量降低它对 LCP 的影响。
在加载视频前先使用占位图
无论你如何优化，视频文件的加载时间始终会比静态图片长。与其在视频下载期间让 Hero 区域出现空白，不如先使用轻量级占位图（poster image）作为首个可见元素。
页面加载时立即显示占位图，然后在主体内容渲染后再加载视频。视频准备好后，再无缝替换图片。
这种做法可以确保浏览器在初始渲染阶段不会优先处理重量级视频文件。结果是 Hero 区域可以更快加载，在保留视频视觉效果的同时改善 LCP。
在这个示例中，浏览器显示第一帧视频花了超过 9 秒。
加上 poster 图后，Largest Contentful Paint 降到了 2.7 秒。
避免重量级第三方轮播库
轮播（slider/carousel）是 Hero 区域里另一个常见且可能严重伤害性能的元素。它看起来很吸引人，但常常会在首屏引入多张大图、额外 JavaScript 和更复杂的布局。
你会发现，很多高性能品牌都会完全避免使用 Hero 轮播。单一的强视觉往往更有效、也更高效。但如果你必须使用轮播，就需要非常谨慎地实现，尽量减小对性能的影响。
很多热门轮播库（如 Swiper.js、Splide.js）体积看起来不大，大约 30KB 到 40KB。但当它们用于 Hero 区域（通常会成为 LCP 元素）时，性能可能反而变差。
文件大小只是问题的一部分，执行时间才是更大的隐患：如果 JavaScript 库没有正确使用 defer 或 async，浏览器就必须先下载、解析并执行它，再继续解析 HTML。
结果是，Hero 图片可能要等轮播脚本完全加载并初始化后才会渲染，这会负面影响 LCP。某些情况下，脚本运行后还会导致布局位移，造成视觉不稳定。
与其使用重量级第三方库，不如做一个轻量的 CSS 或 JavaScript 自定义轮播。Hero 轮播通常在布局和功能上都很简单，所以你可以实现一个非常轻量的方案，避免引入不必要复杂度。
自定义轮播通常不会导致 LCP 问题，并且能在初始加载期间保持布局稳定。
多图轮播时优先首张
当你在 Hero 区域使用轮播时，通常会有多张图片。由于这些是横幅图，每张都偏大，这意味着浏览器在初始阶段要下载全部图片，会恶化 LCP。
这也是很多大品牌不在 Hero 区域使用轮播的原因之一。一次下载多张大图会增加初始页面重量，并对 LCP 产生负面影响。
在必须使用轮播横幅的情况下，我们仍可把性能影响降到最低。一个有效方法是使用 fetchpriority 属性：把第一张图设为 high，其余设为 low。这样浏览器会优先下载第一张图。
图片尺寸与压缩
使用 Shopify 的 image_url Liquid 过滤器
如果你的店铺使用的是 Shopify 免费或付费主题，通常问题不大。真正容易出问题的是存在定制开发（这很常见）但开发者没有正确使用 Shopify Liquid 图片处理代码的场景。在这种情况下，网站往往会错失可观的性能收益。
当你使用类似 {{ image | image_url: width: 2400 | image_tag: loading: "eager" }} 的 Liquid 代码时，Shopify 会生成多种不同宽度的图片变体，让浏览器根据用户屏幕尺寸自动选择最合适的版本。
如果用户使用 27 英寸显示器，浏览器会加载 1920px 图片（约 180KB）。但如果用户是 18 英寸屏幕，则会加载 1200px 图片，体积会更小（约 140KB 或更低），从而提升性能并减少不必要的数据传输。
虽然设备 DPR（Device Pixel Ratio）同样重要，但为简化说明，这里先只考虑屏幕宽度。
屏幕宽度 1024 像素
屏幕宽度 767 像素
在不牺牲质量的情况下压缩图片
很多 Shopify 网站会犯一个错误：没有对图片做压缩。在一个典型 Shopify 店铺中，合理压缩通常可将图片体积减少 40% 到 70%。
例如，未压缩的 Hero 横幅如果是 500KB，压缩后可能降到 250KB，甚至 150KB。这是非常显著的体积下降，尤其对于首屏内容。
由于 Hero 横幅经常会成为 LCP 元素，减小其体积能直接改善加载性能与用户体感速度。
但图片压缩并不是“魔法解法”，它有代价：会降低画质，带来细节模糊与色带现象。因此压缩必须谨慎使用，过度压缩会明显损害视觉清晰度。
对于时尚、奢侈品、美妆和珠宝等行业，图片锐度直接关系到用户对产品价值的感知。如果图片看起来灰暗或压缩过头，可能会降低转化率。
普通图片
压缩图片
通过简化颜色降低文件体积
减少图片中的颜色数量，是另一种在不依赖重压缩的前提下降低文件体积的方法。图片由像素数据构成，颜色变化越复杂，文件需要存储的信息就越多。
当图片颜色更少时（例如背景干净、变化少），文件体积会自然变小。这样你可以在不明显增加图片重量的情况下保持清晰度。
通过简化背景并降低不必要的颜色复杂度，你可以在保留视觉质量的同时获得更小文件体积。
彩色背景图片
渐变简化背景图片
JavaScript 与应用臃肿：隐形性能杀手
JavaScript 是现代网站最重要的组成部分之一，但它也可能成为网站变慢的主要原因之一。对于 Shopify 店铺尤为如此，因为 Shopify 应用会让这个问题更严重。
大多数 Shopify 应用都是用 JavaScript 构建的，每个应用都会向网站注入自己的脚本。如果这些脚本没有被谨慎使用和管理，就会显著拖慢店铺并影响整体性能。
JavaScript 库会带来隐性成本
JavaScript 库是开发者可复用的一组预写代码，用于给网站添加功能。它让开发者不必从零实现复杂功能。
例如，与其从零构建轮播，不如直接使用 Swiper.js 或 Splide.js 这类库。
JavaScript 库确实让开发更快更轻松，但每新增一个库，也意味着浏览器要额外下载、解析并执行更多代码。
这张 Chrome DevTools 请求瀑布图展示了多个阻塞渲染的 JavaScript 请求，同时在页面初始加载阶段产生了超过 700 毫秒的 CPU 处理时间。
避免 Shopify 应用臃肿
在 Shopify 生态中，很多功能并不直接内置在主题里。这有助于保持主题轻量和快速。这些额外功能通常通过 Shopify App Store 的应用提供。
例如，商品评价、组合销售（bundle）和订阅等功能，通常都是通过你在店铺里安装的 Shopify 应用来实现。
不过安装这些应用时一定要非常谨慎。每个应用都可能向网站添加额外脚本和资源，如果管理不当，很快就会让店铺变重、变臃肿。
始终优先选择评分和评论都强的应用
尽量优先选择高评分且评论量大的应用。这条建议看起来很朴素，但能帮你避免很多不必要的麻烦。
评论多且正向的应用通常提供更好的支持，并且开发者维护更积极。它们也更可能遵循更好的开发实践，并保持技术栈更新。
选择口碑好的应用，可以降低安装劣质软件的风险，避免店铺变慢或出现意外问题。
下面这个网站本身并不原生使用 jQuery，但某个质量不佳的第三方应用却不必要地把它加进来了。
卸载未使用或不必要的应用
Shopify 把安装应用这件事做得非常容易，几乎就像在手机上装 App 一样。因此很多店主会在同一类别里反复试多个应用。
测试不同应用并不是坏习惯。这样可以帮助你判断应用是否真的满足需求。问题在于，很多“试过不用”的应用会被遗留在店铺里。
很多店主会忘记卸载不再需要的应用，时间一长，这些闲置应用会让网站越来越臃肿、越来越慢。
避免安装过多应用
Shopify 店主最常见的错误之一就是安装太多应用。即使是非常小的功能，很多人也会依赖应用，而不是更简单的实现方式。
你安装的应用越多，网站额外注入的脚本就越多。这些脚本都必须由浏览器下载并执行，从而增加处理时间。
结果是，浏览器要花更多时间处理这些脚本，网站会变慢，性能表现也会受到负面影响。
很多功能其实可以直接在你的网站里实现，而不是安装应用。请一位优秀的 Shopify 开发者做一次性付费的定制功能，往往是更好的方案。
开发者为你的店铺定制功能时，只会实现你真正需要的核心能力。相对地，应用通常会带来大量你可能永远不会用到的额外功能和脚本。
由于定制代码是主题原生的一部分且更轻量，对网站性能的影响通常会非常小。
例如，很多店主会安装购物车应用，只是为了在购物车抽屉里显示“免运费进度条”。这类应用常见做法是直接替换整个原生购物车，变成自己的定制购物车系统，从而引入更多脚本并增加页面重量。
而优秀的开发者会保留原生购物车，仅在现有购物车抽屉中添加一个轻量的免运费进度条。这样在实现同等效果的同时，不会引入不必要代码，也不会拖慢网站。
这张截图展示了某个购物车抽屉应用使用了 540KB 的脚本。
对比之下，定制开发的原生购物车功能只需要约 6KB 代码。
按需条件加载 JavaScript
在旧版 Shopify 主题中，大多数 JavaScript 会被打包进一到两个大文件。这会让文件变得很重，迫使浏览器下载和处理大量不必要代码。
在新版主题中，特别是 Shopify Online Store 2.0 更新后，JavaScript 往往会按功能拆成多个更小文件。这种结构让“按条件加载 JavaScript”成为可能。
由于文件被拆成更小块，每个功能可以拥有独立脚本。例如搜索可以有自己的 JavaScript 文件，购物车、集合筛选、加入购物车等功能也一样。
这让开发者可以只在真正需要的地方加载脚本。比如加入购物车脚本只在商品页需要，就不必在站点其他页面加载。
通过只在需要处加载脚本，网站避免了不必要的下载与执行，从而减轻页面负担并改善整体性能。
{% if template == 'product' or template.name == 'product' or request.page_type == 'product' %}
{% comment %} 商品页脚本 {% endcomment %}
{% endif %}
延迟非关键 JavaScript
浏览器加载网页时，会自上而下读取 HTML 来构建页面结构。如果在这个过程中遇到 JavaScript 文件，它会暂停 HTML 解析，先下载并执行脚本。
这有点像按说明书组装家具：某一步需要特殊工具时，你必须先停下来去找工具，找到后才能继续。浏览器处理 JavaScript 时也是如此。
这会负面影响 LCP 和 Interaction to Next Paint (INP)。如果脚本在页面加载后修改布局，还可能导致 Cumulative Layout Shift (CLS)。
JavaScript 延迟加载通过 defer 属性解决了这个问题。使用 defer 后，浏览器可以在后台下载脚本的同时继续解析 HTML，脚本会在整个 HTML 文档解析完成后才执行。
这样页面内容可以更快渲染，同时仍能加载所需 JavaScript。
在 Shopify 主题中，很多脚本默认已经被延迟处理。但应用注入脚本或自定义代码常常没有延迟，因此妥善管理它们对性能非常关键。
有些脚本加上 defer 后可能无法正常工作。这种情况下，一个良好替代方案是把这些脚本放在闭合 </body> 标签之前。
因为 </body> 标记了 HTML 文档末尾，把脚本放在这里可以确保 HTML 内容已经渲染，再开始加载和执行脚本。
资源策略与主题架构
减少 CSS 并避免臃肿主题包
继图片和 JavaScript 之后，CSS 也是影响网站速度与性能的重要因素。CSS 默认是 render-blocking 资源。浏览器加载页面时会解析 HTML，一旦遇到 CSS 文件会暂停渲染，先下载并处理样式。如果 CSS 文件很大，这个过程会更久，从而延迟渲染并可能影响 LCP。
在 Shopify Online Store 2.0 更新前，很多主题会把大部分 CSS 放在一个大文件里（如 theme.css），下载和解析成本都很高。更新后，CSS 通常按页面或功能拆成小文件（例如商品页、集合页、搜索页），浏览器只需加载当前页面所需 CSS，减少不必要下载并加快加载。
在定制开发或集成应用时，开发者常常把所有 CSS 都塞进主样式文件（如 base.css）。由于该文件在所有页面加载且是渲染阻塞资源，过多代码会让它快速膨胀并变低效。
更好的方式是按使用位置组织 CSS。全局样式留在 base.css，页面专属样式放入对应文件。
例如，如果你的改动只影响商品页，就应把 CSS 写到 product.css，而不是 base.css。这样可确保每页只加载必要样式，帮助网站保持轻量并提升性能。
消除重复库
在 Shopify 网站做定制功能开发，或构建完全定制店铺时，开发者常会使用不同 JavaScript 库以加快开发并实现复杂功能。但有时同一个库会被误加两次甚至更多次。
例如，开发者可能添加了新版本库来替换旧版本，却忘了删除旧版本。这样会导致重复库同时加载，浪费资源并损害网站性能。常见例子包括 Alpine.js 或 jQuery 被重复加载。
有时问题不是“同一个库重复加载”，而是“同类库并存”。开发者可能没有检查网站已在使用什么库，就直接引入了新库。这在轮播库上尤其常见。
例如，网站已经在使用 Swiper.js，但新开发者又加了一个自己更熟悉的轮播库。结果是页面要同时加载并执行两个不同库，增加 JavaScript 执行时间并拖慢页面。
字体子集化以减小体积
字体子集化（font subsetting）是很多开发者和店主没有充分利用的优化手段。
字体子集化的意思是从字体文件中移除不必要字符，使字体文件更小。
例如，如果你的 Shopify 店铺只做英文业务，字体文件就不需要包含西里尔、阿拉伯或中文字符。这些额外字符在网站里根本不会用到，却会增大文件体积。
移除这些未使用字符后，字体文件会显著变轻。像 Font Squirrel 这样的工具可以生成仅包含网站所需字符的子集字体。
仅这一步就可能让字体文件体积减少 40% 到 50%，帮助浏览器更快下载字体并提升整体页面性能。
非子集字体
子集字体
以更聪明的方式组织代码以提升性能
在创建 section 时，很多开发者（甚至 AI 工具）会把 section 的 CSS 或 JavaScript 直接写在 section 文件里。开发阶段这样做似乎方便，但后续会带来问题。
如果同一个 section 在页面中被复用多次，该 section 内 CSS 会被重复渲染，JavaScript 也可能重复执行。这种重复没有必要，并且会负面影响性能。
因此浏览器必须处理重复 CSS 并反复执行相同 JavaScript，工作负担增加，页面效率下降。
不过，在确实需要把 CSS 或 JavaScript 放进 section、snippet 或 block 文件时，Shopify 提供了更好的做法：使用 Liquid 标签 {% javascript %} 和 {% stylesheet %}。
这些标签会把所有 section、block、snippet 中的代码按类型收集并合并成单一文件，避免样式或脚本重复渲染，同时让代码组织更整洁、更高效。
网络优先级与加载策略
预加载关键资源
Preloading 是一种让浏览器比默认时机更早下载重要资源的技术，确保关键资源在浏览器需要时已经可用。
在 Shopify 店铺中，字体通常在网络瀑布里被较晚发现，往往排在 HTML、CSS 和 JavaScript 之后。如果网站给标题、导航或按钮使用了自定义字体，文本在字体下载完成前可能无法正确显示，从而延迟 First Contentful Paint (FCP)。
使用 font-display: swap 可在自定义字体加载时先显示后备字体。但如果字体没有预加载，后续替换仍可能造成明显视觉跳动。预加载主字体能更早启动下载，帮助文本更早出现并改善 FCP。
使用 Fetch Priority
Fetch Priority 告诉浏览器某个资源有多重要，从而优先下载关键资源。
页面加载时，浏览器会抓取图片、字体、CSS、JavaScript 等大量资源，但它未必知道哪些资源对首屏最重要。fetchpriority 属性允许开发者标记“应更早下载的重要资源”和“可延后下载的次要资源”。
大多数 Shopify 首页顶部都有 Hero 横幅或大图，通常是用户首先看到的视觉元素。因此它经常成为页面的 LCP 元素。给这张图加 fetchpriority="high" 能帮助浏览器优先下载，从而改善 LCP 和整体性能。
在 Shopify 集合页中，首屏可见元素通常是网格里的商品卡片和商品图。由于这些图片出现在首屏，它们对初始页面展示很关键。
为提升加载性能，可将前 1 到 4 张商品图设置为 fetchpriority="high"，让浏览器优先下载；其余商品图设置为 fetchpriority="low"，避免争抢网络资源。
Shopify 商品页也是同理。桌面端商品图可能是 1 到 4 张网格，移动端通常是单图视图。由于首张可见商品图属于初始首屏，它应使用 fetchpriority="high"；其余商品图可用 fetchpriority="low"，避免与最关键图片竞争加载资源。
对首屏以下图片使用懒加载
Lazy loading 是一种把资源加载推迟到“真正需要时刻”的技术，而不是在初始加载时一次性加载全部资源。
但懒加载必须谨慎使用，不当使用会反过来伤害网站性能。
在 Shopify 页面中，首屏可见图片绝不应懒加载，因为它们通常是 LCP 元素的一部分。延迟这些图片会显著恶化 LCP，并让页面体感加载更慢。
使用 Intersection Observer 的高级懒加载
默认懒加载效果不错，但也有局限。浏览器通常会在图片距离视口约 500 到 800 像素时开始加载，而开发者无法控制这个行为。
通过 Intersection Observer API，开发者可以构建更高级的懒加载策略。通过调整 rootMargin，你可以控制图片在进入视口前多早开始加载。
这让加载行为可控性更强，并能改善图片密集型页面的体感性能。
监控你的 Shopify 店铺性能
优化 Shopify 店铺不是一次性任务。新应用、主题更新和自定义代码变更都可能在任何时刻引入性能回归。持续监控可以在影响真实用户之前发现这些问题。
DebugBear 提供 Core Web Vitals 的合成监控和真实用户监控，让你持续追踪店铺性能，并在发生回归时收到告警。
监控页面速度与 Core Web Vitals
DebugBear 监控包含：
- 深度页面速度报告
- 自动化优化建议
- 真实用户分析数据
每月接收页面速度优化技巧
如果你希望持续获取页面速度建议，可以订阅 DebugBear 的月度更新邮件，以便定期跟进新的优化实践。
较新文章可阅读：Technical SEO Checklist: The Complete Guide For 2026，了解完整技术 SEO 检查清单。
较旧文章可阅读：How to Use Lazy Loading Without Hurting Web Performance，查看懒加载不伤性能的实践方式。
术语表（本篇命中）
| 术语 | 译法 | 说明 |
|---|---|---|
| Core Web Vitals | 核心网页指标 | Google 定义的页面体验关键指标集合。 |
| Largest Contentful Paint (LCP) | 最大内容绘制 | 衡量首屏主要内容完成渲染所需时间。 |
| Interaction to Next Paint (INP) | 下一次绘制交互延迟 | 衡量交互到下一次视觉反馈的延迟。 |
| Cumulative Layout Shift (CLS) | 累积布局偏移 | 衡量页面意外布局位移的稳定性指标。 |
| First Contentful Paint (FCP) | 首次内容绘制 | 衡量页面首次显示任意内容所需时间。 |
| lazy loading | 懒加载 | 延迟加载非首屏资源的策略。 |
| fetchpriority | 资源抓取优先级属性 | 用于提示浏览器资源下载优先级。 |
| render-blocking | 渲染阻塞 | 会中断页面渲染流程直至处理完成的资源特性。 |
术语冲突清单（待确认）
本篇无新增冲突。
