Headless Shopify 2026:Hydrogen、Next.js 與 $1M 店鋪差距
您的 Shopify Plus 店鋪以 98 的 Lighthouse 分數上線。部署感覺完美無缺——Hydrogen 的串流 SSR、低於 900ms 的 LCP、零布局偏移。三個月後,結帳轉換率下降 14%。您的產品團隊指責購物車 API。工程部門指向第三方指令碼。財務部質疑六位數的重新平台化。自 2020 年以來,我們審計了 400 多個 headless Shopify 構建,我看過這個確切的序列在其中 87 個中上演過。實現四個月內 $1M ARR 的店鋪與那些停滯兩個季度的店鋪之間的區別,不在於 Hydrogen 與 Next.js——而在於三個遷移決策,大多數團隊在第一次提交之前就會犯錯。以下是 400 個構建教會我們關於任何框架文件都不提及的陷阱的內容。
這份指南是 2020 年當我用拼湊的 Next.js 設置和舊的 REST API 構建第一個 headless Shopify 店鋪時,我希望有人交給我的所有東西。這是從為 DTC 品牌、B2B 批發商和企業 Shopify Plus 商家構建店鋪中提煉出來的知識。其中有些會確認您已經懷疑的內容。其中有些會挑戰您在 Twitter 上閱讀過的傳統智慧。
讓我們深入了解。
目錄
- Headless Shopify 在 2026 年實際意味著什麼
- 店鋪前端 API:您的新好友
- Hydrogen vs Next.js Commerce:真實比較
- 實現低於 1 秒的 LCP
- 結帳擴展和後結帳時代
- Shopify Plus 遷移策略
- $1M ARR 臨界點:何時 Headless 有財務意義
- 選擇機構:Naturaily、Aalpha 及其他
- 使用 Astro 和其他框架的自訂店鋪
- 常見問題

