Pillar Guide · technical-seo

Core Web Vitals 改善完全ガイド 2026年版 — LCP/INP/CLS を実測で改善する技術の教科書

PageSpeed Insights・Lighthouse・CrUX 実測を基に、WordPress/Next.js/Shopify 別に最適化する実装ガイド

Published2026年5月24日32 min read

Index·18セクション

「PageSpeed Insights のスコアは上がったのに、検索順位もコンバージョンも変わらない」「INP だけが赤いままで原因がわからない」 — Core Web Vitals の現場で最もよく聞く声です。CWV は 2020年に導入され、2024年3月に INP が FID を置き換えて以降、安定して 3 指標（LCP / INP / CLS）体制が続いています。Good 判定の閾値も明確で、LCP 2.5 秒以下・INP 200ms 以下・CLS 0.1 以下（75 パーセンタイル）が現在の基準です。本ガイドは 2026 年時点の web.dev 公式仕様と、Tufe Company が Next.js 16 / WordPress / Shopify 案件で実際に踏んだ改善手順を、最短で再現できる形に並べ直しました。

※ 出典: web.dev「Web Vitals」（取得 2026-05） / Google Search Central「Understanding Core Web Vitals and Google search results」（取得 2026-05）

Chapter 1: Core Web Vitals 改善が SEO に与える実影響 — タイブレーカーとしての位置づけ

Google の公式立場：「ランキング要因の 1 つ、ただしタイブレーカー」

社内提案でしばしば誤解されているのは、CWV を「直接的な順位ブースト要因」と扱う説です。Google の検索セントラル公式ドキュメントは、CWV を含むページエクスペリエンス要素について 「コンテンツの関連性と並ぶ要素の 1 つ。同等品質のページが複数ある場合のタイブレーカーとして働く」 と一貫して説明しています。CWV を改善しただけで急に順位が跳ねる、という構図ではありません。

※ 出典: Google Search Central「Understanding Core Web Vitals and Google search results」（取得 2026-05）

逆にこの理解が腑に落ちると、改善優先度の判断はクリアになります。CWV はコンテンツ品質・E-E-A-T・構造化データと「並ぶ」要素として、底上げ的に整える対象です。コンテンツが弱いまま LCP だけ磨いても順位は動きません。

「タイブレーカー」が効く局面は確実に存在する

ではどこに効くか。Tufe Company が現場で観察している効き目は、次の 3 つの局面に集中しています。

競合と差がつきにくい商業ワード — 同等品質のコンテンツがひしめく SERP 環境では、CWV Good がそのまま並び順を分ける材料になる。
モバイル UX が CVR に直結する EC・LP — 順位ではなく、流入後のCVRで効く（後述の RUM 章を参照）。
AI 検索の引用判定 — AI Overview や Perplexity は応答性と表示安定性の指標として実測値を内部で参照していると見られる。引用候補から外れにくいことに直結する。

警戒：俗説と古い数字を持ち込まない

社内・クライアント提案で絶対に使ってはいけない数字を先に潰しておきます。

「LCP が 1 秒遅れると離脱率が 7% 増える」は混同合成 — もとは Akamai 2017 の「CVR が 7%下がる」と、Google/Deloitte 2020 の「離脱率が 32% 増える」という別研究を取り違えた表現が一部の記事で拡散しました。CVR と離脱率は別物です。引用する際は数字と指標を 1 対 1 で照合してください。
「Google が 2.7倍速くなったサイトは収益が 2.7倍」は誤帰属 — 2020年の Deloitte「Milliseconds Make Millions」の業種別事例を、Google 公表値として転載した誤りが出回っています。出典は Deloitte の業界レポートです。
「最初の 3 秒が勝負」は古い俗説 — Nielsen Norman Group の実証では、訪問者が留まるかを判断する中央値は 約 10 秒で、最初の数秒で離脱判断するわけではありません。詳しくは LP コピーリライト vs デザインリライトで扱っています。

※ 出典: Nielsen Norman Group「How Long Do Users Stay on Web Pages?」（取得 2026-05） / Deloitte「Milliseconds Make Millions」（取得 2026-05）

2026 年時点の CWV — 3 指標体制が固まった

2024年3月12日に Google が INP を FID に代わる正式な Core Web Vital として導入して以降、3 指標体制は安定しています。閾値も継続して同一です。

指標	Good	Needs Improvement	Poor	役割
LCP	≤ 2.5 秒	2.5〜4.0 秒	> 4.0 秒	主要コンテンツの表示速度
INP	≤ 200 ms	200〜500 ms	> 500 ms	ユーザー操作への応答性
CLS	≤ 0.1	0.1〜0.25	> 0.25	レイアウトの視覚的安定性

※ 出典: web.dev「Web Vitals」（取得 2026-05） / web.dev「Interaction to Next Paint (INP)」（取得 2026-05）

判定は モバイル/デスクトップそれぞれの 75 パーセンタイルで行われます。「全 PV の上位 75% が Good 閾値以内」が CWV Good ステータスの定義です。平均値で評価しないことに注意してください。

各指標の用語整理は、Core Web Vitals / LCP / INP / CLS / PageSpeed Insights / Lighthouse の各 glossary を参照してください。技術全体像はテクニカル SEO のメインページも併読してください。

Chapter 2: LCP 改善 — 画像・フォント・サーバー応答時間

LCP は「ビューポート内で最も大きな要素の描画完了時刻」

LCP は Largest Contentful Paint の略で、初期ビューポート内に出る最大の画像 / テキストブロック / video ポスターが描画完了するまでの秒数です。Good は 2.5 秒以下、Poor は 4.0 秒超。

LCP を構成する内訳は web.dev が公式に 4 つのサブパートとして整理しています。

TTFB（Time to First Byte） — サーバー応答までの時間
Resource Load Delay — TTFB から LCP 要素のリクエスト開始までの遅延
Resource Load Time — LCP 要素のダウンロード時間
Element Render Delay — ダウンロード完了から実描画までの遅延

※ 出典: web.dev「Optimize LCP」（取得 2026-05）

改善は必ずこの 4 区分のどこがボトルネックかを確認してから着手します。順番を間違えると効きません。

LCP 改善の標準オーダー（Tufe Company の現場手順）

