コアウェブバイタル（Core Web Vitals）とSEO｜ホームページの表示速度改善

ホームページ（ウェブサイト）の運営やSEO（検索エンジン最適化）において、コアウェブバイタル（Core Web Vitals）という言葉を耳にする機会が増えています。Googleが検索ランキングの評価要素としてページエクスペリエンスを組み込んで以来、表示速度のスコアを1点でも高くしようと細かなソースコードの修正に多くの時間や費用を投じるケースも少なくありません。

しかし、実際の検索アルゴリズムの挙動やホームページ制作・改修の現場における実態を冷静に分析すると、世間で語られているほど極端な速度追求が必要ではないことが見えてきます。かつてのホームページ制作では、表示速度の改善といえば高度な専門技術や職人技のようなテクニックによる部分が大きかった時代もありました。

それに対して現代の環境では、各種キャッシュ機構や画像の遅延読み込み、プログラムの非同期処理、次世代フォーマット画像の活用、さらにはレンタルサーバー側で提供されるサーバーキャッシュやWordPress本体の進化によって、基本的な速度対策の大部分は標準的な仕組みである程度まで自動的に改善されるようになっています。

それにもかかわらず、現在の環境でホームページの表示が極端に遅い場合は、細かなコードの書き方ではなく、PHPのバージョンが古いまま放置されていることや、月額数百円の安価なサーバーを使用していてサーバー自体の応答速度（レスポンス）が遅いこと、あるいはWordPressのデータベースが肥大化していることなどが実情であるケースが大半です。また、コアウェブバイタルとSEOの関係についても、表示速度が劇的に速ければ検索順位が大きく跳ね上がるという性質のものではなく、一定以上の遅さがある場合に評価が減点されるという解釈の方が実態に即しています。

本記事では、コアウェブバイタルの正確な仕組みとSEOにおける現実的な位置づけを整理した上で、事業の費用対効果という観点から最も合理的で手間の少ないホームページの表示速度改善アプローチについて詳しく解説していきます。

コアウェブバイタル（Core Web Vitals）の基礎知識と3つの評価指標

コアウェブバイタル（Core Web Vitals）とは、Googleがホームページ（ウェブサイト）におけるユーザー体験（ページエクスペリエンス）の健全性を測るために定義した、3つの具体的な計測指標のことです。

• LCP（Largest Contentful Paint：最大視覚コンテンツの表示時間）
• INP（Interaction to Next Paint：次の描画までのインタラクション時間）
• CLS（Cumulative Layout Shift：累積レイアウトシフト）

スピードアップデート

デザインの美しさや文章の読みやすさといった主観的な要素ではなく、ブラウザ上でページがどのように読み込まれ、ユーザーの操作に対してどのように反応し、画面の表示がどれくらい安定しているかという客観的な数値で評価されます。

現在、コアウェブバイタルは「読み込み時間」「応答性（インタラクティブ性）」「視覚的な安定性」を示す3つの指標で構成されており、それぞれの指標がどのような現象を計測しているのかを正しく把握しておくことが大切です。

コアウェブバイタルの各指標を理解する上では、単なる表面的な言葉の定義だけでなく、Googleがどのような背景からこの基準を導入し、実際の検索アルゴリズムの中でどのようにデータを収集・判定しているのかという裏側の仕組みを知っておくことが重要です。

Core Web Vitals と Google 検索の検索結果について（Google 検索セントラル）

ここでは、3つの評価指標それぞれの詳細な解説に入る前に、コアウェブバイタル全体の評価構造と計測の前提条件について整理していきます。

ページエクスペリエンスのランキング要因としての位置づけと導入の経緯

Googleは長年にわたり、検索結果を通じてユーザーが安全かつ快適に情報を得られる環境づくりを進めてきました。スマートフォンの画面に最適化されているかを評価するモバイルフレンドリーアップデートや、通信の暗号化を評価するHTTPS（常時SSL化）の推奨、画面全体を覆い隠して閲覧を妨げるインタースティシャル（ポップアップ広告など）へのペナルティ、そしてページの読み込み速度をモバイル検索の評価に組み込んだスピードアップデートなどは、すべてその一環として実施されてきた施策です。

コアウェブバイタルは、こうした従来のユーザー保護の取り組みを体系化し、ページエクスペリエンス（ページの閲覧体験）の健全性を客観的な数値で測るための共通基準として策定されました。単にサーバーからの通信速度が速いかどうかだけを測るのではなく、実際にホームページ（ウェブサイト）を訪問した人間が「ストレスなく画面を見られるか」「操作したときにすぐ反応するか」「意図しない画面のズレで誤操作が起きないか」という実用面の快適さを定量化している点に特徴があります。

Chromeユーザーエクスペリエンスレポート（CrUX）による実測データの収集と75パーセンタイル判定の仕組み

コアウェブバイタルの評価においてより専門的には、制作会社の高性能なパソコンや光回線を使って1回だけ計測したテストの数値ではなく、実際にホームページを訪問した一般ユーザーの環境から収集される「フィールドデータ（実測データ）」が検索ランキングの評価に使用されます。このデータは、利用統計情報の送信に同意したChromeブラウザのユーザーから匿名で集められる「Chromeユーザーエクスペリエンスレポート（CrUX）」と呼ばれ、直近28日間の蓄積データをもとに算出されます。

さらに重要なのが、その数値の判定に「75パーセンタイル値」という統計基準が用いられている点です。これは全訪問者の平均値をとるのではなく、読み込みが速かった順（体験が良かった順）に全ユーザーを並べた際、上から75％の位置にあたるユーザーの数値をもってそのページの評価を決めるという仕組みです。つまり、通信環境が良い都市部のユーザーや最新型のスマートフォンを使っている層だけでなく、電波状況がやや不安定な移動中のユーザーや、数年前の標準的な端末を使用している層を含めて、全体の4分の3以上の訪問者が基準値以内で快適に閲覧できて初めて「良好（Good）」と判定される設計になっています。

モバイル環境とデスクトップ環境における評価の分離とURLグループ単位の判定

