WordPressの表示速度を改善する方法9選｜計測・原因の切り分けから効果が出やすい順の手順まで解説

WordPressの表示速度を改善する方法を、9つの対策・やる順番・計測のしかた・原因の切り分け・失敗しやすい点の順に解説します。自社サイト crystal-method.com（WordPress）で実際に行った対策と、そのとき使った計測画面を交えています（手順・数値は2026年10月13日時点で確認）。

改善前

改善後

出典：Ubersuggest のサイトスピード計測（自社サイト crystal-method.com・2026年6月の画面から「読み込み時間」の部分を切り出し）。改善前12.89秒・改善後2.03秒。この値は計測のたびに2.0〜2.7秒の幅で振れます。本文中のLCPの値は、別途 Google Chrome＋Puppeteer（モバイル相当の速度制限・5回の中央値）で測ったラボ値です。

WordPressの表示速度改善とは？まず結論（9つの対策と順番）

WordPressの表示速度改善とは、WordPressで作られたサイトが「開いて、読めて、操作できる」までの時間を短くする取り組み全体のことです。対象はサーバーの応答、画像、CSS・JavaScript、キャッシュ、プラグイン、テーマと幅広く、WordPressはプラグインやテーマを足しやすい反面、それらが積み重なって遅くなりやすい構造を持っています。

先に結論：効果が出やすい順に、次の9つを進めます。

1. キャッシュプラグインを入れる
2. 画像を圧縮し、WebPなど軽い形式にする
3. 最初に見える一番大きな要素（LCP要素）を特定し、優先して読み込ませる
4. CSS・JavaScriptを軽くし、表示を止めない読み込み方にする
5. CDNを使う
6. データベースを掃除する
7. PHPを新しいバージョンにする
8. 使っていないプラグインを整理する
9. それでも遅ければ、サーバー（ホスティング）を見直す

大事なのは順番です。やみくもにプラグインを足す前に、「どこが遅いのか」を計測で切り分けます。この記事では、理由・計測の方法・原因・9つの対策の手順・自社サイトで実際に効いた順番・失敗しやすい点の順に解説します。

表示を遅らせる要因を、どう見分けて直すかは、レンダリングブロック対策で解説しています。

関連記事WordPressの画像をWebP化するには？

WordPressの表示速度を改善する9つの方法【効果が出やすい順】

原因と計測ツールを押さえたうえで、対策を効果の出やすい順に解説します。各対策には「やること」と「効いたかの確認のしかた」を添えています。設定の細かい手順は、それぞれの専用記事にまとめています。

① キャッシュプラグインの導入

最も費用対効果の高い対策の1つです。代表的なプラグインに「WP Rocket」（有料）、「W3 Total Cache」「WP Super Cache」「LiteSpeed Cache」（無料。LiteSpeed Cache はサーバーが LiteSpeed のときに本領を発揮します）があります。

• やること：プラグインを1つだけ有効にし、まず「ページキャッシュ」だけをオンにします。ファイルの結合や遅延読み込みなどの機能は、この段階ではオフのままにします。
• 確認：ログアウトした状態（シークレットウィンドウ）で同じページを2回開き、2回目のTTFBが短くなっていれば効いています。サーバー側に Nginx や LiteSpeed のキャッシュがある場合は、プラグインのキャッシュと二重にならないよう、どちらか一方に絞ります。

② 画像の最適化と次世代フォーマット（WebP）への変換

画像は多くのWordPressサイトで転送量の最大の割合を占めます。やることは3つです。

• 圧縮：「EWWW Image Optimizer」や「Imagify」などでアップロード済みの画像を一括圧縮します。見た目をほとんど変えずにファイルサイズを減らせます（削減幅は画像によって大きく変わります）。
• WebP変換：JPEGやPNGより軽いWebP形式に変換します。Googleの比較研究では、同じ画質（SSIM）でJPEGより25〜34%小さくなります。上記のプラグインで自動変換できるほか、下のように端末のコマンドでも変換できます。
• 遅延読み込み（Lazy Load）：スクロールしないと見えない画像は、表示されるときまで読み込みを遅らせます。WordPressは5.5以降、幅と高さの指定がある画像に標準で loading="lazy" を付けます。

