WordPressの表示速度改善｜基準値と直す順番・見積の見方

WordPressの表示速度は、PageSpeed Insightsで実際の利用者の計測値を見て、基準を超えている指標から直すのが最短です。

基準はGoogleのweb.devが示すCore Web Vitalsの3つで、LCPは2.5秒以内・INPは200ミリ秒以内・CLSは0.1以下が「良好」です。

3つの基準値と測り方、直す順番、やりがちな失敗を順に説明します。

外注するときに見積書で確かめる項目も表にしました。

表示速度の基準になるCore Web Vitals3指標の値

表示速度の良し悪しはLCP・INP・CLSの3つの数字で判定します。

web.devは、ページ読み込みの75パーセンタイルの値で評価し、モバイルとデスクトップを分けて確認するよう勧めています。

75パーセンタイルとは訪問の75%がその値以内に収まっている状態のことです。

指標	測っているもの	「良好」の基準	悪化しやすい原因
LCP	ページ内で一番大きい画像や文字ブロックが表示されるまでの時間	2.5秒以内	トップ画像の容量が大きい。サーバーの応答が遅い。Webフォントの読み込みが遅い
INP	クリックやタップに画面が反応するまでの時間	200ミリ秒以内	読み込むJavaScriptが多い。重いスライダーやポップアップがある
CLS	表示中にレイアウトがずれる量	0.1以下	画像に幅と高さの指定がない。広告やバナーが後から差し込まれる

3指標がすべて基準内に入った状態が、Googleの言う「良好」です。

GoogleはCore Web Vitalsを、検索のコアランキングシステムが他のページエクスペリエンス要素とあわせて考慮する要素のひとつと説明しています。

コンテンツの内容に代わるものではないので、記事の質を保ったまま速度を整える位置づけで取り組みます。

サーバー応答時間（TTFB）も補助の目安になる

TTFBはページを要求してから最初の1バイトが届くまでの時間で、web.devは0.8秒以下を良好とし1.8秒超を不良としています。

TTFBはCore Web Vitalsの指標そのものではありませんが、これが遅いとLCPも遅れます。

LCPが基準を超えているときは、画像より先にTTFBを測っておくと原因の切り分けが早くなります。

1. サーバー管理画面またはドメイン管理画面にログインし、現在のプランやリソース使用量を確認する。
   作業の目安時間は約5分です。
2. ブラウザの開発者ツールを開き、ネットワークタブから対象のページにアクセスしてTTFBの数値を記録する。
   作業の目安時間は約5分です。
3. 利用中のレンタルサーバーのキャッシュ機能やPHPのバージョンが最新になっているかを確認する。
   作業の目安時間は約10分です。
4. ここまでで改善しない場合は、データベースの不要なデータ削除や重いクエリを発行しているプラグインの特定を行う。
   作業の目安時間は約15分です。

数字はサイトの規模やアクセス状況によって変動する目安です。

PageSpeed Insightsで現状を測る4つの手順

測定は無料のPageSpeed Insightsで足ります。

1. PageSpeed Insightsを開き、トップページではなく、問い合わせの多いページのURLを入れて分析します。
2. 結果はモバイルを先に見ます。
   利用者の多くがスマートフォンで見ているサイトが多いためです。
3. 「実際の利用者の計測値」と「その場で再現した計測値」を見分けます。
   前者が過去28日間の実測（フィールドデータ）、後者が検査環境での再現（ラボデータ）です。
4. LCP・INP・CLSのうち、基準を超えた指標に印をつけます。
   この印が次の章で最初に直す対象になります。

パフォーマンススコアは90以上が緑、50から89が黄、50未満が赤で表示されます。

PageSpeed Insightsの説明では、ラボデータのスコアが良くても実際の利用者の体験が良いとは限りません。

アクセスが少ないページは実測値が出ないことがあり、その場合はサイト全体の値に切り替わるか、実測値自体が表示されません。

実測値が出ないときはSearch ConsoleのCore Web Vitalsレポートと、ラボデータの数値を併用します。

