サイト速度

ECサイト表示速度改善ガイド【2026年最新】Core Web Vitals対策でCVRを上げる方法

更新日: 2026年3月30日 · 読了時間: 約15分

ECサイトの表示速度は、売上に直結する最も重要な技術指標の一つです。ページの読み込みが遅いだけで、ユーザーは離脱し、カート追加も購入完了もされないまま競合サイトへ流れていきます。Googleが公式に発表しているデータによれば、モバイルページの読み込みが1秒から3秒に遅延するだけで直帰率は32%増加し、5秒になると90%増加します。さらに2021年以降、Core Web VitalsがGoogle検索のランキング要因に組み込まれたことで、表示速度はSEOにも直接的な影響を与えています。2026年現在、ECサイト運営者にとって表示速度の最適化はCVR改善・SEO対策・ユーザー体験向上の三位一体で取り組むべき最優先課題です。この記事では、表示速度がEC売上に与える具体的な影響から、Core Web Vitalsの測定方法、画像・JavaScript・サーバー・モバイルの最適化手法、そして楽天・Amazon・Shopifyのプラットフォーム別テクニックまでを網羅的に解説します。

1. 表示速度がEC売上に与える影響 ― 1秒の遅延がCVRと売上を蝕む

ECサイトにおいて、ページ表示速度は単なる技術的な指標ではなく、ビジネスの収益に直結する経営指標です。表示が遅いサイトはユーザーの離脱率が高く、カート放棄率も上がり、結果的にCVR（転換率）と売上を大きく毀損します。

表示速度と売上への影響データ

  • ページ読み込み1秒遅延でCVRが約7%低下 ― 表示速度が1秒遅くなるごとに、コンバージョン率は約7%低下するとされている。月商500万円のECサイトなら、1秒の改善で年間420万円の売上増が見込める計算になる
  • モバイルユーザーの53%が3秒以内に表示されないと離脱 ― ECサイトの訪問者の70%以上がモバイルユーザーである現在、モバイルの表示速度は特に重要。3秒の壁を超えると半数以上のユーザーが離脱する
  • 表示速度が速いサイトはSEO順位も上がる ― GoogleはCore Web Vitalsをランキングシグナルに採用しており、表示速度の改善はオーガニック検索流入の増加にも直結する
  • カート放棄率への影響 ― チェックアウトページの表示が遅い場合、カート放棄率は平均で2倍以上に増加する。決済完了直前の離脱は機会損失としてのインパクトが最も大きい
  • ユーザーの期待値は年々厳しくなっている ― 2026年現在、ユーザーが「遅い」と感じる閾値は2秒以内にシフトしている。5年前は3秒以内が許容範囲だったが、高速回線やアプリ体験に慣れたユーザーの期待値は高まり続けている
  • 競合比較が容易な時代だからこそ速度が差別化になる ― 同じ商品・同じ価格帯のECサイトが複数存在するなか、表示が遅いだけで選ばれない。体感速度の差がブランドの信頼性の差として認識される
  • 広告のROASにも直結する ― リスティング広告やSNS広告のクリック後にランディングページの読み込みが遅い場合、広告費を払って獲得したユーザーが表示を待たずに離脱する。表示速度の改善は広告ROASの直接的な改善策になる

2. Core Web Vitals（LCP・FID・CLS）の基本と測定方法

Core Web VitalsはGoogleが定めたウェブページのユーザー体験を測る3つの主要指標です。ECサイトの表示速度を改善するには、まずこれらの指標を正しく理解し、現状を計測することが出発点になります。2024年にはFIDがINP（Interaction to Next Paint）に置き換わっていますが、ECサイトにおける考え方は基本的に同じです。