プラグインでの設定手順、display:none の罠、効果の測り方は WordPressの画像をWebP化・遅延読み込みする方法 にまとめています。

③ LCP要素の特定と集中改善

LCPは「最初の画面で一番大きい要素」が表示されるまでの時間です。まず、その要素が何かを特定します。Lighthouse（PSI）の結果には「LCPの内訳」が出て、LCP要素と、時間がどこで消費されているか（サーバー応答・読み込みの遅れ・読み込み時間・描画の遅れ）が分かります。

• LCP要素が画像のとき：その画像に loading="lazy" を付けてはいけません。逆に fetchpriority="high" を付けて最優先で読み込ませ、表示サイズに合わせてリサイズ・WebP化します。WordPress 6.3以降は、LCP画像と判断した画像に標準で fetchpriority="high" を付けます。
• 画像には幅と高さを指定する：width・height 属性があると、ブラウザは読み込み前に表示領域を確保でき、CLS（表示のずれ）も防げます。WordPressの標準の遅延読み込みも、幅と高さの指定がある画像だけが対象です。
• LCP要素が文字や背景のとき：Webフォントの読み込み待ちや、表示を止めるCSS・JavaScriptが原因のことが多く、④の対策が効きます。

自社サイトでは、記事一覧の先頭に表示されるニュースのサムネイル画像がLCP要素で、そこにテーマが一括で付けていた遅延読み込みが原因でした。遅延読み込みを外して優先読み込みに変え、WebP化・リサイズをしたところ、ラボ値のLCPは8.1秒から1.7秒になりました。要素の特定から改善までの6ステップは Core Web VitalsのLCPを改善する方法 にまとめています。

④ CSS・JavaScriptの最小化と読み込み最適化

ファイルの最小化（Minify）はコメントや空白を除いてサイズを減らします。JavaScriptに defer／async を付けると、描画を止めずに読み込めます。WP Rocket や Autoptimize で設定できますが、テーマやプラグインによっては画面が崩れることがあるため、1項目ずつオンにして表示を確認します。

個別の実装はテーマによって違うので、次の専用記事に分けています：表示を止めるCSSの解消／未使用CSSの削除／クリティカルCSS／ブロックエディタのCSSを減らす／jQueryの遅延読み込み／Googleタグマネージャーの遅延。

⑤ CDN（コンテンツ配信ネットワーク）の利用

CDNはサイトの画像やCSSなどを世界各地のサーバーに複製し、訪問者に近い場所から配信します。海外からのアクセスが多いサイトや、画像の多いサイトで効果が出ます。Cloudflare などのCDNサービスは、CDNのほかにDDoS対策やSSL証明書も提供しています（プランの内容と料金は公式サイトで確認してください）。確認は、PSI のラボ計測で「リソースの読み込み時間」が短くなったかを見ます。

⑥ データベースの最適化

WordPressは投稿のリビジョン（自動保存の履歴）、スパムコメント、ゴミ箱のデータをデータベースにため込みます。「WP-Optimize」などで定期的に掃除し、wp-config.php に define('WP_POST_REVISIONS', 5); を追加してリビジョンの保存数を制限します（WordPress 公式の wp-config.php の説明にある設定です）。効くのは主にTTFBで、管理画面の重さにも効きます。

⑦ PHPバージョンのアップデート

WordPress 公式の動作要件（2026年10月13日確認）は「PHP 8.3以上を推奨」です。PHP 8系は7系より実行速度が上がっており、レンタルサーバーの管理画面から切り替えられる場合がほとんどです。切り替える前に、使っているプラグイン・テーマが対応しているかを確認し、切り替え後は主要ページを一通り開いてエラーが出ないかを見ます。

⑧ 不要プラグインの整理

各プラグインが読み込んでいるCSS・JavaScriptを Chrome の Network パネルで確認し、使っていないものは停止・削除します。「SEO・キャッシュ・画像最適化」の3本を基本に、それ以外は本当に必要かを見直します。停止したら必ず再計測し、効果が無いものを戻すときも1つずつ戻します。

⑨ ホスティング環境の見直し

①〜⑧を行ってもTTFBが長いままなら、サーバー自体の見直しが根本解決になります。共有サーバーからVPSやWordPress専用のマネージドホスティングに移すと、応答速度と同時アクセスへの耐性が変わります。アクセスが増えてきたサイトほど、サーバー品質への投資効果が大きくなります。