Step 1: LCP 要素を特定する。 PageSpeed Insights の「ラボとフィールドの差を診断する」または Chrome DevTools の Performance タブで「LCP」マーカーがどの要素を指しているかを確認します。多くの場合、ファーストビューのヒーロー画像 / H1 / 商品メインビジュアルです。

Step 2: その要素のロードチェーンを最短化する。 画像なら以下の 5 点が標準対策。

fetchpriority="high" を付与 — Chrome 102 以降サポートのフェッチ優先度ヒント。LCP 要素にだけ付ける（複数付与は逆効果）。
loading="lazy" を絶対に付けない — ファーストビュー画像に lazy load を付けるのは LCP 悪化の典型失敗。
画像形式は AVIF / WebP — JPEG 比で平均 30〜50% 軽量化（web.dev のフォーマット比較で AVIF は同等画質で JPEG より大幅に小さいと報告）。
srcset / sizes でレスポンシブ最適サイズ — モバイルに 4K 画像を配るのは LCP の死。
CDN 経由配信 — オリジンから直接配るのではなく、エッジキャッシュを通す。

※ 出典: web.dev「Use modern image formats: AVIF and WebP」（取得 2026-05）

html

<!-- LCP 画像の推奨実装例 -->
<img
  src="/images/hero-1200.avif"
  srcset="/images/hero-640.avif 640w,
          /images/hero-1024.avif 1024w,
          /images/hero-1600.avif 1600w"
  sizes="(max-width: 768px) 100vw, 1024px"
  alt="Hero illustration"
  width="1200"
  height="630"
  fetchpriority="high"
/>

Step 3: preload / preconnect の正しい配置。 LCP 要素が <link rel="preload"> で最優先取得されるよう <head> に配置します。ただしヒーロー画像の preload は LCP 改善に効くが、無関係な背景画像の preload は逆に他リソースを遅延させるため、対象を絞ります。

html

<head>
  <link rel="preload" as="image" href="/images/hero-1200.avif" fetchpriority="high">
  <link rel="preconnect" href="https://cdn.example.com" crossorigin>
  <link rel="dns-prefetch" href="https://analytics.example.com">
</head>

Step 4: TTFB を削る。 TTFB が 800ms を超えると、その時点で LCP 2.5 秒達成はほぼ不可能になります。対策は (1) サーバー側キャッシュ（Vercel Edge / Cloudflare CDN 経由、エッジレンダリングの活用）、(2) SSG / ISR 化、(3) DB クエリ最適化、(4) 重い Server Component の <Suspense> 切り出し、の順で当たります。

Step 5: フォントの自前ホストと font-display: swap。 Web フォントの読み込みが LCP テキスト要素を遅延させます。@font-face に font-display: swap、可能なら自前ホスト + <link rel="preload" as="font">。

css

@font-face {
  font-family: 'NotoSansJP';
  src: url('/fonts/NotoSansJP-Regular.woff2') format('woff2');
  font-weight: 400;
  font-display: swap;
}

LCP の失敗パターン 1 つ

「lazy load を全画像に付けた結果 LCP が悪化」というのが定番の失敗です。loading="lazy" はファーストビュー外の画像にだけ付ける運用が原則。実装は WordPress プラグイン / Next.js Image コンポーネントが自動で出し分けてくれますが、テンプレ全体に一律で lazy を入れる手動実装が事故の温床になります。

LCP は「ヒーロー画像」で 8 割が片付く

Tufe Company の Next.js 16 案件では、LCP 改善の 8 割が「ヒーロー画像の fetchpriority="high" + AVIF 化 + 適切な sizes」の 3 点で片付きます。残り 2 割は TTFB（多くは DB クエリ / 重い middleware）。先に Step 1（要素特定）をやらず先に「サーバーを Edge に移そう」とすると、たいてい外します。

Chapter 3: INP 改善 — JS 最適化・long task 分割・web worker

INP は「観測されたすべての操作のうち最も遅いもの（の代表値）」

INP は Interaction to Next Paint の略で、ページ滞在中に発生したすべてのユーザー操作（click / tap / キー入力。スクロールは除く）のうち、応答完了までが最も遅い操作の値を 1 ページの代表値として取ります。Good は 200ms 以下、Poor は 500ms 超。

※ 出典: web.dev「Interaction to Next Paint (INP)」（取得 2026-05）

INP は LCP と違い「1 回の出来事の時間」ではなく、ページ滞在中の最悪値を測ります。だから「初期表示は速いがメニュー開閉が重い」「フォーム入力 1 文字ごとに 300ms 固まる」というケースが容赦なく赤になります。

INP の内訳

INP は Input Delay → Processing Time → Presentation Delay の 3 区分。多くの現場で問題になるのは Processing Time（イベントハンドラの JavaScript 実行時間）と Presentation Delay（再レンダリングまでの時間）です。

INP 改善の標準オーダー（Tufe Company の現場手順）

Step 1: ボトルネックを特定する。 Chrome DevTools の Performance タブで Web Vitals プロファイリングを ON にして実際の操作を録画 → 200ms 超のタスクが見える化される。または Web Vitals JavaScript ライブラリで実環境のフィールドデータを集める（Chapter 5 で扱います）。

Step 2: long task の分割。 50ms を超える「long task」は INP の主犯。scheduler.yield()（Chrome 129 以降）か setTimeout(..., 0) でブラウザに制御を返します。

javascript

// 改善前: 重い処理を一気に
function processItems(items) {
  for (const item of items) {
    expensiveWork(item);  // 各 5ms × 100 件 = 500ms long task
  }
}

// 改善後: scheduler.yield() でブラウザに描画機会を返す
async function processItems(items) {
  for (const item of items) {
    expensiveWork(item);
    if (navigator.scheduling?.isInputPending() || 'scheduler' in window) {
      await scheduler.yield();
    }
  }
}

※ 出典: web.dev「Optimize INP」（取得 2026-05）

Step 3: 重い計算は Web Worker に逃がす。 暗号処理 / 大量データ整形 / 画像加工はメインスレッドから Web Worker に移すのが標準。Comlink を使うと API は同期メソッド風に書けます。

Step 4: React の重要技術 — useTransition / useDeferredValue。 React 18+ では非緊急な更新を startTransition で囲むと、ユーザー入力の即時応答が優先されます。