コアウェブバイタルの計測データと評価は、スマートフォン（モバイル環境）とパソコン（デスクトップ環境）で完全に分けて集計されます。パソコンはCPUの処理能力が高く、安定した固定回線で接続されることが多いのに対し、スマートフォンは端末自体の計算処理能力に限りがあり、モバイル回線特有の通信遅延も発生しやすいため、パソコンでは良好と判定されていてもモバイルでは不良や改善が必要と判定されるケースが少なくありません。

現在のGoogle検索はモバイル版のページを基準に評価を行うモバイルファーストインデックスを採用しているため、まずはスマートフォン環境における数値を優先して確認する必要があります。

また、アクセス数がまだ少ないホームページや、公開されたばかりの新しい記事ページでは、そのページ単体だけではCrUXの統計に必要なサンプル数が集まらないことがあります。そのような場合、Googleは同じテンプレートや共通のプログラム構造で作られているページ群をまとめた「URLグループ単位」や、ホームページ全体の代表値をもとにページエクスペリエンスの評価を割り当てる仕組みをとっています。したがって、トップページだけでなく、記事ページや一覧ページなどの共通テンプレート全体の構造を整えておくことが大切になります。

LCP（Largest Contentful Paint：最大視覚コンテンツの表示時間）

LCP（Largest Contentful Paint）は、ページの読み込みが開始されてから、ユーザーの画面（ビューポート）内で最も面積の大きい主要なコンテンツ（メイン画像や動画のサムネイル、あるいは大きなテキストブロックなど）が表示されるまでにかかる時間を計測する指標です。Googleは、ページが読み込みを開始してから2.5秒以内にLCPが発生することを良好な基準として定めており、4.0秒を超えると不良と判定します。

従来の「ページのすべてのデータが読み込まれるまでの時間」とは異なり、LCPは「ホームページを訪問した人間が、ページのおおよその内容が表示されて利用可能になったと視覚的に実感できるまでの時間」を重視しています。このLCPの数値に最も大きな影響を与える要素は、サーバーが最初にデータを返し始めるまでの応答時間（TTFB：Time to First Byte）と、ファーストビューに配置されたメイン画像のファイルサイズ、そして画面の描画を妨げるCSSやJavaScriptの処理構造です。

LCPの数値を改善し、2.5秒以内の良好な基準を安定して満たすためには、ブラウザが画面内のどの要素をLCPとして認識するのかという仕様と、ページの読み込みが始まってからその要素が画面に描画されるまでの裏側の処理工程を正確に把握しておく必要があります。

LCPの対象としてブラウザに判定される具体的なHTML要素と再計算の仕組み

ブラウザがLCPの対象（最大視覚コンテンツ）として計測する要素は、HTMLの仕様上あらかじめ決められています。具体的には、imgタグやsvg内のimageタグで配置された画像、videoタグに設定されたポスター画像（動画再生前のサムネイル画像）、CSSのurl関数によって読み込まれる背景画像、そして見出し（h1など）や段落（pなど）といったテキストを含むブロックレベル要素が対象となります。なお、画面全体を覆うような背景色や、最初から透明度（opacity）が0に設定されて見えない状態になっている要素などは、ユーザーの視覚的な目印にならないためLCPの計測対象からは除外されます。

また、ページの読み込みが進むにつれて、LCPとして記録される要素は動的に更新されていく仕組みになっています。たとえば、ページの読み込み初期にまず大きな見出しテキストが表示された時点では、そのテキストが暫定的なLCP要素として記録されますが、その0.5秒後にさらに面積の大きいメインビジュアル画像が読み込まれて画面に表示されると、LCPの対象はその画像へと切り替わり、秒数も画像が表示された時点の数値で上書きされます。そして、ユーザーが画面をスクロールしたりタップしたりといった最初の操作を行った瞬間にLCPの計測は終了し、その時点までに表示された最大面積の要素の記録が最終的なLCP値として確定します。

LCPの時間を構成する4つのサブパート（内訳）とボトルネックの特定

より専門的には、GoogleはLCPが表示されるまでの時間を4つの段階（サブパート）に分解して原因を特定するアプローチを定義しています。LCPが遅い場合、単に「画像が重い」と決めつけるのではなく、この4つのどこに時間がかかっているのかを見極めることが重要です。

TTFB（Time to First Byte：最初の1バイトが到着するまでの時間）

1つ目の段階は「TTFB（Time to First Byte：最初の1バイトが到着するまでの時間）」です。ユーザーがリンクをクリックしてから、サーバーがWordPressのPHPプログラムやデータベースを処理し、HTMLデータの最初の1バイトをブラウザへ返し始めるまでの時間を指します。サーバーの性能が低い場合やPHPのバージョンが古い場合、この最初の段階だけで1秒から2秒以上を費やしてしまい、後続の処理がすべて遅れ込む原因になります。

リソース読み込み遅延（Resource Load Delay）

2つ目の段階は「リソース読み込み遅延（Resource Load Delay）」です。HTMLの最初のデータが届いてから、ブラウザがLCP要素となる画像の存在を見つけて実際にダウンロードを開始するまでの待機時間を指します。メイン画像をHTMLのimgタグとして直接記述せず、JavaScriptを実行して後から動的に画面へ挿入していたり、外部CSSファイルの奥深くに背景画像として指定していたりすると、ブラウザが画像の存在に気づくタイミングが遅れ、ダウンロードが始まるまでに無駄な空白時間が生まれます。

リソース読み込み時間（Resource Load Duration）

3つ目の段階は「リソース読み込み時間（Resource Load Duration）」です。LCPとなる画像ファイルそのものをサーバーから転送し、ダウンロードし終えるまでにかかる純粋な通信時間です。

数メガバイトもある未圧縮の写真データをそのまま配置している場合や、WebP・AVIFといった次世代フォーマットを使用していない場合に、この通信時間が長くなります。

きれいな写真を載せたら順位が落ちる？画像の重さと表示速度が与える影響

要素の描画遅延（Element Render Delay）

4つ目の段階は「要素の描画遅延（Element Render Delay）」です。画像データのダウンロード自体はすでに完了しているにもかかわらず、ブラウザの画面上に実際に表示（ペイント）されるまでに待たされる時間を指します。

HTMLのヘッダー内で読み込まれている巨大なCSSファイルや同期処理されるJavaScriptの解析が終わるまでブラウザが画面の描画を止めている（レンダリングブロックが発生している）場合、画像は手元に届いているのに画面には表示されないという現象が起こります。

