2024年DTC品牌Shopify遷移到Headless Next.js：實現249% ROAS增長

2024年3月，一個DTC護膚品牌找到我們，問題普遍得令人痛心：他們的Shopify主題速度很慢，廣告支出在大量浪費，Core Web Vitals的表現非常糟糕，以至於Google基本上在搜索中對他們降級了。八個月後，他們的廣告支出回報率增加了249%，LCP從8.2秒降至1.4秒，每一個Core Web Vital指標都達到了綠色。這是我們是如何達到這一目標的完整故事——架構決策、權衡取捨、犯過的錯誤，以及真實的數字。

目錄

• 起點：一家陷入困境的Shopify商店
• 為什麼選擇Headless以及為什麼是現在
• 選擇技術棧：Next.js、Hydrogen和Storefront API
• 遷移架構
• 修復Core Web Vitals：真正有效的方法
• ROAS故事：性能如何成為利潤
• 時間表、預算和實際成本
• 經驗教訓和我們會做得不同的地方
• 常見問題

起點：一家陷入困境的Shopify商店

我們叫他們GlowCo（NDA，你懂的）。他們是一個DTC護膚品牌，通過Shopify Plus商店每年營收約320萬美元。他們有47個SKU，通過Recharge提供訂閱模式，每月在Meta和Google廣告上的支出約為85,000美元。

問題不在他們的產品或營銷團隊。問題在他們的網站。

以下是他們聯繫我們時的指標：

指標	數值（2024年3月）	狀態
最大內容繪製時間（LCP）	8.2秒	🔴 差
首次輸入延遲（FID）	340毫秒	🔴 差
累積佈局偏移（CLS）	0.42	🔴 差
互動到下一次繪製（INP）	510毫秒	🔴 差
移動端PageSpeed分數	18/100	🔴
桌面端PageSpeed分數	42/100	🟡
反彈率（移動端）	71%	—
轉換率	1.2%	—
Meta廣告ROAS	1.8倍	—
Google廣告ROAS	2.1倍	—

移動端PageSpeed分數為18。我見過很多Shopify性能不佳的商店，但這一個攜帶著一個主題，其中包含2.4MB未優化的JavaScript、14個阻止渲染的第三方腳本（Klaviyo、Yotpo、一個忠誠度應用、兩個不同的彈窗工具，以及一些分析腳本），以及3MB的PNG英雄圖像，沒有進行任何響應式調整就被提供服務。

他們的Shopify主題是一個流行的高級主題的高度定制版本，在三年內由至少四名不同的自由職業者修改過。Liquid模板代碼是條件邏輯的嵌套混亂，沒有人完全理解它。

但真正引起我注意的是：他們的營銷團隊向我們展示了他們的Meta廣告質量分數已經下降了幾個月。Meta的算法會對加載速度慢的著陸頁面進行懲罰。Google購物的情況是一樣的——他們的廣告獲得了更少的展示次數，而成本更高，因為著陸頁面體驗分數在下降。

他們不僅損失有機流量。他們實際上是在為每次點擊支付更多費用，因為他們的網站速度慢。

為什麼選擇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. 業務案例很清楚。 如果改進網站速度可以將他們的每次點擊成本降低15-20%，同時提高轉換率，該項目將在3-4個月內自我支付。

選擇技術棧：Next.js、Hydrogen和Storefront API

這正是事情變得有趣的地方，因為我們對技術棧進行了認真的討論。

候選項目

Shopify對Headless的官方答案是Hydrogen——他們基於Remix構建的基於React的框架。它與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）	優秀（Islands、SSG）
React生態系統	完整	完整	部分（Islands）
託管選項	僅Oxygen（或自主託管）	Vercel、Netlify、AWS、自主託管	任何靜態主機 + SSR
Shopify集成深度	原生	通過@shopify/hydrogen-react	手動API調用
團隊熟悉度	低	高	中
邊緣渲染	Oxygen Workers	Vercel Edge、Cloudflare	Cloudflare、Netlify
社區/生態系統	增長中	龐大	增長快速

我們認真考慮了Astro。對於內容豐富、互動性較少的網站，Astro的部分水合模型會很理想。但GlowCo的網站需要大量的客戶端互動——一個產品測驗、護膚程序構建器、快速添加購物車抽屜、實時訂閱管理。Next.js的React Server Components為我們提供了服務器渲染性能與客戶端豐富性之間的最佳平衡。

我們也選擇在Vercel上部署而不是Oxygen。Vercel的邊緣網絡和ISR（增量靜態再生）功能為我們提供了細粒度的緩存控制，我們無法在當時的Oxygen上輕易複製。

我們的最終技術棧：

• Next.js 14 （App Router帶React Server Components）
• @shopify/hydrogen-react 用於購物車、Storefront API實用程序
• Shopify Storefront API （GraphQL）用於產品數據
• Shopify Plus結帳 （原生，非自定義構建）
• Sanity CMS 用於編輯內容、著陸頁和博客文章
• Vercel 用於託管和邊緣函數
• Recharge 通過他們的Headless API用於訂閱
• Klaviyo 通過輕量級自定義集成非同步加載

如果你正在評估類似的設置，我們的團隊在Social Animal有關於這個確切架構的深入經驗——如果你想了解更廣泛的情況，我們已經記錄了我們對Headless CMS開發和Next.js開發的方法。

遷移架構

