【2026年3月版】WordPressサイトが重い(遅い)理由

皆さんこんにちは。
taneCREATIVEの「ちほうタイガー」です。

この記事は、WordPressの表示速度や管理画面が遅くなる理由についてまとめたもので、2026年3月3日に改訂しています。

WordPress（ワードプレス）は、世界で圧倒的な支持を得ているオープンソースのブログソフトウエアであり、CMS（コンテンツ管理システム）です。
W3Techsによれば、世界中のWebサイトの約42.6％がWordPressで構築されているとのことです（W3Techs）。

なお、CMSというマーケットにおいて、WordPressは59.9%のシェアを有しているとのことですので、世界で最も使用されているCMSであると言ってよいでしょう。

このWordPressが圧倒的なシェアを有するようになった主な原因としては、WordPressは、オープンソースのCMSであり無料であるというだけでなく、動的なCMSとして様々な機能を実装しやすく、しかも様々なテーマ（Webサイトのデザイン・機能がセットになったパッケージ）やプラグイン（WordPressに機能を追加・カスタマイズするための拡張ツール）などが豊富に開発されており、その結果、初期費用を抑えながら、一定レベル以上の高品質なWebサイトの制作、管理システムの開発、運用を実現できるということになるかと思います。

一方で、動的なCMSであること、テーマやプラグインを用い易いことから、設計・実装の方法次第では表示速度や反応速度が重い（遅い）Webサイトになりやすい傾向にあります。

そこで、本記事では、WordPressで構築されたサイトが重く（遅く）なりやすい理由について、Web制作会社の観点から解説していきます。

まず、前述のように、WordPressは、動的CMSとして様々な機能を実装しやすく、しかも様々なテーマやプラグインなどが豊富に存在することから、非常に利便性の高いCMSであることは間違いありません。

一方で、この特徴が、WordPressで構築されたサイトが重く（遅く）なりやすくなる理由になります。

まず、WordPressは動的CMSであることから、サーバー側の処理負荷が発生しやすい構造となっています。

ここでいう動的CMSとは、ユーザーがアクセスをした時の情報に基づいてデータベースにアクセスし、リアルタイムでWebページを生成するCMSのことを指します。

具体的には、動的CMSのケースでは、Webサーバー内に最初から完全なHTMLファイルが存在するわけではなく、①ユーザーがWebサーバーにアクセス（リクエスト）をすると、②CMSの方でDBサーバーにコンテンツデータ（オプション・投稿・メタなど）を渡すよう指示を出し（クエリ送信）、③DBサーバーからコンテンツデータを送ってもらった上で、④（ページによっては）ユーザーがブラウザで入力したデータや、Webサーバー内に元からある更新頻度の低いファイルと組み合わせて、テーマがHTMLファイルを作成して、⑤ブラウザへ送信するという手順を踏みます（実際にはより多くのステップがありますが、動的なCMSの概要を理解しやすくするようにかなり簡略化しています）。
このように、WordPressで構築されたWebサイトをユーザーが閲覧する際には、基本的に多くのステップを踏むことになることから、（キャッシュが適切に構成されていない場合には）表示速度が遅くなる傾向にあります。

これに対し静的CMS（Jamstackなど）とは、Webサーバー内に最初から完全なHTMLファイルが存在させる手法ですので、①ユーザーがWebサーバーにアクセス（リクエスト）をすると、②Webサーバーが要求されたデータをそのままブラウザに送信し、表示します。
この静的CMSでは、基本的に動的CMSよりステップ数が少ないことから、Webサーバーからのリアクションタイムが短く、表示速度が速くなる傾向にあります。
※この静的CMSと静的サイトジェネレーター（SSG）の違いもあるため、それぞれの流れを（かなり）単純化してまとめた図を作成してみました。

WordPressは動的CMSであり、MySQLないしMariaDBというデータベース内にコンテンツデータが保管されていますが、運用をするに伴い、コンテンツ以外にも色々なデータが保管されていきます。
具体的には、固定ページや投稿の過去の履歴（リビジョン）や、スパムコメントや未承認コメント、下書きデータ、トランジェントデータ、wp_optionsテーブル内のautoloadデータ、投稿メタ・ユーザーメタデータなどです。

Webサイトの運用期間が延びることでデータが増加すること自体は自然な現象ですが、データ量の増加が直ちに速度低下を招くわけではありません。

しかし、適切なインデックス設計がされていない場合や、不要なデータが削除されない場合、テーブルの断片化が進行している場合などが複合的に重なると、クエリ実行時間が増加し、結果として表示速度に影響を与えることがあります。