Core Web Vitals 3指標の基準値

  • LCP（Largest Contentful Paint）: 2.5秒以内 ― ページ内で最も大きなコンテンツ要素（メイン画像やヒーローバナーなど）が表示されるまでの時間。ECサイトでは商品画像やカルーセルのメイン画像がLCPの対象になることが多い
  • INP（Interaction to Next Paint）: 200ms以内 ― ユーザーの操作（クリック、タップ、キー入力）からページが視覚的に応答するまでの時間。ECサイトでは「カートに追加」ボタン押下後のレスポンス、サイズ選択のドロップダウン操作、検索窓の入力応答などが計測対象
  • CLS（Cumulative Layout Shift）: 0.1以下 ― ページ読み込み中に要素が予期せず移動する度合い。ECサイトでは遅延読み込みされた画像のサイズ未指定、後から表示される広告バナー、フォント読み込みによるテキストのズレなどが原因になる
  • PageSpeed Insights（PSI） ― Googleが提供する無料ツール。URLを入力するだけでCore Web Vitalsのスコアと改善提案を取得できる。フィールドデータ（実際のユーザー体験）とラボデータ（シミュレーション）の両方を確認できる
  • Google Search Console ― サイト全体のCore Web Vitalsレポートを確認できる。「良好」「改善が必要」「低い」の3段階で全URLを分類し、問題のあるページをリストアップ。ECサイトでは商品ページ・カテゴリページ・トップページを個別に監視すべき
  • Lighthouse（Chrome DevTools内蔵） ― Chrome DevToolsのLighthouseタブからパフォーマンス監査を実行。スコアだけでなく、具体的なボトルネック（レンダリングブロックリソース、未使用JavaScriptなど）を特定できる
  • Web Vitals拡張機能 ― ChromeウェブストアからインストールできるGoogleの公式拡張機能。ページ閲覧中にリアルタイムでLCP・INP・CLSを表示。ECサイトを回遊しながら各ページの状態を瞬時にチェックできる
  • 計測の優先順位 ― まずトップページ、主要カテゴリページ、売上上位10商品のページ、カートページ、チェックアウトページの順に計測する。全ページを一気に改善するのではなく、売上インパクトの大きいページから着手する

3. 画像最適化 ― WebP/AVIF・遅延読み込み・適切なサイズ設定

ECサイトのページ容量の60〜80%は画像が占めています。つまり、画像の最適化こそが表示速度改善で最もインパクトの大きい施策です。次世代フォーマットへの変換、遅延読み込みの実装、適切なサイズ指定の3つを徹底するだけで、LCPは劇的に改善します。

画像フォーマット比較

  • JPEG ― 従来の標準フォーマット。品質80で保存した場合の平均ファイルサイズを100%とすると、WebPは約70%、AVIFは約50%に削減可能
  • WebP ― Googleが開発した次世代フォーマット。JPEGより25〜35%軽量でほぼ同等の画質を維持。2026年現在、全ブラウザがサポートしておりECサイトでの採用障壁はゼロ
  • AVIF ― 最新の高圧縮フォーマット。JPEGより50%以上軽量。Chrome・Firefox・Safariの最新版で対応済み。WebPよりもさらに軽量だが、エンコード時間が長いため事前の変換処理が必要
  • 商品画像をWebP/AVIFに一括変換する ― Squoosh（Google製、ブラウザで動作）やSharpJS（Node.jsライブラリ）を使って既存のJPEG/PNGをWebPに変換する。HTMLでは<picture>タグを使い、AVIFを最優先、WebPをフォールバック、JPEGを最終フォールバックとして指定する
  • 遅延読み込み（Lazy Loading）の実装 ― ファーストビュー以外の画像にはloading="lazy"属性を追加する。これにより、ユーザーがスクロールして画像が表示領域に近づいたときに初めて読み込みが開始される。ファーストビューのメイン画像には遅延読み込みを適用しないことが重要（LCPが悪化するため）
  • 画像サイズの適切な指定 ― すべての<img>タグにwidth属性とheight属性を明示する。これによりブラウザが画像読み込み前にスペースを確保でき、CLSの発生を防止できる。レスポンシブデザインの場合はCSSでmax-width: 100%とheight: autoを併用する
  • srcsetによるレスポンシブ画像の配信 ― モバイル端末にデスクトップ向けの大きな画像を配信するのは無駄。srcset属性で画面幅に応じた最適サイズの画像を配信する。例: 320w、640w、960w、1280wの4サイズを用意し、デバイスに応じて最適なサイズを自動選択させる
  • CDN経由での画像配信 ― Cloudflare Images、imgix、Cloudinary等の画像CDNを活用すると、リサイズ・フォーマット変換・最適化を自動で行ってくれる。Shopifyは標準でCDN経由の画像配信を提供しているため、URLパラメータでサイズを指定するだけで最適化が可能

