SECTION 01

Core Web Vitalsとは｜2026年にGoogleが本当に見ている3つの体感指標

Core Web Vitalsは「読み込みの速さ」「操作への反応の速さ」「画面のガタつきのなさ」の3つを数値化した指標群です。2024年3月にFID（First Input Delay）がINP（Interaction to Next Paint）に置き換わり、2026年現在はLCP・INP・CLSの3指標が評価対象になっています。熊本の中小企業様からも「Search Consoleで警告が出ているがどこから直せばよいか」というご相談が増えています。

LCP（Largest Contentful Paint）｜最大要素の表示時間

LCPはページの中で「最も大きな要素が表示されるまでの時間」を計測します。ファーストビューのメイン画像や見出しが表示されるまでの体感時間とほぼ一致するため、訪問者の第一印象を直接左右する指標です。基準は2.5秒以内で、4秒を超えると明確に遅いと判定されます。

INP（Interaction to Next Paint）｜操作への応答時間

INPはユーザーがクリックやタップをした時、画面が次に描画されるまでの遅延時間を計測します。古い指標FIDが「最初の1回」だけを見ていたのに対し、INPはページ滞在中の全インタラクションの中で最も遅かった応答時間を採用します。基準は200ms以下で、500msを超えると重大な遅さとして警告対象になります。

CLS（Cumulative Layout Shift）｜画面のガタつき量

CLSはページ読み込み中に要素の位置が予期せず動いた累積量を計測します。画像の高さが指定されていない、広告枠が後から差し込まれる、フォントが切り替わる時のレイアウト崩れなどが原因です。基準は0.1以下で、0.25を超えると明確な体感劣化として評価が下がります。

Core Web Vitalsは「速度」だけでなく「応答性」と「安定性」の3軸で総合的にページ体験を測る、Googleが最も重視する体感指標です。

SECTION 02

LCP・INP・CLSの2026年基準値と、悪い数値が問い合わせ数に与える実害

Core Web Vitalsはあくまで体感指標であり、数値が良ければ自動的に上位表示されるわけではありません。ただし、競合と内容・被リンクが同水準の場合、Core Web Vitalsの差で順位が逆転するケースは熊本の中小企業様の支援現場でも繰り返し観測しています。さらに重要なのは、数値の悪化が問い合わせ数を直接削るという事実です。

LCP悪化が引き起こす「ファーストビュー前離脱」

LCPが4秒を超えるサイトでは、訪問者の半数以上がファーストビューを見る前に離脱します。広告経由の流入では特に顕著で、広告費を払って呼んだユーザーが「白い画面のまま」で去っていく構図になります。LCPを4秒から2.5秒に短縮すると、直帰率が10〜20ポイント改善する事例が多くあります。

INP悪化が引き起こす「操作不能の誤解」

INPが500msを超えると、ボタンを押しても画面が反応しないように見えます。ユーザーは「故障した」「押し方が悪かった」と判断して再タップを試み、それが二重送信や離脱を引き起こします。問い合わせフォームの送信ボタンでINPが悪化していると、CVR自体に直接の悪影響が出ます。

CLS悪化が引き起こす「誤クリックと信頼感低下」

CLSが0.25を超えるページでは、訪問者が押そうとしたボタンが直前で動き、別のリンクを押す事故が頻発します。誤って戻るボタンを押すと離脱、誤って広告を押すと不信感に直結します。特にスマートフォンでは指の精度が落ちるため、CLSの影響が大きく出ます。

SECTION 03

WordPressで遅くなる3大原因｜サーバー・テーマ・プラグインの優先順位

「プラグインを整理しろ」「画像を圧縮しろ」というアドバイスは正しいのですが、その前にサーバーとテーマを点検しないと、いくら表面を磨いても限界があります。CREVIAが熊本の中小企業様のWordPressサイトを診断する時は、サーバーから順に上層へ進む3段階で点検しています。

