ShopifyのCore Web Vitals：完全ガイド（2026年）

ShopifyとCore Web Vitals：サーバーは制御できない

Core Web Vitalsの最適化に関して、ShopifyはWordPressやカスタム構築されたサイトとは根本的に異なります。WordPressでは、サーバー、データベース、キャッシュレイヤー、コードのすべての行など、すべてを制御します。Shopifyでは、一部のものが完全に自分の手から離れている管理されたプラットフォーム内で作業しています。

Core Web Vitals Technology Reportによると、モバイルのCWV合格率においてShopifyはWordPressをリードしています（2025年後半時点で約65%対44%）。これは、高速なサーバー、Cloudflare経由のグローバルCDN、自動的な画像フォーマット変換、事前最適化されたベーステーマなど、Shopifyのインフラストラクチャがデフォルトで優れているためです。プラットフォームはサーバー側をうまく処理します。

問題は、マーチャントがその上に追加するもの（アプリ、サードパーティスクリプト、カスタムテーマの変更、大きすぎる画像、過剰なフォントの読み込み）から発生します。これがShopifyストアがCore Web Vitalsで失敗する理由です。そして、サーバーとコアコードへのアクセスが制限されているため、最適化戦略は異なるものでなければなりません。

数字で見るShopifyのCore Web Vitals

Shopifyは、Core Web Vitalsの合格率に関するCrUX Technology Reportで、Duda（広く使用されていないプラットフォーム）に次いで全体で2位にランクされています。CrUXと独立したベンチマークデータからの数字：

ソース：CrUX Technology Report（2025年6月）、SearchEngineJournal CMS分析、Shero Commerce 1,000ストアベンチマーク（2025年11月）。*中央値はSheroベンチマークからであり、CrUX p75ではありません。

1,000の実際のShopifyストアのShero Commerceベンチマークでは、モバイルで3つのCore Web Vitalsすべてに合格しているのはわずか48%であることがわかりました。これはCrUX Technology ReportがShopify全体で示しているものよりも低く、CrUXに表示されるストア（十分なChromeトラフィックが必要）は、より大規模でより適切に最適化されたストアに偏っていることを示唆しています。2.26秒の中央値モバイルLCPは、2.5秒の「良好」なしきい値に危険なほど近づいており、小さな追加（アプリをもう1つ追加する、最適化されていないヒーロー画像を1つ追加する）でさえ、ストアを合格から不合格に押しやる可能性があることを意味します。

CLSとINPは問題ではありません。Shopifyの0.01という中央値CLSは優れており、153msの中央値INPは快適に良好な範囲内にあります。LCPが、ShopifyストアがCore Web Vitalsに不合格になる部分です。

CoreDashによるShopifyストアからの実際のユーザーデータは、このパターンを裏付けています。CWVに不合格となるストアは、ほぼ常にLCPで不合格になります。8つ以上のサードパーティアプリスクリプトを読み込んでいるストアは、3.0秒を超える中央値モバイルLCPを示します。3つ以下のアプリスクリプトを持つストアは、2.0秒未満の中央値LCPを維持します。インストールされたアプリの数とLCPの相関関係は、データで確認できるShopify CWVの失敗の最も強力な予測因子です。

Shopifyで制御できないこと

最適化する前に、制約を理解してください。Shopifyでは、次のことはできません。