特に wp_options テーブル内の autoload データが肥大化すると、ページ表示のたびに不要なデータが読み込まれるため、パフォーマンス低下の主要因となるケースがあります。

さらに、MySQLやMariaDBのストレージエンジンであるInnoDBは、頻繁に参照されるデータをメモリ上に保持する「InnoDB buffer pool」というキャッシュ領域を使用しています。
このbuffer poolのサイズが十分に確保されていない場合、データの多くをディスクから都度読み込む必要が生じディスクからのデータ読み込みに時間がかかり、処理が遅くなることがあります。

WordPressでは、テーマと呼ばれるWebサイトのデザインと機能がセットになったパッケージを利用することで、デザイン・コーディングの工数を削減することができますが、テーマの設計や実装方針によっては、表示速度に影響が出ることがあります。

特に多機能テーマでは、使用していない機能に関連するCSSやJavaScriptが読み込まれる、アセットの条件付き読み込みが行われていない、外部フォントや外部スクリプトへの依存が多い、といった要因により、ネットワーク負荷やレンダリング負荷が増加する場合があります。

WordPressでは、プラグインと呼ばれるWordPressに機能を追加・カスタマイズするための拡張ツールを利用することで、機能の開発工数を削減することができますが、プラグインの設計や実装内容によっては、表示速度に影響を与える場合があります。

プラグインによっては、不要なデータベースクエリを大量に発行していたり、使用していないページでもCSSやJavaScriptを読み込む構造になっていたり、外部API通信をページ表示時に同期実行する機能がついていたり、レンダリングをブロックするJavaScriptの使い方をしていたり、meta_queryを多用していたりするなどの理由で、サーバー負荷、ネットワーク負荷・レンダリング負荷が増加し、表示速度を低下させるものがあります。

なお、たまに「プラグインの数が多いこと自体がダメなのか？」というご質問をいただきますが、プラグインの数が多いことが直ちに表示速度の低下につながるわけではなく、各プラグインの処理内容や実装品質の方が大きな影響を与えます。

WordPressには「wp-cron」と呼ばれる疑似的なcron機能（クロン機能、決められた時刻や間隔に処理を自動実行する仕組み）が標準で実装されています。
これは予約投稿の公開、プラグインの定期処理、キャッシュ削除、トランジェントの整理などを自動実行するための仕組みです。

しかし、wp-cronは一般的なサーバーサイドのcronとは異なり、サイトへのアクセスを契機として実行される仕組みになっています。つまり、ユーザーがページにアクセスしたタイミングでwp-cron.phpが呼び出され、内部処理が開始されます。

このアクセス時に、バックアップ処理や外部APIとの通信、定期バッチ処理などの負荷の高いタスクが同時に実行されると、ページの表示処理と競合し、サーバー応答時間（TTFB）が増加することがあります。
特にアクセスの少ないサイトでは、実行待ちのタスクが蓄積し、次回アクセス時にまとめて処理されることで、一時的に表示が極端に遅くなるケースもあります。

上記のように、WordPressは、動的CMSであること、テーマやプラグインを用い易いことから、設計・実装の方法次第では表示速度や反応速度が重い（遅い）Webサイトになるケースがありますが、WordPressの特徴と関係なく、サーバーサイド、ネットワーク、レンダリングの高速化を意識せずにWebサイトが制作・運用されていることで重い（遅い）ケースもあります。
以下、当社に高速化のご相談をいただくケースでよくある原因をご紹介してみます。

WordPressであるかどうかに関わらず、WebサーバーのCPU・メモリ・ディスクI/O性能などのリソースが不足している場合には、表示速度が重く（遅く）なることがあります。

特に動的CMSでは、PHPの実行やデータベース処理が発生するため、CPUやメモリが不足すると応答時間（TTFB）が増加しやすくなります。また、ディスクI/O性能が低いと、データベースアクセスやファイル読み込みに時間がかかります。

AWS等のクラウドサーバーでは、選択しているインスタンスタイプのスペックが不足しているケースがあります。

一方、共有レンタルサーバーでは、同一サーバーに格納されている他サイトの負荷の影響を受け、表示速度が不安定になることもあります。

WordPressやプラグインのほとんどはPHPというプログラム言語で開発されています。

PHPはバージョンアップごとにエンジンの最適化が進んでおり、特にPHP7以降は大幅な処理性能向上が実現されています。そのため、古いPHPバージョンを使用している場合、同じ構成でも処理速度に差が出ることがあります。

最新版に更新することは、セキュリティ対策の面だけでなく、表示速度の向上という観点からも重要です。
また、現在の多くのサーバー環境ではPHP-FPMが利用されていますが、ワーカー数やOPcacheの設定が適切でない場合にも、応答時間が増加することがあります。

