blog

AIブログ

実測12.89秒→2.03秒。激重だったWordPressを爆速にした全手順【表示速度改善完全ガイド】

モバイル表示12.89秒の激重サイトを2.03秒（良）まで改善。実際にやった9つの施策を計測値つきで全公開します。

Ubersuggest サイトスピード改善前モバイル読み込み12.89秒・双方向性326ミリ秒・CLS0.00 — 実測ビフォーアフター（自社 crystal-method.com・モバイル）

Ubersuggest サイトスピード改善後モバイル読み込み2.03秒・双方向性74ミリ秒・CLS0.00 — 実測ビフォーアフター（自社 crystal-method.com・モバイル）

WordPress 表示速度改善とは？原因・指標・具体的な対策を徹底解説

「WordPressのサイトが重い」「ページを開くまでに時間がかかる」——こうした悩みを抱えているサイト運営者は少なくありません。表示速度の遅さはユーザーの離脱を招くだけでなく、Googleの検索順位にも直結する深刻な問題です。本記事では、WordPress 表示速度改善の基本的な考え方から、原因の特定方法、具体的な対策、そして改善効果の確認方法まで、体系的に解説します。実際に LCP（Largest Contentful Paint）を 8.1 秒から 1.7 秒へ改善した経験を踏まえた実践的な内容です。

この記事について

本記事は、自社サイト crystal-method.com（WordPress運用） で実際に表示速度を改善した一次データに基づきます（モバイルLCP 8,144ms→1,700ms を実測。Google Chrome + Puppeteer／モバイル相当スロットル・5回中央値）。
発行：クリスタルメソッド株式会社（代表取締役河合継）　｜　運営会社　｜　編集方針

WordPress 表示速度改善とは

WordPress 表示速度改善とは、WordPressで構築されたWebサイトがブラウザに表示されるまでの時間を短縮するための取り組み全体を指します。単純に「ページが早く表示される」だけでなく、ユーザーが「使える」と感じるまでのあらゆる体験を最適化することが目的です。

改善対象となるのは、サーバーの応答速度、HTMLやCSS・JavaScriptの配信効率、画像の最適化、ブラウザキャッシュの活用など、多岐にわたります。WordPressはプラグインやテーマの追加が容易な反面、これらが積み重なることで表示速度が悪化しやすい構造を持っています。そのため、改善は「どこが重いのか」を正確に特定したうえで、優先度の高い箇所から着手することが重要です。

表示速度が重要な理由

表示速度はビジネス成果と検索順位の両方に影響を与えます。改善に取り組む意義を整理しておきましょう。

ユーザー体験への影響

Googleの調査によれば、モバイルページの読み込み時間が1秒から3秒になると直帰率は32%上昇し、5秒になると90%上昇します。ユーザーはページが遅いと判断した瞬間に離脱し、競合サイトへ移動します。表示速度はコンテンツの質と同じくらい、あるいはそれ以上にユーザーの第一印象を左右します。

SEO・検索順位への影響

Googleは2021年6月より「Core Web Vitals（コアウェブバイタル）」を検索ランキングの公式シグナルとして導入しました。これはページの速度・インタラクティブ性・視覚的安定性を数値化したもので、WordPressサイトの表示速度改善はSEO対策と直結しています。特にLCP・INP・CLSの3指標が評価対象となっています。

コンバージョン率への影響

ECサイトの事例では、ページ読み込み時間が1秒改善するとコンバージョン率が約2〜5%向上するというデータが複数報告されています。メディアサイトでもページビュー数や広告表示回数に直接影響するため、表示速度改善はビジネス上の投資対効果が高い施策です。

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

表示速度を改善するには、まず何を測るべきかを理解する必要があります。Googleが定めるCore Web Vitalsの3指標が現在の標準です。