文例：弊社ウェブサイトの表示速度改善について、PageSpeed Insightsで計測したところモバイルのパフォーマンスが現在42点となっております。
LCPの数値が基準を超えておりますので、トップ画像の見直しおよびキャッシュプラグインの設定見直しをお見積りいただけますでしょうか。

直す順番は影響が大きい5つの作業から

順番はLCP画像・画像の容量・プラグイン・キャッシュ・サーバーの5つで進めます。

上から順に費用がかからず戻しやすい作業になっています。

1. トップ画像を見直す（LCPの改善）

LCPの対象はページ最初の画面で一番大きい画像か文字ブロックです。

WordPressは5.5から画像に遅延読み込み（loading="lazy"）を標準で付け、6.3からは最初の大きな画像に読み込み優先の指定（fetchpriority="high"）を自動で付けます。

テーマや高速化プラグインがトップ画像にも遅延読み込みを付けている場合は、その指定を外します。

トップ画像ファイルの容量は目安として200KB以下に収めることが推奨されます。

もしトップ画像の容量が1MBを超えている場合は、表示速度に悪影響を与えるため優先的に圧縮や形式変更を行います。

ファーストビューに収まる領域の画像かどうかをテーマのテンプレートファイルや外観の設定から確認し、遅延読み込みの対象外になっているかをチェックします。

画像サイズが大きいままでHTML側の縮小表示のみを行っている場合は、実際の表示サイズに合わせて画像をあらかじめ縮小してアップロードし直します。

2. 画像の形式と容量をそろえる

管理画面の「メディア」を開き、容量が大きい画像から順に見ていきます。

WordPress 5.8からWebPをアップロードして使えるようになり、公式の開発ノートはJPEGやPNGより平均で約30%小さいとしています。

画像は表示する大きさに合わせて縮小してから入れ、幅と高さの指定を残します。
幅と高さの指定はCLSの悪化も防ぎます。

やってはいけない例として、一眼レフカメラで撮影した数メガバイトある未圧縮のJPEG画像をそのままメディアライブラリに大量にアップロードし、HTMLの幅と高さの指定を一切書かずに表示させるやり方があります。

この状態が駄目な理由は、ブラウザが画像を読み込むまでレイアウトが確定せず画面がガタつく原因になり、さらに通信量が膨らむことでページ表示が大幅に遅れるためです。

代わりにアップロード前に画像を適切な解像度へリサイズし、ファイル形式をWebPに変換した上で、HTMLタグに正しい幅と高さを明記する作業を行います。

3. プラグインを1つずつ止めて測る

管理画面の「プラグイン」から「インストール済みプラグイン」を開き、役割が重なるものを洗い出します。

1つ停止するたびにPageSpeed Insightsで測り、数値が変わらないものは削除候補にします。

作業は本番サイトでなく、複製した確認用の環境で行うと安全です。

よくある勘違いとして「プラグインをたくさん有効化しておけば、サイトの機能も速度も自動で見直しされるはずだ」という思い込みがあります。

実際は同じような機能を持つSEO系やキャッシュ系のプラグインを複数同時に有効にすると、プログラム同士が干渉し合ってかえって処理が重くなり、データベースへの負荷が増大して表示速度が低下します。

なぜそうなるかというと、すべてのリクエストに対して複数のプラグインがそれぞれ個別にJavaScriptやCSSの読み込み、データベースの書き込み処理を実行するためです。

そのため本当に必要なプラグインだけを残して不要なものは停止・削除し、一つのプラグインで複数の役割をまかなう設計にする必要があります。

4. キャッシュは1系統にそろえる

キャッシュは作ったページを保存して次回の表示を速くする仕組みです。

サーバー側の機能とキャッシュ系プラグインを二重に有効にすると、更新が反映されない原因の切り分けが難しくなることがあります。

更新したのに古い表示が出るときは、キャッシュの削除を先に試します。

確認のしかたとして、管理画面のキャッシュ設定やサーバーパネルを開き、キャッシュの有効状態を示すステータスが「ON」または「有効」になっていることを目視します。