4. JavaScript・CSS最適化 ― 不要なスクリプト削除・圧縮・遅延読み込み

ECサイトは計測タグ、チャットウィジェット、レコメンドエンジン、決済スクリプトなど多くのサードパーティJavaScriptが読み込まれています。これらのスクリプトはページの描画をブロックし、INP・LCPを悪化させる主要因です。不要なスクリプトの削除と必要なスクリプトの最適化で、体感速度を大幅に改善できます。

  • 不要なスクリプトの棚卸し ― Chrome DevToolsの「Coverage」タブで、ページ読み込み時に実際に実行されたJavaScriptの割合を確認する。使われていないコードが50%以上を占めているケースは珍しくない。使用していない計測タグ、古いプラグイン、重複ライブラリを特定して削除する
  • レンダリングブロックの解消 ― <head>内のJavaScriptとCSSはページの描画をブロックする。ファーストビューに不要なJavaScriptにはdefer属性またはasync属性を追加し、非同期読み込みにする。CSSは「クリティカルCSS」（ファーストビューの描画に必要な最小限のCSS）をインラインで埋め込み、残りを非同期で読み込む
  • JavaScriptバンドルの分割（コードスプリッティング） ― 全ページで同じ巨大なJavaScriptファイルを読み込むのではなく、ページごとに必要なコードだけを読み込むようにする。Next.jsやNuxt.jsなどのフレームワークを使用している場合は自動的にコードスプリッティングが適用される
  • CSS・JavaScriptの圧縮（Minify） ― 空白・コメント・改行を削除してファイルサイズを20〜30%削減する。ビルドツール（Webpack、Vite、esbuild）に組み込まれている圧縮機能を有効にする。さらにBrotliまたはGzip圧縮をサーバー側で有効にすると、転送サイズが70〜80%削減される
  • サードパーティスクリプトの遅延読み込み ― チャットウィジェット、SNSシェアボタン、レコメンドウィジェットなどのサードパーティスクリプトは、ページの初期描画後に読み込む。Intersection ObserverやrequestIdleCallbackを使って、ユーザーのスクロールやページのアイドル時間を利用して遅延読み込みする
  • Tree Shakingで未使用コードを除去 ― ライブラリ全体をインポートするのではなく、必要な関数だけを個別にインポートする。例えばlodash全体ではなく、lodash/debounceだけをインポートすることでバンドルサイズを大幅に削減できる

5. サーバー・CDN最適化 ― キャッシュ戦略とCDN活用で応答速度を高速化

フロントエンドの最適化だけでは限界があります。サーバーの応答時間（TTFB: Time to First Byte）が遅い場合、すべてのページで表示速度のベースラインが底上げされてしまいます。キャッシュ戦略の最適化とCDNの活用で、サーバー側のボトルネックを解消しましょう。

キャッシュの種類と効果

  • ブラウザキャッシュ ― HTTPヘッダーのCache-Controlを適切に設定し、静的ファイル（画像・CSS・JS）をブラウザに保存させる。2回目以降のアクセスでサーバーへのリクエストを大幅に削減。画像は1年、CSS/JSはハッシュ付きファイル名で長期キャッシュが推奨
  • CDNキャッシュ ― CDN（Content Delivery Network）のエッジサーバーにコンテンツをキャッシュし、ユーザーに最も近いサーバーから配信。日本国内向けECサイトでも東京・大阪の2拠点以上にエッジサーバーがあるCDNを選定する
  • サーバーサイドキャッシュ ― データベースクエリの結果やHTMLレンダリング結果をRedis等にキャッシュし、同じリクエストの処理を高速化。商品ページのHTMLをフルページキャッシュすることでTTFBを100ms以下に抑えられる
  • CDNの選定と導入 ― Cloudflare（無料プランあり）、AWS CloudFront、Fastlyなどが主要CDN。ECサイトの場合、静的ファイルだけでなくHTMLページもCDNキャッシュすることでTTFBを大幅に短縮できる。Shopifyは標準でFastly CDNを使用しているため追加設定は不要
  • TTFBの目標値は200ms以内 ― TTFB（サーバーの最初の応答までの時間）が200msを超えている場合、サーバー側の改善が必要。データベースクエリの最適化、サーバースペックの見直し、キャッシュ戦略の導入を検討する
  • HTTP/2またはHTTP/3の有効化 ― HTTP/2は複数のリクエストを同時に処理でき、HTTP/1.1と比較して30〜50%の速度改善が見込める。HTTP/3はさらにUDPベースのQUICプロトコルを使用し、接続確立の遅延を大幅に削減。多くのCDNが標準でHTTP/3に対応している
  • プリコネクト・プリフェッチの活用 ― <link rel="preconnect">で外部ドメインへの事前接続、<link rel="dns-prefetch">でDNS解決の事前実行を指定する。CDN、フォントサーバー、決済プロバイダーなど頻繁に接続する外部ドメインに適用すると効果的
  • キャッシュの無効化戦略も設計する ― 商品価格の変更やセール開始時にキャッシュが古い情報を返さないよう、キャッシュパージの仕組みを事前に構築しておく。ファイル名にハッシュを含めるバスティングや、CDNのAPIを使ったパージ自動化が有効