WordPressサイトでは、多くの場合MySQL（またはMariaDB）が利用されています。

MySQL 8は内部構造や最適化アルゴリズムが改良されており、適切に設定された環境では旧バージョンと同等、あるいはそれ以上の性能を発揮します。

しかし、5系統など旧バージョンから8系統へ移行する際に、設定値の見直しやインデックスの最適化を行っていない場合、実行計画の変化やデフォルト設定の違いにより、クエリ処理が遅くなるケースがあります。

WordPressサイトは、Apache、Nginx、LiteSpeed、IISなどのWebサーバーソフトウェア上で動作します。

一般的に、NginxやLiteSpeedはイベント駆動型アーキテクチャを採用しており、高同時接続環境では効率的に処理できるとされています。一方、Apacheも適切に設定されたMPM eventやPHP-FPM構成であれば、高いパフォーマンスを発揮します。

そのため、各Webサイトの用途や使用状況に合わせたWebサーバーソフトウェアを選択し、かつ設定内容やキャッシュ構成（ページキャッシュ、リバースプロキシ、OPcacheなど）、PHPとの連携方式を適切に設定できていない場合には、Webサーバーの応答時間（TTFB）が長くなる可能性があります。

WordPressは動的CMSであるため、通常はページ表示のたびにPHPの実行やデータベースへのアクセスが発生します。この動的処理を毎回行っている場合、アクセス増加時にサーバー負荷が高まり、応答時間（TTFB）が増加しやすくなります。

これを回避する代表的な手法が「ページキャッシュ」です。ページキャッシュを導入することで、生成済みのHTMLを保存し、次回以降のリクエストではPHPやデータベース処理を省略できます。適切に構成されたページキャッシュは、動的CMSを実質的に静的配信に近い状態へ変換する役割を担います。

また、「オブジェクトキャッシュ」も重要です。オブジェクトキャッシュ（RedisやMemcachedなど）は、データベースから取得したクエリ結果をメモリ上に保持し、同一リクエスト内や後続リクエストで再利用する仕組みです。ページキャッシュが無効化されるログインユーザー閲覧時やECサイトのカート画面などでも、データベース負荷を大きく削減できるため、動的サイトでは特に有効です。

さらに、PHPには「OPcache」というバイトコードキャッシュ機構があり、PHPスクリプトを毎回コンパイルせずに実行できるようにします。OPcacheが無効化されている、あるいはメモリ設定が不足している場合、PHPの再コンパイルが頻発し、処理効率が低下することがあります。

一方、CDN（コンテンツデリバリーネットワーク）は、画像やCSS、JavaScriptなどの静的アセットを地理的に近い拠点から配信することで、サーバーとの通信にかかる時間を短縮します。CDN単体ではPHP処理を削減できませんが、通信経路を最適化することで体感速度の改善に寄与します。

さらに近年では、CDN側でHTMLそのものをキャッシュする「エッジキャッシュ（フルページキャッシュ）」機能が普及しています。これを適切に設定することで、WordPressで生成されたHTMLをCDN側に保存し、次回以降はCDNから直接配信できるようになります。その結果、WordPressサーバー側で毎回動的処理を行う必要がなくなり、静的サイトに近い応答性能を実現できます。

ページキャッシュ、オブジェクトキャッシュ、OPcache、CDN（エッジキャッシュを含む）を組み合わせた「多層キャッシュ設計」が適切に行われていない場合、サーバー負荷やネットワーク遅延が積み重なり、表示速度が低下するケースがあります。

画像のフォーマットについては、WebPやAVIFといった次世代フォーマットを使用することで、従来広く利用されてきたJPEG形式と比較して、多くのケースで同等の画質を維持しながらより高い圧縮率を実現できます。その結果、転送データ量を削減し、ダウンロード時間を短縮することが可能です。

現在では主要ブラウザがWebPおよびAVIFに対応しており、環境に応じて最適なフォーマットを配信することが推奨されています。
特にファーストビューに表示される主要画像は、LCP（Largest Contentful Paint）に直結するため、画像フォーマットが適切に最適化されていない場合、表示速度の低下につながる可能性があります。

HTML、CSS、JavaScript、JSONなどのテキストデータは、HTTPレスポンス時に圧縮することで転送データ量を削減できます。
gzip、deflate、brotliといった圧縮方式があり、現在では特にbrotliが高い圧縮効率を持つ方式として広く利用されています。

これらの圧縮を有効化せずにそのまま送信している場合、転送データ量が増加し、ネットワーク環境によってはダウンロード時間が長くなります。

