サイトスピード（表示速度）の目安と改善方法｜測定から根本対策まで

「自社のホームページは遅いのか、速いのか。何を基準に判断して、どこから直せばよいのか知りたい」

サイトスピード（表示速度）は、感覚ではなくGoogleが公開している基準値で判断できます。この記事では、表示速度の目安、無料ツールでの測定方法、原因別の改善策、そして画像やプラグインを整理しても遅い場合に「サイトの構成から見直す」方法までを順に解説します。

サイトスピード（表示速度）の目安

表示速度の目安には、Googleが定める「Core Web Vitals（コアウェブバイタル）」の3指標を使います。Search Consoleの評価もPageSpeed Insightsの実測データも、この基準で「良好」「改善が必要」「不良」に分かれます。

判定は1回の測定ではなく、実際の訪問の75%（75パーセンタイル）がこの値を満たしているかで行われ、スマートフォンとパソコンは別々に評価されます。INPは2024年3月に、それまでのFID（First Input Delay）に代わって正式な指標になりました。

あわせて、サーバーが最初の応答を返すまでの時間（TTFB）も確認しておくと原因を絞り込めます。web.devではTTFB 0.8秒以内を目安としています。

表示速度が遅いと何が起きるか

表示が遅いと、まず訪問者が離れます。Googleが2017年に公開したモバイルサイトの調査では、読み込み時間が1秒から3秒に延びると直帰の確率は32%、1秒から5秒では90%高まるとされています。

検索順位への影響については、GoogleはCore Web Vitalsを検索のランキングシステムが評価する「ページエクスペリエンス」の一部としています。ただし、最も重視されるのは内容が検索した人の役に立つかどうかで、速度だけで順位が大きく上がるわけではありません。速度は「内容で選ばれたときに不利にならないための土台」と考えるのが正確です。

サイトスピードを測定する方法

測定では、実際の訪問者の環境で測った「フィールドデータ」と、ツールがその場で測る「ラボデータ」を分けて見ることが大切です。Googleの評価に使われるのはフィールドデータです。

PageSpeed Insightsでページごとに測る

PageSpeed InsightsにURLを入れると、1ページずつ次の2つが表示されます。

• 上段「実際のユーザーの環境で評価する」：Chromeの利用者から集めた過去28日間のフィールドデータ。LCP・INP・CLSが基準を満たしているかがわかる
• 下段「パフォーマンスの問題を診断する」：Lighthouseによるラボデータ。0〜100のスコア（90以上が良好、50〜89が改善が必要、49以下が不良）と、改善の候補が表示される

アクセスの少ないページは上段のデータが出ないことがあります。その場合は下段のスコアと改善候補を手がかりにします。スコアは測るたびに数点変わるため、1回の数字に一喜一憂せず、改善候補のうち削減効果の大きいものから手を付けましょう。

Search Consoleでサイト全体を見る

Search Consoleの「ウェブに関する主な指標」では、サイト全体のURLが「良好」「改善が必要」「不良」にグループ分けされます。どの種類のページで問題が起きているかをまとめて把握でき、修正後に「修正を検証」を押すと、改善したかどうかを28日間かけて確認してくれます。

Chromeの開発者ツールで原因を調べる

原因を詳しく調べるときは、Chromeの開発者ツール（Lighthouseタブ・パフォーマンスタブ）を使います。修正しながらその場で測り直せるため、制作会社や社内の担当者が作業するときに便利です。

原因別の改善方法

測定結果で基準を外れた指標から、原因を絞り込んで直します。

画像を軽くする（LCP）

多くのページで、データ量のいちばん大きな部分は画像です。

• 表示する大きさに合わせて縮小してから掲載する（横幅1,200pxで表示する場所に4,000pxの写真を載せない）
• WebPやAVIFなど、JPEGより軽い形式で配信する
• 画面の下の方にある画像は loading="lazy" で後から読み込む
• 反対に、最初に見える大きな画像（LCPの対象）は遅延読み込みにせず、fetchpriority="high" で優先して読み込む

JavaScriptと外部タグを減らす（INP・LCP）