• サーバーまたはホスティングを変更する。Shopifyは独自のインフラストラクチャ上で実行されます。より高速なホストへの切り替え、サーバーレベルのキャッシュの構成、またはPHP設定の調整はできません。良いニュース：ShopifyのTTFBは一般的に優れています（ほとんどの地域で300ms未満）。
• content_for_headerを削除する。Shopifyは、このLiquidタグを介してすべてのページに必須のJavaScriptを挿入します。これには、Shopify独自の分析、チェックアウトスクリプト、およびアプリ読み込みインフラストラクチャが含まれます。削除することはできず、遅延させるとチェックアウトやアプリの機能が壊れるリスクがあります。
• CDNを制御する。ShopifyはCDNとしてCloudflareを使用しています。独自のCloudflareセットアップの場合のように、キャッシュルール、エッジワーカー、またはカスタムヘッダーを構成することはできません。
• データベースまたはバックエンドコードにアクセスする。ShopifyのLiquidテンプレート言語はサーバー側で実行されますが、Liquidが提供するもの以上にデータベースクエリまたはサーバー側のレンダリングを最適化することはできません。

つまり、最適化戦略全体は、テーマコード、インストールされたアプリ、画像、フォント、サードパーティスクリプトなど、制御できるものに焦点を当てています。

Shopify CWVの最大の問題：アプリの肥大化

インストールされたShopifyアプリは、ShopifyストアでのCore Web Vitalsの失敗の最大の原因です。すべてのアプリは、そのアプリが使用されていないページであっても、ストアのすべてのページにJavaScriptとCSSを挿入できます。ホームページに読み込まれるレビューアプリ。連絡先ページに読み込まれる商品おすすめウィジェット。セールがアクティブでない場合でも、すべての商品ページに読み込まれるカウントダウンタイマー。

アプリがコードを挿入する方法

Shopifyアプリはいくつかの方法でコードを挿入し、これはクリーンアップにとって重要です。

• アプリの埋め込み（テーマエディタ）：これらは、「アプリの埋め込み」の下のテーマエディタでオフに切り替えることができます。これは最もクリーンな方法であり、管理が最も簡単です。
• テーマスニペット：一部のアプリは、インストール時にテーマファイルに直接コードを追加します。アプリをアンインストールしても、このコードは削除されない場合があります。残っているファイルについては、snippets/とsections/を手動で確認する必要があります。
• ScriptTag API：アプリは、テーマファイルに触れることなくプログラムでスクリプトを挿入できます。これらはShopifyのcontent_for_headerを介して読み込まれます。アプリをアンインストールすると削除されますが、スクリプトがキャッシュされる場合があります。
• サードパーティローダー：一部のアプリは独自のCDNから外部JavaScriptを読み込み、追加のDNSルックアップとネットワークリクエストを作成します。

アプリ監査プロセス

これは、パフォーマンスへの影響についてShopifyアプリを監査する方法です。

1. ホームページ、商品ページ、コレクションページ、およびカートページをPageSpeed Insightsで実行します。LCP、INP、およびCLSスコアを記録します。
2. Chrome DevToolsを開き、カバレッジタブに移動します。ページを再読み込みし、未使用のJavaScriptの割合を確認します。肥大化したShopifyストアでは、読み込まれたJavaScriptの60%から80%が、特定のページで未使用になります。
3. JavaScriptでフィルタリングされたネットワークタブを確認します。サイズで並べ替えます。どのスクリプトがテーマではなくアプリから来ているかを特定します。「Initiator」列は、各スクリプトをロードしたものを教えてくれます。
4. アプリを1つずつ無効にし（またはアプリの埋め込みをオフに切り替え）、再テストします。各アプリのINPおよびLCPへの影響を個別に測定します。
5. 各アプリについて、ビジネス上の価値はパフォーマンスコストに見合うか？より軽量な代替手段に置き換えることができるか？特定のページタイプでのみ読み込むことができるか？を決定します。

Shopify最適化プロジェクトのCoreDashデータは、アプリのクリーンアップの典型的な影響を示しています。不要なレビューウィジェットスクリプトを1つ削除したところ、あるストアでは中央値INPが45ms改善しました。3つの未使用のアプリ（以前に無効化されたポップアップツール、ロイヤルティプログラム、および廃止されたチャットウィジェット）を削除したところ、合計ページJavaScriptが380KB減少し、モバイルLCPが1.1秒改善しました。現在アクティブに使用していないアプリはすべて、無意味にストアの速度を落としています。削除してください。