ファーストビュー画像に対する遅延読み込み（lazy）の誤用と優先度ヒント（fetchpriority）の活用

ホームページの制作や改修の現場において、LCPを悪化させている意外な原因としてよく見られるのが、画像の遅延読み込み機能（loading=”lazy”属性）の誤った適用です。遅延読み込みは本来、画面を下にスクロールしなければ見えない位置にある画像の通信を後回しにするための機能ですが、プラグインの設定やテーマの仕様によってページ内のすべての画像に一律で遅延読み込みを指定してしまうと、一番最初に表示しなければならないファーストビューのメイン画像まで読み込みが後回しにされてしまいます。

LCPの対象となるファーストビューのメイン画像には遅延読み込み（loading=”lazy”）を絶対に指定せず、むしろブラウザに対して他のどのファイルよりも最優先でダウンロードするよう指示する優先度ヒント属性（fetchpriority=”high”）を付与するのが現在の標準的な設計です。最新のWordPress環境では、ページ内の最初の大きな画像に対してこの優先度制御を自動的に行う仕組みが組み込まれていますが、独自にカスタマイズされたテンプレートやスライダー（カルーセル）を使用している場合は、メイン画像が最優先で読み込まれるHTML記述になっているかを確認しておくことで、LCPの無駄な遅延を防ぐことができます。

INP（Interaction to Next Paint：次の描画までのインタラクション時間）

INP（Interaction to Next Paint）は、2024年3月に従来の指標であったFID（First Input Delay：初回入力遅延）に代わって正式に導入された、ページの応答性を測る指標です。以前のFIDはユーザーがページ内で最初にクリックやタップを行った際の反応速度だけを計測していましたが、INPはユーザーがそのページに滞在している間に行うすべてのクリック、タップ、キーボード入力に対して、ブラウザが処理を終えて次の画面変化を描画するまでの時間を総合的に計測します。Googleの基準では、200ミリ秒（0.2秒）以下が良好とされ、500ミリ秒を超えると不良と判定されます。

たとえば、スマートフォンの画面でメニューボタンをタップしたときや、アコーディオンパネルを開こうとしたときに、画面が一瞬固まってから遅れて開くような現象がある場合、INPの数値が悪化します。この遅延の主な原因は、ブラウザのメインスレッドが重たいJavaScriptの実行や過剰な外部計測タグの処理で塞がってしまい、ユーザーの操作に対する画面の書き換え処理が待たされることにあります。

INPは、ホームページの見た目が読み込まれた後の「操作のしやすさ（応答の俊敏さ）」を測る指標です。ユーザーがボタンをタップしたにもかかわらず画面が固まって反応しないという事態を防ぐため、ブラウザの内部でどのような処理が行われているのかを詳しく見ていきます。

旧指標であるFID（初回入力遅延）からINPへ変更された技術的な理由

2024年3月まで使用されていた旧指標のFID（First Input Delay：初回入力遅延）には、実際のユーザー体験を正確に測りきれないという2つの大きな技術的限界がありました。1つ目は、文字通りユーザーがページを開いて最初に1回目にクリックやタップを行った瞬間しか計測しておらず、ページを閲覧している途中で行われる2回目以降の操作の重さが一切反映されていなかった点です。2つ目は、FIDが計測していたのが「ユーザーが操作してからブラウザが処理を開始するまでの待ち時間（入力遅延）」だけであり、処理が始まった後に重たいプログラムが動いて画面がなかなか切り替わらないケースを検知できなかった点です。

これに対して新しく導入されたINPは、ユーザーがそのページに滞在している間に行うすべてのクリック、タップ、キーボード入力を対象とし、その中で最も応答に時間がかかった操作（操作回数が非常に多いページでは98パーセンタイル付近の操作）の時間をそのページの評価値として採用します。さらに、処理が始まるまでの待ち時間だけでなく、プログラムの実行時間から実際に次の画面変化が描画されるまでの全工程を計測するため、名実ともにユーザーの体感速度に直結する指標となっています。なお、画面を上下に動かすスクロール操作や、パソコンでマウスカーソルを乗せるだけのホバー操作については、連続的な動作であり性質が異なるためINPの計測対象には含まれません。

INPを構成する3つの処理フェーズとブラウザのメインスレッドの仕組み

ユーザーがスマートフォンの画面をタップしてから、メニューが開くなどの視覚的な変化が画面に表示されるまでの時間は、ブラウザ内部で3つの処理フェーズに分かれています。INPの良好基準である200ミリ秒（0.2秒）以内に収めるには、この3つの合計時間を短く保つ必要があります。

入力遅延（Input Delay）

1つ目のフェーズは「入力遅延（Input Delay）」です。ユーザーが画面に触れた瞬間から、ブラウザがその操作を認識して対応するプログラム（イベントハンドラ）を動かし始めるまでの待ち時間です。ブラウザには、HTMLの解析やCSSのスタイル計算、画面の描画、そしてJavaScriptの実行を一手に引き受ける「メインスレッド」と呼ばれる主要な処理レーンが存在します。ユーザーがタップしたまさにその瞬間、メインスレッドが別の重たいJavaScriptの処理（50ミリ秒以上連続して占有する処理はロングタスクと呼ばれます）を実行中であると、ユーザーの操作は現在の作業が終わるまで順番待ちをさせられ、入力遅延が発生します。

処理時間（Processing Time）

2つ目のフェーズは「処理時間（Processing Time）」です。ユーザーのタップ操作に紐づけられたJavaScriptのプログラムそのものが実行される時間です。たとえば、アコーディオンパネルを開くボタンや絞り込み検索のボタンをタップした際、単に表示を切り替えるだけでなく、裏側で大量のデータをループ処理で再計算したり、画面外の要素まで含めて一斉に書き換えたりする複雑なコードが組まれていると、この処理時間が長引きます。

描画遅延（Presentation Delay）

3つ目のフェーズは「描画遅延（Presentation Delay）」です。JavaScriptの実行が完了してから、ブラウザが変更された要素の配置（レイアウト）や装飾を再計算し、画面のピクセルを塗り替えて実際にモニターやスマートフォンの画面へ次のフレームを表示（Next Paint）するまでの時間です。ページのHTML構造（DOMツリー）が過度に複雑で、1ページ内に何千個ものタグが深く入れ子になって配置されているようなホームページでは、一部の表示を切り替えるだけでも画面全体の再計算に大きな負荷がかかり、描画が完了するまでに時間を要してしまいます。

