「軽量テーマだから速い」の先へ ― WordPressの性能を“構造”で見る
結論
「軽量テーマだから速い」は半分だけ正しい。テーマはWordPressの表示速度を決める要素の一つだが、体感速度を本当に左右しているのは、描画（ブラウザ側のレンダリングとJavaScript実行）・アセット転送（CSS/JS/画像の送り方）・キャッシュ（生成済みHTMLの再利用）・DBクエリ（サーバー側のデータ取得）という4つの層の総和です。軽量テーマに替えたのに重い、と感じるなら、ボトルネックはテーマ以外の層にある可能性が高い。速さは「テーマの良し悪し」という1点ではなく、4層を貫く構造として捉えると、原因の見当が一気につきやすくなります。
この記事はこんな人へ
- 軽量・高速をうたうテーマに替えたのに、体感が変わらず「なぜ」と感じている人
- ページ速度の話が「テーマ」「プラグインの数」だけで止まりがちな人
- PageSpeed Insightsのスコアは見るが、どの数字がどの作業に対応するのか曖昧な人
- プラグインを増やすほど管理画面まで重くなってきた、と感じている運用者
- 速さを感覚ではなく、確認できる場所つきの「構造」で理解したい中級者
よくある認識（近視眼モデル）
- 「重い＝テーマが重い」。だから軽量テーマに替えれば解決する
- 「速さ＝PageSpeed Insightsのスコア」。スコアが上がれば体感も上がるはず
- 「プラグインは数が多いと重い」。だから数を減らせばよい
- 「キャッシュプラグインを入れた＝もう速い」。入れたら設定は終わり
- 「画像を圧縮した＝転送対策は完了」。あとは触る所がない
どれも間違いではありません。ただ、いずれも速度を1点（テーマ／スコア／数）に還元している点が共通の弱さです。実際の遅さは複数の層から同時に発生し、1点を直しても別の層が天井になって体感が頭打ちになります。
なぜ天井にぶつかるか
テーマが担うのは主に「どんなHTMLを出力し、どんなCSS/JSを読み込ませるか」という部分です。確かに大きな影響を持ちます。しかし、実際にユーザーが「遅い」と感じる瞬間は、テーマの外で起きていることが多い。
サーバーがHTMLを生成するのに時間がかかっていれば（DBクエリ層）、どんなに軽いテーマでも最初の1バイトが届くまで待たされます。生成済みHTMLを再利用する仕組み（キャッシュ層）が効いていなければ、アクセスのたびに同じ計算を繰り返します。CSS/JSの送り方（転送層）が悪ければ、HTMLは届いていても画面が完成しません。プラグインが大量のJavaScriptを足していれば、表示が出た後もボタンが反応しない（描画層）。
つまり、テーマという1層だけを軽くしても、残り3層のうち最も遅い層が新しい天井になる。これが「軽量テーマにしたのに重い」の正体です。速さは直列のボトルネックで決まるため、一番遅い層を見つけない限り、他をいくら磨いても体感は変わりません。
俯瞰で見る：層ごとの原因と確認場所
| 層 | 何が起きるか | 主な原因 | 確認の入口 |
|---|---|---|---|
| 描画（レンダリング・JS） | 画面は出るのに操作の反応が鈍い、カクつく | 過剰なJavaScript、多機能テーマ／プラグインのスクリプト、重いアニメーション | ブラウザのDevTools（Performance／Lighthouse）、PageSpeed InsightsのINP・LCP |
| アセット転送 | 初期表示が遅い、画像やフォントの読み込みが目立つ | 画像が未圧縮・サイズ過大、CSS/JSの圧縮や遅延読み込み未設定 | DevToolsのNetwork、PageSpeed Insightsの改善項目 |
| キャッシュ | 2回目以降のアクセスでも毎回遅い | ページキャッシュ未導入・未設定、効いていない | キャッシュ系プラグインの設定画面、サーバー／CDNのキャッシュ設定 |
| DBクエリ | 管理画面が重い、記事数増加で表示が遅い、応答（TTFB）が長い | プラグインによるクエリ増加、肥大化したオプション・リビジョン | ツール ＞ サイトヘルス、クエリ計測系プラグイン |
表の右端「確認の入口」がポイントです。遅さを語るとき、まず「どの画面でそれを確かめるか」が言える状態になると、議論が感覚から構造へ移ります。
INP ― 「操作への反応」を測る指標
2024年3月、Core Web Vitalsの一つが入れ替わりました。それまで応答性の指標だったFID（First Input Delay）に代わり、INP（Interaction to Next Paint）が正式採用されました。INPはページ滞在中のあらゆる操作（クリック・タップ・キー入力）に対して、画面が次に更新されるまでの遅延を測ります。表示自体は速くても、クリックしたメニューが開かない、ボタンの反応がワンテンポ遅れる——こうした「出てはいるが触れない」状態をINPは拾います。プラグインや多機能テーマが足したJavaScriptが、ここに効いてきます。LCP（初期表示の速さ）と並べて見ると、「表示が遅いのか／反応が遅いのか」を切り分けられます。
具体シナリオ① 多機能テーマ＋多数プラグインでINP/LCPが悪化
症状：軽量とされるテーマに替えたのに、トップの初期表示が遅く、メニューやスライダーの操作にもたつきが残る。PageSpeed InsightsではLCPとINPの両方が黄〜赤。
どの層か：転送層と描画／JS層。テーマ本体は軽くても、ビルダー・スライダー・ポップアップ・解析タグなどのプラグインがそれぞれCSS/JSを追加し、合計の転送量とスクリプト実行量が膨らんでいる状態です。
俯瞰の打ち手：まずDevToolsのNetworkとPerformanceで「どのリソースが重いか」「操作時に何が実行されているか」を見る。テーマを疑う前に、機能ごとのプラグインが各層に何を足しているかを棚卸しし、使っていない機能の読み込みを止める。テーマ交換は選択肢の一つであって、最初の一手ではありません。
具体シナリオ② プラグイン追加でDBクエリが膨らみ管理画面が重い
症状：公開ページの体感は悪くないのに、記事一覧や編集画面など管理画面だけが目に見えて重い。記事数が増えてからさらに悪化した。
どの層か：DBクエリ層。関連記事表示、アクセス解析、SEO系などのプラグインが、1ページの表示ごとに多数のデータベース問い合わせを行っているケースです。
俯瞰の打ち手：「ツール ＞ サイトヘルス」でサーバー環境やデータベース関連の指摘を確認し、クエリ計測系のツールで「どのプラグインがクエリを増やしているか」を特定する。リビジョンや不要データの肥大化も疑う。ここでテーマを軽くしても、管理画面のクエリ負荷はほぼ変わりません。
数値はサイトごとに大きく異なるため、本文の症状は一般的な例です。実際の値はご自身のサイトを各ツールで計測して確認してください。
判断軸チェック：どの層がボトルネックか
- 操作の反応が鈍い・触ってから遅れる → 描画／JS層を疑う（INP、DevTools Performance）
- 初期表示だけが遅い（2回目は速い） → 転送層を疑う（LCP、DevTools Network）
- 2回目以降のアクセスでも毎回遅い → キャッシュ層を疑う（キャッシュプラグイン設定）
- 管理画面が重い・記事数増加で悪化 → DBクエリ層・プラグインを疑う（サイトヘルス、クエリ計測）
では、どう向き合うか（3つの判断軸）
- まず「層」を特定してから手を動かす。遅いと感じたら判断軸チェックで当たりをつけ、確認の入口（DevTools／PageSpeed Insights／キャッシュ設定／サイトヘルス）で裏を取る。テーマ交換やプラグイン削除という「作業」から入らない。
- 一番遅い層から直す。速度は直列のボトルネックで決まる。最も遅い層を1つ直すたびに再計測し、次の天井がどこに移ったかを見る。
- テーマ選びは「描画・転送層の初期設定」として評価する。軽量テーマの価値は本物。ただしそれは4層のうち主に2層に効く初期投資であって、キャッシュやDBクエリまで面倒を見てくれるわけではない。
次に読む・関連記事
- 次の講義 → 講義3：ブロック/FSEは設計思想の転換
- 計測と外科手術の実践 → 上級者ガイド 第3回 Core Web VitalsとINP
- 土台 → WordPressはどう動いている？全体図／全体像ハブ
- 関連 → 講義1：ノーコード依存
重くて困っているときは
「軽量テーマに替えたのに重い」「どの層がボトルネックか自分では切り分けられない」——そんなときは、無理に作業から入らず、まず現状の4層を一緒に診断するところから始めるのが近道です。保守プランでは、計測をもとにどの層が天井になっているかを切り分け、優先順位をつけてご相談に応じます。
情報確認日：2026年5月29日
