2024 年 3 月，一个 DTC 护肤品牌找到我们，带着一个令人痛苦的常见问题：他们的 Shopify 主题速度很慢，广告支出在大幅流失，他们的 Core Web Vitals 指标深陷红区，Google 实际上在搜索中降低了他们的排名。八个月后，他们的广告支出回报率（ROAS）增长了 249%，LCP 从 8.2 秒下降到 1.4 秒，每项 Core Web Vitals 指标都完全变绿。这是我们如何做到这一点的完整故事——架构决策、权衡、错误以及实际数字。

目录

DTC Brand Migrated Shopify to Headless Next.js: 249% ROAS Increase

起点：陷入困境的 Shopify 店铺

我们叫他们 GlowCo（保密协议，你懂的）。他们是一个 DTC 护肤品牌，通过 Shopify Plus 店铺每年的销售额约为 320 万美元。他们有 47 个SKU，通过 Recharge 订阅模式，他们每月在 Meta 和 Google 广告上花费大约 85,000 美元。

问题不在于他们的产品或营销团队。问题在于他们的网站。

以下是他们联系我们时的指标情况：

指标 数值（2024 年 3 月） 状态
最大内容绘制 (LCP) 8.2 秒 🔴 不佳
首次输入延迟 (FID) 340ms 🔴 不佳
累积布局偏移 (CLS) 0.42 🔴 不佳
下一次绘制的互动 (INP) 510ms 🔴 不佳
移动 PageSpeed 分数 18/100 🔴
桌面 PageSpeed 分数 42/100 🟡
跳出率（移动） 71% —
转化率 1.2% —
Meta 广告 ROAS 1.8x —
Google 广告 ROAS 2.1x —

移动设备上的 PageSpeed 分数为 18。我见过不少糟糕的 Shopify 店铺，但这家店铺使用的主题有 2.4MB 的未优化 JavaScript、14 个渲染阻止第三方脚本（Klaviyo、Yotpo、一个忠诚度应用、两个不同的弹窗工具和几个分析脚本），以及 3MB 的 PNG 英雄图像，且没有任何响应式调整大小。

他们的 Shopify 主题是一个流行高级主题的高度定制版本，在三年内由至少四个不同的自由职业者修改过。Liquid 模板代码是一个嵌套混乱的条件逻辑，没有人完全理解。

但真正引起我注意的是：他们的营销团队告诉我们，他们的 Meta 广告质量得分已经下降了好几个月。Meta 的算法会惩罚加载缓慢的登陆页面。Google Shopping 情况相同——他们的广告获得的展示次数更少，但 CPC 更高，因为登陆页面体验分数在下降。

他们不仅失去了自然流量。他们因为网站速度慢而为每次点击支付更多费用。

为什么选择 Headless 以及为什么选择现在

GlowCo 已经探索过显而易见的选择。他们尝试过优化现有的 Shopify 主题——删除了一些应用、压缩了图像、切换到了稍微更轻量的主题。有帮助，但帮助不大。LCP 从 8.2 秒下降到大约 6.8 秒。仍然处于深红区。

根本问题是我们反复看到的 Shopify 单体架构的一个问题：你无法控制渲染管道。Shopify 的服务器呈现 Liquid 模板，注入他们自己的 JavaScript（仅 Shopify 核心 JS 就约 200KB），而且你受到主题和应用所做任何事情的摆布。

转向 headless 意味着将前端与 Shopify 的渲染层完全解耦。Shopify 仍然处理商务后端——产品、库存、结账、支付——但我们从零开始构建整个面向客户的体验。

选择现在这个时机有三个原因：

  1. Shopify 的 Storefront API 已经大幅成熟。 到 2024 年初，Storefront API 涵盖了构建完整店铺体验所需的几乎所有内容，包括购物车管理、客户账户和元字段访问。

  2. Shopify 结账扩展性 现在在 Plus 上可用。这意味着我们不需要重建结账流程（说实话，这曾经是 headless 落后的地方）。

  3. 业务案例很清晰。 如果改进网站速度可以将他们的 CPC 降低甚至 15-20%，同时提高转化率，该项目将在 3-4 个月内收回成本。