指標	正式名称	測定対象	良好	要改善	不良
LCP	Largest Contentful Paint	最大コンテンツの描画速度	2.5秒以内	4.0秒以内	4.0秒超
INP	Interaction to Next Paint	ユーザー操作への応答速度	200ms以内	500ms以内	500ms超
CLS	Cumulative Layout Shift	レイアウトのずれ・視覚的安定性	0.1以下	0.25以下	0.25超

LCPはユーザーが「ページが読み込まれた」と感じる最も重要な指標です。INPは2024年3月にFID（First Input Delay）から置き換えられた新しい指標で、クリックやタップなどのインタラクション全体の応答性を評価します。CLSは広告や画像の遅延読み込みによってコンテンツが突然ずれる現象を測定します。

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

WordPressサイトの表示速度が遅い原因は一つではなく、複数の要因が重なっていることがほとんどです。代表的な原因を理解することで、改善の優先順位を正しく設定できます。

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

共有レンタルサーバーの低スペックプランや、サーバーと訪問者の物理的な距離が大きい場合、TTFB（Time to First Byte＝サーバーの初回応答時間）が悪化します。TTFBが200ms以上かかっている場合はホスティング環境の見直しが最優先事項です。

最適化されていない画像

WordPressへのアップロード時に画像を圧縮・リサイズしないまま使用するケースは非常に多く、数MB単位の大きな画像がページ内に複数含まれると、通信量が膨大になります。特にモバイル環境では致命的な遅延要因です。

過剰なプラグインの導入

機能追加のしやすさはWordPressの長所ですが、使用していないプラグインや、同じ機能が重複するプラグインが複数存在すると、不要なCSS・JavaScriptが読み込まれ続けます。プラグインの数よりも「各プラグインが何を読み込んでいるか」が問題です。

レンダリングブロッキングリソース

CSSとJavaScriptが`<head>`内で読み込まれると、ブラウザはこれらの処理が完了するまでページの描画を開始できません。特にjQueryやスライダー系のJSライブラリが多い場合に起こりやすい問題です。

キャッシュが未設定

WordPressはデフォルトではアクセスのたびにPHPを実行してHTMLを動的生成します。キャッシュを設定することで、生成済みのHTMLを再利用でき、サーバー負荷と応答時間を大幅に削減できます。

テーマの品質

高機能・多機能なテーマは使わない機能のCSSやJSまで読み込むことがあります。特にページビルダー系テーマはファイルサイズが肥大化しやすく、表示速度の面では不利になる場合があります。

表示速度の計測ツール

改善を始める前に、現状を正確に把握することが不可欠です。主要な計測ツールとその特徴を理解しましょう。

PageSpeed Insights（PSI）

Googleが提供する無料ツールで、URLを入力するだけでモバイル・PC別のスコアとCore Web Vitalsの計測結果が得られます。「フィールドデータ（実際のユーザーデータ）」と「ラボデータ（テスト環境のデータ）」の両方が確認でき、具体的な改善提案も表示されます。改善前後の比較に最も使いやすいツールです。

Google Search Console

「ウェブに関する主な指標」レポートで、サイト全体のCore Web Vitals状況を一覧で確認できます。実際のユーザー（Chrome利用者）のフィールドデータに基づいているため、PSIのラボデータよりも実態に近い数値が得られます。問題のあるURLが一覧化されるため、修正の優先順位付けに役立ちます。

GTmetrix

ウォーターフォールチャートで各リソースの読み込み順序と時間を可視化できます。「どのファイルが遅延の原因か」をリソースレベルで特定するのに有効です。無料プランでも基本的な分析は十分できます。

Chrome DevTools（ブラウザの開発者ツール）

NetworkパネルとPerformanceパネルを使うことで、ローカル環境を含めた詳細なパフォーマンス分析が可能です。LCP要素の特定、レンダリングブロッキングリソースの確認など、プラグインでは掴みにくい問題の根本調査に使います。

Claude Code・AIエージェントの業務導入をご検討の方は、自社での開発実例を公開しているクリスタルメソッドの無料相談をご利用ください。

WordPress 表示速度改善の具体的な対策

