モバイルECの表示が1秒遅れるとCVRが7%下がるとされています。LCP 2.5秒以内を達成するための10ステップを解説します。

このチェックリストの使い方

以下の10項目を順番に確認・実装していくことで、モバイルECの表示速度を体系的に改善できます。すでに対応済みの項目はスキップして構いません。

1. ヒーロー画像をWebP/AVIFに変換し、width/heightを明示する

なぜ重要か: ヒーロー画像はほとんどのECサイトでLCP(Largest Contentful Paint)要素です。WebP変換だけでファイルサイズが30〜50%削減でき、width/height明示でCLS(レイアウトシフト)も防止できます。 実測値の目安: ヒーロー画像は100KB以下が理想。300KB以上なら即改善対象。 確認コマンド:
# 画像サイズ確認(macOS)
curl -sI https://example.com/hero.jpg | grep -i content-length
# WebP変換(cwebp使用)
cwebp -q 80 hero.jpg -o hero.webp
HTMLの書き方:
<img src="hero.webp" alt="商品画像" width="1200" height="600"
     fetchpriority="high" decoding="async">

---

2. fetchpriority="high"をLCP要素に設定する

なぜ重要か: ブラウザはデフォルトでは画像の読み込み優先度を自動判定しますが、LCP要素にはfetchpriority="high"を明示することで、ブラウザに「この画像を最優先で読み込め」と指示できます。 実測値の目安: LCP改善効果は100〜300ms程度。設定前後でPageSpeed Insightsを比較。 注意: fetchpriority="high" はページ内で1〜2要素のみに使うこと。全画像に設定すると逆効果。
<!-- LCP要素のみにfetchpriority="high" -->
<img src="hero.webp" fetchpriority="high" alt="..." width="1200" height="600">

<!-- ATF以外の画像はloading="lazy" -->
<img src="product-1.webp" loading="lazy" alt="..." width="400" height="400">

---

3. 不要なCSSをインライン化し、残りを非同期読み込みにする

なぜ重要か: CSSはレンダリングブロックリソースです。ATF(Above The Fold)に必要なCSSだけをインライン化し、残りを非同期にすることでFCP(First Contentful Paint)を改善します。 確認コマンド:
# CSSのサイズ確認
curl -sI https://example.com/style.css | grep -i content-length
# 未使用CSS率の確認(DevToolsの「Coverage」タブでも確認可能)
実装例:
<head>
  <!-- クリティカルCSSをインライン -->
  <style>
    / ATFに必要な最小限のCSS /
    body { margin: 0; font-family: sans-serif; }
    .hero { width: 100%; height: 60vh; }
  </style>
  <!-- 残りのCSSを非同期読み込み -->
  <link rel="preload" href="/style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
</head>

---

4. サードパーティスクリプトにdefer/asyncを付与する

なぜ重要か: GTM、GA4、広告タグ、チャットウィジェット等のサードパーティスクリプトは、defer/asyncなしで読み込むとページのレンダリングを完全にブロックします。 目安: サードパーティスクリプトの合計サイズが200KB以上なら要改善。 パターン別の対処:
<!-- GTM: ページ読み込みに必須 → async -->
<script async src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXXX"></script>

<!-- チャットウィジェット: ページ読み込み後でOK → defer -->
<script defer src="https://chat-widget.example.com/widget.js"></script>

<!-- 広告タグ: ユーザー操作後に遅延読み込み -->
<script>
window.addEventListener('scroll', function loadAds() {
const s = document.createElement('script');
s.src = 'https://ads.example.com/tag.js';
document.head.appendChild(s);
window.removeEventListener('scroll', loadAds);
}, { once: true });
</script>

---

5. Google Fontsをpreconnect + font-display: swapに変更する

なぜ重要か: Google Fontsのデフォルト読み込みはLCP要素のテキスト表示を遅延させます。preconnectで接続を事前確立し、font-display: swapでシステムフォントの先行表示を指示します。 改善前:
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=auto" rel="stylesheet">
改善後:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP&display=swap" rel="stylesheet">
さらなる最適化: 使用するweight(400, 700等)だけを指定 → family=Noto+Sans+JP:wght@400;700

---

6. カルーセル/スライダーをCSSスクロールスナップに置き換える

なぜ重要か: Slick.js/Swiper等のJSカルーセルは50〜100KB以上のJSを読み込みます。CSSスクロールスナップならJS 0KBで同等のUXを実現できます。 CSSスクロールスナップ実装:
.product-carousel {
  display: flex;
  overflow-x: auto;
  scroll-snap-type: x mandatory;
  gap: 16px;
  -webkit-overflow-scrolling: touch;
}
.product-carousel .card {
  scroll-snap-align: start;
  min-width: 280px;
  flex-shrink: 0;
}
削減効果: Slick.js削除で80KB(JS + CSS)削減。LCP 200〜500ms改善。

---

7. 商品画像にloading="lazy"を設定する(ATF除く)

なぜ重要か: ECサイトの商品一覧ページは画像が20〜50枚並びます。全画像を同時に読み込むと帯域を圧迫しLCPが悪化します。ATF(画面に見えている範囲)以外の画像にloading="lazy"を設定。 注意: LCP要素(ヒーロー画像)には loading="lazy" を設定しないこと。逆にLCPが悪化します。
<!-- ATF内(最初の3〜4枚): lazy なし -->
<img src="product-1.webp" alt="..." width="400" height="400">
<!-- ATF外(5枚目以降): lazy あり -->
<img src="product-5.webp" alt="..." loading="lazy" width="400" height="400">

---

8. GTMコンテナの肥大化を診断し、不要タグを削除する

なぜ重要か: GTMコンテナは時間とともに不要なタグが蓄積し、100KB以上に膨張することがあります。コンテナサイズが大きいとTBT(Total Blocking Time)が悪化し、INPにも影響します。 確認方法: よくある不要タグ: 過去のキャンペーン用ピクセル、テスト用のカスタムHTML、重複GA4タグ

---

9. CDNのキャッシュヒット率を確認し、TTLを最適化する

なぜ重要か: CDN(Cloudflare, Fastly, Akamai等)を使っていてもキャッシュヒット率が低ければ効果は半減。静的アセットのTTL(キャッシュ保持期間)を適切に設定します。 確認コマンド:
# レスポンスヘッダーでキャッシュ状態を確認
curl -sI https://example.com/style.css | grep -i -E 'cache-control|cf-cache-status|x-cache'
目安:

---

10. CrUXデータでフィールドLCPを継続モニタリングする

なぜ重要か: ラボデータ(PageSpeed Insights)は1回のテスト結果。フィールドデータ(CrUX)は実際のユーザー体験の統計です。Googleのランキング評価に使われるのはフィールドデータ。 確認方法: 目標値(CWV 2026年版): | 指標 | 良好 | 改善が必要 | 不良 | |------|------|-----------|------| | LCP | ≤ 2.5s | 2.5s〜4.0s | > 4.0s | | INP | ≤ 200ms | 200ms〜500ms | > 500ms | | CLS | ≤ 0.1 | 0.1〜0.25 | > 0.25 |

---

まとめ

10項目のチェックリストを順番に実装することで、モバイルECのLCP 2.5秒以内を達成できます。

即効性の高い3施策: ①ヒーロー画像のWebP変換 ②fetchpriority="high"設定 ③サードパーティスクリプトのdefer化。この3つだけでLCP 500ms〜1s改善が見込めます。

自社サイトの現状を確認するには、Pulse DigitalのChrome拡張で診断してみてください。データ送信ゼロ・完全ローカル実行で、ワンクリックでCore Web Vitalsの問題を検出できます。