1. 01

   第1層：サーバー応答時間（TTFB）が500ms以内か

   PageSpeed InsightsのTTFB（Time to First Byte）が1秒を超えている場合、サーバーが根本原因です。共有サーバーの安いプランや、PHPバージョンが古いプランでは、ここが伸び続ける限界要因になります。サーバー移行が画像最適化より先に効きます。

2. 02

   第2層：テーマが軽量設計か、独自JavaScriptが過剰でないか

   海外製の汎用テーマは多機能ですが、使わない機能のJavaScriptとCSSを全ページに読み込むため、テーマ単体で1〜3秒の遅延を生むケースがあります。テーマの軽量版や日本製の機能限定テーマへの切替で、LCPが1秒以上短縮する事例があります。

3. 03

   第3層：プラグインの「フロント出力」量を点検する

   プラグインの件数より、フロント側に出力されるJavaScriptとCSSの量が問題です。SNS共有、フォーム、ポップアップ、解析タグ系プラグインは1個でも重く、複数同居するとINPを直撃します。Query Monitorで負荷を可視化して、重い順に整理します。

4. 04

   補助層：画像・フォント・サードパーティスクリプトの最適化

   サーバー、テーマ、プラグインの3層を整えた後で、画像のWebP化、フォントのpreload、外部スクリプトのdefer化に進みます。逆順で進めると、土台が悪いまま装飾だけ整える形になり、効果が頭打ちになります。

5. 05

   最後の仕上げ：キャッシュとCDNの導入

   WP RocketやLiteSpeed Cache、Cloudflareなどのキャッシュ・CDNは「最後の仕上げ」として導入します。土台が悪いままキャッシュを入れても、キャッシュが切れた瞬間に遅さが露見します。3層の点検が終わった後の上乗せ施策と位置付けます。

SECTION 04

LCPを2.5秒以下にする実装手順｜画像最適化・クリティカルCSS・フォント読込の順番

LCPの改修は、闇雲に画像を圧縮するのではなく、LCP要素を特定して優先的に手当てするのが原則です。PageSpeed InsightsのLCP診断画面で、「最大要素」として表示されるDOMがLCP要素です。CREVIAでは以下の7点を順序立てて実装しています。

1. 01

   LCP要素を特定し、preload で先読みする

   ファーストビューの大きな画像がLCP要素である場合、<link rel="preload" as="image">でheadタグに先読み指定を追加します。これだけで0.3〜0.8秒短縮する事例が多くあります。

2. 02

   LCP画像のフォーマットをWebPまたはAVIFに変換する

   JPEGやPNGに比べてWebPは30〜50%、AVIFは50〜70%軽量化できます。WordPressならEWWW Image OptimizerやShortPixelで自動変換可能です。AVIF対応ブラウザの普及で、2026年現在はAVIF優先の構成も実用的です。

3. 03

   LCP画像のlazy loadは外す

   WordPress 5.5以降の自動lazy loadは便利ですが、ファーストビュー画像にlazy loadが付くとLCPが悪化します。LCP要素の<img>にはloading="eager"を明示し、自動lazy loadから除外します。

4. 04

   クリティカルCSSをインライン化し、残りは非同期化する

   ファーストビューの描画に必要な最小限のCSSをHTML内にインライン記述し、残りのCSSはmedia="print" onloadで遅延読み込みします。レンダリングブロッキングが解消され、LCPが0.5〜1.5秒短縮します。

5. 05

   Webフォントをpreloadし、font-display:swapで描画ブロックを防ぐ

   Google FontsやNoto系フォントの読み込みがLCPを遅らせるケースが多くあります。<link rel="preload" as="font">とCSS側のfont-display:swapを併用すると、フォントロード中もシステムフォントで描画が進みます。

6. 06

   サーバー応答時間（TTFB）を500ms以下に整える

   PHP 8.2以降への更新、OPcache有効化、Object Cacheの導入で、サーバー応答時間が大きく短縮します。レンタルサーバーの上位プランや、KUSANAGI・Kinsta・XServer ビジネスなどの高速プランへの移行も選択肢に入ります。