WordPress標準の機能も確認しておきます。5.5の画像の遅延読み込み、6.3のLCP画像への優先読み込み、6.8の「先読み（Speculative Loading）」（リンクを押し始めたときに次のページを先に取りに行く機能で、標準で有効。ログイン中は動きません）は、本体を最新にしておくだけで使えます。先読みの仕組みは WordPressでリンクのプリフェッチを使う方法 で解説しています。

改善の優先順位と進め方

表示速度改善は「一度にすべてをやる」のではなく、効果の大きい対策から段階的に進めます。次の6ステップを目安にしてください。

実測の記録：crystal-method.comで実際に効いた順番

crystal-method.com（WordPress・約1,200URL）で2026年6月から9月にかけて行った対策を、効いた順に記録します。数値のうち「成果」として書けるのは実際の利用者のデータ（Chrome UX レポート・Search Console）だけで、途中の確認に使ったラボ値は参考として分けています。

結果（実際の利用者のデータ）：サイト全体のモバイルのLCP（75パーセンタイル）は、2026年8月20日の3.9秒から9月6日には2.39秒（良好）になり、Search Console の「ウェブに関する主な指標」では9月上旬にPC・モバイルとも全URLが「良好」になりました。ラボ値はその場で確認できますが、Search Console への反映は実際の利用者のデータがたまってから表れます。

この経験から言えるのは、速度改善で最初にやるべきは「対策を増やすこと」ではなく、何が本当に読み込まれているかを1ページ分、全部見ることです。16.5MBのフォントも、動いていなかった遅延読み込みも、計測ツールのスコアだけを見ていたら気づけませんでした。

まず現状を測る：計測ツールの使い方（PageSpeed Insights・Search Console・Lighthouse・curl）

改善を始める前に、いまの数値を記録しておきます。「何秒だったものが何秒になったか」が分からないと、どの対策が効いたのか判断できません。

PageSpeed Insights（PSI）

Googleの無料ツールです。URLを入力するだけで、モバイル・PC別のスコアと Core Web Vitals の結果が出ます。「実際のユーザーの環境で評価する」（フィールドデータ＝Chrome UX レポート）と「パフォーマンスの問題を診断する」（ラボデータ）の両方が確認でき、改善提案も表示されます。最初に記録しておく画面はこれです。

Google Search Console

「ウェブに関する主な指標」レポートで、サイト全体のURLが「良好」「改善が必要」「不良」のどれかを一覧で確認できます。実際に訪問した Chrome 利用者のデータ（直近28日間の集計）なので、ラボの数値より実態に近く、Googleの評価もこちらが基準です。修正の優先順位付けに使います。

Lighthouse（Chrome の開発者ツール）

PSI のラボ計測と同じ仕組みを、自分のPCの Chrome で動かせます。開発者ツールの「Lighthouse」タブ、またはコマンドラインの npx lighthouse <URL> --form-factor mobile で実行できます。下は、この記事のURLをこの端末で計測した結果です。

Chrome DevTools（Network・Performance パネル）

Network パネルでは、どのファイルがいつ・どれだけの時間をかけて読み込まれたかを1本ずつ見られます。Performance パネルでは LCP 要素（最初の画面で一番大きい要素）が何かを確認できます。プラグインでは掴みにくい原因の根本調査に使います。

curl でサーバーの応答時間（TTFB）だけを測る

サーバーが最初の1バイトを返すまでの時間（TTFB）は、端末のコマンド1行で測れます。ブラウザのキャッシュや拡張機能の影響を受けないので、「サーバーが遅いのか、表示側が遅いのか」を切り分ける最初の一手に向いています（具体的な見方は後述の「診断手順」で説明します）。

主要な計測指標：Core Web Vitals を理解する

Googleが定める Core Web Vitals の3指標が、現在の表示速度の標準です。しきい値は web.dev の各指標のページ（2026年10月13日確認）によります。

LCPは、読者が「ページが開いた」と感じる時間に最も近い指標です。INPは2024年3月にFID（First Input Delay）から置き換えられた指標で、ページ内のすべての操作に対する反応の遅さを評価します。CLSは、画像や広告が後から読み込まれて文章がずれる現象を測ります。TTFB（サーバーの初回応答）は Core Web Vitals には含まれませんが、web.dev は目安として0.8秒以下を推奨しています。

