DTC スキンケアブランドの Shopify から Headless への移行: 249% ROAS 増加
あなたの Shopify 商品ページが読み込まれます。8.2 秒が経過します。ヒーロー画像がぎこちなく表示されます。訪問者の親指が戻るボタンに向かいます—そしてあなたの Meta ピクセルは、チェックアウトがレンダリングされる前に別のバウンスを記録します。2024 年 3 月、DTC スキンケアブランドはこの正確な悪循環で私たちの Slack に現れました:広告費は、Google が事実上検索から優先度を下げるほど遅いテーマに流出していました。8 ヶ月後、彼らの ROAS は 249% 上昇していました。LCP は 8.2s から 1.4s に低下しました。すべての Core Web Vitals が緑になりました。これは完全な内訳です—アーキテクチャの決定、私たちがほぼ間違えた妥協、そして予想以上に速く変わった 3 つのメトリクス。
目次
- 開始地点:問題のある Shopify ストア
- Headless を選ぶ理由とそのタイミング
- スタック選択:Next.js、Hydrogen、Storefront API
- 移行アーキテクチャ
- Core Web Vitals の修正:実際に結果をもたらしたもの
- ROAS ストーリー:パフォーマンスがいかに利益になったか
- タイムライン、予算、実際のコスト
- 学んだ教訓と異なるアプローチ
- FAQ

開始地点:問題のある Shopify ストア
GlowCo と呼びましょう(NDA ですから)。彼らは Shopify Plus ストアを通じて年間約 $3.2M を売り上げている DTC スキンケアブランドです。47 SKU、Recharge を通じたサブスクリプションモデル、Meta と Google 広告に月約 $85K を費やしていました。
問題は彼らの製品でもマーケティングチームでもありませんでした。問題は彼らのウェブサイトでした。
あなたが私たちに連絡してきた時点でのメトリクスは以下の通りです:
| メトリクス | 値(2024 年 3 月) | ステータス |
|---|---|---|
| Largest Contentful Paint (LCP) | 8.2s | 🔴 不良 |
| 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 を受け取っていました。
彼らはオーガニックトラフィックを失っていただけではありませんでした。彼らはサイトが遅いために、すべてのクリックでより多く支払っていました。
Headless を選ぶ理由とそのタイミング
GlowCo はすでに明らかなオプションを探っていました。既存の Shopify テーマを最適化しようとしました—いくつかのアプリを削除し、画像を圧縮し、わずかに軽いテーマに切り替えました。助けになりました、ほぼ。LCP は 8.2s から約 6.8s に低下しました。それでも深い赤です。
基本的な問題は私たちが繰り返し見かけるものです:Shopify のモノリシックアーキテクチャでは、レンダリングパイプラインを制御しません。Shopify のサーバーは Liquid テンプレートをレンダリングし、独自の JavaScript を注入し(Shopify のコア JS だけで約 200KB)、あなたはテーマとアプリが何をしているかの気まぐれです。
Headless に移行することは、フロントエンドを Shopify のレンダリング層から完全に分離することを意味しました。Shopify は引き続きコマースバックエンドを処理します—製品、インベントリ、チェックアウト、支払い—しかし、私たちは最初からまったく新しい顧客向けの経験を構築します。
タイミングは 3 つの理由で理にかなっていました:
Shopify の Storefront API は大幅に成熟していました。 2024 年初頭までに、Storefront API はカート管理、顧客アカウント、メタフィールドアクセスを含む、完全なストア体験に必要なほぼすべてをカバーしていました。
Shopify Checkout Extensibility は Plus で利用可能になりました。これは、チェックアウトを再構築する必要がないことを意味しました(正直に言うと、これは headless が以前は壊れていた場所です)。
ビジネスケースは明確でした。 サイト速度の改善が CPC を 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 サーバーコンポーネントは、サーバーでレンダリングされたパフォーマンスとクライアント側の豊かさの最高のバランスを提供しました。
私たちはまた、Oxygen ではなく Vercel にデプロイすることを選択しました。Vercel のエッジネットワークと ISR(増分静的再生成)機能は、Oxygen で容易に複製できない細粒度のキャッシュ制御を提供しました。
私たちの最終的なスタック:
- Next.js 14(App Router と React サーバーコンポーネント)
- @shopify/hydrogen-react カート、Storefront API ユーティリティ用
- Shopify Storefront API(GraphQL)製品データ用
- Shopify Plus Checkout(ネイティブ、カスタムビルドではない)
- Sanity CMS 編集コンテンツ、ランディングページ、ブログ投稿用
- Vercel ホスティングとエッジ機能用
- Recharge 彼らの headless API を通じたサブスクリプション用
- Klaviyo 軽量なカスタム統合を通じて非同期に読み込まれる
同様の設定を評価している場合、Social Animal の私たちのチームはこの正確なアーキテクチャに深い経験があります—headless CMS 開発と Next.js 開発に対する私たちのアプローチを文書化しています(より広い画像が必要な場合)。