javascript

import { useState, useTransition } from 'react';

function SearchBox() {
  const [input, setInput] = useState('');
  const [results, setResults] = useState([]);
  const [isPending, startTransition] = useTransition();

  const handleChange = (e) => {
    setInput(e.target.value);  // 緊急: 即反映
    startTransition(() => {
      setResults(expensiveSearch(e.target.value));  // 非緊急: yield 可
    });
  };
  return <input value={input} onChange={handleChange} />;
}

Step 5: 第三者スクリプトの遅延読み込み。 チャットウィジェット / アクセス解析 / A/B テストツールの SDK は INP の常連犯です。<script async> ではなく <script defer> または setTimeout で初回操作後にロード、できれば GTM 経由で「初回スクロール後」「初回クリック後」発火に置き換えます。

Step 6: イベントハンドラのデバウンス / スロットル。 input/scroll/resize イベントは lodash.debounce または自前で 100〜300ms デバウンス。requestAnimationFrame でフレーム同期も有効。

INP の失敗パターン 1 つ

「React の再レンダリングを Memo で殺せば INP が直る」という思い込み。React.memo はレンダリング回数を減らすが、1 回の重さは減りません。INP に効くのは useTransition / useDeferredValue / Worker への切り出しの方です。Memo は副作用の管理を複雑化するだけのケースも多く、計測なしの導入は逆効果。

INP は「第三者タグと JS バンドル」で 8 割が決まる

INP は LCP / CLS と違い改善の打率が低い指標です。「いま遅い操作」を一つずつ潰す地道な作業になります。Tufe Company の現場では、最初に第三者タグの整理（半数は不要 / 半数は遅延起動可能）→ React の startTransition 整備 → 重い処理の Worker 化、の順で当たり、200ms 以下に押し込みます。

Chapter 4: CLS 改善 — レイアウト固定・font-display・aspect-ratio

CLS は「予期しないレイアウトシフトの累積スコア」

CLS は Cumulative Layout Shift の略で、ページの可視領域でユーザー操作の直後でない「予期しないレイアウトシフト」が起きるたびに、移動距離 × 影響範囲の積を加算したスコアです。Good は 0.1 以下、Poor は 0.25 超。

※ 出典: web.dev「Cumulative Layout Shift (CLS)」（取得 2026-05）

CLS は 3 指標で改善打率が最も高い指標です。原因が物理的に観察できるからです。

CLS の主な原因 4 つ

サイズ未指定の画像 / 動画 / iframe — 読み込み完了時にレイアウトが押し下げられる
動的に挿入されるバナー / 広告 / 同意ダイアログ — 既存コンテンツが下にズレる
Web フォントの差し替え — FOIT / FOUT による文字幅変動
遅れて読み込まれる CSS / JS による DOM 変更 — Hydration によるコンポーネント差し替え

CLS 改善の標準オーダー（Tufe Company の現場手順）

Step 1: すべてのメディアに width / height または aspect-ratio。 画像・動画・iframe・埋め込み（YouTube / Twitter）には必ずサイズを明示。

html

<!-- 推奨: width/height で aspect ratio を伝える -->
<img src="/hero.avif" width="1200" height="630" alt="...">

<!-- もしくは CSS で aspect-ratio -->
<style>
  .video-wrap { aspect-ratio: 16 / 9; width: 100%; }
</style>

Step 2: フォントの swap 戦略。 font-display: swap を入れるとフォント置換時に文字幅が変わり CLS の原因になります。size-adjust / ascent-override でフォールバックフォントを近似サイズに整形するのが 2026 年の正解。

css

@font-face {
  font-family: 'NotoSansJP-fallback';
  src: local('Hiragino Sans'), local('Yu Gothic');
  size-adjust: 100%;
  ascent-override: 95%;
  descent-override: 22%;
  line-gap-override: 0%;
}

body {
  font-family: 'NotoSansJP', 'NotoSansJP-fallback', sans-serif;
}

Next.js の next/font を使うと自動で同等の処理が入ります。WordPress / Shopify は手動設定。

Step 3: 広告・バナーの予約スペース確保。 Google AdSense 等の広告枠は読み込み前に min-height で枠を確保します。「広告サイズが決まらないから固定できない」場合は min-height: 250px 等で最低スペースを取り、空欄でも見栄えする背景色を当てます。

Step 4: 動的注入される要素は transform で動かす。 CTA ポップアップ / トースト通知などは top / left 変更ではなく transform: translate() を使うと、レイアウト計算が走らず CLS にカウントされません。

Step 5: 同意ダイアログ / Cookie バナーは画面下端固定。 上端や中央に出すと既存コンテンツがズレます。position: fixed; bottom: 0; で表示し、メインコンテンツに padding-bottom を当てておきます。

CLS の失敗パターン 1 つ

「画像に CSS で max-width をパーセント指定しているからサイズ指定は不要」という勘違い。max-width は最大幅を制限するだけで、ブラウザは実画像をダウンロードするまで縦横比を計算できません。width / height 属性または CSS の aspect-ratio を明示しないと、画像読み込み完了時にレイアウトが必ず押し下げられます。

CLS は「width/height・size-adjust・transform」の 3 点セット

Tufe Company の CLS 改善は、ほぼ「全画像・iframe に width/height 付与」「フォントの size-adjust」「ポップアップを transform に書き直す」の 3 点でカタが付きます。コードレビュー時に CLS 関連ルールを ESLint プラグイン（jsx-a11y 系 + 自前ルール）で機械検出にすると、再発がなくなります。

Chapter 5: 計測ツール — PageSpeed Insights / CrUX / RUM / Web Vitals JS

「ラボデータ」と「フィールドデータ」を区別する

CWV 改善の最大のつまずきは、ラボデータ（合成計測）とフィールドデータ（実ユーザー計測）を混同することです。

区分	ツール	計測対象	用途
ラボデータ	Lighthouse / PageSpeed Insights ラボ	単一の環境で合成計測	開発・改善仮説の検証
フィールドデータ	CrUX / PSI フィールド / RUM	実ユーザーの実環境	Google の評価対象

Google のランキング判定に使われるのは CrUX（Chrome User Experience Report）のフィールドデータのみです。Lighthouse スコアは開発時の指標であって、評価値そのものではありません。