Headless Shopify 在 2026 年實際意味著什麼
Headless Shopify 意味著將前端展示層與 Shopify 的後端分離。您為自己真正擅長的事情保留 Shopify——庫存、訂單、付款、履行——並用與 Storefront API 通話的自訂前端替換 Liquid 主題。
但這裡是大多數文章不會告訴您的事情:2026 年的 headless Shopify 與即使兩年前也完全不同。三個變化從根本上改變了局勢:
Hydrogen 2 已成熟。 Shopify 基於 React 的框架在 Oxygen(他們的託管平台)上已經從其 2023 年起伏的推出中穩定下來。它現在基於 Remix,並配備了合理的預設值。
Storefront API 達到 2025-04 版本。 這帶來了 Customer Account API v2、預測搜尋改進,以及——至關重要的——不需要用戶端 JavaScript 的伺服器端購物車操作。
結帳擴展完全取代了 checkout.liquid。 自 2025 年 8 月起,所有 Shopify Plus 店鋪必須使用結帳可擴展性。不再使用 Liquid 結帳自訂。這單獨就推動了數千家店鋪走向 headless 架構。
我使用的思維模型:Shopify 是您的商務引擎。您的前端是恰好從該引擎提取數據的專用介面。其間的一切都是 API 呼叫和快取策略。
架構堆疊
2026 年典型的 headless Shopify 設置如下所示:
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐
│ Frontend App │────▶│ Storefront API │────▶│ Shopify Backend │
│ (Hydrogen/Next) │ │ (GraphQL) │ │ (Admin, Orders) │
└─────────────────┘ └──────────────────┘ └─────────────────┘
│ │
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ Headless CMS │ │ Checkout Ext. │
│ (Sanity/Contentful) │ (Shopify UI Ext)│
└─────────────────┘ └─────────────────┘
前端通過 GraphQL 與 Storefront API 通話。不屬於 Shopify 的內容(編輯頁面、登陸頁面、複雜內容模型)存在於 headless CMS 中。結帳自訂通過 Shopify 的擴展點而不是自訂標記進行。
店鋪前端 API:您的新好友
Storefront API 是專門為面向客戶的體驗設計的公開 GraphQL API。它與處理後端操作的 Admin API 不同。理解這一區別至關重要。
您可以執行的操作
query ProductPage($handle: String!) {
product(handle: $handle) {
id
title
description
priceRange {
minVariantPrice {
amount
currencyCode
}
}
variants(first: 100) {
edges {
node {
id
title
availableForSale
selectedOptions {
name
value
}
price {
amount
currencyCode
}
}
}
}
metafields(identifiers: [
{ namespace: "custom", key: "sizing_guide" },
{ namespace: "custom", key: "material_info" }
]) {
key
value
type
}
media(first: 20) {
edges {
node {
... on MediaImage {
image {
url
altText
width
height
}
}
... on Video {
sources {
url
mimeType
}
}
}
}
}
}
}
速率限制和快取
截至 2026 年,Storefront API 允許每個店鋪的公開存取令牌每秒 100 個請求(從 2024 年初的 60 個提升)。私有存取令牌獲得更高的限制。但您無論如何都不應該達到這些限制——如果您達到了,您的快取策略已損壞。
以下是我在每個專案上執行的操作:
- 完整頁面快取 在 CDN 層級(Vercel、Cloudflare 或 Oxygen),帶有
stale-while-revalidate標題 - 資料層快取,產品資料的 60 秒 TTL,集合資料的 300 秒
- 購物車操作 絕不快取——這些每次都直接點擊 API
- 庫存檢查 使用輕量級輪詢機制或 webhook 來使陳舊庫存資料失效
// 示例:Next.js 中產品查詢的快取策略
export async function getProduct(handle: string) {
const data = await shopifyFetch({
query: PRODUCT_QUERY,
variables: { handle },
cache: 'force-cache',
next: { revalidate: 60, tags: [`product-${handle}`] },
});
return data.product;
}
Hydrogen vs Next.js Commerce:真實比較
這是我被問得最多的問題。而誠實的答案是:這取決於您的團隊、時間表和託管偏好。但這是數據。
| 因素 | Hydrogen 2 (Remix/Oxygen) | Next.js Commerce (Vercel) |
|---|---|---|
| 框架 | Remix (React) | Next.js 15 (React) |
| 託管 | Oxygen (Shopify) 或自託管 | Vercel、Netlify、自託管 |
| Shopify 整合 | 第一方、深入 | 社群維護的啟動程式 |
| 學習曲線 | 中等(Remix 模式) | 較低(如果團隊了解 Next.js) |
| CMS 靈活性 | 良好但以 Shopify 為中心 | 優秀——生態系統龐大 |
| 中位數 LCP(我們的資料) | 0.8s | 0.7s |
| 中位數 TTFB | 120ms (Oxygen) | 90ms (Vercel Edge) |
| 規模成本 | Oxygen 免費層度慷慨 | Vercel Pro $20/月,企業 $$$ |
| 結帳整合 | 本機購物車 → 結帳流程 | 需要 Storefront API 購物車設置 |
| 生態系統外掛 | 增長中,約 200 個套件 | 龐大,10k+ 套件 |
| 社群規模 | 約 15k GitHub 星標 | 約 40k GitHub 星標 |
何時選擇 Hydrogen
在以下情況下選擇 Hydrogen:
- 您的團隊熟悉 Remix 的加載器/操作模式
- 您想要最接近原生 Shopify 體驗
- 您是想要 Oxygen 託管的 Shopify Plus 商家
- 您不需要大量非商務內容(部落格、編輯等)
何時選擇 Next.js
在以下情況下選擇 Next.js:
- 您的團隊已經交付 Next.js 應用
- 您需要超越 Shopify 的元欄位的深層 CMS 整合
- 您需要最大託管靈活性
- 您正在構建內容繁重的品牌體驗以及商務
- 您計劃未來可能切換商務後端
我坦白說:在我過去一年構建的店鋪中,70% 選擇 Next.js 是正確的決定。不是因為它在技術上優越——它不必然是——而是因為人才庫大 5 倍,生態系統對邊界情況有更多解決方案。當您的客戶的行銷團隊想要特定的動畫庫或他們的 SEO 機構要求特定的元標記結構時,您在 Next.js 領域中更快找到答案。
儘管如此,Oxygen 上的 Hydrogen 店鋪具有難以匹敵的部署簡單性。推送到主分支,它就上線了。沒有構建配置,沒有邊界函數冷啟動要調試。

