WordPressが重い理由は？2つの原因とキャッシュが効かない部分

「WordPressは重い」とよく言われます。けれど、何がどう重いのかまで分けて説明されることは、あまりありません。

この記事では、WordPressがページを表示する仕組みから、重くなる理由を2つに分けて整理します。プラグイン・テーマ・サーバー・キャッシュにまつわる誤解もほどき、重さの種類に合った打ち手まで案内します。

WordPressが重い理由は「表示までに2か所で時間がかかる」から

まずは仕組みからです。ここが分かると、後の誤解や打ち手の話がすっきり整理できます。

WordPressがページを表示するまでの流れ

WordPress公式の解説によると、ページへのアクセスがあると、WordPressはおおむね次の順で動きます。（出典: Learn WordPress「Front-end page request」 ）

公式のリファレンスでは、本体・すべてのプラグイン・テーマが読み込まれてから次の処理に進む、と説明されています。つまり、テーマやプラグインは管理画面の中だけでなく、ページを表示するたびに関わっているのです。（出典: WordPress公式「wp-settings.php」 ）

静的HTMLとの違いを並べると、こうなります。

最後の行が大事なポイントです。ブラウザ側の重さは、どちらの仕組みでも「何を載せたか」で決まります。

重さの1つ目：サーバーでページを「組み立てる」時間

1つ目は、HTMLがブラウザに届き始めるまでの時間です。これをTTFB（Time to First Byte）と呼びます。

web.devの定義では、TTFBにはサーバーの処理だけでなく、リダイレクト、DNSの名前解決、接続の確立、応答を待つ時間まで含まれます。目安は0.8秒以下が良好、1.8秒を超えると不良です。（出典: web.dev「TTFB」 ）

組み立ての時間には、次のような要素が効いてきます。（出典: WordPress公式「Optimization」 ）

知恵袋でも「WordPressはメモリを多く使う」という回答が見られますが、メモリの上限値を上げれば速くなる、というものではありません。（出典: WordPress公式「wp_initial_constants()」 ）

ここで1つ、よくある誤解を正しておきます。「WordPressはアクセスのたびに、必ずページを作り直している」わけではありません。ページキャッシュを使えば、一度作ったページを保存して使い回せるため、組み立ての手間を省けます。（出典: WordPress公式「Cache」 ）

重さの2つ目：ブラウザで「読み込み・描画」する時間

2つ目は、HTMLが届いた後の時間です。ブラウザはHTMLを読みながら、画像・CSS・JavaScript・フォントを次々に取りに行き、画面を描いていきます。

ページの中で一番大きな画像や文字の塊が表示されるまでの時間を、LCP（Largest Contentful Paint）と呼びます。大きなメイン画像は、ファイルの重さだけでなく、ブラウザがいつその画像を見つけて取りに行けるかによっても表示を遅らせます。（出典: web.dev「LCP」 ）

フォントとスクリプトも、ここに効いてきます。

WordPressでは、テーマやプラグインがそれぞれCSSやJavaScript、フォントを読み込みます。機能を足すほど、この2つ目の時間も膨らみやすい作りなのです。

数字で見るWordPressの重さ

では、実際のWordPressサイトはどれくらい重いのでしょうか。HTTP Archiveが2026年1月に公開した「2025 Web Almanac」（2025年7月のデータ）には、CMSごとの比較があります。（出典: HTTP Archive「2025 Web Almanac：CMS」 ）

モバイルで、表示の速さ・反応の速さ・画面のずれの3つすべてが良好だったサイトは、WordPressでは半分以下でした。

ただし、この数字はWordPress本体だけの速さではありません。ホスティング、テーマ、プラグインなどを含めた、実際のサイトの結果です。WordPressは2024年から2025年にかけて改善した、とも報告されています。

同じWordPressでも、重さの出方は違う（自社2サイトの実測）

私自身の2サイトでも、重さの出方ははっきり違いました。どちらもWordPressで作っていた時代の数字で、売る側（制作者本人）の事例であることはご了承ください。

点数は近いのに、重さの出方はまるで違います。花文字は表示が始まるまでが遅く、操作の固まりはゼロでした。自社サイトは表示開始こそ3.3秒でしたが、操作できるまで固まる時間（TBT）が610ミリ秒と目立ちます。

正直に言うと、当時はTTFBを記録していませんし、自社サイトのTBTの原因も記録していません。組み立てと読み込みのどちらが主な原因だったのかは、きちんと切り分けられていないのです。花文字については、外部から読み込んでいたGoogle Fontsが決定打だったと私は見ています（詳しくは【実録】自分で作ったWordPressサイトを静的HTML化した全記録 ）。

言えるのは、同じWordPressでも、どこが重いかはサイトごとに違うということ。だからこそ、思い込みで手を打つ前に、測って切り分けるのが先なのです。

では、よく耳にする「〇〇のせいで重い」は、どこまで正しいのでしょうか。

WordPressが重い理由でよくある誤解（プラグイン・テーマ・サーバー・キャッシュ）