表示速度が遅くなる主な原因

WordPressサイトが遅い原因は1つではなく、いくつかが重なっていることがほとんどです。代表的な原因を知っておくと、計測結果からどこを疑うべきかが分かります。

サーバー・ホスティング環境

共有レンタルサーバーの低価格プランや、サーバーと訪問者の物理的な距離が遠い場合は、TTFB（サーバーの初回応答時間）が長くなります。web.dev の目安（0.8秒以下）を大きく超えているなら、サーバー側（ホスティング・サーバーキャッシュ・PHPやデータベースの処理）の見直しを先に検討します。

最適化されていない画像

スマートフォンで撮った数MBの写真をそのままアップロードし、原寸のまま表示しているケースは非常に多く見られます。画像は多くのサイトで転送量の最大の割合を占め、モバイル回線では決定的な遅延要因になります。

プラグインの入れすぎ

使っていないプラグインや、同じ機能のプラグインが重複していると、不要なCSS・JavaScriptが全ページで読み込まれ続けます。問題はプラグインの「数」より、各プラグインが「何を読み込んでいるか」です。

表示を止めるCSS・JavaScript（レンダリングブロック）

CSSとJavaScriptが <head> 内で同期的に読み込まれると、ブラウザはその処理が終わるまでページの描画を始められません。jQueryやスライダー系のライブラリが多いテーマで起こりやすい問題です。

Webフォントの読み込み

日本語のWebフォントは1書体で数MBになることがあります。自社サイトでは、CSSの font-family に Web フォントと同じ名前を書いていたため、その書体を持たない Android 端末で合計約16.5MBのフォントを読み込んでいたことが分かりました。端末に入っているフォント名に変えるだけで転送量は0になり、LCPが大きく改善しました（詳しくは後述の「自社サイトで実際に効いた順番」）。

キャッシュが未設定

WordPressは標準では、アクセスのたびにPHPを実行してHTMLを生成します。ページキャッシュを設定すると生成済みのHTMLを使い回せるため、サーバー負荷と応答時間を大きく減らせます。

テーマの品質

多機能なテーマやページビルダー系のテーマは、使っていない機能のCSS・JavaScriptまで読み込むことがあり、ファイルサイズが大きくなりがちです。

表示速度が重要な3つの理由

表示速度は、読者の体験・検索順位・成果（問い合わせや購入）の3つに影響します。

読者が離れてしまう

ページが表示されるまで待たされると、読者はそのまま戻って別のサイトへ移ります。表示速度は、記事の中身を読んでもらう前の第一印象を決めます。とくにモバイル回線では、PCでは気にならない数百KBの画像や JavaScript が待ち時間に直結します。

検索順位の評価要素になっている

Googleは2021年6月から、ページの表示速度・操作への反応・表示のずれを数値化した「Core Web Vitals（コアウェブバイタル）」を検索ランキングの評価要素に含めています（Google 検索セントラル ブログ、2021年4月の告知）。評価の対象は LCP・INP・CLS の3指標で、WordPressの表示速度改善はそのままSEO対策になります。

問い合わせ・購入の数に影響する

表示が速いページほど、フォームの送信や購入まで進んでもらいやすくなります。広告やメディアサイトではページビューにも直結するため、表示速度の改善は費用対効果の高い施策です。

よくある失敗と注意点

LCP要素に誤って遅延読み込みを設定する

最初の画面で最大の画像に loading="lazy" を付けると、LCPはかえって悪化します。テーマやプラグインによっては画像全体に一括で遅延読み込みを付けることがあり、LCP要素にも付いてしまいます。必ずLCP要素を特定してから、その要素の loading 属性を確認してください。

キャッシュを何層も重ねる

複数のキャッシュプラグインを同時に有効にしたり、サーバー側のキャッシュとプラグインのキャッシュが干渉したりすると、内容が更新されない・ページが壊れるといった問題が起きます。自社サイトでも、サーバーのキャッシュとプラグインのキャッシュが二重になっていて「直したはずの表示が直らない」と誤判定したことがありました。キャッシュは1つの仕組みに絞るのが原則です。

ツールのスコアを過信する