※ 出典: Google Search Central「Understanding Core Web Vitals and Google search results」（取得 2026-05） / Chrome Developers「CrUX」（取得 2026-05）

主要ツールの使い分け

PageSpeed Insights（PSI） — 単一 URL のラボ + フィールドを横並びで見られる Google 公式の入り口。最初に開くべきツール。https://pagespeed.web.dev/ で URL を入れるだけ。

Lighthouse — Chrome DevTools の Lighthouse タブ、または npx lighthouse <url> で CLI。ラボデータの詳細監査用。CI に組み込んで PR 単位でスコア劣化を検出する用途で必須。

CrUX Dashboard — Looker Studio テンプレートで、サイト全体の CWV を時系列で見られる無料ツール。URL: https://lookerstudio.google.com/c/u/0/reporting/55bc8fad-44c2-4280-aa0b-5f3f0cd3d2be/page/M6ZPC。月次レポートはこれをスクショで貼るのが定番。

Search Console > エクスペリエンス > Core Web Vitals レポート — 自社サイトの全 URL を「Good / Needs Improvement / Poor」で分類し、URL 単位で問題を出してくれる。継続監視の本丸。

RUM（Real User Monitoring） — 自前で計測するなら web-vitals JavaScript ライブラリ（Web Vitals の公式 SDK）を仕込んで GA4 や独自エンドポイントに送る。Vercel Analytics・SpeedCurve・Sentry Performance などの SaaS も選択肢。

javascript

// web-vitals v4 で 4 指標を GA4 に送る最小実装
import { onCLS, onINP, onLCP, onFCP, onTTFB } from 'web-vitals';

function sendToAnalytics({ name, value, id }) {
  window.gtag?.('event', name, {
    value: Math.round(name === 'CLS' ? value * 1000 : value),
    metric_id: id,
    metric_value: value,
    metric_delta: value,
    non_interaction: true,
  });
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);

計測ワークフローの推奨

PSI で URL レベルの初診 — 主要 5〜10 URL を毎月測定。
Search Console エクスペリエンスで全体俯瞰 — URL 単位の問題を月次で潰す。
CrUX Dashboard で 28 日移動平均をトラッキング — 改善施策の効果を時系列で見る。
RUM で実ユーザー分布の見える化 — 75 パーセンタイル以外の分布も追う。
Lighthouse CI で PR 単位の劣化検出 — デプロイ前に新規劣化を止める。

失敗パターン：「Lighthouse 100 点なのに Search Console は赤」

これは正常。Google が見ているのは別の場所。Lighthouse はラボ計測、Search Console はフィールド計測で、判定対象そのものが違います。順位評価に効くのは Search Console / CrUX 側だけ。Lighthouse 100 点は開発時の参考値として扱い、改善完了の判定は必ずフィールド側で取る。

Tufe Company の現場では、Lighthouse 95+ / PSI フィールド Good を両立させて初めて「改善完了」と判定します。詳しい計測ツールの選定は GA4 vs GSC も併読してください。

Chapter 6: WordPress 特化 — プラグイン構成・LiteSpeed Cache・画像最適化

WordPress は世界の Web サイトの過半数で使われている CMS で、CWV 改善のリクエストも最多です。一方で「プラグインを入れすぎて遅い」「テーマが古い」など、典型的なボトルネックが集中する場所でもあります。技術的な乗り換え判断軸は WordPress vs Next.js を先に押さえると、本章の改善優先度が立てやすくなります。

WordPress 改善の標準スタック（Tufe Company 推奨）

レイヤー	推奨	理由
ホスティング	エックスサーバー / ConoHa WING / Kinsta / WP Engine	PHP 8.2+ / OPcache / HTTP/3 対応
キャッシュ	LiteSpeed Cache（LiteSpeed サーバー時）/ WP Rocket / W3 Total Cache	フルページキャッシュ + Critical CSS
画像最適化	EWWW Image Optimizer / Smush / ShortPixel	WebP / AVIF 自動変換 + lazy load
CDN	Cloudflare（無料プラン可） / KeyCDN / BunnyCDN	エッジキャッシュ + HTTP/3
不要 JS 削減	Asset CleanUp / Perfmatters	ページ別に不要 CSS/JS を停止

LiteSpeed Cache の最小設定

LiteSpeed Cache は無料で機能豊富。最初に押さえる設定。

Cache > Cache: ON — フルページキャッシュ
Cache > Browser: ON — ブラウザキャッシュ
Page Optimization > CSS Settings: CSS Minify ON / CSS Combine OFF（HTTP/2 環境では Combine は逆効果）
Page Optimization > JS Settings: JS Defer ON（外部 JS をできるだけ defer）
Page Optimization > Media Settings: Lazy Load Images ON（ファーストビューは除外設定推奨）
Page Optimization > VPI: Viewport Image Generate ON — ファーストビュー画像を自動判定して lazy load を外す

プラグイン削減が最大の効き目

実際のところ「LiteSpeed Cache を設定する」より「不要プラグインを 20 個削除する」方が効くケースが大半です。Tufe Company の現場では、初診時に必ず以下をチェックします。

インストール済みプラグインで過去 6 ヶ月使われていないものは削除
「人気記事」「関連記事」系プラグインは DB クエリが重い → キャッシュ可なものに置き換え
セキュリティプラグイン（All In One WP Security 等）は管理画面以外で動作不要なものを停止
お問い合わせフォームを Contact Form 7 → CF7 ベースの軽量化または Formidable / Gravity Forms に再検討

Avada / Elementor / Divi 系テーマの注意

ページビルダー系テーマは初期描画の JS 量が極端に多く、INP・LCP の両方を悪化させます。完全な乗り換えが難しい場合は、以下の局所最適化が現実解。

GeneratePress / Astra など軽量テーマへの段階移行（テンプレ単位）
Elementor の Performance > Improved Asset Loading: ON
Divi の Performance > Dynamic Module Framework / Critical CSS: ON
Avada はビルダーの「Performance Wizard」を実行

詳しい WordPress vs Next.js / Shopify の判断軸は WordPress vs Next.js と WordPress vs Shopify で扱っています。

WordPress 移行を検討すべきライン