ネットでよく見る「重い原因」を、2つの場所に当てはめながら確かめていきます。

「プラグインが多いほど重い」？——数より中身

プラグインは、確かに重さの原因になります。ただ、WordPress公式は「数」と「それぞれの性能」の両方を要因に挙げ、1つずつ停止して測る方法を示しています。「何個以上なら遅い」という共通の基準はありません。（出典: WordPress公式「Optimization」 、Kinsta ）

ほかの制作者の事例が分かりやすいです。高速テーマのSWELLを使い、画像もWebP化済みなのに50〜55点だったサイトで、機能を1つずつ止めて影響を測った例です。

フォントやスライダーを外したうえで、プラグインもすべて一時停止した段階で99点まで上がりました。原因を探すための切り分けの数字で、最終的な構成の点数ではありません。（出典: tae-create.com ）

「高い有料テーマなら速い」？——価格ではなく作り

WordPress公式がテーマについて挙げているのは、軽量で効率的な作りか、画像が多く非効率な作りか、という違いです。価格と速さの関係を示す資料は見つかりませんでした。（出典: WordPress公式「Optimization」 ）

冒頭でも触れたとおり、私が作った花文字のサイトは「高速」をうたう有料テーマを使い、高速なレンタルサーバー、画像圧縮プラグイン、キャッシュの設定まで入れて57点でした。テーマの名前や値段では、重さは決まらないのです。

「サーバーを変えれば速くなる」？——半分正解

サーバーの性能（CPU・メモリ・混み具合）は、組み立て側の時間に効きます。一方で、画像の重さやブラウザでのJavaScriptの処理は、サーバーを変えても軽くなりません。（出典: WordPress公式「Optimization」 ）

Xでは、制作者のこんな指摘がありました。

Dacchi615 Xの投稿より

サーバーを変えればWordPressは速くなる、 というのは、半分正解、半分間違いです。 サイトの遅さの原因が画像・重いテーマ・大量のプラグインにあるなら、移転しても根本的には解決しないこともあります。まず原因を確認。サーバー移転はその後です。

Xで元の投稿を見る

私も同じ考えです。サーバーを変えて縮むのは、組み立ての時間だけ。読み込み側が重いサイトなら、引っ越し代を払っても体感はほとんど変わらない、ということが起こり得ます。

実際、ほかの制作者の事例では、mixhost（LiteSpeed）へ移った後もモバイル45点でした。その後、不要なプラグインの停止、画像の圧縮、キャッシュやコードの最適化を重ねて73点、のちに78点まで上がっています。サーバーの引っ越しだけでなく、中身の手当てが効いた例でしょう。（出典: funet.work ）

PHPのバージョンも、よく話題になります。ホスティング会社Kinstaの自社測定（WordPress 6.8.0・追加プラグインなし・追加キャッシュなし・OPcache有効・同時接続15・各構成5回）では、1秒あたりに処理できたリクエスト数は次のとおりでした。（出典: Kinsta「PHP benchmarks」 ）

差は小さく、8.3は8.2より低い結果です。新しいほど必ず速い、とは言えません。これは処理能力の比較で、ページの表示時間がこれだけ縮むという意味でもない点に注意してください。

「キャッシュを入れれば解決」？——組み立ては省けても、読み込みは残る

先ほど見たとおり、ページキャッシュで減らせるのは組み立ての時間です。ブラウザが画像・CSS・フォント・JavaScriptを読み込む時間は、キャッシュでは消えません。ログイン中の閲覧やECのカートなど、そもそもキャッシュの対象から外れるページもあります。（出典: WordPress公式「Cache」 、WP Rocket ）

見落としやすいのはWebフォントと外部スクリプト

プラグインやサーバーに目が行きがちですが、読み込み側で効いてくるのがWebフォントと外部スクリプトです。

外部のフォントやスクリプトは、ブラウザに読み込みや描画を待たせることがあります。（出典: web.dev「Font best practices」 ）

先ほどのSWELLの事例では、Googleフォントを1つ外して約5点、すべて外して約15点、スライダーを外して約15点上がっていました。速くするために機能を外すときは、お客さんとどれを残すかを相談したそうです。（出典: tae-create.com ）

Webフォントを外したら点数が大きく上がった、という経験は私にもあります。花文字を作り直したときも、外部のGoogle Fontsをやめて端末に入っているフォントに切り替えました。見た目のこだわりと速さは、ときに引き換えになります。

結局のところ、やるべきことは1つに絞られます。どちらの重さなのかを、測って確かめることです。

WordPressが重い理由に合わせて、打ち手を選ぶ

打ち手は、大きく分けて2つの方向があります。

まず「どちらの重さか」を切り分ける

切り分けには、GoogleのPageSpeed Insightsが使えます。TTFBが遅ければ組み立て側、表示開始（FCP）やLCP、操作の固まり（TBT）が遅ければ読み込み・描画側を疑う、というのが基本の見方です。

点数は低いのに、見た感じはそこまで遅くない。そんな相談はよくありますが、それは速い回線で見ているからかもしれません。