选择技术栈：Next.js、Hydrogen 和 Storefront API

这是事情变得有趣的地方，因为我们在技术栈上有真正的辩论。

竞争者

Shopify 对 headless 的官方答案是 Hydrogen——他们基于 React 的框架，建立在 Remix 之上。它与 Shopify 的 API 紧密集成，部署在 Oxygen（Shopify 的托管平台）上。

但我们最终选择了 Next.js 14（App Router）使用 Shopify 的 Hydrogen React 库——不是完整的 Hydrogen/Remix 框架。

原因如下：

因素 Hydrogen（Remix/Oxygen） Next.js + Hydrogen React Astro + Storefront API
SSR/SSG 灵活性 良好（Remix 流式传输） 优秀（ISR、SSG、SSR、RSC） 优秀（岛屿、SSG）
React 生态系统 完整 完整 部分（岛屿）
托管选项 仅 Oxygen（或自托管） Vercel、Netlify、AWS、自托管 任何静态主机 + SSR
Shopify 集成深度 本地 通过 @shopify/hydrogen-react 手动 API 调用
团队熟悉度 低 高 中等
边缘渲染 Oxygen Workers Vercel Edge、Cloudflare Cloudflare、Netlify
社区/生态系统 增长中 庞大 快速增长

我们认真考虑过 Astro。对于内容丰富且交互性较少的网站，Astro 的部分水合模型将是理想的。但 GlowCo 的网站需要大量客户端交互——一个产品问卷调查、一个护肤常规生成器、快速添加购物车抽屉、实时订阅管理。Next.js 的 React 服务器组件为我们提供了服务器呈现性能与客户端丰富性的最佳平衡。

我们也选择在 Vercel 而不是 Oxygen 上部署。Vercel 的边缘网络和 ISR（增量静态再生）功能为我们提供了在该时期无法轻松在 Oxygen 上复制的细粒度缓存控制。

我们的最终技术栈：

  • Next.js 14（App Router 与 React 服务器组件）
  • @shopify/hydrogen-react 用于购物车、Storefront API 实用程序
  • Shopify Storefront API（GraphQL）用于产品数据
  • Shopify Plus 结账（本地，非自定义构建）
  • Sanity CMS 用于编辑内容、登陆页面和博客文章
  • Vercel 用于托管和边缘函数
  • Recharge 通过他们的 headless API 用于订阅
  • Klaviyo 通过轻量级自定义集成异步加载

如果你评估类似的设置，我们在 Social Animal 的团队对这个确切的架构有深入的经验——我们已经记录了我们对 headless CMS 开发 和 Next.js 开发 的方法，如果你想了解更大的图景。

DTC Brand Migrated Shopify to Headless Next.js: 249% ROAS Increase - architecture

迁移架构

数据层

我们将 Shopify 作为所有商务数据的真实来源。产品、变体、库存、定价、客户、订单——一切都保留在 Shopify 中。这是不可协商的。Shopify 的商务引擎经过实战检验，他们的结账转化率很难被超越。

对于内容，我们设置了 Sanity 作为 headless CMS。产品页面从 Shopify 拉取结构化数据（定价、变体、库存）和来自 Sanity 的编辑内容（成分故事、使用指南、交叉销售叙述）。这种分离至关重要——这意味着营销团队可以更新页面内容而不触及产品数据，运营团队可以管理库存而不破坏登陆页面。

// 简化的产品页面数据获取（Next.js App Router）
async function getProductPageData(handle: string) {
  const [shopifyProduct, sanityContent] = await Promise.all([
    getShopifyProduct(handle),   // Storefront API GraphQL
    getSanityProductContent(handle) // Sanity GROQ 查询
  ]);

  return {
    product: shopifyProduct,
    editorial: sanityContent,
    // 合并元字段以获取结构化数据
    structuredData: buildProductSchema(shopifyProduct, sanityContent),
  };
}

渲染策略

