はじめに：ユーザーは「3秒」待ってくれません
あなたは、スマホで検索して気になるサイトを開いた時、画面が真っ白のまま動かなかったらどうしますか？
おそらく、数秒待って「戻るボタン」を押し、別のサイトへ移動するでしょう。
Googleの調査によると、モバイルページの読み込みに3秒以上かかると、53%のユーザーが離脱すると言われています。
ページ表示速度は、単なる「快適さ」の問題ではなく、SEO（検索順位）とビジネスの売上に直結する最重要課題です。
この記事では、なぜGoogleがこれほどまでに「速度」を重視するのか、そして2025年のSEOにおいて必須となる指標「Core Web Vitals」について、初心者にもわかりやすく解説します。
1章：表示速度は「ランキング要因」である
結論から言うと、ページ表示速度はGoogleの検索アルゴリズムにおける「ランキング要因（順位決定要素）」の一つです。
これはGoogleが公式に認めており、特にモバイル検索においてその傾向は顕著です。
なぜGoogleは速度を重視するのか？
Googleの使命は「ユーザーにとって有益な情報を、最も快適な形で届けること」です。
いくら内容が素晴らしい記事でも、表示されるまでに10秒もかかるサイトは「ユーザーをイライラさせる低品質なサイト（UXが悪い）」と判断されます。
結果として、以下のような悪循環に陥ります。
- 表示が遅い
- ユーザーがすぐ離脱する（直帰率の上昇）
- 滞在時間が短くなる
- Googleが「このページは価値がない」と判断する
- 検索順位が下がる
2章：SEOの通信簿「Core Web Vitals」とは？
では、具体的に「何がどうなれば合格」なのでしょうか？
その基準となるのが、Googleが定めた3つの指標「Core Web Vitals（コアウェブバイタル）」です。
2025年現在、以下の3つが健全なサイトの条件とされています。
1. LCP (Largest Contentful Paint) ：読み込み速度
「メインのコンテンツが表示されるまでの時間」です。
ページを開いてから、一番大きな画像や見出しが表示されるまでの時間を指します。
- 2.5秒以内：合格（Good）
- 4.0秒超：不合格（Poor）
ユーザーが「あ、画面が表示されたな」と認識できる最初の瞬間であり、最も重要な指標です。
2. INP (Interaction to Next Paint) ：応答性
「タップやクリックに対する反応速度」です。
以前はFID（First Input Delay）という指標でしたが、2024年3月からINPに置き換わりました。
ボタンを押したのに反応がない、メニューが開かないといった「もっさり感」を評価します。
- 200ミリ秒以内：合格（Good）
- 500ミリ秒超：不合格（Poor）
3. CLS (Cumulative Layout Shift) ：視覚的安定性
「レイアウトのズレ」です。
記事を読んでいる最中に、遅れて広告画像が表示され、本文がガクッと下にズレて「誤タップ」してしまった経験はありませんか？
このような不快なレイアウト移動を数値化したものです。
- 0.1以下：合格（Good）
- 0.25超：不合格（Poor）
3章：サーバーと画像の最適化が鍵を握る
これらの指標を改善するためには、サイトの中身だけでなく、土台となるサーバー環境も重要です。
「格安レンタルサーバー」を使っている場合、アクセスが集中すると応答速度（TTFB）が遅くなり、LCPの悪化を招くことがあります。
また、現代のWebサイトにおいて容量の大部分を占めるのは「画像」です。
高画質な写真をそのまま貼り付けていると、それだけで「速度のペナルティ」を受けているようなものです。
次回の第2部では、自分のサイトがこれらの基準を満たしているかどうかを調べる「測定ツール」の使い方を解説します。
Google公式の「PageSpeed Insights」の見方や、Search Consoleでのエラー確認方法をマスターしましょう。
4章：まずは現状把握！2大測定ツールの正しい使い方
「なんとなく遅い気がする」という感覚値ではなく、具体的な数値でサイトの状態を把握しましょう。
使用するのは、Googleが提供している以下の2つの無料ツールです。
1. PageSpeed Insights（ページスピードインサイト）
特定の「1ページ」の速度を詳細に分析するツールです。
トップページや主要な記事ページのURLを入力するだけで、0〜100点のスコアと改善項目が表示されます。
- モバイルとデスクトップ：タブで切り替えられますが、SEOで重要なのは圧倒的に「モバイル」のスコアです。
- Core Web Vitalsの合否：画面上部に「合格」「不合格」の判定が出ます。ここが赤（Poor）になっている場合は緊急の対策が必要です。
- 改善できる項目：「次世代フォーマットでの画像の配信」や「使用していないJavaScriptの削減」など、具体的な指示が表示されます。
2. Google Search Console（サーチコンソール）
サイト「全体」の健康状態を監視するツールです。
メニュー内の「エクスペリエンス」＞「ウェブに関する主な指標」を見ると、サイト内で速度に問題があるURLの数と推移がグラフで確認できます。
（参考：Search Consoleの使い方）
5章：スコアの目安は？100点を目指す必要はない
PageSpeed Insightsを使ってみると、モバイルのスコアが「30点」や「40点」と表示され、ショックを受ける方が多いです。
しかし、慌てる必要はありません。
目指すべき現実的なライン
- 90〜100点（緑）：理想ですが、デザインや機能を犠牲にしないと到達できない場合が多いです。無理に目指す必要はありません。
- 50〜89点（オレンジ）：ここを目指しましょう。多くのWebサイトはこの範囲内であれば、SEO的に大きなマイナスにはなりません。
- 0〜49点（赤）：改善が必要です。特にLCP（読み込み時間）が遅い場合は、ユーザーの離脱に直結しています。
Googleのジョン・ミューラー氏も「スピードはランキング要因の一つだが、コンテンツの品質より優先されるわけではない」と発言しています。
スコアゲームに陥るのではなく、あくまで「ユーザーがストレスなく閲覧できるか（Core Web Vitalsが緑になっているか）」を最優先基準にしてください。
6章：診断結果から「改善の優先順位」を決める
PageSpeed Insightsにはたくさんの改善案が表示されますが、全てを実行するのは技術的に難しい場合があります。
効果が高く、かつ比較的対応しやすい順に対策しましょう。
優先度「高」：画像の最適化
「改善できる項目」で最もよく指摘されるのが画像関連です。
「画像を適切なサイズにする」「次世代フォーマット（WebP）を使う」などは、プラグイン導入などで比較的簡単に解決でき、かつ容量削減効果が絶大です。
優先度「中」：サーバー応答時間の短縮
LCPの数値が悪い場合、そもそもサーバーの性能不足である可能性があります。
キャッシュプラグインを入れるか、サーバー自体を高性能なものに乗り換える検討が必要です。
優先度「低」：JavaScriptの削減
プログラムのコードをいじる必要があるため、専門知識がないとサイトが壊れるリスクがあります。
ここは制作会社やエンジニアに相談すべき領域です。
次回の第3部では、優先度「高」の項目である「LCP（読み込み速度）」の具体的な改善テクニックについて解説します。
誰でもできる「画像のWebP化」から、ちょっと高度な「キャッシュ設定」まで、サイトを劇的に軽くする方法を紹介します。
7章：LCP悪化の犯人は9割が「画像」
PageSpeed InsightsでLCPの評価が低い場合、その原因のほとんどは「画像の容量が大きすぎること」にあります。
スマホで撮影した数MBの写真を、そのままリサイズせずにアップロードしていませんか？それは、道路に巨大な岩を置いて渋滞させているようなものです。
対策1：次世代フォーマット「WebP」を使う
従来のJPGやPNGに比べて、画質を保ったまま容量を30%〜50%も軽量化できるのが、Googleが推奨する画像形式「WebP（ウェッピー）」です。
現在、主要なブラウザは全て対応しています。
【WordPressユーザーの場合】
「EWWW Image Optimizer」などのプラグインを導入し、「WebP変換」の設定をONにするだけで、過去の画像も含めて自動的に変換してくれます。
（参考：WordPressのプラグイン管理）
対策2：画像の遅延読み込み（Lazy Load）
ページを開いた瞬間に、画面外（スクロールしないと見えない部分）にある画像まで読み込む必要はありません。
「Lazy Load」を設定すれば、ユーザーがスクロールして画像が表示エリアに近づいたタイミングで初めて読み込みが開始されます。
これにより、初期表示（LCP）にかかる通信量を大幅に削減できます。
8章：サーバーの応答速度（TTFB）を改善する
画像がどれだけ軽くても、データを送ってくるサーバー自体が遅ければ意味がありません。
「最初の1バイトが届くまでの時間（TTFB）」が遅い場合は、以下の対策を検討しましょう。
対策1：キャッシュ（Cache）を利用する
WordPressなどの動的サイト（アクセスごとにページを生成する仕組み）は、その処理に時間がかかります。
「キャッシュ」とは、一度生成したページを一時保存しておき、2回目以降のアクセスにはその保存データを返す仕組みです。
「WP Super Cache」や「W3 Total Cache」などのプラグイン導入が有効ですが、設定を間違えると表示崩れの原因になるため注意が必要です。
対策2：サーバー自体の乗り換え
月額数百円の格安サーバーを使っている場合、スペックの限界かもしれません。
最新の「NVMe SSD」を搭載した高速サーバーや、PHPのバージョンを最新（8.x系）にするだけで、表示速度が2倍以上になることも珍しくありません。
SEOに本気で取り組むなら、サーバーへの投資は最もコスパの良い施策です。
（参考：サーバー移行の手順）
9章：さらに速く！CDN（コンテンツデリバリーネットワーク）の活用
上級者向けのテクニックですが、「CDN」を使うという手もあります。
これは、画像やCSSなどの静的ファイルを、自社サーバーではなく、世界中に分散された専用サーバー（エッジサーバー）から配信する仕組みです。
Cloudflare（クラウドフレア）などが有名で、アクセスが集中してもサーバーがダウンしにくくなり、物理的に距離が近いサーバーからデータが届くため、速度が劇的に向上します。
次回の第4部では、残る2つの指標「INP（応答性）」と「CLS（レイアウトのズレ）」の改善方法について解説します。
「ボタンを押したのに反応しない」「読んでる途中で画面がガクッと動く」といった、ユーザー体験を損なう現象を防ぐための技術的な対策をお伝えします。
10章：INP改善｜「タップしても反応しない」をなくす
INP（Interaction to Next Paint）が悪化する主な原因は、「重いJavaScriptの処理」がブラウザのメインスレッドを占有してしまうことです。
サーバーからデータは届いているのに、裏側でプログラムが一生懸命動いているせいで、ユーザーの「タップ」を受け付けられない状態です。
対策1：JavaScriptの「遅延読み込み（Defer/Async）」
ページの表示に必須ではないプログラム（例：SNSのシェアボタン、アクセス解析タグ、チャットボットなど）は、後回しで読み込ませましょう。
HTMLの<script>タグにdeferやasync属性を付けることで、描画をブロックせずに裏側で読み込ませることができます。
対策2：不要なアニメーションや機能を削る
過剰な動きのあるデザインや、複雑なハンバーガーメニューの実装などが原因になることもあります。
「Autoptimize」や「Flying Scripts」などのプラグインを使えば、特定のJavaScriptファイルの実行を「ユーザーがアクションを起こすまで待機させる」といった高度な制御も可能です。
11章：CLS改善｜「読んでる途中でズレる」を防ぐ
CLS（Cumulative Layout Shift）は、主に「画像のサイズ指定忘れ」や「Webフォントの読み込み遅れ」によって発生します。
ユーザーが誤って広告をクリックしてしまう原因にもなり、非常に嫌われる要素です。
対策1：画像や動画にwidthとheightを指定する
ブラウザは画像を読み込むまで、その「大きさ」を知りません。
そのため、読み込みが終わった瞬間に「グイッ」とスペースを広げてしまい、レイアウトがズレます。
これを防ぐには、全ての<img>タグや動画埋め込み（iframe）に、あらかじめ幅（width）と高さ（height）を指定しておきます。
そうすれば、ブラウザは「ここにこれだけのスペースが必要だな」と事前に場所を確保してくれるため、ズレが発生しません。
対策2：Webフォントのチラつきを防ぐ
Google FontsなどのWebフォントを使っていると、フォントデータが届くまでの間、文字が表示されなかったり、代替フォントから切り替わる瞬間に文字幅が変わってレイアウトがズレたりします。
CSSでfont-display: swap;を指定すれば、「最初は代替フォントですぐに表示し、データが届き次第スムーズに切り替える」という挙動になり、CLSの悪化を最小限に抑えられます。
12章：それでも直らない時は？「第三者スクリプト」を疑え
自社のコードをどれだけ最適化しても、INPやLCPが改善しない場合があります。
その犯人は、外部から読み込んでいる「第三者スクリプト」かもしれません。
- Google AdSenseなどの広告タグ
- InstagramやXの埋め込みタイムライン
- 高機能なアクセス解析ヒートマップ
これらは外部サーバーからデータを取得するため、どうしても遅延の原因になります。
「本当にその位置に広告が必要か？」「全ページでヒートマップを動かす必要があるか？」を見直し、不要なページでは読み込まない設定にするのが賢明です。
次回の最終回（第5部）では、これまでの総仕上げとして「モバイル最適化（スマホでの速度改善）」に特化したテクニックと、AMP（アンプ）の現状、そしてよくある質問への回答をまとめてお届けします。
13章：PCとは違う！モバイル特有の「重さ」に対処する
PageSpeed Insightsで計測すると、PCスコアは90点なのに、モバイルスコアは40点…という現象はよく起こります。
これは、スマホがPCに比べて「CPU性能が低い」ことと、「通信環境（4G/5G）が不安定」であることが原因です。
モバイルファーストインデックス（MFI）の導入により、Googleは「スマホサイトの評価」を基準に順位を決めています。
つまり、PCサイトがどれだけ速くても、スマホサイトが遅ければSEO評価は上がりません。
スマホ最適化の鉄則
- 画像をPCと分ける
PC用の巨大な横長バナーを、スマホでそのまま縮小表示させていませんか？
HTMLの<picture>タグを使い、スマホ（画面幅が狭い時）には「スマホ用にリサイズ・トリミングした軽量画像」を読み込ませるように指定しましょう。 - 動画の自動再生を避ける
ファーストビュー（トップページ上部）での動画背景はリッチですが、スマホでは通信量を食い潰す要因です。
スマホ時は「静止画」に切り替えるか、再生ボタンを押さない限り読み込まない設定にしましょう。
14章：AMP（アンプ）はもう不要？2025年の現状
数年前まで、モバイル高速化の切り札としてGoogleが強く推奨していた「AMP（Accelerated Mobile Pages）」ですが、現在はどうなっているのでしょうか？
結論：無理に導入する必要はない
以前は、AMP対応していないとスマホ検索の「トップニュース枠」に掲載されないという優遇措置がありました。
しかし現在、Googleはその要件を撤廃し、「Core Web Vitalsさえ満たしていれば、AMPでなくても優遇する」という方針に転換しています。
AMPはデザインの制約が厳しく、導入・管理のコストも高いため、今から新規で導入するメリットは薄れています。
通常のHTMLサイトを軽量化（WebP化やキャッシュ利用）する「正攻法」で十分戦えます。
15章：速度改善に関するQ&A
- Q. JimdoやWixなどの作成ツールを使っていて、どうしても速くなりません。
-
A. ツールの仕様上、限界があります。
JimdoやWixなどのSaaS型サービスは、手軽に作れる反面、サーバー設定やコードを自由にいじれないため、根本的な速度改善が難しい場合があります。
画像の圧縮などできる限りのことをやって、それでも遅すぎる場合は、WordPressなどの自由度の高いCMSへの移行（SEO対策の本格化）を検討する時期かもしれません。 - Q. スコア100点満点を取る必要はありますか？
-
A. ありません。90点（緑色）になれば十分です。
100点を目指して必要な機能やデザインまで削ってしまうと、本末転倒です。
ユーザーがストレスを感じないレベル（LCP 2.5秒以内）を達成していれば、それ以上の微差はランキングに影響しません。 - Q. 速度を上げるとコンバージョン（売上）も上がりますか？
-
A. 確実に上がります。
Amazonの調査では「0.1秒の遅延で売上が1%減少する」というデータがあります。
SEOだけでなく、Web集客の最終目的である「成約率」を高めるためにも、表示速度の改善は最強の投資です。
16章：まとめ｜速度は「おもてなし」の基礎である
全5回にわたり、ページ表示速度とCore Web Vitalsについて解説してきました。
Webサイトにおける「速さ」とは、リアル店舗における「入店しやすさ」や「接客のスムーズさ」と同じです。
どれだけ美味しい料理（コンテンツ）を用意していても、注文してから30分待たされる店には、二度と行きたくないはずです。
Googleのためではなく、あなたのサイトを訪れてくれる大切なお客様のために。
今日からできる改善を一つずつ積み重ね、快適なWeb体験を提供していきましょう。
⚡ あなたのサイト、もっと速くできます
「PageSpeed Insightsのスコアが赤色のまま…」
「WordPressが重くて表示に時間がかかる」
OMNIWEBでは、専門エンジニアによる「サイト高速化チューニング」を提供しています。
現状のボトルネックを診断し、デザインを崩さずにスコアを改善します。