原因と計測ツールを理解したうえで、実際の改善施策を優先度の高い順に解説します。

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

最もコストパフォーマンスの高い施策の一つです。代表的なプラグインとして「WP Rocket」（有料）「W3 Total Cache」「WP Super Cache」（ともに無料）があります。ページキャッシュを有効にするだけで、多くのケースでTTFBと全体的な読み込み時間が改善します。

WP Rocketは設定が簡単で、後述するファイル最適化・遅延読み込みなども一括で設定できるため、初心者にも扱いやすい選択肢です。サーバー側でNginxやVarnishのキャッシュが有効な場合は、プラグインとの競合に注意が必要です。

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

画像は多くのWordPressサイトで最大の転送量を占めます。以下の3点を実施しましょう。

圧縮：「EWWW Image Optimizer」や「Imagify」でアップロード済み画像を一括圧縮。品質を維持しながらファイルサイズを30〜70%削減できます。
WebP変換：JPEGやPNGより30〜50%軽いWebP形式へ変換。上記プラグインで自動変換が可能です。
遅延読み込み（Lazy Load）：スクロールしないと見えない画像は、表示されるタイミングまで読み込みを遅らせます。WordPressは5.5以降、ネイティブで`loading=”lazy”`属性をサポートしています。

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

LCPは「ビューポート内で最も大きなコンテンツ要素」の描画速度です。当社の運営するメディアサイトでは、PageSpeed InsightsとChrome DevToolsを使ってLCP要素を調査したところ、記事一覧ページのトップに表示されるニュースサムネイル画像がLCP要素であることが判明しました。

このサムネイル画像は遅延読み込みが適用されており、それが原因でLCPが 8.1 秒という深刻な状態になっていました。LCP要素に`loading=”lazy”`を適用してはいけません。LCP要素の画像には逆に優先読み込み（fetchpriority=”high”）を付与し、遅延読み込みを解除することが正しい対応です。

さらに、サムネイル画像をWebP形式に変換し、表示サイズに合わせてリサイズしたところ、LCPは8.1 秒から 1.7 秒へと大幅に改善しました。Core Web Vitalsの評価も「不良」から「良好」に変わり、検索上の評価改善にも寄与しました。

問題発見

LCP 8.1秒

PSI・DevToolsで計測

→

原因特定

LCP要素＝
Newsサムネイル

lazy load誤設定

→

対策実施

lazy解除＋
fetchpriority=”high”

WebP変換・リサイズ

→

改善完了

LCP 1.7秒

評価：良好

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

ファイルの最小化（Minify）はコメントや空白を除去してファイルサイズを削減します。JSの結合・非同期化（async/defer属性の付与）はレンダリングブロッキングを防ぎます。WP RocketやAutoptimizeプラグインで設定できますが、テーマやプラグインによっては競合が発生することがあるため、変更後は必ず表示確認を行ってください。

⑤ CDN（コンテンツデリバリーネットワーク）の利用

CDNはサーバーのコンテンツを世界各地のエッジサーバーにキャッシュし、訪問者に最も近いサーバーから配信します。日本のサーバーを使っていても海外からのアクセスが多いサイトでは特に効果的です。Cloudflareの無料プランはWordPressでも比較的導入しやすく、CDNに加えてDDoS対策やSSL証明書も提供します。

⑥ データベースの最適化

WordPressは投稿のリビジョン（自動保存履歴）、スパムコメント、削除済みデータなどをデータベースに蓄積します。これらが大量になるとデータベースクエリが遅くなります。「WP-Optimize」や「Advanced Database Cleaner」で定期的にクリーンアップを行いましょう。また、`wp-config.php`に`define(‘WP_POST_REVISIONS’, 5);`を追記してリビジョン数を制限することも有効です。

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

古いPHPバージョンを使い続けているサイトは、パフォーマンス面でも大きな損失があります。PHP 8.1〜8.3はPHP 7.x系と比較して実行速度が大幅に向上しています。レンタルサーバーのコントロールパネルからPHPバージョンを変更できる場合が多いです。変更前にプラグイン・テーマとの互換性を確認してください。