并非每个页面都需要相同的渲染方法。我们对此很有针对性：

  • 产品页面： ISR，60 秒重新验证。产品不会每秒变化，但我们需要一分钟内的库存准确性。
  • 集合页面： ISR，5 分钟重新验证。这些变化更少。
  • 首页和登陆页面： ISR，具有由 Sanity 网络钩子触发的按需重新验证。当营销团队发布时，网络钩子会触发我们的重新验证端点。
  • 购物车/账户页面： 完整客户端，带有服务器呈现的外壳。这些本质上是动态的。
  • 博客/编辑： 在构建时进行静态生成，具有按需重新验证。

购物车实现

这是 @shopify/hydrogen-react 发挥作用的地方。CartProvider 和相关的 hooks 处理所有购物车状态管理，包括乐观 UI 更新。购物车存储在 Shopify 的 Storefront API 中（而不是本地状态），这意味着它跨会话和设备持久化。

// 带乐观更新的购物车抽屉
'use client';
import { CartProvider, useCart } from '@shopify/hydrogen-react';

function CartDrawer() {
  const { lines, totalQuantity, cost, linesUpdate } = useCart();

  return (
    <Sheet>
      {lines.map((line) => (
        <CartLine
          key={line.id}
          line={line}
          onQuantityChange={(quantity) =>
            linesUpdate([{ id: line.id, quantity }])
          }
        />
      ))}
      <CartTotal cost={cost} />
      <CheckoutButton />
    </Sheet>
  );
}

结账

我们没有构建自定义结账。这很重要。Shopify 的本地结账（特别是在 Plus 上使用结账扩展性）有多年的 A/B 测试和优化内置其中。Shop Pay 本身可以为回访客户增加 50% 的结账转化率。我们使用结账 UI 扩展来自定义品牌一致性和追加销售小部件，但核心流程保持 Shopify 本地。

修复 Core Web Vitals：真正起作用的方法

这是大多数案例研究掩盖的部分。转向 headless 不会神奇地修复你的 Core Web Vitals。你绝对可以构建一个缓慢的 Next.js 网站。我见过这种情况发生。重要的是一旦你控制了渲染管道，你所做的具体优化。

LCP：从 8.2 秒到 1.4 秒

单一最大的 LCP 改进来自三件事：

  1. 消除渲染阻止资源。 在旧的 Shopify 主题中，14 个第三方脚本同步加载。在我们的 Next.js 构建中，关键 CSS 是内联的，JavaScript 是代码分割的，仅在需要时加载，第三方脚本在主内容绘制后使用 next/script 与 strategy="lazyOnload" 加载。

  2. 使用 next/image 进行图像优化。 我们以 WebP/AVIF 格式提供响应式图像，为每个视口正确调整大小。英雄图像从 3MB PNG 下降到约 80KB AVIF 文件。LCP 元素（通常是英雄图像）现在作为优先级预获取资源加载。

  3. 使用 stale-while-revalidate 的边缘缓存。 Vercel 上的 ISR 意味着重新验证窗口后的第一个访问者立即获得缓存页面，而服务器在后台再生。大多数访问者永远不会等待服务器呈现。

CLS：从 0.42 到 0.02

布局偏移是由没有尺寸的图像、字体加载晚（FOUT）和动态注入的应用小部件引起的。我们的修复：

  • 所有图像都有明确的 width 和 height 属性（或使用 aspect-ratio CSS）
  • 字体使用 font-display: swap 预加载和大小调整的备用字体
  • 折叠线上方没有动态注入的第三方小部件
  • 任何异步内容的骨架 UI 组件

INP：从 510ms 到 78ms

与下一次绘制的互动是最难修复的。旧主题在整个 DOM 上附加了事件处理程序，jQuery 瀑布流，以及阻止主线程的大量客户端 JavaScript。

React 服务器组件是这里的关键。通过在服务器上呈现大部分页面，仅对交互组件（购物车抽屉、产品选择器、问卷调查小部件）进行水合，我们大幅减少了客户端 JavaScript 的数量。产品页面的总客户端包从 2.4MB 下降到 187KB。

之后的数字