Tufe Company の現場経験では、以下のいずれかに当てはまる場合は WordPress 改善より Next.js や Headless への移行検討が現実的です。

インストール済みプラグインが 40 個以上
テーマが PHP 7.x 時代のもので、互換のために古い PHP を維持している
DB サイズが 1GB を超えてクエリが遅い
LCP が改善後も 4 秒を切らない（モバイル）

詳しくは Web 制作サービスまたは WordPress リライトで。

Chapter 7: Next.js 特化 — Image / Font / Suspense / streaming SSR

Next.js はパフォーマンス最適化機能が一級品で、デフォルトで CWV Good を達成しやすい技術スタックです。ただし何も考えずに書くと逆に遅くなる落とし穴もあります。

Next.js 16 で押さえる最適化レイヤー

レイヤー	機能	効く指標
Image	`next/image` で自動 lazy / WebP・AVIF 変換 / `sizes` 自動最適化	LCP / CLS
Font	`next/font` で自前ホスト + size-adjust 自動	LCP / CLS
Suspense	コンポーネント単位の streaming（Hydration を段階化）	LCP / TTFB
Server Components	クライアント JS を減らす	INP
Edge Runtime	リージョン近接化（エッジレンダリング）	TTFB / LCP
ISR	静的配信 + 背面再生成	TTFB / LCP
Partial Prerendering	静的シェル + 動的部分の段階配信	LCP / TTFB

`next/image` の正しい使い方

next/image の肝は「LCP 要素 1 つだけに priority を立て、残りは何も足さず default の lazy に任せる」ことです。次のスニペットは、Tufe Company が初診の Next.js リポジトリで真っ先に置き換える最小形です。

tsx

// 推奨: app/page.tsx
import Image from 'next/image';
import hero from '../public/hero.jpg';

export default function Page() {
  return (
    <Image
      src={hero}
      alt="..."
      priority             // LCP 画像にだけ
      sizes="(max-width: 768px) 100vw, 1024px"
      placeholder="blur"   // 自動 blurDataURL
      className="w-full h-auto"
    />
  );
}

ポイントは priority を LCP 要素にだけ付けること。すべての画像に付けると優先度の意味が消えます。

`next/font` で CLS を自動回避

手書きの @font-face で size-adjust まで詰めるのは骨が折れますが、next/font は同等の処理をビルド時に勝手にやってくれます。app/layout.tsx に 10 行入れるだけでフォント由来の CLS が事実上消えるので、改修着手の最初の 10 分で必ず置き換えてください。

tsx

// app/layout.tsx
import { Noto_Sans_JP } from 'next/font/google';

const noto = Noto_Sans_JP({
  subsets: ['latin'],
  display: 'swap',
  weight: ['400', '700'],
  variable: '--font-noto',
});

export default function RootLayout({ children }) {
  return (
    <html lang="ja" className={noto.variable}>
      <body>{children}</body>
    </html>
  );
}

next/font は自動で size-adjust / ascent-override を計算してフォールバックフォントを近似してくれるため、フォント差し替えによる CLS がほぼゼロになります。手動 @font-face を書いていたら、まずここを置き換えるだけで CLS が改善します。

Server Components で JS を減らす

Next.js 13+ の App Router では、デフォルトで全てのコンポーネントが Server Component です。'use client' を書いた瞬間に JS バンドルに乗ることを意識します。INP 改善の本丸は 「クライアントに送る JS をできるだけ減らす」 ことであり、Server Components はそのための最強の道具です。

Suspense で streaming SSR

ページ全体を最遅 API に合わせて待たせるのを、<Suspense> の境界で「速いところだけ先に流す」設計に書き換えます。下の最小サンプルは、Hero を即配信しつつ重い商品リストだけスケルトンで先送りする標準パターンです。

tsx

import { Suspense } from 'react';

export default function Page() {
  return (
    <>
      <Hero />                              {/* 即座にストリーミング */}
      <Suspense fallback={<Skeleton />}>
        <SlowProductList />                 {/* DB 取得を待つ間も Hero は表示 */}
      </Suspense>
    </>
  );
}

重い DB 取得をする部分を <Suspense> で囲むと、Hero 部分の HTML が先に届き LCP が速くなる。重い API 呼び出しがあるページでは必ず使う技。

Next.js 16 + Vercel での Tufe Company 実測

Tufe Company の自社サイト（本 guide が掲載されているサイト）の主要ページの CrUX 計測値は次の通りです。

ページ	LCP	INP	CLS
トップ	≈ 1.4 秒	≈ 90 ms	≈ 0.01
/guides	≈ 1.6 秒	≈ 110 ms	≈ 0.02
/market	≈ 1.8 秒	≈ 130 ms	≈ 0.03

※ Tufe Company 内部実測 / 2026-05時点。Vercel デプロイメント、東京リージョン、PageSpeed Insights モバイル計測値。3 ページとも 3 指標 Good。

Next.js でやりがちな失敗

全部 Client Component 化 — 'use client' を最上位に書くと配下が全部クライアント JS に乗り INP 悪化
fetch の cache を無効化しすぎ — cache: 'no-store' を全 API に付けると ISR / SSG の旨味がゼロ
画像を <img> で直接書く — next/image の最適化が一切効かない
use client 内で巨大ライブラリ import — moment.js / lodash 全量 import などはバンドルを膨らませる

詳しい Next.js vs WordPress / Headless の選び方は Headless CMS vs WordPress プラグイン LLMO、SSR の選択肢は SSG vs SSR を参照。

Chapter 8: Shopify 特化 — テーマ最適化・アプリ過剰実装の弊害

Shopify は EC 専用 SaaS で、サーバー・CDN・基盤は Shopify が管理するため WordPress のような根本的速度差は出にくい一方、「アプリの入れすぎ」と「テーマの古さ」が CWV を確実に殺します。

Shopify CWV 改善の優先順位

不要アプリのアンインストール — アプリは Liquid テンプレに JS タグを差し込むため、入れた分だけ確実に遅くなる
テーマの世代を最新化 — Online Store 2.0 対応テーマ（Dawn / Sense / Refresh 等）はパフォーマンス設計が一段違う
Liquid の N+1 クエリ排除 — {% for product in collection.products %} 内で product.images 全件を読むなど
画像の手動最適化 — Shopify CDN は WebP 自動配信するが、元画像が巨大だと意味がない
第三者タグの GTM 一元化 — Klaviyo / Recart / Privy などのウィジェットは GTM 経由で遅延起動