サードパーティ製スクリプト（外部計測タグやチャットボット等）がINPに与える深刻な影響

実際のホームページ運営において、INPの数値を悪化させている最大の原因となっているのが、ホームページ本体のプログラムではなく、外部から読み込まれている「サードパーティ製スクリプト」の過剰な設置です。

事業でWebマーケティングを展開していると、GoogleアナリティクスやGoogleタグマネージャーをはじめ、複数のWeb広告のコンバージョン計測タグやリマーケティングタグ、ユーザーの動きを記録するヒートマップツール、画面右下に常駐するチャットボットやWeb接客ポップアップツール、さらにはSNSのタイムライン埋め込みウィジェットなどが次々と追加されていくことがよくあります。これらの外部ツールはすべて独自のJavaScriptをブラウザのメインスレッド上で実行するため、複数のツールが重なるとスマートフォンのCPUが常にフル稼働に近い状態になり、ユーザーがメニューをタップした際の反応（INP）を著しく鈍らせます。

細かなプログラムの書き換えを行う前に、まずはGoogleタグマネージャーの中身やヘッダー・フッターの記述を点検し、すでに終了した広告キャンペーンの古いタグや、現在誰も見ていないヒートマップツールのスクリプトなどを削除して整理するだけで、メインスレッドの負荷が劇的に軽くなり、INPが良好な水準へと回復するケースは非常に多く見られます。また、タップした瞬間にボタンの色や 모양を即座に変化させて「操作を受け付けたこと」を画面上に素早く描画する設計にすることも、INPの改善において有効なアプローチです。

CLS（Cumulative Layout Shift：累積レイアウトシフト）

CLS（Cumulative Layout Shift）は、ページが読み込まれている最中や閲覧中に、画面内のテキストや画像、ボタンなどの配置が予期せずガクッとずれる「レイアウトシフト」がどれくらい発生したかを数値化した指標です。時間を測るLCPやINPとは異なり、画面内で要素が移動した面積の割合と移動した距離を掛け合わせたスコアで算出され、0.1以下が良好、0.25を超えると不良と判定されます。

スマートフォンでホームページの文章を読んでいる最中に、遅れて読み込まれた画像やバナー広告が突然挿入されて文章が下に押し下げられたり、リンクをタップしようとした瞬間に画面がずれて別のボタンを誤って押してしまったりする現象は、ユーザーに強いストレスを与えます。CLSが悪化する原因の大半は、HTML内の画像タグ（img要素）や埋め込み要素（iframe要素）に横幅（width）と高さ（height）の指定が記述されていないため、画像ファイルが読み込まれるまでブラウザ側で表示領域のサイズを確保できないことに起因しています。

CLSは、ページの読み込み中や閲覧中に画面内の要素が意図せず動いてしまう「視覚的な不安定さ」を測る指標です。CLSがどのように計算され、どのような要素が画面のズレを引き起こしているのかを知ることで、ユーザーに誤タップや読みづらさのストレスを与えない堅牢なページ構造を作ることができます。

レイアウトシフトスコアの算出ロジック（影響割合と距離割合）とセッションウィンドウ

LCPやINPが「ミリ秒・秒」という時間を単位としているのに対し、CLSは画面のズレの大きさを表す独自のスコア（単位のない数値）で評価されます。このレイアウトシフトスコアは、「影響割合（Impact Fraction）」と「距離割合（Distance Fraction）」という2つの数値を掛け合わせることで算出されます。

影響割合とは、今見えている画面（ビューポート）全体の面積に対して、位置がズレた要素が「移動する前の領域」と「移動した後の領域」を合わせた面積がどれくらいの割合を占めたかを示す数値です。距離割合とは、画面の高さ（または横幅）に対して、その要素がどれだけの距離を移動したかを示す割合です。たとえば、画面の面積の50％を占める大きなテキストブロックが、遅れて読み込まれたバナーによって画面の高さの20％分だけ下へ押し下げられた場合、移動前後の影響領域は画面の70％（0.7）となり、移動距離の割合は20％（0.2）となるため、0.7×0.2＝0.14というCLSスコアがその1回のズレだけで記録されます。これだけで良好基準である0.1を超えてしまう計算になります。

また、現在のCLSの計測では「セッションウィンドウ」という集計方式が採用されています。ページを上から下まで長く閲覧している間に起きた小さなズレを無制限に足し算し続けると、滞在時間が長いページほど不利になってしまうため、発生したレイアウトシフトを最大5秒間の時間枠（セッションウィンドウ）ごとに区切って合計し、ページ滞在中に発生したウィンドウの中で最も数値が大きかった枠のスコアをそのページのCLS値として判定する仕組みになっています。

画像サイズ未指定以外にCLSを悪化させる代表的な要因（Webフォント・動的バナー・非同期要素）

CLSが悪化する最も典型的な原因は、画像タグ（img要素）や動画・地図などの埋め込みタグ（iframe要素）に横幅（width）と高さ（height）の属性、あるいはCSSによる縦横比（aspect-ratio）が指定されておらず、画像データが到着するまでブラウザが枠の高さを0として扱ってしまうことにありますが、現場ではそれ以外にもCLSを引き起こす代表的な要因が3つ存在します。

Webフォントの読み込みによる文字の再配置

1つ目は、Webフォントの読み込みによる文字の再配置です。デザイン性を高めるために外部の日本語Webフォントなどを読み込んでいるホームページでは、通信環境によってフォントデータの到着が遅れると、最初はスマートフォンやパソコンに最初から入っている標準フォントでテキストを表示し、数秒後にWebフォントが読み込まれた段階でフォントが切り替わる現象（FOUT：Flash of Unstyled Text）が起きます。標準フォントとWebフォントで文字のわずかな幅や行の高さが異なると、フォントが切り替わった瞬間に文章の改行位置がすべてズレてしまい、段落の高さが変わってページ全体にレイアウトシフトが発生します。

JavaScriptによって後から非同期で挿入される動的コンテンツ