PageSpeed Insights のスコアは、Googleのテスト環境で測ったラボ値が中心です。スコアが90点以上でも実際の利用者の体感が遅いことはあり、逆にラボ値が改善しても Search Console の判定がすぐには変わらないこともあります。成果は Search Console の実際の利用者のデータで確認してください。

JS・CSSのMinify・結合でサイトが崩れる

JavaScriptの最小化や結合を有効にしたあと、特定のページでデザインが崩れたり動かなくなったりすることがあります。設定を変えたら主要ページ（トップ・記事一覧・個別記事・問い合わせ）を確認し、問題があれば対象ファイルを除外リストに追加します。

「どこが遅いのか」を実測で切り分ける診断手順

速度改善でいちばん失敗しやすいのは、原因を特定しないまま高速化プラグインを次々に入れてしまうことです。設定が競合して逆に遅くなったり、どの対策が効いたのか分からなくなったりします。まずやるべきは、遅延がサーバーが最初の1バイトを返すまで（TTFB）で起きているのか、ブラウザ側の読み込み・描画で起きているのかを分けて測ることです。

手順1：TTFBとフロントを分けて測る

端末で次のコマンドを実行すると、TTFBだけを数値で取れます（Mac・Linux の標準の端末、Windows は PowerShell や WSL で使えます）。

curl -s -o /dev/null https://例のURL/ -w "TTFB %{time_starttransfer}秒\n"

• TTFBが長い（目安0.8秒超）なら、原因はサーバー・PHP・データベース側であることが多いです。
• TTFBは短いのに全体が重い場合は、画像・CSS・JavaScript・Webフォントなど、フロントの読み込み側が原因であることが多いです。Chrome の Network パネルの Waterfall で、どのリクエストが長いか、どこで直列に待たされているかを見ます。
• キャッシュが効いているときといないとき（管理画面にログインした状態など）で数値が大きく違うことがあるため、ログアウト状態でも測ります。

TTFBの計測から画像のWebP変換までを、この端末で実際に操作した録画です（約12秒）。

手順2：プラグインを二分探索で特定する

「どのプラグインが重いか分からない」ときは、1つずつ止めるより二分探索の方が効率的です。ステージング環境で有効なプラグインの半分を停止して計測し、遅い側に原因が残るのでさらにその半分を停止、と繰り返すと候補を絞り込めます。複数のプラグインの組み合わせが原因の場合は単純な二分探索では特定しきれないこともあるため、絞り込めないときはログや個別停止での確認も併用してください。テーマが疑わしいなら、標準テーマに一時的に切り替えて比較します。

症状から当たりをつける対応表

この切り分けを先に済ませておくと、後の対策が「効いたか効かないか」を1つずつ数値で判断でき、手戻りを減らせます。

サイトを壊さず「戻せる」状態のまま進める3つのルール

高速化の対策の多くは、キャッシュ・遅延読み込み・CSS/JSの結合や遅延実行など「表示の挙動そのものを変える」ものです。効果が大きい設定ほど、レイアウト崩れ・機能停止・フォーム送信不可といった事故を起こしやすくなります。運用中のサイトでは、1回に1つだけ変える／必ず計測する／すぐ戻せるようにしておくの3つを守ります。

ルール1：変更は1つずつ、計測しながら

• 本番にいきなり入れず、まずステージング（複製環境）で適用して、見た目と主要な導線（記事表示・検索・問い合わせフォーム・カートなど）を目で確認します。
• 1つの対策ごとに前後の数値を記録します。まとめて入れて速くなっても、どれが効いてどれが事故の原因かが分からなくなります。
• 効果が測れない・体感が変わらない対策は入れっぱなしにせず外します。設定が積み重なるほど競合と保守の手間が増えます。

ルール2：戻せる状態を先に用意する

• 変更前にフルバックアップ（データベース＋ファイル）を取ります。functions.php やテーマの直接編集は、元のファイルを .bak として残してから触ります。
• プラグインで挙動を変える設定は、どの項目をオンにしたかを記録します。不具合のときに「全部止めて戻す」より「その1項目だけ戻す」方が早く復旧できます。

ルール3：キャッシュの整合性で足をすくわれない

