Core Web Vitals改善の実務手順｜Next.jsチェックリスト

Core Web Vitalsの数値改善を任された情シス担当者にとって、「何から手を付ければいいか」が最初のつまずきどころだと感じています。この記事は総論ではなく、実際に確認すべき項目を順番に並べたチェックリストとして使えるようにまとめました。

この記事で分かること

• LCP・INP・CLSをNext.jsのどの機能で改善できるか
• 改善作業を進める順番（優先度の付け方）
• 計測から改善、再計測までの実務フロー

自社サイトやWebアプリの表示速度についてGoogle Search Consoleやユーザーから指摘を受け、対応を求められている情シス担当者の方に向けて書いています。

なぜパフォーマンス改善は後回しにされがちなのか

パフォーマンス改善は「壊れているわけではない」ため、他の開発タスクより優先度が下がりやすいという事情があります。しかし、Core Web Vitalsは検索順位に影響する評価指標であり、放置すると離脱率にもじわじわ響いてきます。中小企業の限られた開発リソースでは、闇雲に手を付けるのではなく、影響の大きい項目から順に着手することが重要です。

なお、Next.js 16の新機能全般やパフォーマンスの考え方の全体像についてはNext.js 16の新機能とパフォーマンス最適化で扱っています。この記事はその総論を前提に、実務で手を動かす際の具体的な手順に絞って解説します。

何から計測すればいいか

改善の前に、まず現状を数値で把握します。

1. Google Search Consoleの「ウェブに関する主な指標」で問題ページを一覧化する
2. PageSpeed Insightsで代表ページのLCP・INP・CLSの実測値（フィールドデータ）を確認する
3. Lighthouseのラボデータと実測値を混同しない（シミュレーション値は参考程度に留める）

実測値と計測環境によるシミュレーション値には差が出ることがあるため、まずは実際のユーザー環境に近いフィールドデータを優先して見ることをおすすめします。

LCPをどう改善するか

LCP（Largest Contentful Paint）は、画面内で最も大きな要素が表示されるまでの時間です。改善の優先順位は次の通りです。

1. 画像最適化を確認する

next/imageコンポーネントを使っているか、priority属性がファーストビューの画像に設定されているかを確認します。使っていない画像タグが残っている場合、最も効果が出やすい改善ポイントです。

2. サーバーコンポーネントとキャッシュ戦略を見直す

Next.js 16では'use cache'ディレクティブでコンポーネント単位・関数単位のキャッシュ戦略を柔軟に組めます。頻繁に更新されないデータを扱うページでは、キャッシュの効かせ方一つでLCPが大きく変わります。

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

next/fontを使ってフォントを自己ホストし、レイアウトシフトと読み込み遅延を同時に抑えます。

INPをどう改善するか

INP（Interaction to Next Paint）はユーザー操作への応答性を測る指標です。

• クライアントコンポーネントの範囲を最小限にする（Server Componentsで完結できる部分はサーバー側に留める）
• 重いJavaScript処理はuseTransitionなどで優先度を下げる
• サードパーティスクリプト（アクセス解析タグ等）はnext/scriptのstrategyをafterInteractiveやlazyOnloadに設定する

Turbopackがビルド速度の改善に寄与する一方、実行時のINPは主にクライアント側のJS実行量に左右される点に注意が必要です。

CLSをどう改善するか

CLS（Cumulative Layout Shift）はレイアウトのズレを測る指標です。

• 画像・動画には必ずwidth・height（またはaspect-ratio）を指定する
• 動的に挿入される広告やバナーには、あらかじめ領域を確保しておく
• Webフォント読み込み時のフォールバックフォントとのサイズ差をnext/fontのadjustFontFallbackで吸収する

改善後の確認フロー

改善を反映したら、以下の順序で再確認します。

1. ステージング環境でLighthouseを実行し、ラボデータで劣化がないか確認
2. 本番反映後、1〜2週間はSearch Consoleのフィールドデータの推移を観察する
3. 改善しなかった項目は、計測方法自体が正しいか（ボット除外設定など）を疑う