2つ目は、JavaScriptによって後から非同期で挿入される動的コンテンツです。ページの読み込みが完了した一拍後に、画面の最上部へ突然挿入されるキャンペーンのお知らせバーや、既存のコンテンツを押し下げる形で表示されるCookie同意バナー、あるいは記事の途中に後から通信して埋め込まれる関連記事リストや高さが固定されていない広告枠などは、読んでいる最中の文章をガクッと下に移動させるため、CLSを大幅に悪化させます。通知バーやバナーを出す場合は、既存の要素を押し下げるのではなく、画面の上に重なるレイヤー（position: fixedなど）として表示するか、最初からその高さ分の空白領域（プレースホルダー）をHTML側で確保しておく必要があります。

CSSによるアニメーションの記述方法

3つ目は、CSSによるアニメーションの記述方法です。要素をスライドさせたり動かしたりする演出を入れる際、CSSのtop、left、margin、height、widthといった周囲の要素の配置（ジオメトリ）に直接影響を与えるプロパティを変化させて動かすと、ブラウザはそれをレイアウトシフトとして検知してしまいます。要素に動きをつける場合は、周囲のレイアウト配置に影響を与えずにGPU側で描画処理を行えるtransformプロパティ（translateによる移動やscaleによる拡大縮小など）を使用するのが正しい実装方法です。

ユーザーの操作に伴う正当な画面変化がCLSから除外される条件（500ミリ秒ルール）

画面内の要素の位置が動くとすべてCLSとして減点されるのではないかと懸念される方もいますが、Googleの計測仕様では「ユーザー自身の能動的な操作によって引き起こされた画面変化」はCLSの計算から除外されるルールになっています。

具体的には、ユーザーがリンクやボタンをクリック・タップしたり、キーボードを入力したりしてから「500ミリ秒（0.5秒）以内」に発生したレイアウトの移動については、ユーザーが自分の意思で起こした正当な画面変化とみなされ、CLSスコアには加算されません。たとえば、よくある質問のページで質問項目をタップして回答のテキストが下に広がり、それによって下の要素が押し下げられたとしても、タップしてから0.5秒以内に開き始めれば「予期せぬズレ」とは判定されない仕組みです。

ただし注意が必要なのは、ボタンをタップした後にサーバーへデータを取りに行く通信処理などが挟まり、500ミリ秒以上経過してから遅れて画面の要素が広がった場合です。操作から0.5秒が過ぎてしまった後の画面移動は、たとえユーザーのタップがきっかけであっても「時間差で起きた予期せぬレイアウトシフト」としてCLSに加算されてしまいます。通信を伴う要素を展開させる場合は、タップした瞬間にまず表示用の枠（スケルトン画面やローディング領域）を0.5秒以内に広げて場所を確保し、その確保された枠の中に後からデータを流し込むように設計することで、CLSの悪化を防ぐことができます。

コアウェブバイタルとSEOの現実的な関係性「加点」ではなく「減点回避」の指標

SEOの話題になると、コアウェブバイタルのスコア改善があたかも検索順位を劇的に引き上げる特効薬であるかのように語られることがあります。しかし、検索エンジンの仕組みと実際の検索結果の変動を専門的な視点から検証すると、コアウェブバイタルがSEOに与える影響の性質は、多くの人がイメージしているものとは少し異なります。

結論から述べると、コアウェブバイタルは「劇的に速くすればするほど検索順位が上がる加点方式の指標」ではなく、「一定以上の遅さや表示崩れがあるホームページの評価を下げる減点方式（足切り）の指標」と捉える方が正確です。

劇的に速くしても検索順位が急上昇するわけではない理由

Googleの検索アルゴリズムにおいて最も優先される評価基準は、あくまで「ユーザーの検索意図に対して、最も的確で信頼性が高く、有益な情報が記載されているか」というコンテンツの質と関連性、そして運営元の専門性や信頼性（E-E-A-T）です。どれほどページの表示速度が0.1秒単位で高速であっても、記載されている情報が薄っぺらであったり、検索キーワードの意図とズレていたりすれば、検索上位に表示されることはありません。

Google自身も公式ドキュメント等を通じて、ページエクスペリエンス（コアウェブバイタルを含む）は数あるランキングシグナルの一つであり、関連性の高い優れたコンテンツが存在する場合は、ページエクスペリエンスの数値が多少劣っていてもコンテンツの評価が優先される旨を明言しています。つまり、すでに実用上問題のない速度で表示されているホームページ（たとえばPageSpeed Insightsのスコアが70点〜80点台で、実際の体感がスムーズな状態）を、多大な労力をかけて95点や100点に引き上げたとしても、それによって検索順位が5位から1位に跳ね上がるような直接的なSEO効果はほぼ発生しないのが現実です。

一定以上の遅さがSEOの評価減点と機会損失を招く構造

一方で、ホームページの表示速度が一定の水準を下回り、極端に遅い状態になっている場合は話が別です。クリックしてから画面が表示されるまでに何秒も真っ白な状態が続いたり、操作するたびに画面がフリーズしたりするような「不良（Poor）」判定の領域に入ると、SEOにおいても事業上の成果においても明確なマイナス影響が生じます。

第一に、競合他社と同等レベルのコンテンツ品質を持っている場合、極端に遅いホームページはページエクスペリエンスの低評価によって検索順位の競争で競り負ける要因になります。第二に、サーバーの応答速度（TTFB）が著しく遅いホームページは、Googleの検索ロボット（クローラー）がページを巡回する際の効率（クロールバジェット）を悪化させます。サーバーの反応が鈍いと、クローラーが一定時間内に読み取れるページ数が減少し、新しく追加した記事や修正したページのインデックス登録や再評価が遅れる原因になります。

そして第三に、検索エンジンの評価以上に深刻なのが、訪問したユーザーの直帰（離脱）です。現代のインターネット利用者はページの読み込み遅延に対して非常にシビアであり、表示に3秒から5秒以上かかると半数近くのユーザーがページを見る前にブラウザの「戻る」ボタンを押してしまいます。せっかくSEOで検索上位を獲得しても、ページが開く前にユーザーが離脱してしまっては事業の売上や問い合わせには繋がりません。

PageSpeed Insightsのスコア至上主義が抱える罠