ShopifyでのLCPの修正

Shopifyストアでは、LCP要素はほぼ常に、ホームページのヒーローバナー画像、商品ページの注目の商品画像、またはコレクションページのコレクションバナーです。ShopifyのCDNは自動的に画像をWebP形式で配信するため、これが役立ちます。ただし、自分で処理する必要があるいくつかの最適化があります。

ヒーロー画像をプリロードする

Shopifyのimage_tag Liquidフィルターには、組み込みのpreloadパラメーターがあります。trueに設定すると、Shopifyはサーバーからrel=preloadを含むLink HTTPヘッダーを送信します。ブラウザはHTMLの解析を開始する前にこれを受信するため、可能な限り早いプリロードシグナルとなります。また、タグからimagesrcsetとimagesizesも自動的に含まれるため、レスポンシブなプリロードがURLの不一致のリスクなしに正しく機能します。

これを<img>のfetchpriority: 'high'と組み合わせて、スクロールせずに見えるセクションのShopifyのデフォルトの遅延読み込みをオーバーライドするためのloading: 'eager'を使用します。ヒーロー画像の場合、次のようになります。

{{ section.settings.hero_image | image_url: width: 1200 | image_tag:
    preload: true,
    fetchpriority: 'high',
    loading: 'eager',
    sizes: '100vw'
}}

その1行で、HTTPヘッダープリロード（可能な限り早い）、<img>上のfetchpriority="high"、遅延の代わりのイーガーロード、自動のwidthおよびheight属性（CLSを防止）、および自動のsrcset生成が提供されます。プリロードを使用しない場合でも、ヒーロー画像には常にfetchpriority="high"を設定してください。

テーマがヒーローにCSS背景画像を使用している場合

一部のShopifyテーマは、ヒーローバナーを<img>タグの代わりにCSS background-imageとしてレンダリングします。これはLCPのアンチパターンです。fetchpriorityが失われ、自動srcsetが失われ、ShopifyのHTTPヘッダープリロードが失われ、ブラウザはCSSファイルをダウンロードして解析するまで画像のフェッチを開始することさえできません。

正しい修正は、CSSの背景を<img>タグに変換して、image_tagを適切に使用できるようにすることです。これはテーマコードの変更ですが、正しいものです。

どうしてもテンプレートを変更できない場合は、theme.liquidに手動のプリロードヒントを追加できます。

{%- if template == 'index' -%}
  <link rel="preload" as="image" href="{{ section.settings.hero_image | image_url: width: 1200 }}">
{%- endif -%}

注意：プリロード内のURLは、Shopifyの?v=バージョンスタンプと&width=パラメーターを含め、CSS内のURLと完全に一致している必要があります。1つのパラメーターでも異なる場合、ブラウザは画像を2回ダウンロードし、パフォーマンスが向上するどころか低下します。

完全なLCP画像プリロード戦略については、LCP画像をプリロードする方法を参照してください。

スクロールせずに見える範囲では遅延読み込みしない

多くのShopifyテーマは、ヒーローを含むすべての画像にloading="lazy"を適用します。これにより、ブラウザにページ上で最も重要な画像の優先順位を下げるように指示します。テーマが、スクロールせずに見える画像から遅延読み込みを除外していることを確認してください。Shopifyのimage_tagフィルターを使用する最新のテーマの場合は、ヒーロー画像にloading: 'eager'を使用します。

画像サイズを最適化する

ShopifyのCDNはURLパラメーターを使用してその場で画像のサイズを変更できますが、Liquidテンプレートは適切なサイズを要求する必要があります。800pxでしか表示されない場合に、2000px幅の画像を読み込まないでください。適切なsrcsetおよびsizes属性を持つShopifyのレスポンシブ画像マークアップを使用してください。私たちの画像最適化ガイドを参照してください。