指标 之前（2024 年 3 月） 之后（2024 年 11 月） 状态
LCP 8.2 秒 1.4 秒 🟢 良好
FID 340ms 12ms 🟢 良好
CLS 0.42 0.02 🟢 良好
INP 510ms 78ms 🟢 良好
移动 PageSpeed 18 94 🟢
桌面 PageSpeed 42 99 🟢
总 JS（产品页面） 2.4MB 187KB —
TTFB（p75） 1.8 秒 0.12 秒 —

ROAS 故事：性能如何转化为利润

这是橡胶与路面相遇的地方。没有人为了好玩而迁移到 headless——业务案例必须存在。

新网站在 2024 年 7 月至 10 月期间分阶段推出。到 11 月，我们有干净的数据进行比较。结果老实说比我们预期的更好。

直接转化影响

移动跳出率从 71% 下降到 38%。这本身就非常巨大——这意味着 46% 更多的访客坚持观看产品。移动转化率从 1.2% 升至 2.8%。

桌面转化率从 2.4% 提高到 3.9%。

整体混合转化率：1.2% → 3.1%

广告平台影响

这是连我们都惊讶的部分。在所有 Core Web Vitals 通过绿色的六周内：

  • Google 广告 CPC 下降 22% —— Google 的登陆页面体验分数改进，直接降低了每次点击的成本
  • Meta 广告 CPM 下降 18% —— Meta 的算法开始更多地展示他们的广告（更好的登陆页面 = 更高的相关性分数 = 更低的成本）
  • Google Shopping 展示份额增加 34% —— 更好的页面体验意味着 Google 更愿意展示他们的产品列表

对 ROAS 的综合影响：

渠道 之前 ROAS 之后 ROAS 变化
Meta 广告 1.8x 5.2x +189%
Google 搜索广告 2.1x 7.4x +252%
Google Shopping 2.4x 8.8x +267%
混合 1.95x 6.8x +249%

249% 的混合 ROAS 增长来自两个复合因素：更低的每次点击成本和更高的转化率。当你的点击成本较低，且每次点击以更高的比率转化时，数学就会复合得非常漂亮。

自然流量

我不应该不提及 SEO 影响。在所有 Core Web Vitals 变绿后的 4 个月内：

  • 自然流量增加 67%
  • 目标关键字的平均排名提高了 4.2 个位置
  • 自然收入增加 89%

Google 已明确表示页面体验是排名信号。这是现实世界的证明。

时间表、预算和真实成本

我相信透明度对于这类项目的实际成本。以下是真实的详细分类：

时间表： 从启动到全面推出的 7 个月（从第 5 个月开始进行分阶段推出）

团队： 2 名高级前端开发人员、1 名 Shopify 后端专家、1 名设计师、1 名项目经理（兼职）

项目总成本： 约 145,000 美元

月度托管/基础设施： 约 350 美元/月（Vercel Pro + Sanity Growth 计划）

持续 Shopify Plus： 2,300 美元/月（未变——他们已经在 Plus 上）

回本期： 根据改进的 ROAS 和转化率带来的增加收入，该项目在 2.8 个月内收回成本。

这种投资对每个品牌都合适吗？否。如果你每年的销售额不足 100 万美元，数学可能还不适用。但对于每月花费 50,000 美元以上用于广告、Core Web Vitals 较差的 DTC 品牌，ROI 几乎总是存在的。我们很乐意谈论细节——联系我们 或 查看我们的 headless 商务项目定价模型。

经验教训以及我们会做得不同的地方

什么有效

  • 保持 Shopify 结账本地 100% 是正确的选择。没有结账转化回归。
  • ISR 与按需重新验证 为我们提供了两个世界最好的：静态性能与动态内容。
  • 分阶段推出（首先推出博客/编辑页面，然后是集合，然后是 PDP，然后是首页）让我们在迁移高流量页面之前在生产中验证性能。

