DTCブランドがShopifyからHeadless Next.jsに移行:ROAS249%増加
目次
- 開始地点:トラブルに見舞われたShopifyストア
- なぜヘッドレスか、なぜ今か
- スタックの選定:Next.js、Hydrogen、Storefront API
- マイグレーションアーキテクチャ
- Core Web Vitalsの修正:実際に成果を上げたもの
- RAOSの話:パフォーマンスがどのように利益になるか
- タイムライン、予算、および実際のコスト
- 学んだ教訓と異なるアプローチ
- FAQ

開始地点:トラブルに見舞われたShopifyストア
彼らをGlowCoと呼びましょう(NDA、ご存知ですね)。彼らはShopify Plusストアを通じて年間約320万ドルを売上げているDTCスキンケアブランドです。彼らは47のSKU、Rechargeを通じたサブスクリプションモデルを持ち、MetaとGoogle広告に月額約85,000ドル使っていました。
問題は彼らの製品やマーケティングチームではありませんでした。問題は彼らのウェブサイトでした。
彼らが私たちに連絡してきたときのメトリクスは次のようなものでした:
| メトリクス | 値(2024年3月) | ステータス |
|---|---|---|
| Largest Contentful Paint (LCP) | 8.2秒 | 🔴 低い |
| First Input Delay (FID) | 340ms | 🔴 低い |
| Cumulative Layout Shift (CLS) | 0.42 | 🔴 低い |
| Interaction to Next Paint (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、ロイヤルティアプリ、2つの異なるポップアップツール、いくつかの分析スクリプト)を実行していました。また、ヒーロー画像は3MBのPNGで、レスポンシブサイジングなしで配信されていました。
彼らのShopifyテーマは人気のあるプレミアムテーマの大幅にカスタマイズされたバージョンで、3年間に少なくとも4人の異なるフリーランサーによって修正されていました。Liquidテンプレートコードは誰も完全には理解していない条件付きロジックの入れ子の混乱でした。
しかし、本当に私の目を引いたのはこれです:彼らのマーケティングチームは、彼らのMeta広告の品質スコアが数ヶ月間低下していることを示していました。Metaのアルゴリズムはゆっくり読み込まれるランディングページにペナルティを与えます。Google Shoppingも同じ話です — 彼らの広告はランディングページの経験スコアが低下しているため、より少ないインプレッションでより高いCPCを受けていました。
彼らはオーガニックトラフィックを失っていただけではありませんでした。彼らは彼らのサイトが遅いために、すべてのクリックに対してより多く支払っていました。
なぜヘッドレスか、なぜ今か
GlowCoはすでに明らかなオプションを探索していました。彼らは既存のShopifyテーマを最適化しようとしました — いくつかのアプリを削除し、画像を圧縮し、わずかに軽いテーマに切り替えました。それはほぼ役に立ちました。LCPは8.2秒から約6.8秒に低下しました。それでも深刻な赤でした。
根本的な問題は、Shopifyのモノリシックアーキテクチャで繰り返し見られるものです:レンダリングパイプラインを制御できません。ShopifyのサーバーはLiquidテンプレートをレンダリングし、独自のJavaScript(Shopifyのコアジェーンだけで約200KB)を注入し、あなたはテーマとアプリが何をしているかの慈悲に頼っています。
ヘッドレスに移行することは、フロントエンドをShopifyのレンダリングレイヤーから完全に切り離すことを意味していました。Shopifyはまだコマースバックエンド — 製品、在庫、チェックアウト、支払い — を処理しますが、顧客向けの全体的な体験をゼロから構築します。
タイミングは3つの理由で意味がありました:
Shopifyのストアフロント APIは大幅に成熟していました。 2024年初頭までに、Storefront APIはカート管理、カスタマーアカウント、メタフィールドアクセスを含む、完全なストア体験に必要なほぼすべてをカバーしていました。
Shopifyチェックアウト拡張性は現在Plusで利用可能でした。これは、カスタムチェックアウトを構築する必要がないことを意味していました(正直なところ、かつてはヘッドレスが崩れた場所です)。
ビジネスケースは明確でした。 サイトスピードの改善が広告CPCを15~20%削減でき、同時にコンバージョン率を改善できれば、プロジェクトは3~4ヶ月以内に自身の費用を払い戻します。
スタックの選定:Next.js、Hydrogen、Storefront API
ここは興味深い場所です。スタックについて本当の議論がありました。
候補
Shopifyのヘッドレスのオフィシャルな答えは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は、サーバーレンダリングのパフォーマンスとクライアント側のリッチネスの最良のバランスを提供しました。
また、OxygenではなくVercelにデプロイすることを選びました。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ヘッドレスAPI経由のサブスクリプション用
- Klaviyo軽量のカスタム統合経由で非同期読み込み
同様のセットアップを評価している場合、Social Animalのチームはこの正確なアーキテクチャに関する深い経験を持っており、ヘッドレスCMS開発とNext.js開発へのアプローチを記録しており、より広い画像を探したい場合。