Shopify でアプリを評価する 3 つの観点

テーマファイルへの注入有無 — 「テーマファイルを編集します」と聞かれるアプリは、削除しても Liquid 改変が残る。事前に backup 必須。
管理画面以外で JS を発火するか — 多くのアプリは全ページで JS を読み込む。フロント不要のアプリは即削除。
代替の Shopify 標準機能で済むか — レビューアプリの一部は Shopify Reviews（無料）で代替可、決済アプリの一部は Shopify Payments の機能で代替可。

Dawn テーマ（Shopify 公式）の標準パフォーマンス

Shopify 公式の Dawn テーマは Lighthouse 90+ で出荷されており、特別な改造を加えなければ CWV Good を達成しやすい設計です。OS 2.0 系テーマに乗り換えるだけで LCP / INP が一気に改善するケースが多くあります。

Shopify でやりがちな失敗

「アプリで全部解決」してテンプレを触らない — 結局アプリ群が JS を撃ち合って INP 悪化
画像を Liquid で 16:9 と 1:1 を切り替えるだけで width / height 指定なし → CLS 悪化
{{ 'app.js' | asset_url | script_tag }} で読み込んだ JS を defer せず
メイン商品画像に loading="lazy" が入っている（Dawn 派生テーマでも稀に発生）

EC で外せない関連最適化

EC の CWV は 商品詳細ページ（LCP / CLS） と カート画面（INP） の 2 箇所が最重要です。詳しくは EC × Product page vs Category page CVR・EC × Business SEO・EC × LLMO で扱っています。WordPress vs Shopify の選択は WordPress vs Shopify を参照。

Chapter 9: よくある失敗 10 パターン

CWV 改善で「改善したつもりで悪化する」失敗を、再現性順に 10 個に整理しました。チェックリスト的に使ってください。

無効な preload — 使われない / 重複する <link rel="preload"> を増やすと、本来 LCP 要素に回るはずの帯域を食い、逆に LCP が悪化。preload するのは LCP 要素 + 主要フォントの 2 種だけが原則。
全画像 lazy load — ファーストビューのヒーロー画像に loading="lazy" を付けると LCP が確実に悪化。テンプレ一括設定の事故が多発。
画像の width / height 省略 — 「CSS で max-width をパーセント指定してるから不要」は誤り。ブラウザは実画像 DL までサイズを計算できず CLS が出る。
Lighthouse スコアだけ追って CrUX を無視 — Google の評価対象はフィールドデータ。Lighthouse 100 点でも Search Console は赤、という現象は頻発する。
第三者タグの整理を後回し — Analytics / 広告 / チャット / A/B / レビューで 10〜30 タグが入っていることがあり、INP の主犯。GTM 経由で初回操作後発火に置き換える。
CSS の @import 多用 — @import は逐次読み込みでブロッキング。<link> 並列読み込み + Critical CSS インライン化が正解。
動的注入バナーで CLS 悪化 — Cookie バナー / キャンペーン告知 / 同意ダイアログを画面上端・中央に動的挿入するとレイアウトが押し下げられる。position: fixed + 画面端配置が原則。
LCP 改善で loading="eager" を全画像に — eager は lazy の逆で全部を即時ロード。帯域を浪費して LCP 含む全体が遅くなる。本当に必要なのは LCP 1 要素だけ。
「LCP 1 秒で離脱率 7% 増える」を社内提案で引用 — Akamai 2017 の CVR 7% 低下 と Google/Deloitte 2020 の 離脱率 32% 増加 を混同した古い俗説。指標と数字を 1 対 1 で照合せずに使うと、クライアント前で必ず指摘される。
CWV 改善で順位が即上がる前提で経営報告 — Google は「タイブレーカー」と公式表現。CWV 単独での順位ブースト効果は限定的で、コンテンツ品質と並ぶ底上げ要素として位置づける。経営報告は CVR・離脱率・AI 引用率の改善とセットで。

※ 出典: web.dev「Optimize LCP」（取得 2026-05） / Google Search Central「Understanding Core Web Vitals and Google search results」（取得 2026-05）

Chapter 10: Tufe Company の実装事例と支援領域

ここまで自分で next.config を書き直し、第三者タグを GTM 経由で整理し、CrUX Dashboard を月次で追えるなら、本章は読み飛ばしてください。実装はわかったが手を動かす時間が無い・既存サイトに穴があるか棚卸ししたい、という場合の窓口だけ用意しておきます。

Tufe Company 自社サイトの実装スタック（参考）

基盤: Next.js 16 (App Router) + React Server Components + Partial Prerendering
ホスティング: Vercel（東京リージョン）
画像: next/image + AVIF 自動変換 + Vercel Image Optimization
フォント: next/font で Noto Sans JP 自前ホスト + size-adjust 自動
計測: Vercel Analytics（RUM）+ Search Console エクスペリエンス + PSI 月次
CI: Lighthouse CI で PR 単位の劣化検出

主要 3 ページの実測値は Chapter 7 に掲載。3 指標とも Good ステータスを継続中です（※ Tufe Company 内部実測 / 2026-05時点）。

段階別の支援メニュー

フェーズ	Tufe Company の打ち手	価格・形態
現状把握（無料）	Web CVR 監査ツール	無料
書面で診る	CVR リライトレポート	単発（市場ページ参照）
AI 検索健全度も含めて診る	AI Search Health Check	¥14,800（単発）
WordPress を本気で速くする	WordPress リライト	月次契約（要見積）
Next.js へリプレース	Web 制作（Next.js 移行）	案件単位
個別相談	無料相談（45 分・オンライン・契約前提ではない）	無料

「いきなりサービスを契約する」必要は無いように設計しています。まずは PageSpeed Insights で自社サイトを 1 ページ診断、Search Console のエクスペリエンスレポートで赤の URL を確認、それでも改善方針が立たなければ Web CVR 監査ツールに URL を入れる、という順番で十分です。

CWV 改善 30 項目チェックリスト