⑧ 不要プラグインの整理と代替検討

各プラグインが何のCSS・JSを読み込んでいるかをChrome DevToolsのNetworkパネルで確認し、使用していないプラグインは停止・削除します。また、複数の機能を一つのプラグインにまとめることで読み込みファイル数を削減できます。例えばSEOプラグイン・キャッシュプラグイン・画像最適化プラグインの3本構成を基本とし、それ以外は本当に必要かどうか検討します。

⑨ ホスティング環境のアップグレード

上記の施策をすべて試みてもTTFBが遅い場合は、ホスティング環境の見直しが根本解決になります。共有サーバーからVPS・マネージドWordPressホスティング（Kinstaなど）への移行は、サーバー応答速度とスループットを根本から改善します。特にアクセス数が月間10万PVを超えるサイトでは、ホスティング品質への投資効果が高くなります。

改善の優先順位と進め方

表示速度改善は「一度にすべてをやる」のではなく、インパクトの大きい施策から段階的に取り組むことが重要です。以下のフレームワークを参考にしてください。

計測・ベースライン確認
PageSpeed Insights・GTmetrix・Search Consoleで現状スコアを記録する

サーバー品質の確認
TTFBが200ms超ならホスティング改善を最初の検討対象にする

LCP要素の特定と対策
DevToolsでLCP要素を確認し、画像なら最適化・優先読み込みを実施

キャッシュと画像の一括最適化
キャッシュプラグイン導入・画像圧縮・WebP変換・Lazy Loadを設定

JS・CSSの最適化
Minify・defer/async化・不要プラグインの削除を実施

再計測・効果確認
各施策後にPageSpeed Insightsで数値を確認。Search Consoleで28日後の変化を追う

よくある失敗と注意点

LCP要素に誤ってLazy Loadを設定する

前述のとおり、LCP要素（ファーストビューで最大の画像など）に`loading=”lazy”`を付与するとLCPスコアが悪化します。WordPressのテーマによっては、サムネイル画像全体に一括でlazy loadを適用している場合があり、意図せずLCP要素に適用されていることがあります。必ずDevToolsでLCP要素を特定してから、その要素のloading属性を確認してください。

キャッシュプラグインの競合

複数のキャッシュプラグインを同時に有効にしたり、サーバー側のキャッシュとプラグインキャッシュが干渉したりすると、コンテンツが正しく更新されない・ページが壊れるといった問題が発生します。キャッシュは一つの仕組みに絞ることが原則です。

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

PageSpeed InsightsのスコアはGoogleのテストサーバーから計測したラボデータが中心であり、実際のユーザー環境とは異なります。スコアが90点以上でも実ユーザーの体感が遅い場合もあるため、Search Consoleのフィールドデータも必ず確認してください。

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

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

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

表示速度は一度改善してもその後のプラグイン追加やコンテンツ更新によって再び悪化することがあります。継続的なパフォーマンス維持のために以下を習慣化しましょう。

新プラグイン導入前後に必ず計測する：新しいプラグインが何のリソースを追加するかを確認し、速度への影響を把握する
月1回のSearch Console確認：「ウェブに関する主な指標」レポートで新たに「要改善」「不良」となったURLがないかチェックする
画像アップロード時のルール化：大きな画像は必ずリサイズ・圧縮してからアップロードするルールを設定する
PHPとWordPress本体の定期アップデート：パフォーマンス改善が含まれるケースも多く、セキュリティとあわせて最新版を維持する

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

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

TTFBとフロントを分けて測る

ブラウザの開発者ツール（Networkタブ）で、HTMLドキュメント自体の「Waiting for server response（TTFB）」を確認する。ここが長ければ原因はサーバ／PHP／DB側であることが多い。
TTFBは短いのに全体が重い場合は、画像・CSS・JS・Webフォントなどフロントの読み込み側が原因であることが多い。Waterfallでどのリクエストが長いか、どこで直列に待たされているかを見る。
キャッシュ有効時と無効時（管理画面ログイン状態など）で数値が大きく異なることがあるため、ログアウト状態の実ユーザー相当でも測る。