ホームページの表示速度を計測する際、Googleが提供する「PageSpeed Insights」を利用する方は多いですが、このツールの画面上部に大きく表示される「0〜100のパフォーマンススコア」だけを見て一喜一憂することには注意が必要です。

PageSpeed Insightsには、実際のChromeブラウザ利用者の統計データに基づく「フィールドデータ（実測データ）」と、特定のテスト環境（意図的に通信速度やCPU性能を制限したシミュレーション環境）で計測される「ラボデータ（診断スコア）」の2種類が存在します。Googleが検索ランキングの評価に参照しているのは前者のフィールドデータ（28日間の実ユーザーの体験データ）であり、後者の0〜100点のスコアそのものではありません。

ラボデータのスコアを100点に近づけることだけを目的にしてしまうと、事業に必要なアクセス解析ツール（Googleアナリティクスやタグマネージャー）や広告計測タグ、Webフォント、さらにはユーザーの理解を助ける高精細な図解画像やお問い合わせフォームの補助スクリプトまで削ぎ落とさなければならなくなります。見栄えやコンバージョン（成約）のための機能を犠牲にしてテスト上の点数だけを上げても、ホームページ本来の目的である事業成果が下がってしまっては本末転倒です。一定以上の遅さによる減点とユーザーの離脱を防ぎ、快適に閲覧できる水準を確保できていれば、スコアの細かな数字に固執する必要はありません。

ホームページの表示速度改善における歴史的変化｜職人技のテクニックから標準機能の自動化へ

ホームページの表示速度改善に対する考え方は、ここ10年ほどの間で大きく変化しました。かつてはWebエンジニアや制作者が手作業でソースコードを書き換え、複雑な設定を行わなければ達成できなかった高速化処理の多くが、現在ではブラウザ、サーバー、そしてWordPressをはじめとするCMS（コンテンツ管理システム）の標準機能として組み込まれるようになっています。

なぜ現代においては細かなテクニックに過度にこだわる必要がなくなったのか、その技術的な背景を整理します。

かつての表示速度改善で求められた細かな技術的チューニング

今から10年以上前のWeb制作現場では、通信回線やブラウザの描画性能、そしてHTTP/1.1という通信プロトコルの制約を補うために、制作者側で多くの技術的工夫を凝らす必要がありました。

たとえば、同時に通信できるファイル数の制限を回避するために、複数の小さなアイコン画像を1枚の画像に結合してCSSで表示位置を切り替える「CSSスプライト」という手法が使われていました。また、ブラウザの画面描画を止めないようにCSSやJavaScriptファイルを一つに結合して改行や空白を削るミニファイ（圧縮）作業を手動で行ったり、画面外の画像を遅れて読み込ませるために専用のJavaScriptライブラリ（jQueryプラグインなど）を導入してタグを書き換えたりといった、非常に手間のかかる作業が一般的でした。サーバーの設定ファイル（.htaccess）に複雑なキャッシュ制御コードやGzip圧縮の記述を手作業で追記することも、当時の速度改善における定番のテクニックでした。

現代の標準的な仕組みで自動的に改善される主要要素

しかし現在では、インターネット全体の通信規格がHTTP/2やHTTP/3へと進化したことで複数のファイルを同時に高速通信できるようになり、ブラウザやサーバー、WordPress自体の機能も飛躍的に向上しました。その結果、特別な裏技や複雑なカスタマイズを施さなくても、基本的な環境を整えるだけで大部分の速度改善が自動的に行われるようになっています。

各種キャッシュ機構とサーバーキャッシュの進化

現代の表示速度改善において最も大きな役割を果たしているのが、キャッシュ（一度処理したデータやファイルを一時保存して再利用する仕組み）の進化です。特に近年では、ホームページ側で複雑なキャッシュプラグインを設定しなくても、レンタルサーバー会社側で高性能な「サーバーキャッシュ（コンテンツキャッシュ・アクセラレーター）」や「ブラウザキャッシュ設定」が標準機能として用意されているケースが増えています。

サーバー会社の管理画面でスイッチをオンにするだけで、Webサーバー（NGINXやLiteSpeedなど）が生成済みのページデータをメモリ上に保持し、アクセスがあった際にプログラムの処理を省略して瞬時にページを返す仕組みが整っています。

画像や埋め込み要素の遅延読み込み（Lazy Loading）の標準化

ページ内の下部にある画像やYouTubeなどの埋め込み動画を、ユーザーが画面をスクロールして近づくまで読み込まないようにする「遅延読み込み（Lazy Loading）」も、現在ではブラウザの標準機能（loading=”lazy”属性）としてサポートされています。

さらにWordPressにおいては、バージョン5.5以降からこの遅延読み込みの属性が画像やiframeタグに自動的に付与される仕様が本体に組み込まれました。かつてのように外部のJavaScriptライブラリを読み込ませて無理やり遅延読み込みを実装する必要はなくなり、標準状態のままで初期読み込み時の通信量を大幅に削減できるようになっています。

JavaScriptの非同期読み込み（async・defer）と優先度制御

ページの表示速度（特にLCPやINP）を低下させる要因であったJavaScriptの読み込みによる描画ブロックについても、WordPressのバージョンアップによって根本的な改善が進んでいます。たとえばWordPress 6.3以降では、スクリプトを非同期で読み込む「async」や、HTMLの解析が終わってから実行させる「defer」といった制御がWordPressのコア機能（スクリプトAPI）として統合されました。

また、ページ内で最も重要なメイン画像（LCP要素となる画像）を自動的に判別し、ブラウザに対して最優先で読み込むよう指示する属性（fetchpriority=”high”）を自動付与する仕組みもWordPress本体に組み込まれています。つまり、ある程度以上の新しいバージョンのWordPressと、その仕様に準拠したテーマを使用していれば、裏側で自動的に高度な優先度制御や非同期処理が行われる設計になっています。

次世代フォーマット画像（WebP・AVIF）と画像サイズの最適化

ホームページのデータ容量の大部分を占める画像ファイルについても、従来のJPEGやPNGに代わって、画質を維持したままファイルサイズを大幅に圧縮できる次世代フォーマット（WebPやAVIF）が全主要ブラウザで標準対応となりました。WordPressでもバージョン5.8からWebPに、バージョン6.5からはさらに圧縮率の高いAVIFに標準対応しています。