7. 07

   CDN導入で物理距離を縮める

   Cloudflare無料プランやBunnyCDNを導入すると、画像とCSS・JSがエッジサーバーから配信され、TTFBがさらに短縮します。熊本のサーバーから関東のユーザーに配信するより、エッジ経由のほうが速い場面が多くあります。

LCP改修の効果検証はラボ値ではなく現場値で行う

改修後の効果検証はPageSpeed Insightsのラボ値だけでなく、Search Consoleの「ウェブに関する主な指標」レポートで現場値（CrUXデータ）の推移を月次で確認します。ラボ値で2.5秒以下を達成しても、現場値が4秒のままだとGoogleの評価には反映されないため、改修着手前のベースライン計測と継続監視がセットになります。

LCPは「LCP要素を特定 → preload → 軽量化 → CSS/フォント → サーバー → CDN」の順で潰すと、2.5秒以下が現実的な到達ラインになります。

SECTION 05

INPを200ms以下にする手順｜JavaScript分割・スクリプト遅延・サードパーティ整理

INPの悪化は、メインスレッドで動く長いJavaScriptタスクが原因のほぼ全てです。WordPressの場合、原因はSNS共有プラグイン、解析タグ、広告タグ、ポップアップ、チャットウィジェットの5系統に集中しています。改修の優先順位は「重い順に外す・遅延させる」が原則です。

サードパーティスクリプトを最後に読み込む

Google Analytics、Google Tag Manager、Meta Pixel、各種SNSピクセル、チャットツール（Chatwork・Tawk.toなど）は、ページの描画と操作開始を遅らせる代表的な原因です。<script async>または<script defer>属性を付け、ページ操作可能になった後で読み込むよう変更します。重要度が低いものはrequestIdleCallbackを使ってさらに後置します。

JavaScriptを分割してメインスレッドを開放する

1つのJavaScriptファイルが200ms以上動き続けると、その間ユーザーの操作は全て無視されます。1タスクを50ms以内に収まるように分割し、間にメインスレッド開放のタイミング（setTimeoutやyieldToMain）を挟む設計が必要です。WordPressテーマが独自に長いJSを抱えている場合は、テーマ側の見直しが必要になります。

使っていないJavaScriptを物理的に削除する

Chrome DevToolsのCoverageタブで、未使用のJavaScript行数を可視化できます。50%以上が未使用のサイトでは、テーマやプラグインのコード分割（code splitting）で、必要なページだけに必要なJSを読ませる構成に変えるとINPが大きく改善します。

フォントとアイコンを最小単位に絞る

FontAwesomeなどのアイコンフォント全セット読み込みは、INPに見えにくい悪影響を与えます。実際に使うアイコンだけをSVGスプライト化するか、Material SymbolsのVariable Fontを部分読込する形に変更すると、JavaScript解析時間が短縮します。

SECTION 06

CLSを0.1以下にする手順｜画像width/height・広告枠・遅延読込の安定化

CLSの改修は、見た目の派手さがない地味な工程ですが、誤クリックと信頼感低下を防ぐ重要な工程です。WordPressサイトのCLS悪化原因は、画像・広告・フォント・遅延読込の4系統に集約されます。

1. 01

   全画像にwidth/height属性を明示する

   CSSでwidth:100%; height:autoと指定するだけでなく、<img>タグにwidth/heightを明示すると、ブラウザが画像の縦横比を計算し、読み込み前に高さを確保します。CLSの最大原因の1つです。

2. 02

   広告枠にmin-heightを設定する

   Google AdSenseやアフィリエイト広告の差し込み枠は、広告ロード前後で高さが変動しがちです。CSSでmin-heightを指定し、最大想定サイズの空間を先に確保します。

3. 03

   遅延読込（lazy load）でサイズが確定する設計にする

   lazy loadで画像が遅れて表示される時、サイズ未指定だと表示瞬間にレイアウトが揺れます。lazy load対象の画像にもwidth/heightを必ず明示し、空のdiv要素で代替表示領域を確保しておきます。