次にブラウザのシークレットウィンドウやプライベートモードでサイトを開き、トップページや個別記事の読み込み時にHTTPレスポンスヘッダのキャッシュ関連の数値や、PageSpeed Insightsの「スクリプトの評価時間」「メインスレッドの処理時間」の数値が改善しているかを確認します。

判断の線として、キャッシュが正常に効いている状態では再読み込み時のサーバー応答時間が目に見えて短縮され、PageSpeed Insightsのラボデータにおける「JavaScriptの実行時間」が基準値以下に収まることを目安とします。

5. サーバーとPHPのバージョンを確認する

TTFBが基準を超えているときは、レンタルサーバーの管理画面でPHPのバージョンを確認します。

WordPress公式の動作要件のページに載っている推奨版より古い場合は、バージョンを上げる作業が効果の大きい手段になります。

上げる前にテーマとプラグインが対応しているかを確認します。

所要時間の目安は全体の確認と作業を含めて約20分です。

1. レンタルサーバーの管理画面にログインして現在のPHPバージョンを確認する。
2. WordPressのダッシュボードで利用中のテーマとプラグインが新しいPHPバージョンに対応しているかを公式情報で確認する。
3. サーバーの管理画面からワンクリックでPHPのバージョンを1段階だけ新しいものに切り替える。
4. サイトのトップページと管理画面を開き、エラーや表示崩れが起きていないかを自分の目で確かめる。
5. PageSpeed Insightsを再度実行し、TTFBの数値が切り替え前と比べて下がっているかを確認する。

指標別に原因と直し方を分ける判断表

どの指標が基準を超えたかで、先に見る場所が変わります。

基準を超えた指標	先に疑う場所	最初にやる作業
LCPが2.5秒を超える	トップ画像とサーバー応答	画像の容量を落とし、遅延読み込みが付いていれば外す。TTFBが0.8秒超ならサーバーを確認する
INPが200ミリ秒を超える	JavaScriptを読み込むプラグインとテーマの機能	スライダーやポップアップなど動きの多い部品を1つずつ止めて、再計測する
CLSが0.1を超える	幅と高さの指定がない画像、後から出るバナー	画像に幅と高さを指定し、バナーの表示枠を先に確保する
3つとも基準内	改善不要	新しいプラグインや画像を足した直後に再計測するだけにする

基準内に入ったら、それ以上スコアを追わずに内容の改善へ時間を回します。

作業ごとの記録は1行ずつ残す

直した作業と数値は、1作業につき1行の記録にします。

記録する項目は作業した日と対象のURLと作業の内容、そして作業後のLCP・INP・CLS・TTFBの4つの数値です。

ラボデータは測るたびに少しずつぶれるため、同じ条件で3回測って真ん中の値を記録すると、改善したのか誤差なのかを見分けやすくなります。

実測値は過去28日間の集計なので、作業の結果が数字に出るまでに数週間かかります。

その間はラボデータで改善の方向を確認します。
実測値は月に1回だけ見直すと、数字の増減に振り回されずに済みます。

文例：表示速度改善の作業を依頼する際は「対象URLはトップページで、作業内容は画像のWebP変換と不要プラグインの停止、確認項目はLCPが2.5秒以内に入るかの計測です。
作業前後の数値を記載したレポートをいただけますと幸いです」とメールに明記すると、後々の認識のズレを防ぐことができます。

表示速度改善でよくある失敗4つ

よくあるのはトップ画像まで遅延読み込みにしてLCPを悪化させる失敗です。

高速化プラグインの「すべての画像を遅延読み込み」をオンにすると起きやすく、PageSpeed Insightsでは最初の画像が遅れて読み込まれたという診断が出ます。

2つ目はプラグインを本番サイトで直接削除して表示崩れや機能停止を起こす失敗です。

止めて確認してから問題がなければ削除する、という順に分けて進めます。

3つ目は高速化プラグインを複数重ねて入れる失敗です。

同じ役割の機能が競合し、原因の特定に時間がかかるうえに、数値が改善したかどうかも判断しにくくなります。

4つ目は画像を縮めすぎて画質を落とし、サイトの印象まで損なう失敗です。