サーバー側のレスポンスタイムはどう改善するか

Core Web Vitalsの3指標に加え、TTFB（Time to First Byte）もLCPに間接的な影響を与えるため、あわせて確認しておきたい項目です。

• データ取得処理がウォーターフォール状になっていないか（並列で取得できるものはPromise.allでまとめる）
• Firestoreへのクエリが不要にインデックスなしの条件検索になっていないか
• 頻繁にアクセスされるが更新頻度の低いデータは、Next.js 16の'use cache'でキャッシュを効かせる

特にサーバーコンポーネントでのデータ取得は、実装が直感的な分、複数の非同期処理を意図せず直列実行してしまうことがあります。ネットワークタブでリクエストの発生順序を確認し、並列化できる余地がないか見直すことをおすすめします。

改善の優先順位はどう決めればいいか

限られた工数でパフォーマンス改善を進める場合、全ページを均等に改善しようとすると効果が薄まります。優先順位を決める基準としては、次の3点を掛け合わせて考えることをおすすめしています。

• 流入の多さ：アクセス数が多いページほど改善効果が全体に波及する
• 指標の悪化度合い：Search Consoleで「不良」判定されているページを優先する
• コンバージョンへの近さ：問い合わせフォームや料金ページなど、事業成果に直結するページを優先する

この3点が重なるページ（例えばアクセスが多く、指標も悪く、コンバージョンに近いページ）から着手すると、限られた工数でも成果を実感しやすくなります。

AI駆動開発でパフォーマンス改善はどう変わるか

Claude Codeのようなツールを使うと、画像タグのnext/image未使用箇所やwidth・height欠落の洗い出しといった機械的なチェックはAIに任せやすい作業です。一方で、「どのページから優先的に手を付けるか」というビジネスインパクトの判断は人間側の役割として残ります。改善候補のリストアップはAIに任せ、優先順位付けと最終判断は人が行う、という役割分担が実務では機能しやすいと感じています。

ゼットリンカーでの進め方

私たちがパフォーマンス改善に関わる場合、まず現状の実測値を洗い出し、影響度の大きいページから数週間単位の短いサイクルで改善と再計測を繰り返す進め方を取っています。全ページを一度に直すのではなく、流入の多いページから着手することで、限られた工数でも成果を実感しやすくなります。

キャッシュ戦略の詳細な使い分けについてはNext.js 16のuse cacheを中小企業のフルスクラッチでどう使い分けるかも参考にしてください。

よくある質問

Q. Lighthouseのスコアが低いのに実際のユーザーからは遅いと言われません。なぜですか？ A. Lighthouseはシミュレーション環境での計測値です。実際のユーザー環境（回線・端末）とは異なるため、Search Consoleのフィールドデータなど実測値も合わせて確認することをおすすめします。

Q. 画像をnext/imageに置き換えるだけでLCPは改善しますか？ A. 多くの場合改善しますが、priority属性の設定漏れや画像サイズが最適化されていないと効果が限定的です。ファーストビューの主要画像から優先的に見直してください。

Q. パフォーマンス改善にどれくらいの期間がかかりますか？ A. 計測・改善・再計測のサイクルを考えると、数週間単位での取り組みが現実的です。一度に全て解決しようとせず、優先度の高いページから段階的に進めることをおすすめします。

Q. Turbopackを有効にすればパフォーマンスは自動的に良くなりますか？ A. Turbopackは主にビルド・開発体験の高速化に寄与するもので、本番の表示速度改善には別途の最適化が必要です。混同しないよう注意してください。

まとめ

Core Web Vitals改善は、計測→優先度付け→改善→再計測のサイクルを地道に回すことに尽きます。次の一手に迷ったら、まずファーストビューの画像最適化から着手することをおすすめします。改善の進め方について相談したい場合は、要件未定の段階でも構わない15分のカジュアル相談をご利用ください。

本記事は Next.js 16.x 時点の情報です。最終更新：2026-08-03