加えて、アップロードされた1枚の画像から複数のサイズを自動生成し、閲覧している端末（パソコン、タブレット、スマートフォン）の画面幅に合わせて最適なサイズの画像を配信するレスポンシブ画像機能（srcset属性）も標準で動作します。適切なサイズで画像を書き出し、次世代フォーマットを活用するだけで、画像に関する速度低下の大部分は解消されます。

ホームページの軽量化・高速表示化【SEO内部対策】

ホームページが極端に遅い本当の理由｜現場で判明する3つの構造的ボトルネック

ここまで見てきたように、現代のホームページ制作環境では、標準的な仕組みだけで十分な表示速度が出るように設計されています。それにもかかわらず、「自社のホームページの読み込みが異常に遅い」「PageSpeed Insightsで著しく低い評価が出ている」という場合、その原因はどこにあるのでしょうか。

数多くのホームページ制作や修正・改修の現場を調査してきた実情から申し上げると、あまりに遅いホームページの原因は、CSSの記述方法といった細かなテクニックの不足ではなく、サーバー環境やPHPのバージョン、データベースの状態といった根本的な部分に問題があるケースがほとんどです。

PHPのバージョンが古く処理速度が著しく低下している

WordPressをはじめとする動的なホームページは、ユーザーからアクセスがあるたびにサーバー上で「PHP」というプログラミング言語が動き、データベースから記事や設定の情報を引き出してHTMLページを組み立てています。このPHPのバージョンが古いことこそが、ホームページの表示が遅くなる最大の原因の一つです。

特に、PHP 5系やPHP 7系（7.0〜7.4など）のまま運用されているホームページと、現在の主流であるPHP 8系（8.1、8.2、8.3など）で運用されているホームページとでは、プログラムの実行速度に圧倒的な差があります。PHP 8系では内部エンジンの改良やJIT（Just-In-Time）コンパイラなどの技術導入により、PHP 7系と比較しても処理速度が大幅に向上し、メモリ消費量も抑えられています。

なぜ多くのホームページが古いPHPのまま放置されているかというと、「昔制作したWordPressテーマ（または古いプラグイン）がPHP 7系までしか対応しておらず、サーバーの管理画面でPHP 8系に切り替えると画面が真っ白になってエラーが出るため、古いPHPのままにせざるを得ない」という事情が背景にあります。この古いPHPによる処理の遅さが、サーバーの応答時間（TTFB）を直接的に悪化させています。

安価なサーバーや旧世代のサーバー契約でレスポンス（TTFB）が遅い

もう一つの大きな要因が、ホームページを設置しているレンタルサーバー自体の性能不足です。月額数百円（100円〜500円程度）で提供されている格安のレンタルサーバーや、コスト削減を最優先にしたプランでは、1台の物理サーバーに大量の契約者を詰め込んでいたり、CPUやメモリの割り当てが極端に制限されていたりすることが少なくありません。

また、意外と見落とされがちなのが「有名大手レンタルサーバーを10年前から継続契約しているケース」です。同じサーバー会社の同じプラン名であっても、10年前に契約したまま一度もサーバー移行（新サーバーへの引っ越し機能などの利用）を行っていない場合、ホームページのデータは10年前の古い世代のハードウェア（旧式のCPUやHDD・初期世代SSDなど）の上で稼働し続けていることがあります。

サーバー自体の基礎体力や応答性能が低いと、ブラウザがページを要求してから最初の1バイトのデータが返ってくるまでの時間（TTFB）だけで2秒も3秒もかかってしまいます。サーバーからの返事が遅ければ、その後にブラウザ側でどれほど高度な画像圧縮や非同期読み込みを行っても、コアウェブバイタルのLCP（最大視覚コンテンツの表示時間）が良好になることはありません。

WordPressの投稿リビジョンや不要データによるデータベースの肥大化

サーバーのスペックやPHPのバージョンに加えて、長期間運用されているWordPressで頻繁に発生するのが「データベースの肥大化」によるレスポンス低下です。

WordPressには、記事を作成・編集している最中に変更履歴を自動保存する「リビジョン（投稿リビジョン）」という便利な機能があります。しかし、リビジョンの保存数に制限をかけないまま何年も記事の更新や修正を繰り返していると、1つの記事に対して何十件、サイト全体で数万件もの過去のリビジョンデータがデータベース（wp_postsテーブルなど）に蓄積されていきます。

さらに、過去にインストールして削除したプラグインが残した不要な設定データや、一時保存データ（トランジェント）、そしてページを開くたびに毎回自動で読み込まれる設定領域（wp_optionsテーブルのautoloadデータ）が肥大化すると、データベースの検索・抽出処理に時間がかかるようになります。その結果、ページを生成する際のサーバー内部処理が重くなり、表示速度や管理画面の操作速度が目に見えて低下していきます。

補足：旧式であっても静的HTMLのホームページが高速な理由

ここで一つ、技術的な誤解を解くために補足しておきます。「昔作られた古いホームページだから遅い」と一括りにされがちですが、正確には「古い環境のWordPressなどの動的システムだから遅い」のであり、旧式であっても「静的HTML」で作られたホームページであれば、表示速度は非常に高速です。

静的HTMLのホームページは、アクセスがあった際にPHPプログラムを動かしたりデータベースに問い合わせたりする工程が一切存在しません。サーバー上にすでに完成した状態で置かれているHTMLファイルと画像ファイルをそのままブラウザに送り返すだけなので、サーバーの負荷が極めて低く、安価なサーバーであっても瞬時に画面が表示されます（もちろん、1枚10MBもあるような未加工のデジカメ写真をそのまま貼り付けているような場合は除きます）。

したがって、表示速度の問題で頭を抱えるケースの大半は、WordPressなどの便利な更新システムを導入していながら、そのシステムを動かす裏側の環境（サーバー、PHP、WordPress本体、テーマ、データベース）が古い状態で止まっていることに起因しています。

費用対効果の高い現実的な改善 細かい修正よりも環境刷新が有効な理由

ホームページの表示速度を改善し、コアウェブバイタルの評価を健全な水準に引き上げるにあたって、事業者が取るべき最も賢明な選択は何でしょうか。