4. 04

   Webフォントのレイアウトシフトを最小化する

   システムフォントからWebフォントに切り替わる瞬間、文字幅が変わって周辺要素が動きます。size-adjustとascent-overrideでフォール時のシステムフォントとWebフォントの幅を揃えると、シフトがほぼ消えます。

5. 05

   JavaScriptで動的挿入する要素はサイズ事前確保

   ポップアップ、お知らせバー、カウントダウンタイマーなど、JavaScriptで後から挿入する要素は、表示位置と高さを事前に確保します。コンテンツ上部に唐突に挿入する設計は、CLSを直撃するため避けます。

CLSは「要素のサイズを先に予約する」だけで0.1以下に到達します。地味ですが誤クリック防止と信頼感に直結する重要な工程です。

SECTION 07

PageSpeed InsightsとSearch Consoleでの実測手順｜現場値とラボ値の読み方

改修の効果検証は、PageSpeed Insightsの単発計測だけでは不十分です。Googleが実際にランキング評価に使うのは、Chromeから収集される現場値（CrUXデータ）であり、Search Consoleの「ウェブに関する主な指標」レポートで月次推移を確認できます。3つの実測手順に分けて整理します。

1. 01

   PageSpeed Insightsでラボ値とフィールドデータを分けて読む

   PageSpeed Insightsの結果画面では、上部の「実際のユーザーの環境で評価する」がフィールドデータ（現場値）、下部の「パフォーマンスの問題を診断する」がラボ値です。現場値はCrUXデータベース由来で過去28日の実測値、ラボ値はその場での計測値です。改善判断はフィールドデータ優先で行います。

2. 02

   Search Consoleの「ウェブに関する主な指標」レポートで全URL状況を確認

   Search Console左メニューの「ウェブに関する主な指標」で、サイト内全URLが「良好」「改善が必要」「不良」のいずれかに分類されます。URLグループごとに同じ問題を抱えている場合が多く、テンプレート単位で改修すれば一気に解決できます。

3. 03

   Chrome DevToolsのPerformanceとLighthouseで原因を特定する

   数値が悪い原因はPageSpeed Insightsだけでは詳細が掴めないことがあります。Chrome DevToolsのPerformanceタブで実際の読み込み挙動を録画し、Lighthouseで詳細レポートを出力すると、どのスクリプト・どの画像が遅延の元か特定できます。

4. 04

   CrUX Dashboardで月次推移を可視化する

   Googleが提供する無料のCrUX Dashboard（Looker Studio連携）で、自社サイトのLCP・INP・CLSの月次推移をグラフ化できます。改修前後の比較レポートを作る時に有効です。設定は無料で30分以内で完了します。

5. 05

   Web Vitals拡張機能でリアルタイム計測する

   Chrome拡張機能「Web Vitals」をインストールすると、閲覧中ページのCore Web Vitalsがリアルタイムで表示されます。開発中の修正効果を即時確認できるため、エンジニアの作業効率が大きく上がります。

SECTION 08

業種別の改修事例｜飲食・士業・クリニック・BtoBで何が効いたか

同じCore Web Vitals改修でも、業種によって「どこが致命傷か」が異なります。トップページに大きな写真を多用する飲食店、テキスト中心の士業、予約導線が複雑なクリニック、資料請求と長文ページが中心のBtoBで、改修の優先順位は変わります。実際に効いた業種別事例を共有します。

飲食店の事例｜トップ画像のAVIF化とプリロードでLCPを3.8秒→1.9秒に

熊本市内の飲食店様のサイトは、トップにメイン料理写真をフルワイドで表示する構成で、LCPが3.8秒に達していました。メイン画像をAVIFに変換し、preload属性を追加、lazy loadから除外する3点改修で、LCPが1.9秒まで短縮しました。改修後3ヶ月でSearch Consoleの表示回数が27%増加しています。

士業の事例｜不要なJavaScriptプラグインを4本削除してINPを280ms→140msに

合志市の士業事務所様のサイトでは、過去に導入したSNS共有ボタン、人気記事ランキング、関連記事サムネ自動生成、Tag Cloudの4プラグインがINPを悪化させていました。実際の利用率を計測した上で4本を停止・削除し、INPが280msから140msに改善、フォームの送信ボタンの応答性が体感で改善しました。