容量の目安にこだわって圧縮率を上げすぎると、商品や店舗の写真がぼやけて、かえって問い合わせが減ることがあります。

画像は拡大して見てもざらつかない範囲で止め、LCPが基準内に入った時点で圧縮を終えます。

表示速度改善における失敗を避けるためには、いくつかの具体的な数字の目安を把握しておくことが判断の基準になります。

たとえば画像のファイル容量は、1枚あたりおおむね100KBから200KB未満をひとつの目安として縮小すると、画質を保ちつつ読み込みを軽くできます。

プラグインの数は有効化している合計が20個を超えると、それぞれの処理が重なり合ってTTFBやLCPに悪影響が出やすくなるため、15個以下に抑えるのが安全です。

高速化の施策を行う期間は、1回あたり1つの作業に絞り、その効果がPageSpeed Insightsのラボデータに反映されるまで3日から5日ほど様子を見るのが確実な手順となります。

また費用の目安や予算を考える際には、自社の売上に占めるスマホからのアクセス割合を算出しておき、その割合が70%を超える場合はモバイルのLCP改善を最優先にするという判断基準を設けると投資対効果を見失わずに進めることができます。

自分で直すか頼むかの分かれ目と見積の確認項目

画像の見直しとプラグインの整理までは自分で進められ、テーマの修正とサーバーの設定変更は専門家に任せるのが安全です。

費用の相場は作業範囲で大きく変わるため、この記事では金額を示しません。

見積書で確かめる項目を挙げるので、比べるときの物差しに使ってください。

確認する項目	確かめる理由
対象のURLと目標の指標	「どのページのLCPを2.5秒以内にする」と書かれていないと、完了の判定ができない
計測の方法と条件	モバイルかデスクトップか、実測値かラボデータかで数字が変わる
作業の範囲	画像の変換・プラグイン整理・キャッシュ設定・テーマ修正のどこまで含むかで金額が変わる
作業前のバックアップ	表示崩れが起きたときに元へ戻せる状態かを確かめる
作業後の再計測と報告	改善前後の数値を同じ条件で受け取れるか
その後の保守	プラグイン追加で再び遅くなったときの対応が含まれるか

見積に対象URLと目標値がない場合は、先に決めてもらうよう依頼するのが費用対効果を判断する近道です。

cantikでは、表示速度の計測と改善の優先順位づけを、ZOOM・電話・メールでご相談いただけます。

自分で作業を進める際や専門家に依頼する際において、やってはいけない具体的な失敗の形があります。

最も危険なのはバックアップを取らないまま本番環境のテーマファイルやサーバーの.htaccessを直接書き換えることであり、これをやってしまうと、わずかな記述ミスでサイト全体が真っ白になり閲覧できなくなる致命的な障害につながります。

代わりに行うべき行動は、テスト環境やサーバーのバックアップ機能を使って復元できる状態を確保してから作業を開始することです。

また一度に複数の設定変更やプラグインの入れ替えをまとめて行うことも避けるべき行動であり、どの変更が原因で表示速度が改善したのか、あるいは逆にどこが原因で表示崩れが起きたのかが分からなくなってしまいます。

代わりに何をするかといえば、1回につき1つのファイルや1つのプラグインだけを変更し、その都度PageSpeed Insightsで数値を測って記録を残すという手順を徹底します。

さらにネット上で見つけた古い解説記事を鵜呑みにして、現在のWordPressのバージョンや利用中のテーマに合わないコードをそのままコピペして貼り付けることも、エラーを引き起こす典型的な誤りです。

代わりに導入するコードや設定が公式ドキュメントや最新の動作要件に適合しているかを自分の目で確認してから適用する習慣をつけます。

知らないと損する注意点

キャッシュプラグインを使えば自動で最速になると思われがちな誤り