移行アーキテクチャ
データレイヤー
私たちはすべてのコマースデータの情報源として Shopify を保持していました。製品、バリアント、インベントリ、価格設定、顧客、注文—すべて Shopify に残ります。これは譲歩できません。Shopify のコマースエンジンは実証済みで、彼らのチェックアウトコンバージョン率は beat するのが難しいです。
コンテンツについては、Sanity を headless CMS として設定しました。製品ページは Shopify から構造化データを引き出し(価格設定、バリアント、インベントリ)、Sanity から編集コンテンツ(成分ストーリー、使用ガイド、クロスセルナレーティブ)を引き出しました。この分離は重要です—マーケティングチームが製品データに触れることなくページコンテンツを更新でき、ops チームが着陸ページを壊すことなくインベントリを管理できることを意味します。
// 簡略化された製品ページデータ取得(Next.js App Router)
async function getProductPageData(handle: string) {
const [shopifyProduct, sanityContent] = await Promise.all([
getShopifyProduct(handle), // Storefront API GraphQL
getSanityProductContent(handle) // Sanity GROQ query
]);
return {
product: shopifyProduct,
editorial: sanityContent,
// マージメタフィールド構造化データ用
structuredData: buildProductSchema(shopifyProduct, sanityContent),
};
}
レンダリング戦略
すべてのページが同じレンダリングアプローチを必要とするわけではありません。私たちはこれについて意図的でした:
- 製品ページ: 60 秒の再検証を伴う ISR。製品は毎秒変わるわけではありませんが、1 分以内のインベントリ精度が必要でした。
- コレクションページ: 5 分の再検証を伴う ISR。これらはさらに頻繁に変わります。
- ホームページとランディングページ: Sanity webhook によってトリガーされたオンデマンド再検証を伴う ISR。マーケティングチームが公開すると、webhook は再検証エンドポイントを ヒット します。
- カート/アカウントページ: サーバーでレンダリングされたシェルを含む完全なクライアント側。これらは本質的に動的です。
- ブログ/編集: ビルド時の静的生成とオンデマンド再検証。
カート実装
これは @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 Extensibility を備えた Plus)には、何年もの A/B テストと最適化が組み込まれています。Shop Pay だけで、リピーターの場合、チェックアウトコンバージョンを 50% 増加させることができます。ブランディングの一貫性とアップセルウィジェット用の Checkout UI 拡張機能を使用してカスタマイズしましたが、コア フロー は Shopify ネイティブのままです。
Core Web Vitals の修正:実際に結果をもたらしたもの
ここが、ほとんどのケーススタディが見落とす部分です。Headless に移行しても、Core Web Vitals は魔法のように修正されません。絶対に遅い Next.js サイトを構築できます。実装されるのを見てきました。重要なのは、レンダリングパイプラインを制御できるようになれば、実装する特定の最適化です。
LCP:8.2s から 1.4s へ
単一の最大 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 サーバーコンポーネントがここが鍵でした。ページの大部分をサーバーでレンダリングし、インタラクティブなコンポーネント(カートドロワー、製品セレクター、クイズウィジェット)のみをハイドレートすることで、クライアント側の JavaScript の量を大幅に削減しました。製品ページの総クライアント束は 2.4MB から 187KB に低下しました。
その後の数字
| メトリクス | 前(2024 年 3 月) | 後(2024 年 11 月) | ステータス |
|---|---|---|---|
| LCP | 8.2s | 1.4s | 🟢 良好 |
| FID | 340ms | 12ms | 🟢 良好 |
| CLS | 0.42 | 0.02 | 🟢 良好 |
| INP | 510ms | 78ms | 🟢 良好 |
| モバイル PageSpeed | 18 | 94 | 🟢 |
| デスクトップ PageSpeed | 42 | 99 | 🟢 |
| 総 JS(製品ページ) | 2.4MB | 187KB | — |
| TTFB(p75) | 1.8s | 0.12s | — |
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 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 増加は、クリック単価が低く、各クリックがコンバージョンする割合が高い 2 つの複合要因から来ました。クリックのコストが安く、各クリックがより高い率でコンバージョンする場合、数学は素晴らしくなります。
オーガニックトラフィック
すべての Core Web Vitals が緑になってから 4 ヶ月以内に、SEO への影響を見落とすことはできません:
- オーガニックトラフィックは 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 ヶ月で元を取りました。
このような投資がすべてのブランドに適切ですか?いいえ。年間 $1M 未満で行っている場合、数学はおそらくまだ機能していません。ただし、月 $50K 以上の広告を費やしており、Core Web Vitals が悪い DTC ブランドの場合、ROI はほぼ常にあります。具体的に話し合うことに満足しています—私たちに連絡してくださいまたは headless コマースプロジェクトの価格設定モデルを確認してください。
学んだ教訓と異なるアプローチ
機能したこと
- Shopify チェックアウトをネイティブに保つこと は 100% 正しい呼び出しでした。チェックアウトコンバージョン低下なし。
- オンデマンド再検証を伴う ISR は、静的パフォーマンスと動的コンテンツの両方を最適にしました。
- 段階的ロールアウト(ブログ/編集ページから開始し、次にコレクション、次に PDP、次にホームページ)は、トラフィックの多いページを移行する前に本番環境でパフォーマンスを検証させました。
異なることを行った方法
- Recharge headless 移行をより早く開始します。 彼らの headless API にいくつかの癖があり、私たちのタイムラインの 3 週間を食べました。Recharge を使用している場合、余分な時間を予算化します。
- 初日から A/B テストインフラストラクチャを設定します。 月 2 でそれを追加し、初期の比較データを失いました。
- Recharge headless 移行をより早く開始します。 Vercel の Edge Config を環境変数アプローチの代わりに機能フラグ用に使用します。段階的ロールアウトをより上手にしました。
1 つの正直な注意
Headless アプローチは運用の複雑さを追加します。GlowCo は 1 つではなく 2 つのシステムを管理しています。彼らのマーケティングチームは、Shopify アプリをインストールして storefront に表示させることはできません—新しいサードパーティ統合には開発作業が必要です。GlowCo の規模と広告費では、パフォーマンスの向上がこの摩擦をはるかに上回っています。しかし、開始時に理解する必要がある実際のトレードオフです。
FAQ
Shopify ストアを headless Next.js に移行するのにどのくらい時間がかかりますか?
複雑さに応じて、30 ~ 100 SKU の典型的な DTC ブランドの場合は 4 ~ 8 ヶ月を期待します。GlowCo のプロジェクトは、カスタムスキンケアクイズと Recharge サブスクリプション統合により 7 ヶ月かかりました。シンプルなストア、カスタム機能が少なかるば、4-5 ヶ月で行うことができます。
Headless に移行すると Shopify アプリが壊れますか?
はい、ほとんどのテーマ依存 Shopify アプリは headless セットアップでは機能しません。ストアフロントに UI を注入するアプリ(レビューウィジェット、ロイヤルティポップアップ、アップセルツール)は、API ベースの代替または カスタムビルド コンポーネントのいずれかで置き換える必要があります。バックエンドアプリ(インベントリ管理、配送など)は、フロントエンドに触れないため、引き続き機能します。
Hydrogen または Next.js は headless Shopify に適していますか?
チームとリクイルメント に依存します。Hydrogen(Remix に基づく)は、そのまま Shopify 統合を提供し、Shopify の公式にサポートされているパスです。Next.js は、より大きなエコシステム、より多くのホスティングの柔軟性、React サーバーコンポーネントを提供します。私たちは、チームの既存の専門知識と Vercel のエッジキャッシング機能のため、GlowCo に対して Next.js を選択しました。どちらも優れた選択肢です。
2026 年の headless Shopify 移行のコストはどのくらいですか?
現実的な予算は、ストア複雑さ、カスタム機能、エージェンシー料金に応じて $80,000 ~ $250,000+ の範囲です。GlowCo のプロジェクトは $145,000 でした。$50K 未満で完全な headless ビルドを見積もるエージェンシーに注意してください—限定的なカスタマイズでテンプレートを取得する可能性があります。月次インフラストラクチャコストは通常、ホスティングと CMS については $200-600 で実行されます。
Core Web Vitals は本当に Google 広告コストに影響しますか?
はい。Google 広告は、品質スコア計算の一部として「ランディングページの経験」スコアを使用します。より優れたページ速度と Core Web Vitals スコアは、より高い品質スコアにつながり、クリック単価を直接削減します。GlowCo は、Core Web Vitals が改善された後、CPC が 22% 削減されました。Meta は広告関連スコアに同様の信号を使用します。
Headless に移行する際に Shopify チェックアウトを保持できますか?
絶対に、そして強くお勧めします。Shopify のチェックアウトは高度に最適化されており、Shop Pay などの機能を含んでいます(リピーターのチェックアウトコンバージョンを 50% 以上増加させることができます)。Shopify Plus を使用して、ブランディングの一貫性を保ちながらコア チェックアウト フローをそのまま保つために、Checkout 拡張機能を使用してルックアンドフィールをカスタマイズしておよびアップセルを追加できます。
Headless Shopify と Shopify Hydrogen の違いは何ですか?
Headless Shopify は、Shopify の Storefront API を使用するカスタムフロントエンドの広い概念です。Hydrogen は、Remix に基づき、Shopify の Oxygen ホスティングに展開された Shopify の特定のフレームワークです。Next.js、Astro、Nuxt、または任意のフレームワークで headless に移行できます。Hydrogen は、headless Shopify エコシステム内の 1 つのオプションです。
小規模な Shopify ストアの場合、Headless は価値がありますか?
通常、違います。年間収益が $1M 未満で、月の広告支出が $20K 未満の場合、headless 移行のコストが意味のある ROI を生成する可能性は低いです。既存のテーマを最適化することに焦点を当てます—使用されていないアプリを削除し、画像を圧縮し、Dawn のようなパフォーマンスに焦点を当てたテーマに切り替えます。広告費が十分に多い場合、小さな効率向上が大きなドル金額に変換されるまで、headless を検討してください。