公開前 / 改修前 / 月次レビューでこの 30 項目を 1 つずつ潰してください。

LCP（10 項目）

INP（10 項目）

CLS（10 項目）

コピペで使える最適化スニペット集

next.config.ts 最適化スニペット

「とりあえずこの設定を入れておけば外さない」最小セットです。AVIF/WebP 自動配信、静的アセットの 1 年キャッシュ、Next.js 16 の Partial Prerendering 有効化までを 1 ファイルに集約しています。

typescript

import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048, 3840],
    imageSizes: [16, 32, 48, 64, 96, 128, 256, 384],
    minimumCacheTTL: 60 * 60 * 24 * 7, // 7 日キャッシュ
  },
  compress: true,
  poweredByHeader: false,
  productionBrowserSourceMaps: false,
  experimental: {
    optimizePackageImports: ['lucide-react', 'date-fns', 'lodash'],
    // Partial Prerendering（Next.js 16）
    ppr: 'incremental',
  },
  async headers() {
    return [
      {
        source: '/:all*(svg|jpg|jpeg|png|webp|avif|woff2)',
        headers: [
          {
            key: 'Cache-Control',
            value: 'public, max-age=31536000, immutable',
          },
        ],
      },
    ];
  },
};

export default nextConfig;

Image コンポーネント最適化パターン（LCP 画像専用）

tsx

import Image from 'next/image';

// LCP 画像（ファーストビュー大型画像）
<Image
  src="/hero.jpg"
  alt="..."
  width={1200}
  height={630}
  priority                                       // LCP 要素にだけ
  sizes="(max-width: 768px) 100vw, 1200px"
  quality={85}
  placeholder="blur"
/>

// ファーストビュー外画像（自動 lazy）
<Image
  src="/section.jpg"
  alt="..."
  width={800}
  height={450}
  loading="lazy"                                 // default だが明示
  sizes="(max-width: 768px) 100vw, 800px"
/>

web-vitals + GA4 計測スニペット

Chapter 5 の sendToAnalytics をベースに、各ページの app/layout.tsx で読み込めばサイト全体の RUM が始まります。

公的・一次情報リソース集

社内 Slack に貼って共有してください。

Google / web.dev 公式

web.dev「Web Vitals」 — 3 指標の定義と閾値
web.dev「Optimize LCP」 — LCP 改善の総合ガイド
web.dev「Interaction to Next Paint (INP)」 — INP の仕様
web.dev「Optimize INP」 — INP 改善の総合ガイド
web.dev「Cumulative Layout Shift (CLS)」 — CLS の仕様
web.dev「Optimize CLS」 — CLS 改善の総合ガイド
Google Search Central「Understanding Core Web Vitals and Google search results」 — Google の公式立場
Chrome User Experience Report (CrUX) — フィールドデータ公開仕様

計測ツール

PageSpeed Insights — 単一 URL のラボ + フィールド
Lighthouse — ラボ計測の本丸
CrUX Dashboard（Looker Studio テンプレ） — サイト全体の CrUX 時系列
Search Console — エクスペリエンス > Core Web Vitals
web-vitals JavaScript library — RUM 実装の公式 SDK

Next.js / WordPress / Shopify 公式

まとめ — 5 つの要点

CWV はタイブレーカー — Google 公式立場。直接ブースト効果は限定的で、コンテンツ品質と並ぶ底上げ要素。
3 指標体制が固まった — LCP 2.5s / INP 200ms / CLS 0.1 が Good 閾値（75 パーセンタイル）。
ラボとフィールドを区別 — 評価対象は CrUX のフィールドデータ。Lighthouse スコアは開発時の参考値。
改善打率は CLS > LCP > INP — CLS は機械的に潰せる。INP は地道に第三者タグと long task を削る。
「改善したつもりで悪化」を避ける — preload 乱用 / 全画像 lazy / loading="eager" 全付与は典型失敗。Chapter 9 の 10 パターンで毎月セルフチェック。

よくある質問

Q. Core Web Vitals を改善すれば検索順位は上がりますか？

CWV 単独で順位を直接ブーストする効果は限定的、と Google は公式に説明しています。「コンテンツの関連性と並ぶ要素の 1 つで、同等品質のページが複数ある場合のタイブレーカーとして働く」というのが正確な位置づけです。CVR や AI 検索引用率の改善とセットで効くものとして経営報告するのが現実的です。詳しくは Chapter 1（CWV が SEO に与える実影響）を参照してください。

※ 出典: Google Search Central「Understanding Core Web Vitals and Google search results」（取得 2026-05）

Q. PageSpeed Insights のラボデータと Search Console のフィールドデータが一致しません。どちらを信じるべきですか？

Google の評価対象は Search Console / CrUX のフィールドデータです。Lighthouse / PSI のラボデータは開発時の参考値で、両者が一致しないのは仕様通りの正常動作です。改善判定は Search Console / CrUX で行い、Lighthouse は CI で劣化検出する用途に使い分けてください。詳しくは Chapter 5（計測ツール）を参照してください。

Q. INP の改善が一番難しいと聞きますが、何から手を付ければ良いですか？

第三者タグの整理 → React の useTransition 整備 → 重い処理の Web Worker 化、の順が Tufe Company の現場標準です。第三者タグ（Analytics / 広告 / チャット / A/B / レビュー）は半数が不要、半数が GTM 経由で初回操作後発火に置き換え可能なケースが多くあります。詳しくは Chapter 3（INP 改善）を参照してください。

Q. WordPress と Next.js、どちらが Core Web Vitals 達成しやすいですか？

技術的には Next.js が圧倒的に有利ですが、WordPress でも適切な設定で Good 達成は可能です。Tufe Company の判断基準は「インストール済みプラグインが 40 個以上 / テーマが古い PHP 依存 / DB が 1GB 超」のいずれかに該当する場合は Next.js / Headless への移行検討、それ以外は WordPress 改善で十分、というラインです。詳しくは Chapter 6（WordPress）/ Chapter 7（Next.js）と WordPress vs Next.js を参照してください。

Q. Shopify でアプリを減らせと言われましたが、どれを残せば良いですか？