Xでは、別の制作者がこう書いていました（一部抜粋）。

Ryo_DS3 Xの投稿より

速度調査するとWordPressの処理速度は0.03秒。 原因は回線だったので、繋ぎ直したらある程度解消されました。 ただ、測る過程で雛形由来の無駄を発見。 使っていないライブラリ、CDN待ちのGSAP、使わないフォント。 速い遅いは、体感ではなく数字で見る。

Xで元の投稿を見る

組み立てが0.03秒なら、サーバー側の処理を疑う必要は薄いでしょう。そして測ったからこそ、使っていないフォントやライブラリという、読み込み側の無駄が見つかっています。サーバーが遅いと思ったら原因は回線や画像だった、という場面は私も経験があります。

ただ、今回の調査では、組み立て側が主な原因だったとはっきり分かる実測例は手元にありませんでした。だからこそ、どちらと決めつけずに測ることが大切です。

測った結果は、次のように打ち手へつなげます。

（出典: web.dev「Optimize TTFB」 、web.dev「Optimize LCP」 、web.dev「TBT」 ）

測り方や点数の見方は、PageSpeedのスコアを改善するには｜57点→100点の実例と発注側の視点 で詳しく解説しています。

WordPressのまま軽くした例

WordPressのままでも、読み込み側を手当てして軽くなった例はあります。ほかの制作者の事例をまとめると、次のとおりです。

（出典: cielo-design.com 、tae-create.com 、funet.work ）

後から足した画像が重くなっていた、高速テーマとWebP化を済ませても点数が上がらない、といった相談は私も受けたことがあります。一方で、私自身の経験では、WordPressのまま設定を触っても、思うようには速くなりませんでした。速くできたのは、静的HTMLに作り替えたときです。

どちらが正しい、という話ではありません。重さの種類と、どこまで機能を残したいかで、WordPressのままで足りるかどうかが変わります。具体的な手順は、ホームページの表示が遅い原因と、根本から速くする方法 にまとめています。

組み立てをやめる静的化という選択と、向かないサイト

もう1つの方向が、組み立てそのものをやめる静的化です。作り置きのHTMLを返すだけなので、PHPでの組み立て処理はなくなります（通信の時間は残ります）。

私の2サイトは、どちらも静的HTMLに作り替えてPageSpeed Insights（携帯電話）で100点になりました。

どちらも、作り直しのときに複数の変更を同時に入れています。花文字ではフォントを変え、自社サイトでは配信先も移しました。点数の差は、静的化だけの効果ではありません。

静的化には向かないサイトもあります。次に当てはまるなら、WordPressのまま軽くするほうが合うでしょう。

WordPress以外の選択肢を比べたい方は、WordPressを使わないホームページという選択肢 も参考にしてください。

静的でも、読み込みが重ければ遅い（医局サイトの作業記録）

私が手がけた、ある大学の医局のサイトが分かりやすい例です。もともと通常のHTMLで作られていたサイトを、静的サイトを生成する仕組み（Hugo）で作り直しました。PageSpeed Insights（携帯電話）の数字は、作り替え前の76点から97点に、LCPは5.0秒から2.5秒になっています（2026年8月27日に測定）。

その途中は、順調ではありませんでした。作業中のある時点では、モバイル70点・LCP 11.9秒という計測も出ています。組み立てる処理は一切ない静的なサイトなのに、です。

作業の記録に残っている原因は、どれも読み込み側でした。

一度、CSSの埋め込みだけを見送ったことがありますが、そのときは点数がいまひとつでした。画像だけ、フォントだけを直しても足りず、いくつもの読み込みの重さが重なっていたわけです。

CSSの背景画像が見つかりにくいのは、外部のCSSを取ってきて処理しないと、ブラウザが画像のURLを知ることができないからです。web.devも、メインの画像はHTMLから見つけられるようにすることを勧めています。（出典: web.dev「Optimize LCP」 、web.dev「Fetch Priority」 ）

なお、PageSpeed Insightsの点数は測るたびに数点ぶれます。途中の数字は作業中の記録として見てください。

WordPressが重い理由は「組み立て」と「読み込み」の2つ

重さの出どころは、組み立てと読み込みの2か所。キャッシュやサーバーの変更が効くのは主に組み立て側で、画像・フォント・外部スクリプトの重さは、どんな仕組みでも作り方次第で残ります。

静的化の費用や進め方が気になった方はWordPressの静的化を代行で頼む費用と手順 を、自社サイトの重さを測ってほしい方は無料スピード診断 をご利用ください。

あわせて読みたい

ホームページの表示が遅い原因と、根本から速くする方法

自社のホームページが遅い・スマホで真っ白——その原因（重い仕組み・画像・共有サーバー・使わない機能）と、速さの目安（Core Web Vitals）、測り方、軽量化と静的化どちらで直すかまでを、発注側の目線で解説します。

ページを見る →

WordPressが重い理由に関するよくある質問

Yahoo!知恵袋に実際に寄せられている質問から、重さに関わるものを選んで答えます（「」内は質問の書き出しです）。