プラグインを二分探索で特定する

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

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

症状	疑うべき原因	確認する場所
ページ全体が均一に遅い／TTFBが長い	サーバ・PHPバージョン・重いDBクエリ	Query Monitor等の診断プラグインで遅いクエリを確認、PHP設定
特定ページだけ遅い	そのページの投稿数・関連表示・重いショートコード	該当テンプレート、ループ処理
初回は遅いが2回目は速い	キャッシュ未生成／キャッシュ対象外	キャッシュ層の除外設定
画像の多いページで極端に遅い	未圧縮・原寸配信・遅延読み込み未適用	Networkの画像サイズと表示サイズ

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

サイトを壊さず「戻せる」状態のまま高速化を進める実務手順

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

変更を1つずつ・計測しながら進める

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

戻せる状態を先に用意する

変更前にフルバックアップ（DB＋ファイル）を取得する。特にfunctions.phpやテーマ直接編集は退避（.bak）してから触る。
プラグインで挙動を変える設定は、どの項目をオンにしたかを記録する。不具合時に「全停止して戻す」より「その1項目だけ戻す」ほうが早く復旧できることが多い。

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

速度改善の作業中に誤判定しやすいのが、キャッシュ絡みの問題です。設定を直したのに反映されない／直したはずの崩れが直らない、という場合は古いキャッシュが残っているだけのことがあります。判断を誤らないために次を徹底します。

場面	やること	理由
設定変更の直後	ページキャッシュとCDN/ブラウザキャッシュを両方クリアする	層が複数あり、片方だけ消しても旧表示が残ることがある
崩れの確認	ログアウト状態＋シークレットウィンドウで確認する	ログイン中はキャッシュ対象外で本番と挙動が異なる場合がある
「直らない」と感じた時	まずキャッシュとCDNを疑い、設定を重ねていじらない	キャッシュ由来を設定ミスと誤認して改悪してしまうことがある

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

まとめ

WordPress 表示速度改善とは、サーバー応答から画像配信、コード最適化まで多層にわたる取り組みです。重要なのは「計測→原因特定→優先度の高い施策から実施→再計測」というサイクルを繰り返すことです。

Core Web Vitalsの3指標（LCP・INP・CLS）を軸に現状を把握し、LCP要素の特定・画像最適化・キャッシュ設定を最初のステップとして取り組むことで、多くのサイトで大きな改善効果が得られます。実際にニュースサムネイル画像のLCP要素を特定し、誤ったLazy Load設定を修正してWebP化を行った結果、LCPを 8.1 秒から 1.7 秒へ改善できたように、原因の正確な特定が最短ルートへの鍵です。施策は闇雲に増やすのではなく、根拠を持って一つひとつ検証する姿勢が、持続的な高速化につながります。

参考（公式ドキュメント）

Study about AI

AIについて学ぶ

生成AIの著作権と法的リスクを回避する安全対策｜米国xAI社提訴から学ぶ経営視点の実務

## 生成AIの法的リスクを浮き彫りにしたxAI社への民事訴訟 2026年7月23日、米国の法律事務所Potts Law Firmは、xAI社（Grok AIの...
AI ユーザー活用実態調査から紐解く日本企業の現在地と経営層が取るべき次の一手

対話型AIの急速な普及に伴い、世界のユーザーが実際にどのような目的でAIを使い、どのような課題に直面しているのか、その具体的なデータの蓄積が進んでいます。Goo...
AIモデル盗用セキュリティリスクとは？MoonshotのClaude 5蒸留疑惑から学ぶ企業の防衛策

AIモデル盗用セキュリティリスクとは？MoonshotのClaude 5蒸留疑惑から学ぶ企業の防衛策生成AIの急速な普及と高度化に伴い、企業の意思決定者は生産...