はじめに：Googleは「速さ」と「快適さ」を見ている
「検索順位を上げるには、キーワードを含んだ高品質な記事を書けばいい」
これは正解ですが、2025年のSEOにおいては「不十分」です。
Googleは現在、コンテンツの中身だけでなく、「そのページが快適に閲覧できるか（ユーザー体験）」を厳しく評価しています。
その評価基準となるのが、Core Web Vitals（コアウェブバイタル）と呼ばれる3つの指標です。
この記事では、専門用語が多くて挫折しがちなこの3つの指標について、その意味と改善策をわかりやすく噛み砕いて解説します。
1章：Core Web Vitalsの3つの柱
Core Web Vitalsは、以下の3つの要素で構成されています。
これらは「ロード時間」「インタラクティブ性」「視覚的安定性」という、Webサイトの快適さを決める三大要素を数値化したものです。
1. LCP (Largest Contentful Paint) ：読み込みの速さ
「メインコンテンツが表示されるまでの時間」です。
ページを開いた時、ユーザーが一番見たい「大きな画像」や「見出し」が画面に出てくるまでの秒数を測ります。
- 意味：ユーザーに「ページが表示された」と認識させる速度。
- 合格ライン：2.5秒以内
2. FID (First Input Delay) / INP (Interaction to Next Paint) ：応答の良さ
「ユーザーの操作に対する反応速度」です。
ボタンやリンクをタップした時に、ブラウザが反応して処理を開始するまでのタイムラグを測ります。
※FIDは2024年に廃止され、より包括的な指標であるINPに置き換わりました（後述）。
- 意味：「サクサク動くか、もっさりしているか」の体感。
- 合格ライン（INP）：200ミリ秒以内
3. CLS (Cumulative Layout Shift) ：見た目の安定性
「レイアウトのズレ」です。
記事を読んでいる途中で、遅れて読み込まれた広告によって本文がガクッと下にズレた経験はありませんか？
あの不快な「予期せぬ移動」を数値化したものです。
- 意味：誤クリックを防ぎ、ストレスなく読めるか。
- 合格ライン：0.1以下
2章：なぜFIDではなく「INP」なのか？（2025年の重要変更）
これまでSEO対策をしてきた方の中には、「FID」という言葉に馴染みがあるかもしれません。
しかし、Googleは2024年3月をもってFIDをCore Web Vitalsから除外し、代わりにINP (Interaction to Next Paint) を採用しました。
FIDとINPの違い
- FID（旧）：「最初の」1回のタップ（First Input）の反応速度だけを見ていました。
- INP（新）：ページ滞在中の「全ての」タップやキーボード操作を計測し、その中で最も遅かった反応を評価します。
つまり、INPの方が「ページ全体の使いやすさ」をより厳密にチェックする指標なのです。
これからのSEO対策では、「最初のクリックだけ速ければいい」という小手先の対策は通用しません。
3章：スコアが悪いとどうなる？SEOへの影響
これらの指標（Core Web Vitals）のスコアが悪いと、具体的にどのようなデメリットがあるのでしょうか。
1. 検索順位への悪影響
Googleは、Core Web Vitalsをランキング要因として使用しています。
競合サイトとコンテンツの質が同程度だった場合、Core Web Vitalsのスコアが良い（＝快適な）サイトの方が上位に表示されやすくなります。
2. ユーザーの離脱（直帰率の悪化）
LCPが悪い（表示が遅い）サイトは、中身を見る前にユーザーが「戻るボタン」を押してしまいます。
また、CLSが悪い（画面がズレる）サイトは、ユーザーにストレスを与え、二度と訪問したくないと思わせてしまいます。
結果として滞在時間が短くなり、それがさらにGoogleからの評価を下げるという悪循環に陥ります。
次回の第2部では、3つの指標の中で最も改善効果がわかりやすい「LCP（読み込み速度）」の改善テクニックに焦点を当てます。
「画像圧縮」や「WebP変換」など、今日からできる具体的な施策を解説します。
4章：敵を知る！LCP要素を特定しよう
LCPを改善するためには、まず「あなたのページの中で、どの要素がLCP（最大コンテンツ）として判定されているか」を知る必要があります。
これはPageSpeed Insightsで簡単に確認できます。
- PageSpeed Insightsを開く。
- URLを入力して分析する。
- 「診断」セクションにある「LCP の最大要素（Largest Contentful Paint element）」という項目を見る。
多くのサイトでは、以下のいずれかがLCP要素になっています。
- メインビジュアル（ヒーローイメージ）：記事のトップにある大きな画像。
- H1見出しテキスト：画像がない場合のタイトル文字。
- 動画のポスター画像：YouTube埋め込みなどのサムネイル。
この特定された要素を「いかに速く画面に出すか」が勝負です。
5章：画像の最適化（LCP改善の特効薬）
LCPが悪化する原因のNo.1は「画像の容量が大きすぎること」です。
以下の3ステップでダイエットさせましょう。
ステップ1：次世代フォーマット「WebP」への変換
従来のJPEGやPNGを使っているなら、Googleが開発した軽量フォーマット「WebP（ウェッピー）」に変換しましょう。
画質をほぼ落とさずに、ファイルサイズを30%〜50%ほど削減できます。
WordPressなら「EWWW Image Optimizer」や「Converter for Media」などのプラグインを入れるだけで、アップロード済みの画像を一括変換できます。（参考：WordPressプラグインの活用）
ステップ2：レスポンシブ画像の提供（srcset）
PC用の巨大な画像（横幅2000px）を、スマホ（横幅375px）でそのまま読み込ませるのは通信の無駄です。
srcset属性を使って、「画面サイズに合わせて最適な大きさの画像を出し分ける」設定にしましょう。
（※現代のWordPressテーマなら標準対応していることが多いです）
ステップ3：LCP画像は「遅延読み込み」しない！
ここが最大の落とし穴です。
「サイトを速くするために、画像は全部Lazy Load（遅延読み込み）にしよう」と考えるのは間違いです。
LCP要素（メイン画像）まで遅延読み込みさせてしまうと、スクリプトが動くまで表示が始まらず、逆にLCPスコアが悪化します。
「ファーストビューの画像だけは即時読み込み（eager）にする」のが鉄則です。
6章：サーバー応答速度（TTFB）の短縮
画像がどれだけ軽くても、データを送ってくるサーバー自体が遅ければ意味がありません。
「最初の1バイトが届くまでの時間（TTFB）」が遅い場合の対策です。
1. ページキャッシュの利用
WordPressなどの動的サイトは、アクセスがあるたびにデータベースからページを生成するため時間がかかります。
「キャッシュ（一時保存データ）」を表示させることで、生成時間をカットし、爆速で表示させることができます。
2. サーバーのスペックアップ
月額数百円の格安サーバーを使っている場合、CPU性能やメモリが不足している可能性があります。
スマホでの表示速度を上げるためにも、高速なSSD（NVMe）を搭載したサーバーへの乗り換えは、最もコストパフォーマンスの良い投資です。
3. CDN（コンテンツデリバリーネットワーク）の活用
画像やCSSなどの静的ファイルを、自社サーバーではなく、世界中に分散された「エッジサーバー」から配信する仕組みです。
ユーザーに物理的に近いサーバーからデータが届くため、通信遅延を最小限に抑えられます。
次回の第3部では、クリックしたのに反応しないイライラを解消する指標「INP（旧FID）」の改善方法について解説します。
JavaScriptの読み込み順序を変えるだけで、サイトの「サクサク感」を取り戻すテクニックをお伝えします。
7章：INP悪化の犯人は「メインスレッドの渋滞」
INP（Interaction to Next Paint）のスコアが悪い時、裏側では何が起きているのでしょうか？
一言で言えば、ブラウザの「メインスレッド」が忙しすぎて、ユーザーの相手ができない状態です。
イメージしてください：
あなたはホテルのフロント（ブラウザ）でベルを鳴らしました（タップ）。
しかし、フロント係（メインスレッド）は電話対応や書類整理（JavaScriptの処理）に追われていて、あなたの方を向くことさえできません。
この「無視されている時間」がINPの正体です。
主な原因は「JavaScript」
画像やCSSの読み込みは比較的スムーズに行われますが、JavaScript（動的なプログラム）は複雑な計算を伴うため、CPUに負荷をかけます。
特に以下のような要素がINPを悪化させます。
- 過剰なアニメーション効果
- 大量の広告スクリプト
- SNSの埋め込みタイムライン
- 複雑なハンバーガーメニューの実装
8章：JavaScriptを「ダイエット」させる3つの方法
INPを200ミリ秒以内（合格ライン）にするには、メインスレッドを空けておく必要があります。
そのための具体的な対策は以下の3つです。
対策1：不要なプラグインを削除する
WordPressを使っている場合、最も簡単な解決策はこれです。
「便利そうだから」と入れたものの、実際には使っていないスライダープラグインや、過剰な機能を持つページビルダーなどが裏で重いスクリプトを動かしているケースが多々あります。
使用していないプラグインは「無効化」ではなく「削除」しましょう。
対策2：読み込みタイミングを遅らせる（Defer/Async）
ページの表示にすぐ必要ないスクリプトは、後回しにします。
HTMLの<script>タグに属性を追加することで制御できます。
- defer：HTMLの解析が終わってからスクリプトを実行する（推奨）。順序が保たれるため安全です。
- async：読み込み次第すぐに実行する。解析を中断させるリスクがあるため、独立したスクリプト（アナリティクスなど）に向いています。
対策3：第三者スクリプトの遅延実行
Googleマップ、YouTube動画、チャットボットなどは非常に重い外部スクリプトです。
これらは「ユーザーがスクロールしてその場所に来るまで読み込まない（Lazy Load）」設定にするのが効果的です。
WordPressなら「Flying Scripts」などのプラグインを使えば、指定したキーワードを含むスクリプトの読み込みを遅らせることができます。
9章：複雑なUI処理を見直す
プログラムの読み込みだけでなく、実行時の処理自体が重いケースもあります。
CSSでできることはCSSでやる
例えば「メニューが開くアニメーション」をJavaScriptで事細かに制御すると負荷がかかります。
現代のブラウザでは、CSSアニメーション（transitionやtransform）を使った方が、GPU（グラフィック処理装置）を使って滑らかかつ高速に描画できます。
アクセシビリティへの配慮もINP改善に繋がる
例えば、<div>タグで作った自作ボタンにJavaScriptでクリックイベントを付けるよりも、本来の<button>タグや<a>タグを使った方が、ブラウザ標準の挙動を利用できるため処理が軽く、かつアクセシビリティ（誰にでも使いやすい設計）の観点からも推奨されます。
正しいHTMLタグを使うことは、SEOと速度改善の両方に効くのです。
次回の第4部では、最後の指標「CLS（視覚的安定性）」の改善方法について解説します。
「読んでる途中でガクッと画面がズレる」現象を防ぐための、画像サイズ指定やWebフォントの扱い方をお伝えします。
10章：CLS悪化の2大原因は「画像」と「フォント」
CLS（Cumulative Layout Shift）が悪くなる原因は非常にシンプルです。
ブラウザがページを描画している最中に、「後から読み込まれた要素が、既存のコンテンツを押し下げてしまう」からです。
特に多いのが以下の2パターンです。
- 画像や広告が遅れて表示され、スペースが広がる。
- Webフォントが適用された瞬間に、文字の幅が変わって改行位置がズレる。
11章：画像・動画の「場所取り」をする
ブラウザは、画像を読み込み終わるまで「その画像がどれくらいの大きさか」を知りません。
そのため、最初は高さを0pxとして処理し、画像が表示された瞬間に本来の高さ（例：300px）までグイッと広げます。
これがズレの正体です。
対策：widthとheightを必ず指定する
HTMLの<img>タグや<iframe>（動画埋め込み）には、必ず幅と高さを記述しましょう。
レスポンシブデザインであっても、「アスペクト比（縦横比）」をブラウザに伝えるために必要です。
<img src="photo.jpg" width="800" height="600" alt="写真">
こう書いておけば、CSSで「width: 100%; height: auto;」としていても、ブラウザは「あ、ここは4:3の比率だな」と計算し、読み込み前からスペースを確保（予約）してくれます。
広告枠（AdSenseなど）も固定する
広告が表示されるかどうかわからない場合でも、あらかじめmin-height（最低限の高さ）をCSSで指定し、空のボックスを作っておくのが鉄則です。
「広告が出なかったら空白になる」ほうが、「広告が出て記事がズレる」よりもUX（ユーザー体験）としてはマシだからです。
12章：Webフォントの「チラつき」を防ぐ
おしゃれなフォント（Webフォント）を使うと、データが重いため読み込みに時間がかかります。
その間、ブラウザの挙動は以下のどちらかになります。
- FOIT (Flash of Invisible Text)：読み込み終わるまで文字を表示しない（透明）。
- FOUT (Flash of Unstyled Text)：最初は標準フォントで表示し、読み込み終わったらWebフォントに切り替える。
後者の場合、標準フォントとWebフォントで「文字の幅」が違うと、切り替わった瞬間に文章の長さが変わり、改行位置がズレてしまいます。
対策：font-display: swap; を使う
CSSでfont-display: swap;を指定すると、「最初は代替フォントで表示し、準備ができ次第スムーズに切り替える」という挙動になります。
これにより、文字が見えない時間をなくしつつ、ズレを最小限に抑えることができます。
さらに、上級者向けにはsize-adjustというプロパティを使い、代替フォントの大きさを微調整してWebフォントの幅に近づけておくことで、切り替わりのズレをほぼゼロにすることも可能です。
次回の最終回（第5部）では、これまでの改善策を総まとめし、実際にどのくらいスコアが改善したかを確認する手順と、今後どのようにサイトをメンテナンスしていけば良いか（運用編）について解説します。
13章：改善結果の正しい確認方法
画像の圧縮やサーバー設定の見直しが終わったら、実際にどれくらい速くなったかを確認しましょう。
ただし、ツールによって結果が出るタイミングが違うので注意が必要です。
1. PageSpeed Insights（即時確認）
こちらは「今現在のページの状態」を分析するツールなので、改善策を実行した後すぐに計測すれば、新しいスコアが表示されます。
まずはここで「合格ライン（緑色）」に近づいているかを確認しましょう。
2. Google Search Console（長期確認）
Search Consoleの「ウェブに関する主な指標」レポートは、実際のユーザーのアクセスデータを元に集計されるため、改善結果がグラフに反映されるまでに最大で28日ほどかかります。
「修正したのにエラーが消えない！」と焦らず、データが蓄積されるのを待ちましょう。
エラー修正後は、必ず「修正を検証」ボタンを押してGoogleに報告してください。
14章：二度と遅くしない！日々の運用ルール
一度サイトを高速化しても、日々の更新で重い画像やスクリプトを追加していけば、すぐにまた遅くなってしまいます。
快適な状態を維持するために、以下のルールを徹底しましょう。
- 画像のサイズ制限：ブログに載せる写真は、横幅を最大1200px程度にリサイズしてからアップロードする。（スマホで撮った4000pxの写真をそのまま上げない）
- プラグインの定期検診：「これ何だっけ？」という使っていないプラグインは削除する。
- 外部スクリプトの吟味：新しいSNSウィジェットや計測ツールを入れる時は、「本当に全ページに必要か？」を考える。
特にホームページ更新を複数人で行っている場合、担当者全員にこのルールを周知することが重要です。
15章：まとめ｜Core Web Vitalsは「おもてなし」の心
全5回にわたり、LCP・INP・CLSの改善方法について解説してきました。
専門的な用語が多くて難しく感じたかもしれませんが、Googleが言いたいことは非常にシンプルです。
「ユーザーを待たせず、快適に情報を提供してください」
表示速度の改善は、単なるSEOテクニック（検索順位を上げる手段）ではありません。
あなたのサイトを訪れてくれた人に対する「おもてなし（ホスピタリティ）」そのものです。
サクサク動く快適なサイトは、ユーザーの信頼を勝ち取り、結果としてモバイル検索順位の上昇や、売上の向上という大きなリターンをもたらしてくれます。
ぜひ今日から、できる範囲で改善に取り組んでみてください。
⏱️ あなたのサイト、プロが高速化します
「プラグインの設定が難しくて怖い…」
「自力でやったけどスコアが上がらない」
OMNIWEBでは、専門エンジニアによる「WordPress高速化サービス」を提供しています。
画像の最適化からサーバー移転の代行まで、安全かつ確実にCore Web Vitalsを改善します。