高速化系のプラグインをインストールすれば、自分で画像を圧縮したりコードを見直したりしなくても、設定をオンにするだけでサイトが常に最速の状態で維持されるという思い込みがよく見られます。
実際は複数のキャッシュプラグインが同時に有効になっていると内部で処理が衝突し、かえってサーバーの応答時間が長くなって表示速度が低下します。
なぜそうなるかというと、同じような仕組みを持つプログラムがそれぞれ独立してデータを一時保存しようと競い合い、不要な書き込み処理がデータベースに何度も発生するためです。
今日からできる確認方法として、利用中のプラグイン一覧を開き、役割が重複しているものがないかを自分の目で一つずつ確かめる作業を行ってください。

トップ画像の遅延読み込みで速度が上がると思われがちな誤り

すべての画像に遅延読み込みを適用すれば、ページを開いたときの初期データが軽くなり表示速度が上がっていくはずだという思い込みが存在します。
実際は一番最初に見えるトップ画像にまで遅延読み込みの指定が残っていると、ブラウザがその画像の読み込みを後回しにしてしまい、LCPの数値が大幅に悪化してユーザー体験を損ないます。
なぜそうなるかというと、ブラウザの仕組み上、画面の最上部にある要素の描画が遅れるとページ全体の表示完了を示す指標が遅延判定を受けるからです。
今すぐできる確認手順として、ページのソースコードやテーマの設定画面を開き、ファーストビューの画像に遅延読み込みが設定されていないかを自分の目で直接チェックしてください。

スコアの数値が緑色なら速度対策は十分だと思われがちな誤り

PageSpeed Insightsのパフォーマンススコアが90以上の緑色に達していれば、サイトの表示速度に関する作業はすべて完了したためそれ以上見直す必要はないという思い込みがあります。
実際はスコアの数値が高くても特定のページでLCPやINPが基準を超えている場合があり、実際の利用者がスマホで見たときの体験とは必ずしも一致しません。
なぜそうなるかというと、スコアの判定はラボデータと呼ばれるテスト環境でのシミュレーション結果が含まれており、実際のユーザーの通信環境や端末の性能差がそのまま反映されないからです。
手元の確認方法として、スコアだけでなく実際の利用者の計測値であるフィールドデータの項目を開き、3つの指標がすべて良好の基準内に収まっているかを直接確認するようにします。

いまの状態を確かめるチェックリスト

PageSpeed Insightsを開き、モバイルの表示速度を確認しながら順番に状態を確かめます。

• PageSpeed InsightsでスマホのLCPが2.5秒以内に収まっている
• スマホのINPが200ミリ秒以内に収まっている
• スマホのCLSが0.1以下に収まっている
• トップ画像の容量が200KB以下になっている
• トップ画像に遅延読み込みが設定されていない
• 不要なプラグインが停止または削除されている
• キャッシュ機能が1系統のみ有効になっている
• PHPのバージョンが推奨版以上になっている

チェックボックスの×が多い項目から順に手を付けると、全体の表示速度が短期間で改善しやすくなります。
自分で進める時間や手が回らない作業がある場合は、専門の外部担当へ任せる選択肢もあります。
表示速度の現状診断や優先順位の整理はお気軽に無料相談へお問い合わせください。

よくある質問

Q1. 表示速度は検索順位に影響しますか？

影響する可能性はありますが、順位を決める要素ではありません。

GoogleはCore Web Vitalsを他のページエクスペリエンス要素とともにコアランキングシステムが考慮する要素のひとつと説明しています。

内容の関連性に代わるものではないので、記事の質と並行して整えます。

Q2. PageSpeed Insightsのスコアは何点を目指せばよいですか？

点数よりもLCP・INP・CLSが基準内に入っているかを優先します。

スコアは90以上が緑ですが、ラボデータの点が高くても実際の利用者の体験が良いとは限らないと説明されています。

まず実測値の3指標を確認し、基準を超えた指標から直します。

Q3. 有料のプラグインやCDNは入れたほうがよいですか？

先に無料でできる作業を済ませ、数値が基準を超えたまま残った場合に検討します。

画像の見直しとプラグインの整理だけで基準内に入るサイトもあります。

CDNはTTFBと画像の転送時間を測ってから必要かどうかを判断します。

▶ 関連サービス：ホームページ・LP・ECサイト制作