作業中に誤判定しやすいのがキャッシュです。設定を直したのに反映されない、直したはずの崩れが直らない、という場合は古いキャッシュが残っているだけのことがあります。

この手順を型にしておくと、万一問題が起きても切り分けて元に戻しやすくなります。プラグインや設定の具体的な機能・料金・対応バージョンは変わりやすいため、適用前に必ず公式サイト・公式ドキュメントで最新情報を確認してください。

改善効果を継続させるための運用習慣

表示速度は一度改善しても、その後のプラグイン追加や記事の更新で再び悪化することがあります。次の4つを習慣にします。

• 新しいプラグインの導入前後に必ず計測する：何のファイルが増えたかを Network パネルで確認し、速度への影響を把握します。
• 月1回は Search Console を確認する：「ウェブに関する主な指標」で、新たに「改善が必要」「不良」になったURLがないかを見ます。
• 画像のアップロード時のルールを決める：大きな画像は必ずリサイズ・圧縮してからアップロードします。自動変換プラグインを入れている場合も、変換が実際に動いているか（配信されているURLの拡張子）を時々確認します。
• PHPとWordPress本体を定期的に更新する：性能改善が含まれることが多く、セキュリティの面でも最新版を維持します。

よくある質問

WordPressが遅くなる主な原因は何ですか？

原因は一つではなく、サーバー環境（初回応答の遅さ）、最適化されていない画像、プラグインの入れすぎ、表示を妨げるCSS・JavaScript、キャッシュ未設定、テーマの品質などが重なっていることがほとんどです。

表示速度の改善は何から始めればよいですか？

まずPageSpeed InsightsやSearch Consoleで現状を記録し、次にサーバーの初回応答（TTFB）を確認します。そのあと、ファーストビューで最も大きい要素（LCP）の特定と対策、キャッシュと画像の最適化、CSS・JavaScriptの最適化の順に進め、施策ごとに再計測します。

Lazy Loadを設定すれば必ず速くなりますか？

いいえ。ファーストビューで最も大きい画像（LCP要素）にloading=”lazy”を付けると、かえってLCPが悪化します。テーマが画像に一括でLazy Loadを付けている場合があるため、開発者ツールでLCP要素を特定してから設定を確認してください。

表示速度はどのくらいを目指せばよいですか？

Googleが示すCore Web Vitalsの「良好」の基準が目安です。LCP（最大コンテンツの描画）は2.5秒以内、INP（操作への応答）は200ミリ秒以内、CLS（レイアウトのずれ）は0.1以下です。PageSpeed InsightsやSearch Consoleの「ウェブに関する主な指標」で確認できます。

高速化プラグインを入れるだけで速くなりますか？

キャッシュや画像圧縮のプラグインは効果が出やすい一方、原因がサーバーの応答やテーマにある場合は、プラグインを足しても改善しません。複数のキャッシュプラグインを同時に使うと不具合の原因にもなります。先に計測して、遅い箇所がサーバー側か表示側かを切り分けてから入れるのが安全です。

まとめ

WordPressの表示速度改善は、サーバーの応答から画像の配信、CSS・JavaScript、フォントまで何層にもわたる取り組みです。大事なのは「計測→原因の特定→効果の大きい対策から実施→再計測」のサイクルを、1つずつ戻せる形で回すことです。

Core Web Vitals の3指標（LCP・INP・CLS）を軸に現状を把握し、LCP要素の特定・画像の最適化・キャッシュの設定から始めると、多くのサイトで大きな効果が出ます。自社サイトでも、LCP要素に付いていた誤った遅延読み込みを直し、WebP化とフォントの見直しを進めた結果、2026年9月に Search Console の判定が全URLで「良好」になりました。対策を闇雲に増やすのではなく、何が読み込まれているかを実際に見て、根拠を持って一つずつ確かめる姿勢が、持続する高速化につながります。

関連記事

• Core Web VitalsのLCPを改善する方法
• WordPressの画像をWebP化・遅延読み込みする方法
• WordPressの未使用CSSを削除する方法
• レンダリングを妨げるCSSを解消する方法
• WordPressでクリティカルCSSを使う方法
• ブロックエディタのCSSを減らす方法
• WordPressのjQueryを遅延読み込みする方法
• WordPressのGTMを遅延読み込みする方法
• WordPressでリンクのプリフェッチを使う方法