ShopifyでのINPの修正

ShopifyでのINPの失敗は、ほぼ完全にJavaScriptがメインスレッドをブロックすることが原因です。Shopify独自のcontent_for_headerインジェクションは、すでに削除できないベースラインJavaScriptを追加しています。その上に追加するすべてが問題を悪化させます。

クリティカルでないサードパーティスクリプトを遅延させる

チャットウィジェット（Tidio、Zendesk、Intercom）、レビューアプリ（Judge.me、Yotpo、Loox）、パーソナライズツール（Klaviyoポップアップ、Privy）、および分析（Googleアナリティクス、Facebookピクセル、Hotjar）は、初期ページのレンダリング中に読み込まれるべきではありません。正しいアプローチはrequestIdleCallbackです。ブラウザは、メインスレッドがアイドル状態のとき（通常はページがレンダリングされてから数秒後）にのみ、これらのスクリプトを読み込みます。

インタラクションベースの遅延（最初のスクロール、クリック、またはタップでスクリプトをロードする）は使用しないでください。ユーザーがボタンをタップし、サイトがその同じイベントで500KBのサードパーティJavaScriptを読み込むことで応答すると、メインスレッドがブロックされ、そのインタラクションはひどいINPスコアを取得します。遅延のポイントは、メインスレッドをユーザーインタラクションのために解放しておくことであり、ユーザーインタラクションと競合することではありません。

クリティカルでないスクリプトでsrc属性をdata-srcに置き換え、ブラウザがアイドル状態のときにそれらを元に戻します。

<script>
(window.requestIdleCallback || function(cb) { setTimeout(cb, 1); })(function() {
  document.querySelectorAll('script[data-src]').forEach(function(s) {
    s.src = s.dataset.src;
  });
});
</script>

setTimeoutのfallbackは、requestIdleCallbackをサポートしていないSafariをカバーします。requestIdleCallbackとは異なり、真のアイドルウィンドウを待ちません。しかし、それでもメインスレッドを分割し、動的に挿入されたスクリプトはいずれにしてもプリロードスキャナーをバイパスするため、実際には十分に機能するfallbackとなります。

JavaScriptの遅延戦略の詳細については、JavaScriptを遅延させる14の方法を参照してください。

テーマJavaScriptを減らす

ShopifyのOnline Store 2.0テーマ（Dawnなど）は軽量になるように構築されていますが、多くのサードパーティテーマは、メガメニュー、商品スライダー、クイックビューモーダル、およびアニメーションのために重いJavaScriptを追加します。Chrome DevToolsのカバレッジタブを使用して、テーマのJavaScriptを監査します。テーマが200KBを超えるJavaScriptをロードする場合は、無効にできる機能やCSSの代替手段で置き換えることができる機能を探してください。

ShopifyでのCLSの修正

ShopifyストアでのCumulative Layout Shiftは、通常、寸法の無い画像、フォントの入れ替え、およびアプリから動的に挿入されたコンテンツの3つによって引き起こされます。

Liquidテンプレートで画像サイズを設定する

Liquidテンプレートで、widthおよびheight属性が欠落している<img>タグを確認してください。Shopifyのimage_tagフィルターはこれらを自動的に出力できます。

{{ product.featured_image | 
   image_tag: widths: '200,400,800', sizes: '(max-width: 768px) 100vw, 50vw' }}

これにより、適切な寸法を持つレスポンシブ画像が生成され、画像の読み込み時のレイアウトのずれを防ぎます。

動的コンテンツのためのスペースを予約する

ページ読み込み後にレビュースター、トラストバッジ、カウントダウンタイマー、または告知バーを挿入するアプリの埋め込みは、CLSの原因となります。各動的要素について、要素が表示されたときに周囲のコンテンツがずれないように、CSS min-heightでスペースを確保してください。これは、既存のコンテンツの上に挿入される要素にとって特に重要です。

