株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
ページスピードとCore Web Vitalsが2026年のSEOで重要な理由
Core Web Vitals（CWV）は、Googleがユーザー体験を評価するための3つの指標で、2026年のSEOランキングにおける重要なシグナルです。Googleのランキングは通常ページ単位で評価され、サイト全体を扱う評価もあります。Search ConsoleのURL群単位のレポートを、ランキングの評価単位そのものとはみなせません。CWVはランキングに使われますが、基準の達成だけで順位や事業成果は決まりません。
2026年9月8日公表のCrUX・2026年8月データでは、対象は18,294,881オリジンで、CWV良好は55.6%、INP良好は85.3%でした。この集計でINPは最も不合格率が高い指標ではありません。CrUXの集計条件を満たすオリジンについての数値であり、全Webサイトの端末別達成率ではない点に注意が必要です。
Core Web Vitals 3指標の基準値（2026年版）
| 指標 | 測定対象 | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP（Largest Contentful Paint） | 読み込み速度 | 2.5秒以下 | 2.5〜4.0秒 | 4.0秒超 |
| INP（Interaction to Next Paint） | 操作応答性 | 200ms以下 | 200〜500ms | 500ms超 |
| CLS（Cumulative Layout Shift） | 視覚的安定性 | 0.1以下 | 0.1〜0.25 | 0.25超 |
2024年の重要な変更：2024年3月にFID（First Input Delay）がINPに置き換わりました。FIDは最初の操作の入力遅延のみを測定していました。INPはページ利用中のクリック・タップ・キーボード操作から、外れ値を除いた最も長い応答時間を、その訪問の値とします。操作が多い場合は50操作ごとに上位1件を除きます。75パーセンタイルは、各訪問の値を集めてサイトやページを評価する際の基準で、1訪問内の操作の75%点ではありません。
最適化の優先順序：TTFB → LCP → INP → CLS
最も効果的な改善順序はTTFB（Time to First Byte）→ LCP → INP → CLSです。上流の改善が下流に波及するため、この順序が効率的です。
LCP最適化（読み込み速度）
LCPはページの最も大きな可視要素（ヒーロー画像・見出しテキスト等）の表示完了時間を測定します。
- 画像のプリロード：ヒーロー画像にpreloadヒントを付与し、早期に読み込みを開始させる
- クリティカルCSSのインライン化：ファーストビューに必要なCSSをHTML内に埋め込み、外部CSS読み込みの待機を排除
- フォントの最適化：font-display: swapでフォント読み込み中もテキストを表示。Web Font Loaderの活用
- サーバーサイドレンダリング（SSR）：Next.jsのSSRやISR（Incremental Static Regeneration）でサーバー側でHTMLを事前生成
- CDNの活用：ユーザーに近いエッジサーバーからコンテンツを配信
- 画像フォーマットの最適化：WebP/AVIFフォーマットへの変換で画像サイズを50〜80%削減
INP最適化（操作応答性）——遅い操作の特定と改善
INPの改善では、まず遅い操作を特定し、入力待ち・イベント処理・次の描画までのどこに時間がかかるか調べます。従来のFIDより広い範囲の操作応答性を扱うため、JavaScriptの実行や描画処理を確認し、原因に応じてイベント処理からアーキテクチャまで見直します。
- ロングタスクの分割：50msを超える長いJavaScriptタスクを分割し、await scheduler.yield()やsetTimeoutで次のタスクへ処理を渡す。既に解決したPromiseをawaitするだけでは描画の機会を作れない。scheduler.yield非対応時にはsetTimeout等へ切り替える
- Web Workerの活用：重い計算処理をメインスレッドからWeb Workerに移動
- React Server Componentsの活用：Next.js App Routerでサーバーコンポーネントを使い、クライアントに送るJavaScriptを削減
- イベントハンドラーの最適化：不要なre-renderを防ぐmemo化、debounce/throttleの適用
- DOM複雑度の削減：DOM要素数を1,500以下に抑え、深いネストを避ける
- サードパーティスクリプトの遅延読み込み：広告・分析タグ等をIntersection Observerで遅延読み込み
CLS最適化（視覚的安定性）
CLSは3指標の中で最も改善しやすい指標です。
- 画像・動画にwidth/heightを明示：ブラウザがレイアウト計算前にスペースを予約
- 広告・動的コンテンツの領域確保：広告枠や遅延読み込みコンテンツに事前にmin-heightを設定
- Webフォント切り替え時のずれを抑制：swapだけでは寸法差によるずれが起こるため、size-adjust等で代替フォントとの寸法をそろえるか、font-display: optionalを検討
- アニメーションにtransformを使用：top/leftではなくtranslateを使い、レイアウト再計算を回避
Next.jsサイトでのCWV最適化：renueの実践知見
renueでは、3,000記事以上を掲載するNext.jsコーポレートサイト（renue.co.jp）のCWV最適化を継続的に実施しています。大規模コンテンツサイト特有の課題と実践的な解決策を紹介します。
next/imageによるLCP最適化
Next.jsのnext/imageコンポーネントは、自動的にWebP/AVIF変換・レスポンシブ画像生成・遅延読み込みを実行します。ヒーロー画像にはpriority属性を付与してプリロードし、LCPの改善に直結させます。自社サイトでもCDN経由での最適化画像配信を標準化しています。
CWV自動モニタリングの仕組み
renueではSEOツール基盤の一部としてCore Web Vitalsの自動取得機能を実装しています。対象ページのCWVスコアをプログラマティックに取得・記録し、閾値を超えた場合に通知する仕組みを運用しています。さらに、社内向けダッシュボードにCWVの可視化パネルを組み込み、技術指標と事業指標を一元管理しています。
3,000記事サイトのパフォーマンス戦略
- ISR（Incremental Static Regeneration）：3,000ページという件数だけで全静的生成が不可能になるわけではない。generateStaticParamsで全パスまたは一部のパスをビルド時に生成できるため、ビルド時間・更新頻度・実行環境の制約を測り、必要に応じてISRを組み合わせる
- 動的サイトマップとの連携：CMSから全記事を動的に取得してサイトマップを生成し、lastmodの正確性を保つ
- CSSのコード分割と配信確認：Next.jsの本番ビルドはCSSを結合・圧縮・分割する。ファーストビュー用のクリティカルCSS自動抽出とは区別し、共有CSSやグローバルCSSを含む実際の配信量を確認
- サードパーティスクリプトの管理：next/scriptのstrategy="lazyOnload"でGA4・GTM等の分析タグを遅延読み込み
CWV計測ツール比較
| ツール | データ種類 | 特徴 |
|---|---|---|
| PageSpeed Insights | ラボ+フィールド | CrUXデータ（実ユーザー）とLighthouseデータを両方表示 |
| Google Search Console | フィールド | サイト全体のCWVステータスをURL群単位で確認 |
| Lighthouse | ラボ | ローカル環境でのシミュレーション計測。CI/CDに統合可能 |
| Chrome DevTools | ラボ | パフォーマンスパネルでLong Taskやレイアウトシフトを特定 |
| web-vitals（npm） | フィールド | JavaScriptライブラリで実ユーザーのCWVをリアルタイム収集 |
| CrUX Dashboard | フィールド | Data StudioでCWVの月次トレンドを可視化 |
重要な注意点：実ユーザーの「フィールドデータ」（CrUX）と、原因調査に使うLighthouse等のラボデータを分けて確認します。GoogleはCWVをランキングに使う一方、良いスコアでも上位表示を保証しないと説明しています。Lighthouseの点数やCWVの合否だけで順位への効果を有無に分けることはできません。
よくある質問（FAQ）
Q1: Core Web Vitalsはどの程度SEO順位に影響しますか？
CWVはGoogleのランキングシステムが使う要素の一つですが、その点数だけで順位が決まるわけではありません。コンテンツの関連性や品質を含む複数の要素が評価されるため、競合と同品質なら必ずCWVで順位が決まるという規則として扱わず、利用者の体験改善と併せて取り組みます。
Q2: FIDからINPに変わって何が変わりましたか？
FIDは、そのページでの最初の操作からイベント処理を開始できるまでの入力遅延を測定していました。ロード直後に限らず、後から行った最初のクリックも対象ですが、2回目以降の操作は対象外でした。INPはすべてのインタラクションを評価するため、ページ全体のJavaScriptパフォーマンスが問われます。INP基準を満たせていないサイトも少なくありません。
Q3: モバイルとデスクトップで別々に評価されますか？
はい。CWVはモバイルとデスクトップの実測値を分けて確認します。モバイルファーストインデックスは、検索がモバイル版の内容を基にする仕組みであり、CWVをモバイルだけ優先して評価するという意味ではありません。デスクトップ検索にもページ体験の評価が導入されているため、両方の利用状況に応じて改善します。
Q4: SPAやNext.jsサイトでもCWVは計測されますか？
はい。Next.jsのSSR/ISRページはCWVが正常に計測されます。CSR（クライアントサイドレンダリング）のみのSPAではLCPの計測が不安定になる場合があるため、SSRまたはSSGの併用を推奨します。
Q5: CWV改善の費用対効果は？
画像最適化やfont-display設定といった基本対策は工数が小さく効果が大きいため、最初に着手すべきです。INP改善ではJavaScriptや描画の原因調査が必要です。redBusの公開事例では、JavaScript処理・表示処理・API応答などを改善した後に売上が約7%増えたと報告されています。個別企業の複合施策の結果であり、自社のCVR向上率や回収期間は実測して判断します。
ページスピード・Core Web Vitals改善のご相談
renueでは、Next.jsサイトのCWV最適化からSEOパフォーマンス改善まで支援しています。3,000記事以上のコンテンツサイト運営で培った大規模サイト最適化の知見をもとに、技術とSEOの両面からサポートいたします。
無料相談はこちら →