マイグレーションアーキテクチャ
データレイヤー
すべてのコマースデータのソースオブトゥルースとしてShopifyを保持していました。製品、バリアント、在庫、価格、顧客、注文 — すべてShopifyに留まります。これは非交渉でした。Shopifyのコマースエンジンは十分にテストされ、彼らのチェックアウトコンバージョン率は打つのが難しいです。
コンテンツについて、私たちはSanityをヘッドレス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),
};
}
レンダリング戦略
すべてのページが同じレンダリングアプローチを必要とするわけではありません。これについて意図的でした:
- 製品ページ: 60秒の再検証を伴うISR。製品は毎秒変わりませんが、1分以内の在庫の正確性が必要でした。
- コレクションページ: 5分の再検証を伴うISR。これらはさらに頻繁に変わります。
- ホームページとランディングページ: Sanityウェブフックによってトリガーされるオンデマンド再検証を伴うISR。マーケティングチームが公開されるとき、ウェブフックは再検証エンドポイントにヒットします。
- カート/アカウントページ: サーバーレンダリングシェルを持つ完全なクライアント側。これらは本質的に動的です。
- ブログ/編集: ビルド時の静的生成とオンデマンド再検証。
カート実装
これは@shopify/hydrogen-reactがそのお金を稼いだ場所です。CartProviderと関連フックはすべてのカート状態管理、楽観的な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のネイティブチェックアウト(特にCheckout拡張性を持つPlus)は、年月のA/Bテストと最適化が焼き込まれています。Shop Payだけで返品顧客のチェックアウトコンバージョンを50%増加させることができます。チェックアウトUI拡張を使ってブランディングの一貫性とアップセルウィジェットをカスタマイズしましたが、コアフローはShopifyネイティブのままです。
Core Web Vitalsの修正:実際に成果を上げたもの
ここはほとんどのケーススタディが明らかにしない部分です。ヘッドレスに移行してもCore Web Vitalsが魔法のように修正されません。完全にスローなNext.jsサイトを構築することができます。起こったのを見ました。重要なのは、レンダリングパイプラインを制御したら、あなたが行う特定の最適化です。
LCP:8.2秒から1.4秒へ
単一の最大LCP改善は3つのことから来ました:
レンダリングをブロックするリソースを排除する。 古いShopifyテーマでは、14個のサードパーティスクリプトが同期的に読み込まれました。Next.jsビルドでは、重要なCSSがインラインされ、JavaScriptはコード分割され、
next/scriptを使ってメインコンテンツが描画された後に読み込まれます(strategy="lazyOnload"付き)。next/imageによるイメージ最適化。 各ビューポート用に適切にサイズ設定されたWebP/AVIF形式でレスポンシブイメージを提供しました。ヒーロー画像は3MBのPNGから約80KB AVIFファイルに行きました。LCP要素(通常はヒーロー画像)は現在、優先度プリフェッチされたリソースとして読み込まれます。stale-while-revalidateを伴うエッジキャッシング。 VercelでのISRは、再検証ウィンドウの後の最初の訪問者がサーバーがバックグラウンドで再生成している間にキャッシュされたページを即座に取得することを意味します。ほとんどの訪問者はサーバーレンダリングを待たせることはありません。
CLS:0.42から0.02へ
レイアウトシフトは、寸法のない画像、フォントが遅く読み込まれた(FOUT)、および動的に注入されたアプリウィジェットによって引き起こされました。修正:
- すべての画像には明示的な
widthとheight属性があります(またはaspect-ratioCSSを使用) font-display: swapとサイズ調整されたフォールバックでプリロードされたフォント- フォールドの上に動的に注入されるサードパーティウィジェットなし
- 任意の非同期コンテンツのスケルトンUIコンポーネント
INP:510msから78msへ
インタラクションから次の描画までは、修正が最も難しかったです。古いテーマはDOM全体に添付されたイベントハンドラー、jQuery滝、およびメインスレッドをブロックしている大量のクライアント側のJavaScriptを持っていました。
React Server Componentsがここで鍵でした。ページのほとんどをサーバーでレンダリングし、インタラクティブなコンポーネント(カートドローワー、製品セレクター、クイズウィジェット)のみをハイドレーションすることで、クライアント側の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秒 | — |
RAOSの話:パフォーマンスがどのように利益になるか
ここはゴムが道路に当たる場所です。誰もぼんやりとした理由でヘッドレスに移行しません — ビジネスケースがそこにある必要があります。
新しいサイトは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 Shoppingインプレッションシェアが34%増加 — より良いページエクスペリエンスは、Googleがより多く彼らの製品リストを表示することをいとわず意味しました
RAOSへの結合効果:
| チャネル | 前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%のブレンドRAOS増加は2つの複合要因から来ました:クリックあたりの低いコストと高いコンバージョン率。クリックが少ないコストでそれぞれのクリックが高い率で変換されるとき、数学は美しく複合されます。
オーガニックトラフィック
すべてのCore Web Vitalsが緑色に変わってから4ヶ月以内のSEO影響を見落とすことは怠け者でしょう:
- オーガニックトラフィックが67%増加
- ターゲットキーワードの平均位置が4.2位置で改善
- オーガニック収益が89%増加
Googleはページエクスペリエンスがランキング信号であることを明確にしています。これは現実世界の証拠でした。
タイムライン、予算、および実際のコスト
私は、このような プロジェクトが実際に何かが費用するかについての透明性を信じます。実際の分析:
タイムライン: キックオフから完全なローンチまで7ヶ月(月5から段階的なロールアウト付き)
チーム: 2人のシニアフロントエンド開発者、1人のShopifyバックエンド専門家、1人のデザイナー、1人のプロジェクトマネージャー(パートタイム)
プロジェクト総コスト: 約145,000ドル
月ホスティング/インフラストラクチャ: 約350ドル/月(Vercel Pro + Sanity成長計画)
進行中のShopify Plus: 2,300ドル/月(変更なし — 彼らはすでにPlusにいました)
回収期間: 改善されたRAOSとコンバージョン率からの増加収益に基づいて、プロジェクトは2.8ヶ月以内にそれ自体を支払いました。
この種の投資がすべてのブランドに適切ですか?いいえ。年間100万ドル未満で行われている場合、数学はまだおそらく機能しません。しかし、月額50,000ドル以上の広告を使っているDTCブランドで、Core Web Vitalsが悪い場合、ROIはほぼ常にそこにあります。詳細について話し合っており、喜んでします — 私たちに連絡してくださいまたはヘッドレスコマースプロジェクトの価格設定モデルを確認してください。
学んだ教訓と異なるアプローチ
機能したもの
- Shopifyチェックアウトをネイティブに保つは100%正しい呼び出しでした。チェックアウトコンバージョン後退なし。
- ISRとオンデマンド再検証は両方の世界を与えてくれました:静的パフォーマンス付きの動的コンテンツ。
- 段階的なロールアウト(ブログ/編集ページをまず起動し、次にコレクション、その後PDP、その後ホームページ)は、高トラフィックページを移動する前に、本番環境でパフォーマンスを検証することを許可しました。
異なることをしたでしょう
- Rechargeヘッドレスマイグレーションを早く開始します。 彼らのヘッドレスAPIはいくつかの予期しない奇癖を持っていて、それは私たちのタイムラインの3週間を食べました。Rechargeを使用している場合、余分な時間を予算してください。
- 初日からA/Bテストインフラストラクチャを設定します。 月2でそれを追加し、いくつかの早い比較データを失いました。
- 環境変数アプローチの代わりにVercelの Edge Configを使用します 機能フラグ用。段階的なロールアウトをより清潔にしたでしょう。
1つの正直な注意
ヘッドレスアプローチは運用複雑さを追加します。GlowCoは1つではなく2つのシステムを管理しています。彼らのマーケティングチームはShopifyアプリをインストールして、ストアフロントに表示されるだけではできません — 新しいサードパーティの統合には開発作業が必要です。GlowCoにとって、彼らのスケールと広告支出では、パフォーマンスの向上がこの摩擦をはるかに上回ります。しかし、これは入り口で理解する必要のある本当のトレードオフです。
FAQ
Shopifyストアをヘッドレスをセットアップするのにどのくらい時間がかかりますか?
30~100 SKUを持つ典型的なDTCブランドの場合、複雑さに応じて4~8ヶ月を期待してください。GlowCoのプロジェクトは彼らのスキンケアクイズとRecharge購読統合などのカスタム機能のため7ヶ月かかりました。カスタム機能が少ないシンプルなストアは4~5ヶ月で行うことができます。
ヘッドレスへの移行でShopifyアプリが崩れますか?
はい、ほとんどのテーマに依存するShopifyアプリはヘッドレスセットアップでは機能しません。ストアフロント(レビューウィジェット、ロイヤルティポップアップ、アップセルツール)にUIを挿入するアプリは、APIベースの代替またはカスタムビルドコンポーネントで置き換える必要があります。バックエンドアプリ(在庫管理、出荷など)は引き続き機能します。フロントエンドに触れません。
ヘッドレスShopifyの場合はHydrogenまたはNext.jsはより良いですか?
チームと要件に依存します。Hydrogen(Remixの上に構築)はボックスから密なShopify統合を提供し、Shopifyの公式にサポートされたパスです。Next.jsはより大きなエコシステム、より多くのホスティング柔軟性、およびReact Server Componentsを提供します。チーム既存の専門知識とVercelのエッジキャッシング機能のため、GlowCoのためにNext.jsを選びました。どちらも優れた選択肢です。
2025年のヘッドレスShopifyマイグレーションの費用はいくらですか?
現実的な予算は、ストア複雑さ、カスタム機能、および代理店レートに応じて80,000ドルから250,000ドル以上の範囲です。GlowCoのプロジェクトは145,000ドルでした。完全なヘッドレスビルドに対して50,000ドル未満で見積もっている代理店を警戒してください — 限定的なカスタマイズテンプレートを取得します。月ホスティングと CMS コストは通常 200~600 ドルです。
Core Web Vitalsは本当にGoogle広告コストに影響しますか?
はい。Google広告は「ランディングページエクスペリエンス」スコアを使用して、品質スコアの計算の一部です。より良いページスピードとCore Web Vitalsスコアはより高い品質スコアにつながり、クリックあたりのコストが直接低下します。GlowCoはCore Web Vitalsが改善した後、CPC 22%削減を見ました。Metaはリリバント性スコアのための類似信号を使用します。
ヘッドレスに移行するときShopifyチェックアウトを保つことができますか?
完全に、そして強く推奨します。Shopifyのチェックアウトは非常に最適化されており、Shop Payのような機能を含めます(返品ショップの場合、チェックアウトコンバージョンを50%以上ブーストすることができます)。Shopify Plusを使用して、チェックアウト拡張性を使って、ブランディング一貫性をカスタマイズしてアップセルを追加しながら、コアチェックアウトフローをネイティブのままにしておくことができます。
ヘッドレス Shopify と Shopify Hydrogen の違いは何ですか?
ヘッドレスShopifyは幅広い概念です — Shopifyの Storefront API を使用するカスタムフロントエンド。Hydrogenはヘッドレスストアフロントを構築するためのShopifyの特定のフレームワークで、Remixの上に構築され、Shopifyの Oxygen ホスティングにデプロイされます。Next.js、Astro、Nuxt、またはフレームワークでヘッドレスに移行できます。Hydrogenはヘッドレスのプロショップエコシステム内の1つのオプションです。
小さなShopifyストアの場合はヘッドレスは価値がありますか?
通常いいえ。年間100万ドル未満で行われ、月額20,000ドル未満の広告費を使っている場合、ヘッドレスマイグレーションのコストは意味のあるROIを生成しない可能性があります。最初に既存のテーマを最適化することに焦点を当てます — 未使用のアプリを削除し、画像を圧縮し、Dawnのようなパフォーマンスに焦点を当てたテーマに切り替えます。広告費が高いときにヘッドレスを検討してください。これにより、小さな効率向上でも大きなドル額に変換されます。