フォントの読み込みを最適化する

ShopifyテーマがカスタムWebフォントをロードする場合は、それらが適切に一致するfallbackフォントを備えたfont-display: swapを使用していることを確認してください。テキストが正しいフォントでレンダリングされるまでの時間を短縮するために、プライマリフォントファイルをプリロードします。実際に使用するフォントの太さとスタイルのみを読み込みます。フォントの最適化に関する私たちのガイドを参照してください。

Shopifyテーマの選択とパフォーマンス

テーマの選択は、ストアのパフォーマンスのベースラインを設定します。ThemeVitalsプロジェクトは、Shopifyテーマの実際のCrUXデータを追跡しています。主な調査結果：

• Dawn（Shopifyのデフォルトの無料テーマ）は、パフォーマンスを優先して構築されているため、Core Web Vitalsで一貫して優れたパフォーマンスを発揮します。
• 多くのセクション、アニメーション、および組み込み機能（メガメニュー、商品クイックビュー、AJAXカートドロワー）を持つテーマは、より多くのJavaScriptを持ち、INPが悪化する傾向があります。
• Online Store 2.0テーマは、Shopifyの最新のセクションアーキテクチャとアセットロードを使用しているため、一般的にレガシーテーマよりも高速です。

新しいテーマを選択する場合は、購入前にThemeVitalsでそのCrUXデータを確認してください。最も安価なパフォーマンスの最適化は、高速なテーマから始めることです。

Shopifyがデフォルトでうまく行っていること

Shopifyはすぐに使える状態で多くのことを正しく行っています。

• 高速なインフラストラクチャ：ShopifyのサーバーとCloudflare CDNは、一貫して低いTime to First Byteをグローバルに提供します。
• 自動WebP：ShopifyのCDNは、ブラウザがサポートしている場合、画像を自動的にWebP形式に変換します。
• HTTP/2とBrotli：すべてのShopifyストアでデフォルトで有効になっています。
• オンザフライのサイズ変更が可能な画像CDN：URLパラメーターを使用して、任意の幅の任意の画像をリクエストできます。
• プリコネクトヒント：Shopifyは、CDNドメインのプリコネクトヒントを自動的に追加します。

これらのデフォルトが、Shopifyのベースラインパフォーマンスが良好である理由です。あなたの仕事は、過剰なアプリやスクリプトでこれらの利点を台無しにしないことです。

Shopifyストアの監視

Shopifyの管理ダッシュボードには「速度スコア」が含まれていますが、これはLighthouseベースの単純化された数値であり、実際のCore Web Vitalsを表すものではありません。実際のパフォーマンス監視のために：

• Google Search Console：ストア全体のフィールドデータについて、Core Web Vitalsレポートを確認してください
• CoreDash：軽量のRUMスニペット（theme.liquidに1行のコード）をインストールして、ページタイプ、デバイス、国別に分類されたリアルタイムのCore Web Vitalsデータを取得します
• PageSpeed Insights：個々の商品、コレクション、およびホームページのURLをテストして診断データを取得します

アプリのインストール、テーマの更新、および季節的なキャンペーンの開始のたびに監視します。Shopifyでのパフォーマンスの低下は、ほぼ常に最近追加されたものが原因です。

CoreDashの監視データによると、ShopifyのCWV低下の最も一般的な原因は、JavaScriptをグローバルに挿入する新しいアプリのインストールです。平均して、新しいShopifyアプリはすべてのページ読み込みに50KBから150KBのJavaScriptを追加します。LCPのしきい値（2.3から2.5秒）にちょうど達しているストアの場合、1つのアプリをインストールしただけでしきい値を超えてしまう可能性があります。2番目に一般的な原因は、季節的な変更です。セールイベントのために追加され、その後忘れ去られた、ブラックフライデーのキャンペーンバナー、休日のポップアップ、プロモーションのカウントダウンタイマーなどです。