使っていないスライダー、アニメーション、古いjQueryのプラグイン、試しに入れたまま残っている計測タグやチャットツールは、表示と操作の反応を遅くします。PageSpeed Insightsの「使用していないJavaScriptの削減」「サードパーティコードの影響を抑えてください」に出てくるものから整理しましょう。

WordPressなどのCMSでは、プラグインの数と重さが主な原因になりがちです。CMSごとの具体的な手順は、CMSの速度を改善する手順で詳しく解説しています。

サーバーの応答を速くする（LCP・TTFB）

TTFBが遅い場合は、ページ側をいくら軽くしても効果が限られます。

• ページをキャッシュし、アクセスのたびにHTMLを組み立てないようにする
• PHPなどの実行環境を新しいバージョンに更新する
• 共有サーバーの性能が足りない場合は、プランやサーバーを見直す

レイアウトのずれを防ぐ（CLS）

画像・動画・広告・埋め込み要素には、あらかじめ幅と高さ（またはアスペクト比）を指定して表示枠を確保します。ページ上部に後から差し込まれるお知らせバーやCookieの同意バナーも、CLSが悪化する典型的な原因です。

それでも遅いときは、サイトの構成から見直す

画像やプラグインを整理しても基準に届かない場合、原因はサイトの作り方そのもの（重いテーマやページビルダー、アクセスのたびにデータベースからページを組み立てる仕組み、性能の低いサーバー）にあることが多いです。この段階では、部分的な調整より構成の見直しが近道になります。

CDNを導入する

CDNの代表例がCloudflareです。DNSの設定を切り替えるだけで、今のサーバーのまま画像やページをキャッシュして配信できます。導入の手順はCloudflareのDNS設定で解説しています。

静的配信・ヘッドレスCMSに作り直す

会社のホームページの多くは、ページの内容が訪問者ごとに変わりません。こうしたサイトは、あらかじめHTMLを作っておいてCDNから配信する「静的配信」にすると、サーバーでの処理がなくなり、LCPとTTFBが大きく改善します。

Next.jsはこの静的配信を標準で扱えるフレームワークです（Next.jsのレンダリング方式を参照）。WordPressの更新画面を使い続けたい場合は、表示だけをNext.jsに置き換えるヘッドレス化という方法もあります。移行の手順と注意点はWordPressのヘッドレス化で解説しています。

作り直しを検討する目安は次のとおりです。

• 画像とプラグインを整理しても、スマートフォンのLCPが「不良」のまま
• テーマやページビルダーの仕様で、不要なCSS・JavaScriptを外せない
• サイトの更新が止まっており、リニューアルを考えている

当サイト（ulty.jp）で測って直した記録

当サイトのトップページを、この記事の手順どおりにPageSpeed Insightsで測定し、改善した結果です（測定日は2026年10月1日）。訪問数がまだ少なく、実際の訪問者のデータ（フィールドデータ）は表示されないため、数値はすべてラボデータです。

改善前は1回、改善後は2回測定しており、「〜」は2回の測定値の幅です。

原因は、使っていないWebフォントでした。フォントの指定に誤りがあり、画面には端末のフォントが表示されているのに、Webフォントの定義（約370件）と先読みだけが毎回読み込まれていました。この定義と先読みを削除し、スマートフォンでは表示されない画像の先読みもやめたところ、スマートフォンのLCPが6.8秒から2.0秒以下になりました。見た目は変えていません。

パソコンのスコアは、測定のたびに72〜93点の間で変わりました。LCPは0.5〜0.6秒で安定しており、変動しているのはJavaScriptの処理待ち時間（TBT）です。「スコアは測るたびに変わるため、1回の数字で判断しない」という点は、当サイトでも同じでした。この処理待ち時間は、引き続き改善していきます。

まとめ：目安を知り、測ってから直す

表示速度の改善は、測る→原因を絞る→直す→測り直す、の繰り返しです。まずはPageSpeed Insightsで主要なページを測り、基準を外れている指標から手を付けてください。

Ultyは、Next.jsによる静的配信で、表示速度を重視した会社のホームページを制作しています。今のサイトが遅く、作り直しを検討している場合はご相談ください。

サイトスピードに関するよくある質問