6. モバイル表示速度の特別な考慮点

ECサイトのトラフィックの70%以上がモバイルからである現在、モバイル表示速度の最適化はデスクトップ以上に重要です。モバイル環境はデスクトップと比較してCPU性能が低く、ネットワーク帯域が不安定で、画面が小さいという3つの制約があり、それぞれに固有の対策が求められます。

  • モバイルファーストで設計する ― デスクトップ版を先に作ってモバイル対応するのではなく、モバイルを最優先で設計し、デスクトップに拡張する。CSSのメディアクエリはmin-widthで記述し、モバイルがベーススタイルになるようにする
  • モバイル向け画像サイズの最適化 ― スマートフォンの画面幅は320〜430px程度。デスクトップ向けの1200px幅の画像をモバイルに配信するのは帯域の無駄。srcset属性でデバイスに応じた適切なサイズの画像を配信し、転送量を50%以上削減する
  • タッチ操作の応答性（INP対策） ― モバイルではタップ操作の応答が遅いとストレスが大きい。特に「カートに追加」「サイズ選択」「画像スワイプ」の3つのインタラクションは200ms以内に視覚的フィードバックを返すことが重要。重いJavaScript処理はWeb Workerに逃がすか、requestAnimationFrameで最適化する
  • 4G/低速回線でのテストを必ず行う ― Chrome DevToolsのNetworkタブで「Slow 3G」や「Fast 3G」をシミュレートし、低速環境でも許容できる表示速度であることを確認する。Wi-Fiのオフィス環境でのテストだけでは不十分
  • フォントの最適化 ― WebフォントのダウンロードはLCPに影響する。font-display: swapを指定してフォント読み込み中もテキストを表示させる。日本語フォントは容量が大きい（数MB）ため、サブセット化して実際に使用する文字のみを含むフォントファイルを生成する
  • AMP（Accelerated Mobile Pages）の検討 ― 特定の商品ランディングページや記事ページでAMP版を用意することで、Googleモバイル検索からの遷移を高速化できる。ただしAMPの制約（JavaScriptの制限）がEC機能と相性が悪い場合もあるため、カテゴリ別に導入を判断する

モバイル速度チェックリスト

  • LCPが2.5秒以内（4G回線シミュレーション時）
  • INPが200ms以内（特にカート追加・サイズ選択操作）
  • CLSが0.1以下（画像サイズ指定・フォント最適化済み）
  • モバイル向け画像（640px以下）が配信されている
  • 不要なサードパーティスクリプトが遅延読み込みされている
  • タップターゲットが48px以上（指で押しやすいサイズ）

7. 楽天・Amazon・Shopifyでの速度改善テクニック（プラットフォーム別）

ECモールやカートシステムを利用している場合、サーバー設定やCDN導入は自分ではコントロールできない部分が多くあります。しかし、各プラットフォームの仕組みを理解し、コントロール可能な範囲で最適化を行うことで、表示速度を大きく改善できます。