HTML、CSS、JavaScriptのファイルには、改行や空白、インデント、コメントなど、ブラウザの実行には不要な記述が多く含まれています。これらを削除してファイルサイズを削減する手法を「Minify（軽量化）」といいます。
Minifyを実施することで、転送データ量が削減され、ダウンロード時間の短縮につながります。特にJavaScriptファイルが大きい場合や、複数のCSSファイルを読み込んでいる場合には効果があります。

Minifyを実施せずにそのまま送信している場合、転送データ量が増加し、ネットワーク環境によってはダウンロード時間が長くなります。

なお、MinifyはHTTPレスポンス時のgzipやbrotliによるテキスト圧縮とは別の最適化手法であり、両者を組み合わせることでより高い効果が期待できますが、Minifyはテーマやプラグインとの互換性に影響を与える場合があるため、実装時には表示崩れや動作不良が発生しないか十分な検証が必要になります。

Webフォントはデザイン性やブランド表現を高める一方で、Unicodeの広い文字範囲や複数のウェイト（Regular、Boldなど）を含むことから、ファイルサイズが大きくなりやすい特性があります。

Webフォントを採用しなければフォントファイルのダウンロード自体は発生しませんが、採用する場合には、使用しない文字セットやウェイトを削除する「サブセット化」を行うことで、大幅な軽量化が可能です。

Webフォントを採用しつつ最適化がされていない場合、フォントの読み込み遅延によりテキスト表示が遅れたり、レイアウトシフトが発生し、CLSが悪化することがあります。特にファーストビューのテキストがLCP要素となる場合、表示パフォーマンスに直接影響を与える可能性があります。

動画プレイヤーやチャットウィジェットなどのサードパーティ製コンテンツは、埋め込み時に多数のJavaScriptや外部リソースを読み込みます。
特にYouTubeのiframe埋め込みでは、複数ドメインへの通信やスクリプト初期化が発生し、初期表示時のメインスレッド負荷が増加します。

これにより、LCPやINPといったCore Web Vitalsに悪影響を与える場合があります。
この問題を軽減する手法として、外観のみを静的要素で再現し、ユーザー操作時に実際のプレイヤーへ置き換えるファサードがあります。

ファサードを使用せずに直接埋め込みを行っている場合、初期表示時の負荷が増大し、表示速度が低下する可能性があります。

画像のサイズ指定とは、HTMLのimgタグにwidthおよびheight属性を明示することを指します。

これらを指定していない場合、ブラウザは画像の読み込み完了まで表示領域のサイズを確定できず、読み込み後にレイアウトが再計算されます。
その結果、ページのレイアウトシフトが発生し、ユーザー体験に悪影響を与える可能性があります。

この画像サイズの未指定は、主として視覚的安定性の指標であるCLS（Cumulative Layout Shift）に影響を与えますが、レンダリング処理が追加で発生するため、ページの描画効率が低下する可能性もあります。

オフスクリーン画像の遅延読み込み（Lazy Load）とは、ファーストビューに表示されていない画像の読み込みを、ユーザーがスクロールして表示領域に入るタイミングまで遅延させる技術です。
これにより初期表示時のネットワーク負荷を軽減し、主要コンテンツの描画を優先できます。

一方で、ファーストビューに表示される主要画像（特にLCP対象画像）にLazy Loadを適用すると、読み込み開始が遅れ、かえって表示パフォーマンスが悪化することがあります。

Lazy Loadを適切に設定していない場合、LCPの悪化や描画効率の低下を招く可能性があります。

ブラウザはHTMLを解析しながらページを描画しますが、外部CSSや同期実行されるJavaScriptはレンダリングをブロックする要因となる場合があります。

特にCSSは、適用が完了するまで描画が保留されるため、読み込みが遅いと初期表示が遅延します。
そのため、ファーストビューに必要なCSS（Critical CSS）をインライン化し、それ以外を遅延読み込みさせる手法が有効です。

また、JavaScriptについては、scriptタグにdeferやasync属性を付与することで、HTML解析を妨げない形で読み込みが可能です。
deferは分析完了後に順序通り実行され、asyncは読み込み完了時に即時実行されます。

これらのJavaScriptやCSSの最適化を行っていない場合、LCPの遅延や描画効率の低下につながる可能性があります。
なお、非同期化はテーマやプラグインとの依存関係に影響を与えるため、慎重な検証が必要です。

WordPressサイトであってもある程度は表示速度を高速にすることは比較的簡単にできます。

一方で、一定以上の高速化については、WordPressやテーマ、プラグインに対する深い理解と、サーバーサイド、ネットワーク、レンダリングの高速化に対する深い知見が必要となります。