評価の 3 観点は (1) テーマファイルへの注入有無、(2) 管理画面以外で JS を発火するか、(3) Shopify 標準機能で代替可能か。フロントエンドで動かないアプリ、6 ヶ月以上未使用のアプリ、レビュー / 決済 / メール配信などで標準機能で代替できるアプリは即削除候補です。詳しくは Chapter 8（Shopify 特化）を参照してください。

Keywords

#Core Web Vitals#LCP#INP#CLS#PageSpeed Insights#Lighthouse#Next.js パフォーマンス#WordPress 高速化#Shopify 最適化#テクニカルSEO

Authored & Reviewed By

Tufe Company

Engineering

公開2026年5月24日

執筆者ページを見る

§ Tufe Market

このトピックに効く、即購入できる成果物

読んでいるトピックと相性のよい、Tufe の即時納品プロダクト。問い合わせ不要、その場で買って導入できます。

Bundle

Industry SEO

8 業種から 1 業種を選択 → KW 設計 30 / 記事構成 30 本（詳細 10 + ライト 20）/ サイト構造 / JSON-LD 3 種 / E-E-A-T 30 項 / 失敗パターン 8 / 12 ヶ月ロードマップを即時生成。規制業種は薬機法・医療広告・弁護士法等に準拠。

¥6,980詳細 →

Instant

Schema Library

業種を選ぶと、JSON-LD 12 種（Organization / LocalBusiness / Service / Product / FAQ / HowTo / Article / Event / BreadcrumbList / Person / Review / AggregateRating）を会社情報入りで AI が即時生成。WordPress (functions.php) / Next.js / 静的 HTML 対応。

¥2,980詳細 →

Instant

AI Search Pack

URLを入れるだけで llms.txt / robots.txt / 構造化データを即時生成。AI検索（ChatGPT・Claude・Perplexity・Gemini）に引用される土台を最短で整備。

¥2,980詳細 →

Tufe Market 全12商品を見る料金一覧

— Ready to Implement?

本気で成果を出したい方へ。

Tufe Companyが戦略立案から実装までワンストップで支援します。まずは無料相談で現状ヒアリングから。

無料で相談する無料ツールを試す

完全ガイド一覧に戻る

Core Web Vitals 改善 完全ガイド 2026年版 — LCP/INP/CLS を実測で改善する技術の教科書

Chapter 1: Core Web Vitals 改善が SEO に与える実影響 — タイブレーカーとしての位置づけ

Google の公式立場：「ランキング要因の 1 つ、ただしタイブレーカー」

「タイブレーカー」が効く局面は確実に存在する

警戒：俗説と古い数字を持ち込まない

2026 年時点の CWV — 3 指標体制が固まった

Chapter 2: LCP 改善 — 画像・フォント・サーバー応答時間

LCP は「ビューポート内で最も大きな要素の描画完了時刻」

LCP 改善の標準オーダー（Tufe Company の現場手順）

LCP の失敗パターン 1 つ

LCP は「ヒーロー画像」で 8 割が片付く

Chapter 3: INP 改善 — JS 最適化・long task 分割・web worker

INP は「観測されたすべての操作のうち最も遅いもの（の代表値）」

INP の内訳

INP 改善の標準オーダー（Tufe Company の現場手順）

INP の失敗パターン 1 つ

INP は「第三者タグと JS バンドル」で 8 割が決まる

Chapter 4: CLS 改善 — レイアウト固定・font-display・aspect-ratio

CLS は「予期しないレイアウトシフトの累積スコア」

CLS の主な原因 4 つ

CLS 改善の標準オーダー（Tufe Company の現場手順）

CLS の失敗パターン 1 つ

CLS は「width/height・size-adjust・transform」の 3 点セット

Chapter 5: 計測ツール — PageSpeed Insights / CrUX / RUM / Web Vitals JS

「ラボデータ」と「フィールドデータ」を区別する

主要ツールの使い分け

計測ワークフローの推奨

失敗パターン：「Lighthouse 100 点なのに Search Console は赤」

Chapter 6: WordPress 特化 — プラグイン構成・LiteSpeed Cache・画像最適化

WordPress 改善の標準スタック（Tufe Company 推奨）

LiteSpeed Cache の最小設定

プラグイン削減が最大の効き目

Avada / Elementor / Divi 系テーマの注意

WordPress 移行を検討すべきライン

Chapter 7: Next.js 特化 — Image / Font / Suspense / streaming SSR

Next.js 16 で押さえる最適化レイヤー

next/image の正しい使い方

next/font で CLS を自動回避

Server Components で JS を減らす

Suspense で streaming SSR

Next.js 16 + Vercel での Tufe Company 実測

Next.js でやりがちな失敗

Chapter 8: Shopify 特化 — テーマ最適化・アプリ過剰実装の弊害

Shopify CWV 改善の優先順位

Shopify でアプリを評価する 3 つの観点

Dawn テーマ（Shopify 公式）の標準パフォーマンス

Shopify でやりがちな失敗

EC で外せない関連最適化

Chapter 9: よくある失敗 10 パターン

Chapter 10: Tufe Company の実装事例と支援領域

Tufe Company 自社サイトの実装スタック（参考）

段階別の支援メニュー

CWV 改善 30 項目チェックリスト

LCP（10 項目）

INP（10 項目）

CLS（10 項目）

コピペで使える最適化スニペット集

next.config.ts 最適化スニペット

Image コンポーネント最適化パターン（LCP 画像専用）

web-vitals + GA4 計測スニペット

公的・一次情報リソース集

Google / web.dev 公式

計測ツール

Next.js / WordPress / Shopify 公式

まとめ — 5 つの要点

よくある質問

Q. Core Web Vitals を改善すれば検索順位は上がりますか？

Q. PageSpeed Insights のラボデータと Search Console のフィールドデータが一致しません。どちらを信じるべきですか？

Q. INP の改善が一番難しいと聞きますが、何から手を付ければ良いですか？

Q. WordPress と Next.js、どちらが Core Web Vitals 達成しやすいですか？

Q. Shopify でアプリを減らせと言われましたが、どれを残せば良いですか？

このトピックに効く、即購入できる成果物

本気で成果を出したい方へ。

Core Web Vitals 改善完全ガイド 2026年版 — LCP/INP/CLS を実測で改善する技術の教科書

`next/image` の正しい使い方

`next/font` で CLS を自動回避