數據層

我們將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 webhook觸發的按需重新驗證。營銷團隊發布時，webhook會點擊我們的重新驗證端點。
• 購物車/帳戶頁面： 完整的客戶端，帶有服務器渲染的shell。這些本質上是動態的。
• 博客/編輯： 在構建時進行靜態生成，帶有按需重新驗證。

購物車實現

這是@shopify/hydrogen-react發揮作用的地方。CartProvider和相關的hook處理所有購物車狀態管理，包括樂觀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：從510毫秒到78毫秒

互動到下一次繪製是最難修復的。舊主題在整個DOM上附加了事件處理程序，jQuery瀑布流，以及阻止主線程的大量客戶端JavaScript。

React Server Components是這裡的關鍵。通過在服務器上渲染大多數頁面，只水合交互式組件（購物車抽屜、產品選擇器、測驗小部件），我們大幅減少了客戶端JavaScript的數量。產品頁面的總客戶端bundle從2.4MB降至187KB。

後續數字

指標	前（2024年3月）	後（2024年11月）	狀態
LCP	8.2秒	1.4秒	🟢 好
FID	340毫秒	12毫秒	🟢 好
CLS	0.42	0.02	🟢 好
INP	510毫秒	78毫秒	🟢 好
移動端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跨董事會全部通過綠色後的6週內：

• Google廣告CPC下降22% ——Google的著陸頁面體驗分數改進，直接降低了每次點擊的成本
• Meta廣告CPM下降18% ——Meta的算法開始更多地展示他們的廣告（更好的著陸頁面=更高的相關性分數=更低的成本）
• Google購物展示份額增加34% ——更好的頁面體驗意味著Google更願意展示他們的產品列表

ROAS的綜合影響：

頻道	之前ROAS	之後ROAS	變化
Meta廣告	1.8倍	5.2倍	+189%
Google搜索廣告	2.1倍	7.4倍	+252%
Google購物	2.4倍	8.8倍	+267%
混合	1.95倍	6.8倍	+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萬美元以下，數學可能還不成立。但對於DTC品牌，每月支出50,000美元以上的廣告，Core Web Vitals很差，投資回報率幾乎總是存在的。我們很樂意談論具體情況——聯繫我們或查看我們的定價模型以獲取Headless商務項目。

經驗教訓和我們會做得不同的地方

有效的地方

• 保持Shopify結帳原生 100%是正確的決定。沒有結帳轉換回歸。
• 帶有按需重新驗證的ISR 給了我們兩個世界中最好的：靜態性能與動態內容。
• 分階段推出 （首先推出博客/編輯頁面，然後是集合，然後是PDP，然後是首頁）讓我們在遷移高流量頁面之前驗證生產中的性能。

我們會做得不同的地方

• 更早開始Recharge Headless遷移。 他們的Headless API有一些我們沒有預料到的怪癖，它吃掉了我們時間表的3週。如果你使用Recharge，預算額外的時間。
• 從第一天開始設置A/B測試基礎設施。 我們在第2個月添加了它，並失去了一些早期比較數據。
• 使用Vercel的Edge Config進行功能標誌 而不是我們開始時的環境變量方法。會讓分階段推出更乾淨。

一個誠實的警告

Headless方法增加了操作複雜性。GlowCo現在管理兩個系統而不是一個。他們的營銷團隊不能只是安裝一個Shopify應用並讓它出現在店面——任何新的第三方集成都需要開發工作。對於GlowCo，在他們的規模和廣告支出中，性能收益遠遠超過這種摩擦。但這是你從一開始就需要理解的真實權衡。

常見問題

將Shopify商店遷移到Headless Next.js需要多長時間？ 對於一個典型的DTC品牌，有30-100個SKU，預計4-8個月，具體取決於複雜性。GlowCo的項目花了7個月，因為有自定義功能，如他們的護膚測驗和Recharge訂閱集成。具有較少自定義功能的更簡單商店可以在4-5個月內完成。

採用Headless會破壞Shopify應用嗎？ 是的，大多數依賴主題的Shopify應用在Headless設置中將不起作用。將UI注入到你的店面中的應用（評論小部件、忠誠度彈窗、升售工具）需要被替換為基於API的替代品或自定義構建的組件。後端應用（庫存管理、運輸等）繼續正常工作，因為它們不接觸前端。

Hydrogen還是Next.js對Headless Shopify更好？ 這取決於你的團隊和要求。Hydrogen（構建在Remix上）開箱即用提供了更緊密的Shopify集成，是Shopify的官方支持路徑。Next.js提供了更大的生態系統、更多的託管靈活性和React Server Components。我們為GlowCo選擇了Next.js，因為團隊的現有專業知識以及Vercel的邊緣緩存功能。兩者都是優秀的選擇。

2025年Headless Shopify遷移的成本是多少？ 現實預算範圍從80,000到250,000美元以上，具體取決於商店複雜性、自定義功能和機構費率。GlowCo的項目是145,000美元。對報價低於50,000美元的機構要謹慎——你可能會得到一個有限定制的模板。月度基礎設施成本通常為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遷移的成本可能不會產生有意義的投資回報率。首先關注優化你現有的主題——移除未使用的應用、壓縮圖像、切換到性能導向的主題，如Dawn。當你的廣告支出足夠高，甚至小的效率收益都能轉化為大量美元時，考慮採用Headless。