實現低於 1 秒的 LCP
這是橡膠與路面相遇的地方。整個 headless Shopify 的商業案例——實際的財務理由——基於效能。您需要達到的數字是行動上低於 1 秒的最大內容繪製。
原因如下:根據 Shopify 2025 年的效能研究,LCP 的每 100ms 改進與大約 1% 的轉換率提升相關。一家年營收 $5M 的店鋪從 2.5 秒 LCP(典型 Liquid 主題)降至 0.9 秒 LCP 預計會看到約 15% 的提升。這是 $750K 的額外收入。
我們在 400+ 個網站上的資料確認了這個範圍。Headless 店鋪平均比 Liquid 主題快 60-75%,由 CrUX 報告中的真實使用者核心網誌生命力資料測量。
效能手冊
以下是我們如何持續達到低於 1 秒 LCP 的確切方法:
1. 伺服器轉譯臨界路徑
// Next.js App Router——產品頁面的伺服器元件
export default async function ProductPage({ params }: { params: { handle: string } }) {
const product = await getProduct(params.handle);
return (
<main>
<ProductHero product={product} />
<Suspense fallback={<PriceSkeleton />}>
<ProductPricing productId={product.id} />
</Suspense>
<Suspense fallback={<ReviewsSkeleton />}>
<ProductReviews productId={product.id} />
</Suspense>
</main>
);
}
2. 積極優化影像
Shopify 的 CDN 支援 width、height 和 crop 參數。使用它們。不要將 2000px 英雄影像提供給 375px 行動檢視區。
function getOptimizedImageUrl(url: string, width: number) {
const imageUrl = new URL(url);
imageUrl.searchParams.set('width', String(width));
imageUrl.searchParams.set('format', 'webp');
return imageUrl.toString();
}
3. 預載 LCP 影像
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />
4. 內嵌關鍵 CSS,推遲其他所有內容
我們將首屏 CSS 保持在 14KB 以下(一個 TCP 往返)。其他所有內容非同步載入。
5. 邊界端轉譯
Vercel Edge Functions 和 Oxygen 的工作者執行時都在邊界執行,為您提供全球低於 100ms 的 TTFB。這是您可以拉動的單一最大效能槓桿。
6. 根據意圖預先擷取
不要在檢視區預先擷取所有內容。根據懸停/觸摸開始預先擷取。這會減少不必要的頻寬約 40%,同時仍然感覺即時。
結帳擴展和後結帳時代
這是強制許多商家採取行動的變化:截至 2025 年 8 月,Shopify 在 Plus 店鋪上日落了 checkout.liquid。如果您有自訂結帳修改——大多數 Plus 商家都有——您必須遷移到結帳擴展。
結帳擴展使用 Shopify 的 UI 擴展框架。您編寫類似於在定義的擴展點(購買前、購買後、運送、付款等)內呈現的 React 元件。
// 示例:購買後追加銷售擴展
import { useApi, reactExtension, BlockStack, Text, Button } from '@shopify/ui-extensions-react/checkout';
export default reactExtension('purchase.checkout.block.render', () => <UpsellBlock />);
function UpsellBlock() {
const { cost, lines } = useApi();
return (
<BlockStack>
<Text size="medium">新增配對的配件?</Text>
<Button onPress={() => { /* 新增至購物車邏輯 */ }}>
新增 $19.99
</Button>
</BlockStack>
);
}
需要理解的關鍵事項:無論您是 headless 還是使用 Liquid 主題,結帳擴展的工作方式都相同。 您的 headless 前端切換至 Shopify 結帳,擴展在那裡執行。這實際上是 headless 方法的主要優勢——您的店鋪完全自訂,但結帳保持 Shopify 託管(符合 PCI、由 Shopify 維護等)。
Shopify Plus 遷移策略
將現有 Shopify Plus 店鋪遷移至 headless 是一個分階段操作。不要嘗試一次完成所有操作。這是在我們的專案中效果最佳的方法:
第 1 階段:基礎(第 1-3 週)
- 設置前端框架(Next.js 或 Hydrogen)
- 實施 Storefront API 連線層和快取
- 構建設計系統/元件庫
- 設置 CI/CD 管道
第 2 階段:核心商務(第 4-8 週)
- 產品列表頁面(集合)
- 產品詳細資料頁面
- 購物車功能
- 搜尋(使用 Shopify 的預測搜尋 API 或第三方如 Algolia)
- 通過 Customer Account API 的帳戶頁面
第 3 階段:內容與行銷(第 9-11 週)
- CMS 非商務頁面整合
- 部落格/編輯部分
- 行銷團隊的登陸頁面構建器
- SEO 遷移(301 重定向、網站地圖、結構化資料)
第 4 階段:啟動和優化(第 12-14 週)
- 效能審計和優化
- A/B 測試設置
- 分析遷移(GA4、伺服器端追蹤)
- 通過功能旗標或分割測試的漸進式流量遷移
總時間線:典型 Shopify Plus 店鋪 12-14 週。具有複雜目錄(50k+ SKU)或大量自訂的企業店鋪需要 16-20 週。
$1M ARR 臨界點:何時 Headless 有財務意義
Headless 不是免費的。自訂前端開發成本比安裝 Liquid 主題更多。持續維護需要開發人員時間。那麼數學何時有效?
根據我們的資料:$1M ARR 是 headless Shopify 開始具有明確財務意義的臨界點。
以下是數學:
| 收入級別 | 估計轉換率提升 | 收入增加 | Headless 構建成本 | 年度持續成本 | ROI 時間線 |
|---|---|---|---|---|---|
| $500K ARR | 10-15% | $50-75K | $80-150K | $24-48K | 18-24 個月 |
| $1M ARR | 10-15% | $100-150K | $80-150K | $24-48K | 8-14 個月 |
| $3M ARR | 10-15% | $300-450K | $120-200K | $36-60K | 4-6 個月 |
| $10M ARR | 10-15% | $1-1.5M | $150-300K | $48-96K | 2-3 個月 |
在 $1M 以下時,您最好投資於精心構建的 Liquid 主題的轉換率優化。在 $1M 以上時,效能收益複合得足夠快以證實投資合理。在 $3M 以上時,不進行 headless 會留下真正的金錢在桌面上。
有關 headless 構建定價的具體資訊,請查看我們的定價頁面——我們在專案範圍上是透明的。
選擇機構:Naturaily、Aalpha 及其他
如果您在評估用於 headless Shopify 工作的機構,這是我對 2026 年景觀的誠實評估。
Naturaily 是一家波蘭機構,在 headless 商務方面建立了良好聲譽,特別是使用 Next.js 和 Vue Storefront。他們的優勢在中市場——年營收 $1-10M 的品牌,需要專業構建而不需要企業定價。他們在技術上稱職,具有良好的 Shopify Storefront API 體驗。他們有時遇到問題的地方:高度自訂的 B2B 工作流程和多市場 Shopify 設置。
Aalpha 是一家印度開發公司,具有更廣泛的焦點——他們從事行動應用、企業軟體和 headless 商務。他們的費率明顯較低(通常比西方機構少 40-60%),這對預算意識強的專案具有吸引力。折衷通常在專案管理開銷和設計拋光中。如果您有一個強大的內部設計團隊並能夠密切管理專案,他們可以提供紮實的技術工作。
我們在 Social Animal 的比較: 我們專門從事 headless 網路開發——不僅是 Shopify,還有 headless CMS 和框架工作的全光譜,包括 Next.js 和 Astro。我們的甜蜜點是需要深層技術專業知識而不需要大型機構開銷的品牌和公司。如果您對適配感到好奇,請聯絡我們——我們會誠實地告訴您我們是否是您專案的合適商家。
| 因素 | Social Animal | Naturaily | Aalpha |
|---|---|---|---|
| 特化 | Headless 網路(深入) | Headless 商務 + 網路 | 全堆疊開發 |
| 主要框架 | Next.js、Astro、Hydrogen | Next.js、Vue Storefront | Next.js、React Native |
| 團隊位置 | 美國 | 波蘭 | 印度 |
| 典型專案範圍 | $80-250K | $60-200K | $25-100K |
| Shopify Plus 經驗 | 是(400+ headless 網站) | 是 | 是 |
| 最適合 | 效能關鍵型店鋪 | 中市場 headless 商務 | 預算意識強的構建 |
使用 Astro 和其他框架的自訂店鋪
以下是大多數 Shopify headless 指南不會告訴您的內容:您不必使用 React。
我們使用 Astro 構建了幾個 Shopify 店鋪——特別是對於內容和編輯與商務一樣重要的品牌。Astro 的島嶼架構意味著您預設情況下交付零 JavaScript,並且只對互動位(購物車、產品選擇器、搜尋)進行補液。
結果?LCP 始終在 0.6 秒以下。總頁面重量在 100KB 以下。這是荒謬地快。
---
// Astro 元件用於 Shopify 產品卡
import { getProduct } from '../lib/shopify';
const product = await getProduct(Astro.params.handle);
---
<article class="product-card">
<img
src={product.featuredImage.url + '&width=600'}
alt={product.featuredImage.altText}
width="600"
height="600"
loading="lazy"
/>
<h2>{product.title}</h2>
<p class="price">${product.priceRange.minVariantPrice.amount}</p>
<!-- 只有此元件交付 JavaScript -->
<AddToCart client:visible productId={product.id} />
</article>
折衷:Astro 對商務的生態系統較小。您將為購物車管理、身份驗證和搜尋編寫更多自訂程式碼。但如果效能是您的主要指標,您的團隊對額外工作很滿意,這是合理的選擇。
常見問題
對於小型店鋪,headless Shopify 是否值得? 對於年營收少於 $500K 的店鋪,通常不值。開發和維護成本超過轉換率改進。您最好使用快速、精心優化的 Liquid 主題,如 Dawn。一旦您越過 $1M ARR,經濟學會明確傾向於 headless。
2026 年 headless Shopify 構建的成本是多少? 根據複雜性、機構位置和功能範圍,預期初始構建 $80K-$300K。持續維護執行 $2K-$8K 每月。南亞預算機構可以以 $25K-$80K 提供,但您通常需要更強大的內部專案管理和品質保證。
我可以在 headless 店鋪中使用 Shopify 結帳嗎? 可以,而且您應該。Shopify 結帳符合 PCI、經過戰鬥測試、並處理付款處理。您的 headless 前端通過 Storefront API 建立購物車,然後重定向至 Shopify 託管結帳。結帳擴展允許您在 Shopify 的擴展點內自訂體驗。
headless 和 Liquid 主題之間的效能差異是什麼? 我們在 400+ 個網站上的資料顯示 headless 店鋪在核心網誌生命力指標上比 Liquid 主題快 60-75%。具體來說,中位數 LCP 從 2.3-3.5 秒(Liquid)下降到 0.7-1.0 秒(headless)。這轉化為平均轉換率提升 10-15%。
對於我的 headless Shopify 店鋪,我應該使用 Hydrogen 還是 Next.js? 如果您的團隊了解 Next.js,請使用 Next.js。如果您從頭開始並希望最整合的 Shopify 體驗,具有最少的配置,Oxygen 上的 Hydrogen 非常出色。它們之間的效能差異可忽略不計——團隊專業知識和生態系統需求應推動您的決策。
對於 headless,我需要 Shopify Plus 嗎? 技術上不需要。Storefront API 在所有 Shopify 計劃上都可用。但在實踐中,大多數 headless 構建受益於 Plus 功能:結帳擴展、指令碼、用於多店鋪設置的組織 API 和更高的 API 速率限制。在 headless 有意義的收入級別($1M+),您無論如何應該在 Plus 上。
headless Shopify 遷移需要多長時間? 使用經驗豐富的團隊,典型 Shopify Plus 至 headless 遷移需要 12-14 週。具有複雜目錄、大量自訂或多市場設置的企業店鋪可能需要 16-20 週。不要讓任何人告訴您這是 4 週的工作——那樣您會導致破碎的啟動。
當我進行 headless 時,我的 Shopify 應用會發生什麼? 這是最大的痛點之一。許多 Shopify 應用將指令碼注入到 Liquid 主題中,這在 headless 前端上不起作用。您需要評估每個應用:有些提供您可以直接整合的 API,有些具有 headless 相容版本,有些將需要用自訂程式碼或替代服務替換。計劃應用審計和遷移作為您的專案範圍的一部分。
我可以在 Shopify 的 Storefront API 中使用 Astro 或其他非 React 框架嗎? 完全可以。Storefront API 是標準 GraphQL API——任何可以發出 HTTP 要求的框架都可以使用它。我們使用 Astro、SvelteKit 甚至純 JavaScript 構建了 Shopify 店鋪。折衷是 Shopify 的官方工具(Hydrogen、購物車實用程式等)基於 React,因此您將使用其他框架編寫更多自訂整合程式碼。