WordPress のプラグインが「軽い」か「重い」かは、ファイルサイズや機能の数ではなく、そのプラグインが表示のたびに何をしているかで決まります。全ページに CSS や JavaScript を読み込む、大きな設定データを毎回読み込む、重いデータベースクエリを実行する、といった動きがなければ、多機能なプラグインでも表示速度への影響は小さく済みます。この記事では、プラグインが重くなる仕組み、導入前に見ておきたいポイント、Query Monitor や PageSpeed Insights を使った測り方、重いプラグインを見つけたときの対処を説明します。
プラグインが重くなる4つの原因
1. フロントエンドに読み込むファイル
訪問者に影響が出やすいのは、プラグインがページに追加する CSS・JavaScript・Web フォントです。たとえば、お問い合わせページでしか使わないフォームの JavaScript を全ページで読み込むと、関係のないページまで読み込みが増えます。スライダーや SNS 埋め込みのように、外部サーバーへのリクエストを伴うものは特に影響が出やすくなります。
2. 自動読み込みされるオプション
WordPress は、wp_options テーブルのうち「自動読み込み」の対象になっている設定を、ページを表示するたびにまとめて読み込みます。プラグインが大きなデータ（ログやキャッシュなど）を自動読み込みの設定として保存すると、すべてのリクエストでそのデータが読み込まれます。プラグインを削除したあとも設定が残り続ける場合があるため、長く運用しているサイトほど溜まりやすい部分です。
3. データベースクエリ
関連記事の表示、閲覧数のカウント、アクセスログの記録などは、表示のたびにデータベースへの問い合わせを発生させます。記事数が少ないうちは問題にならなくても、データが増えるにつれて遅くなることがあります。
4. WP-Cron と管理画面での処理
予約処理を行う WP-Cron の仕組みは、サイトへのアクセスをきっかけに動きます。プラグインが頻繁なスケジュールで重い処理（外部 API との同期、画像の一括処理など）を登録していると、そのタイミングでアクセスした訪問者の表示が遅れることがあります。また、管理画面で定期的に通信する機能が多いと、管理画面だけが重いという症状になります。
導入前に見ておきたいポイント
インストール前の段階でも、ある程度は重さを予想できます。
- 機能が目的に合っているか: 使いたい機能が1つだけなのに、多数の機能を持つプラグインを入れると、使わない機能のファイルや処理まで抱えることになります。逆に、複数の小さなプラグインを1つの多機能プラグインにまとめられる場合もあるので、数ではなく役割で考えます。
- 読み込み範囲を絞る設定があるか: 特定のページだけでファイルを読み込む設定や、使わない機能を停止する設定があるプラグインは、軽く運用しやすくなります。
- 外部サービスに依存するか: 表示のたびに外部サーバーと通信するものは、そのサーバーの応答速度にも左右されます。
- 更新が続いているか: WordPress.org のプラグインページで最終更新日、検証済みの WordPress バージョン、レビューを確認します。古いプラグインは、新しい WordPress で効率の悪い動き方をすることがあります。
プラグインの重さを測る方法
予想だけで判断せず、実際に測って確かめるのが結局は近道です。ここでは3つの方法を組み合わせます。
Query Monitor でサーバー側の処理を見る
Query Monitor は、ページの表示中に実行されたデータベースクエリ、読み込まれた CSS と JavaScript、外部への HTTP リクエスト、PHP のエラーなどを一覧できるプラグインです。インストールして有効化すると、管理者でログインしている間だけ管理バーに計測結果が表示されます。
確認したいのは、クエリをプラグインなどの「コンポーネント」別に集計した画面です。どのプラグインが何件のクエリを実行し、どれだけ時間を使っているかが分かります。遅いクエリや重複したクエリが特定のプラグインに集中していれば、それが改善の候補です。調査が終わったら、Query Monitor 自体も停止しておきます。
PageSpeed Insights で訪問者側の影響を見る
PageSpeed Insights は、ページの読み込みにかかる時間や、表示を妨げているファイルを示してくれます。診断結果に、使われていない JavaScript や CSS、表示をブロックしているリソースとしてプラグインのファイルが挙がっていれば、そのプラグインがフロントエンドに負担をかけています。
スコアは測るたびに多少ぶれるため、1回の結果で判断せず、同じ条件で数回測って比べてください。
ステージング環境で無効化して比べる
もっとも分かりやすいのは、プラグインを1つずつ無効化して前後の数値を比べる方法です。本番環境で試すと訪問者に影響が出るため、ステージング環境（本番のコピー）で行います。
- ステージング環境で、無効化前の数値（PageSpeed Insights の結果、Query Monitor のクエリ数と処理時間）を記録する
- 調べたいプラグインを1つだけ無効化する
- 同じページで同じ条件のまま測り直し、差を記録する
- プラグインを有効に戻し、次のプラグインで同じことを繰り返す
WP-CLI が使える環境なら、次のように切り替えると手早く進められます。
# 有効なプラグインの一覧を確認する
wp plugin list --status=active
# 調べたいプラグインを1つだけ無効化する（example-plugin は実際のスラッグに置き換える）
wp plugin deactivate example-plugin
# 計測後に元に戻す
wp plugin activate example-plugin自動読み込みオプションの量を確認する
自動読み込みのデータが大きくなっていないかは、データベースを直接確認すると分かります。phpMyAdmin などで次の SQL を実行すると、自動読み込み対象の設定がサイズの大きい順に表示されます。読み取りのみのクエリですが、念のためデータベースのバックアップを取ってから操作してください。テーブル接頭辞が wp_ 以外の場合は書き換えます。
SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY size DESC
LIMIT 20;WordPress 6.6 以降では自動読み込みの値として on や auto などが使われるようになったため、古い yes とあわせて条件に入れています（2026年10月現在）。サイズの大きい項目の名前を見て、どのプラグインのものかを推測します。削除したプラグインの設定が残っている場合でも、SQL で直接消すのは影響範囲を確かめてからにしてください。
重いプラグインを見つけたときの対処
設定で読み込み範囲を絞る
まずはプラグインの設定に、ファイルを読み込むページを限定する項目や、不要な機能を停止する項目がないかを確認します。設定で解決できれば、コードを書く必要はありません。
必要なページ以外でファイルを外す
設定がない場合は、子テーマの functions.php で特定のページ以外ではファイルを読み込まないようにする方法があります。ハンドル名（スクリプトやスタイルの登録名）は Query Monitor の「Scripts」「Styles」の一覧で確認できます。
// お問い合わせページ以外では、example-plugin の CSS と JavaScript を読み込まない
add_action( 'wp_enqueue_scripts', function () {
if ( is_page( 'contact' ) ) {
return;
}
wp_dequeue_style( 'example-plugin-style' );
wp_dequeue_script( 'example-plugin-script' );
}, 100 );ハンドル名と固定ページのスラッグは、実際のものに置き換えてください。外したファイルを使う機能（フォームの送信確認など）がそのページで動かなくなっていないかを、変更後に確認します。
代わりのプラグインやサーバー機能を検討する
設定やコードで改善できない場合は、同じ目的のより軽いプラグインに置き換えるか、サーバー側の機能で代替できないかを検討します。ページキャッシュや画像の WebP 変換などは、レンタルサーバーが標準で提供していることも多く、プラグインを入れずに済む場合があります。置き換えの前にはバックアップを取り、ステージング環境で動作を確かめてから本番に反映してください。
まとめ
- 軽さはプラグインの数や機能の多さではなく、フロントエンドのファイル、自動読み込みオプション、クエリ、WP-Cron の処理で決まる
- 導入前に、目的に合った機能か、読み込み範囲を絞れるか、更新が続いているかを確認する
- Query Monitor、PageSpeed Insights、ステージングでの無効化テストを組み合わせて実際に測る
- 重いプラグインは、設定での絞り込み、不要なページでのファイル除外、代替への置き換えの順に対処する