我们会做得不同的地方

  • 更早开始 Recharge headless 迁移。 他们的 headless API 有一些我们没有预料到的怪癖，它占用了我们时间表的 3 周。如果你使用 Recharge，请预留额外时间。
  • 从第一天开始设置 A/B 测试基础设施。 我们在第 2 个月添加了它，丢失了一些早期比较数据。
  • 使用 Vercel 的 Edge Config 进行功能标志 而不是我们开始使用的环境变量方法。会使分阶段推出更清晰。

一个诚实的警告

headless 方法增加了运营复杂性。GlowCo 现在管理两个系统而不是一个。他们的营销团队不能只是安装一个 Shopify 应用并让它出现在店面上——任何新的第三方集成都需要开发工作。对于 GlowCo，在他们的规模和广告支出，性能收益远远超过这种摩擦。但这是一个真实的权衡，你在开始时需要理解。

FAQ

将 Shopify 店铺迁移到 headless Next.js 需要多长时间？

对于典型的 DTC 品牌，有 30-100 个 SKU，预期 4-8 个月，取决于复杂性。GlowCo 的项目花费了 7 个月，因为他们有自定义功能，如护肤问卷调查和 Recharge 订阅集成。功能较少、自定义功能较少的更简单的店铺可以在 4-5 个月内完成。

转向 headless 会破坏 Shopify 应用吗？

是的，大多数主题相关的 Shopify 应用在 headless 设置中不会工作。向店面注入 UI 的应用（评价小部件、忠诚度弹窗、追加销售工具）需要被 API 基础的替代品或自定义构建的组件替换。后端应用（库存管理、运输等）继续工作正常，因为它们不接触前端。

对于 headless Shopify，Hydrogen 还是 Next.js 更好？

这取决于你的团队和要求。Hydrogen（基于 Remix 构建）提供开箱即用的更紧密 Shopify 集成，是 Shopify 官方支持的路径。Next.js 提供更大的生态系统、更多的托管灵活性和 React 服务器组件。我们为 GlowCo 选择 Next.js 是因为团队现有的专业知识和 Vercel 的边缘缓存功能。两者都是优秀的选择。

2025 年 headless Shopify 迁移成本是多少？

现实的预算范围从 80,000 到 250,000 美元以上，取决于店铺复杂性、自定义功能和机构费率。GlowCo 的项目是 145,000 美元。小心报价低于 50,000 美元进行完整 headless 构建的机构——你可能会得到有限定制的模板。月度基础设施成本通常为 200-600 美元用于托管和 CMS。

Core Web Vitals 真的会影响 Google 广告成本吗？

是的。Google 广告使用"登陆页面体验"分数作为质量分数计算的一部分。更好的页面速度和 Core Web Vitals 分数会导致更高的质量分数，直接降低你的每次点击成本。GlowCo 在 Core Web Vitals 改进后看到了 22% 的 CPC 降低。Meta 对广告相关性评分使用类似的信号。

转向 headless 时可以保留 Shopify 结账吗？

绝对可以，我们强烈推荐。Shopify 的结账经过高度优化，包括 Shop Pay 之类的功能（对回访购物者可以将结账转化率提高 50% 以上）。通过 Shopify Plus，你可以使用结账扩展性来自定义外观并添加追加销售，同时保持核心结账流程完整。

headless Shopify 和 Shopify Hydrogen 之间的区别是什么？

Headless Shopify 是一个广泛概念——任何使用 Shopify Storefront API 的自定义前端。Hydrogen 是 Shopify 用于构建 headless 店面的特定框架，基于 Remix 并部署在 Shopify 的 Oxygen 托管上。你可以使用 Next.js、Astro、Nuxt 或任何框架进行 headless。Hydrogen 只是 headless Shopify 生态系统中的一个选项。

对于小型 Shopify 店铺，headless 值得吗？

通常不值得。如果你每年的收入不到 100 万美元，每月在广告上花费少于 20,000 美元，headless 迁移的成本可能不会产生有意义的 ROI。首先关注优化你现有的主题——删除未使用的应用、压缩图像、切换到性能为中心的主题，如 Dawn。当你的广告支出足够高，使得即使很小的效率提升也能转化为显著金额时，考虑 headless。