クリニックの事例｜予約ウィジェットを遅延読込してCLSを0.31→0.07に

菊陽町のクリニック様では、外部予約システムのウィジェットをトップページに埋め込んでおり、後から読み込まれるタイミングでレイアウトが大きく揺れ、CLSが0.31でした。ウィジェットのコンテナにmin-heightを設定し、表示位置を予約ボタンの近くに移動した結果、CLSが0.07まで改善しました。

BtoBの事例｜サーバー移行とテーマ軽量化でPageSpeedスコアを32→78に

八代市の製造業向けBtoB事業者様では、安価な共有サーバーと多機能海外テーマの組合せで、PageSpeedスコアが32（赤）でした。XServerビジネスへの移行、テーマを国産軽量テーマに変更、未使用プラグイン12本の削除を順に実施し、3ヶ月でスコアが78に改善、CV経由の問い合わせが月15件から24件に伸びました。

業種ごとに「効く施策」は違います。汎用ノウハウだけでなく、業種特性に応じた優先順位を組むと改修の投資対効果が安定します。

SECTION 09

CREVIAが行うCore Web Vitals改修｜既存サイトを壊さない移行手順と対応範囲

運用中のWordPressサイトを改修する際は、表示崩れ、機能停止、SEO評価の一時下落などのリスクが付きまといます。CREVIAでは、本番に直接手を入れず、ステージング環境での検証を挟む3ステップ構成を標準にしています。

1. 01

   現状診断と優先順位レポート（初週）

   PageSpeed Insights、Search Console、Chrome DevToolsで現状値を可視化し、サーバー・テーマ・プラグイン・画像・JavaScriptの5層で改修の優先順位を3〜5件に絞ったレポートを納品します。診断だけのご依頼も対応可能です。

2. 02

   ステージング環境での実装と検証（2〜5週目）

   本番のクローンをステージング環境に作成し、改修を実施します。表示崩れチェック、フォーム動作確認、Search Console連携確認まで完了してから本番反映するため、運用中サイトでも安心です。WordPress、テーマ、プラグイン、画像、JS、サーバー設定まで一括対応します。

3. 03

   月次のCore Web Vitals監視と継続改善（6週目以降）

   改修後の現場値をCrUX Dashboardで月次レポート化し、新規ページや新規プラグイン導入時に数値が悪化していないかを継続監視します。半年で「全URL良好」状態を維持できる運用設計を行います。

Core Web Vitals改修は単発ではなく、診断・実装・月次監視の一気通貫で支援することで、SEO地盤と問い合わせ動線の両方を安定的に底上げできます。

SUMMARY

まとめ｜Core Web Vitals改修でSEOと問い合わせを同時に伸ばす最短ルート

Core Web Vitalsの改修は、地味で派手さがない地盤工事ですが、SEO評価と問い合わせ動線の両方に効く投資対効果の高い施策です。重要なのは以下の3点に集約されます。

1. 1

   サーバー・テーマ・プラグインの3層を上から順に点検する

   画像最適化やCSS調整より、サーバー応答時間とテーマの軽量性が先に効きます。土台が悪いまま装飾だけ整えても、効果は頭打ちになります。

2. 2

   LCP・INP・CLSの中で悪い指標から優先的に潰す

   3指標を同時に追うのではなく、PageSpeed Insightsで赤判定の指標を1つずつ潰す方が、投資対効果が見えやすくなります。

3. 3

   ラボ値と現場値の両方を月次で追う

   PageSpeed Insightsの単発計測だけでなく、Search ConsoleとCrUXの現場値で月次推移を見ないと、Googleの評価には繋がりません。

株式会社CREVIAは、熊本県内250社以上の支援実績をもとに、診断から改修、計測、月次PDCAまで一気通貫でご支援可能です。既存サイトを壊さない移行手順を前提に進めるため、運用中サイトでも安心してご相談ください。

SECTION 10

よくある質問