正直なところ、よほど特殊なアニメーションを多用しているサイトや極端に旧式のシステムでない限り、CSSの記述順序を1行ずつ入れ替えたり、JavaScriptのコードを細かく削ったりするような技術面の微調整に多大なコストをかける必要はあまりないのかもしれません。それよりも、現状のホームページを取り巻く古い環境を最新のものに刷新していく方が、はるかに少ない手間で、なおかつ劇的な速度改善効果を得ることができます。

月額数百円の安価なサーバーから月額2000円前後の標準的なサーバーへの移行

もし現在、月額数百円の格安レンタルサーバーを利用している場合や、何年も前に契約した古いサーバープランのまま運用している場合は、月額1000円〜2000円前後の現代の標準的な高性能レンタルサーバー（高速なNVMe SSDを搭載し、十分なCPU・メモリリソースとサーバーキャッシュ機能を備えたプラン）へ乗り換えるだけで、表示速度が劇的に改善されることがよくあります。

月額数百円のサーバーを月額2000円程度のサーバーに変更したとしても、事業におけるコストの差は月にわずか1000円〜1500円程度、年間でも1万数千円から2万円程度の違いに過ぎません。細かなプログラム修正を外部の制作会社に依頼して数十万円の費用をかけるよりも、サーバーという土台そのものを最新の高速環境へ移行する方が、初期費用も手間も圧倒的に少なく、しかもサイト内の全ページが一斉に高速化されます。

PHP8系対応のWordPressテーマへの変更とPHPバージョンの最新化

現在使用しているWordPressテーマが古く、PHP 7系（あるいはPHP 5系）でしか動作しないためにバージョンアップが止まっている場合は、テーマをPHP 8系に対応したものへ変更（または改修）し、サーバーのPHPバージョンを8以上（PHP 8.2や8.3など）へ引き上げることが非常に有効です。

PHPのバージョンを7系から8系へ変更し、あわせてWordPress本体やプラグインを最新の状態にアップデートするだけで、サーバー内部でのプログラム処理速度が大幅に短縮されます。さらに、先述した通り最新のWordPress本体には画像の遅延読み込みや優先度制御（fetchpriority）、スクリプトの非同期処理などが最初から組み込まれているため、テーマとPHPとWordPress本体を最新化するだけで、個別の高速化テクニックを一つずつ手作業で実装しなくても、自動的にコアウェブバイタルの各指標が改善されていきます。

データベースの整理とリビジョン管理の適正化

長年運用しているWordPressにおいて、管理画面の動作やページの初期応答が重くなっている場合は、データベース内の不要な投稿リビジョンやゴミ箱内のデータ、期限切れの一時データを整理（クリーニング）することでレスポンスが回復します。

一度溜まりすぎたリビジョンデータを安全に削除した上で、今後は1記事あたりに保存するリビジョン数を3件〜5件程度に制限する設定を入れておけば、将来にわたってデータベースが肥大化するのを防ぐことができます。これもデザインの変更や複雑なコード改修を伴わずに、短時間で実施できる効果的な改善策です。

ホームページの改修とセキュリティ・保守性の同時改善という事業上のメリット

サーバーの見直しやPHP 8系への対応、WordPressの最新化というアプローチが優れている理由は、単に表示速度（コアウェブバイタル）が改善されるだけにとどまらない点にあります。

古いPHPバージョンや古いWordPressを放置し続けることは、セキュリティ上の脆弱性を抱えたままホームページを公開し続けることを意味し、改ざんや不正アクセスのリスクを高めます。また、レンタルサーバー会社側で古いPHPバージョンの提供が完全に終了（強制アップデート）された際、ある日突然ホームページが真っ白になって表示されなくなるという事業上の大きなトラブルにも直結します。

つまり、速度改善をきっかけとして最新の環境へ移行することは、コアウェブバイタルによるSEOの減点回避とユーザーの離脱防止を実現すると同時に、ホームページのセキュリティ強化と長期的な安定稼働を一度に達成できる、極めて合理的な投資といえます。

事業成長を見据えたコアウェブバイタルとSEOへの向き合い方

ホームページ（ウェブサイト）は、それ自体が目的ではなく、事業の魅力や強みを正しく伝え、見込み客からの信頼を獲得し、お問い合わせや売上といった成果を生み出すための大切な事業資産です。コアウェブバイタルや表示速度の改善についても、この本来の目的から外れないようにバランス感覚を持って向き合うことが重要です。

技術的な細部に固執しすぎず本質的なボトルネックを解消する

WebマーケティングやSEOの情報を調べていると、専門用語が並んだ細かな高速化テクニックに目を奪われがちですが、枝葉の部分にばかり気を取られて幹の部分を見失っては意味がありません。

まずは、極端に巨大なサイズの画像をそのまま貼っていないかを確認し、その上で「サーバーの性能と世代」「PHPのバージョン」「WordPress本体とテーマのバージョン」「データベースの状態」という大きなボトルネックを点検してみてください。これらを現代の標準的な最新環境へと整え、サーバー側のキャッシュ機能などを適切に有効化すれば、それだけで大多数のホームページは十分に快適な表示速度に達し、コアウェブバイタルにおけるSEO上の減点リスクも解消されます。

表示速度の確保を前提としたコンテンツ品質と導線設計の追求

基本的な環境整備によって「遅すぎて検索エンジンから減点される」「遅すぎてユーザーが読む前に離脱する」というマイナス要因を取り除いた後は、1ミリ秒の速度短縮やテストスコアの1点の上昇に執着するのをやめ、本来注力すべき領域へとリソースを振り向けるべきです。

検索ユーザーが本当に知りたい疑問に深く答える専門性の高い記事の作成、自社の実績や強みが明確に伝わるページの拡充、そして訪問した人が迷わずお問い合わせや申し込みへと進める分かりやすい導線設計こそが、検索順位を引き上げ、事業の成果を最大化する直接的な原動力になります。コアウェブバイタルはあくまで快適にホームページを見てもらうための「土俵（前提条件）」として堅実にクリアし、その上で中身のある本質的なWebマーケティングを展開していくことが、長期的に揺るがないホームページ運営へと繋がっていきます。

SEO（検索エンジン最適化）対策と費用・料金