楽天市場の速度改善テクニック

  • 商品画像の最適化が最重要 ― 楽天の商品ページは画像が大量に使われるため、画像サイズの最適化が最もインパクトが大きい。楽天GOLDに画像をアップロードする際、WebP形式で保存し、横幅は800px以内に抑える
  • HTMLメールのような装飾を削減する ― 楽天の商品ページはHTMLで自由にデザインできるが、テーブルレイアウトやインラインCSS、画像の過度な使用はページ容量を肥大化させる。必要最小限のHTMLで構成し、CSS for RMSを活用する
  • iframe読み込みの最適化 ― 楽天の商品ページには楽天の共通ヘッダー・フッター等がiframeで読み込まれるため、自社でコントロールできない遅延が発生する。自社コントロール部分のHTMLを軽量にすることで、全体の表示時間を相殺する

Amazonの速度改善テクニック

  • 商品画像のガイドライン遵守が速度にも貢献 ― Amazonの画像ガイドライン（最長辺1600px以上・2000px推奨、JPEG/PNG/GIF）に準拠しつつ、不必要に巨大な画像は避ける。ズーム機能が動作する1600px以上を確保しつつ、ファイルサイズは500KB以下を目安にする
  • A+コンテンツの画像最適化 ― A+コンテンツ（商品紹介コンテンツ）で使用する画像は、Amazonが指定するサイズ規定に正確に合わせる。規定より大きい画像をアップロードしても自動リサイズされるが、元ファイルの転送にリソースが使われる
  • バリエーション構成の見直し ― カラーバリエーションが過度に多い商品ページは読み込みが遅くなる。バリエーションが20以上ある場合は、カテゴリを分割して別ASINにすることも検討する

Shopifyの速度改善テクニック

  • テーマの速度を確認する ― Shopifyテーマの選定時にパフォーマンスを重視する。Dawn（Shopify公式テーマ）はパフォーマンス最適化済みで推奨。サードパーティテーマを使用する場合は、デモサイトのPageSpeed Insightsスコアを事前に確認する
  • アプリの見直しと削減 ― Shopifyアプリは便利だが、各アプリが独自のJavaScript/CSSを追加するため、インストール数が増えるほどページが遅くなる。現在使用しているアプリを棚卸しし、不要なアプリはアンインストールする。アプリ1つあたり0.3〜1秒の遅延が発生しうる
  • Liquidコードの最適化 ― テーマのLiquidテンプレートで不要なループ処理、過度なセクション数、未使用のLiquidタグを整理する。Shopifyの「テーマエディター」でセクション数を最小限に抑え、使っていないセクションは削除する
  • Shopify標準CDNの活用 ― ShopifyはFastly CDNを標準搭載しており、追加のCDN設定は不要。画像URLにサイズパラメータ（例: _300x300）を付与することで、サーバーサイドで最適なサイズにリサイズされた画像が配信される
  • カスタムフォントの使用を最小限にする ― Shopifyテーマに独自の日本語Webフォントを追加する場合、フォントファイルの容量に注意。Noto Sans JPのフルセットは数MBあるため、必ずサブセット化して使用する。可能であればシステムフォントにフォールバックする設計が最も高速

プラットフォームを問わず、表示速度改善の基本は「計測→ボトルネック特定→改善→再計測」のPDCAサイクルです。PageSpeed Insightsで現状を把握し、最もインパクトの大きい施策から順に着手してください。画像最適化だけで劇的に改善するケースが多いため、まずは商品画像のWebP変換とサイズ最適化から始めることを強くおすすめします。

高速なECサイトに最適化された商品説明文をAIで自動生成

EC Copy AIは、商品情報を入力するだけで楽天・Amazon・Yahoo!・Shopifyに最適化された商品説明文をAIが自動生成します。SEOに強い構造化されたテキストで、画像に頼らず商品の魅力を伝えるコピーを30秒で作成。ページ容量を増やさずにCVRを高める軽量な商品説明文を、月10回まで無料・登録不要でお試しいただけます。

無料で商品説明文を生成する →

関連記事

楽天市場楽天市場の商品名SEO完全ガイドAmazonAmazon商品説明文の書き方AI活用AIでEC商品説明文を自動生成する方法
記事一覧を見る →