こんにちは。WordPressの深淵へようこそ。
WordPressを学び始めると、誰もが一度は「なぜかサイトが重い…」という壁にぶつかります。その原因の多くは、実はコアの心臓部である `wp_options` テーブルに隠されているのです。
今日は、WordPressを「ただ使う人」から「掌握するエンジニア」へとステップアップするための、最も重要で、かつ見落とされがちな「autoload」の仕組みについて解説します。
—
1. `wp_options` テーブルという「心臓部」の正体
WordPressの `wp_options` テーブルは、サイトの「設定」を司る場所です。テーマのオプション、プラグインの有効化状態、サイトのURLなどがここに格納されています。
このテーブルには `autoload` というカラムが存在し、値は `yes` か `no` のどちらかです。
なぜ `autoload` が重要なのか？
WordPressのコア（`wp-settings.php`）は、ページがリクエストされるたびに、`autoload = ‘yes’` となっている全てのデータを一度にメモリへ読み込みます。
— 内部で実行されているクエリのイメージ
SELECT option_name, option_value FROM wp_options WHERE autoload = ‘yes’;
もし、この設定が何千件とあり、データ容量が数MBに達していたらどうなるでしょう？ ユーザーがトップページにアクセスするたびに、WordPressはその重いデータを毎回PHPのメモリ上に展開しているのです。これが「サイト全体の低速化」の真犯人です。
—
2. 肥大化のサインを見抜く
「自分のサイトの `wp_options` は大丈夫か？」と思ったとき、以下のコマンドをターミナル（MySQL）で打ってみてください。これで、autoloadが有効なデータの総容量を確認できます。
— autoloadが有効なデータの合計サイズをKB単位で表示
SELECT SUM(LENGTH(option_value)) / 1024 AS autoload_size_kb
FROM wp_options
WHERE autoload = ‘yes’;
目安: 1MBを超えていたら要注意です。特にプラグインが削除された後も設定データが残っている「ゴミ屋敷」状態は、WordPressのパフォーマンスを確実に蝕みます。
—
3. なぜ「ゴミ」が溜まるのか？（陥りやすい罠）
開発者がプラグインを作る際、`add_option()` を使うことがありますよね。実は、この関数はデフォルトで `autoload` が `yes` に設定されます。
// 例：プラグインの設定を保存するコード
// 第3引数が省略されると、デフォルトで ‘yes’ (autoloadされる)
add_option( ‘my_plugin_heavy_data’, $huge_array );
// こう書くのがプロの嗜みです
add_option( ‘my_plugin_heavy_data’, $huge_array, ”, ‘no’ );
多くのプラグイン開発者は、設定画面のデータなら `yes` で問題ないと考えますが、その設定値が巨大な配列やログデータである場合、それは autoload すべきではありません。 `no` に設定することで、必要な時だけ `get_option()` で呼び出すのが賢い設計です。
—
4. 現場で使える「診断・修正」の極意
もしサイトが重いと感じたら、以下の手順でクリーンアップを行いましょう。
手順①：autoloadが巨大なオプションを特定する
WP-CLI（WordPressのコマンドラインツール）がインストールされているなら、これが最強です。
autoloadされているオプションの中で、データサイズが大きい上位10件を表示
wp db query “SELECT option_name, length(option_value) AS size FROM wp_options WHERE autoload = ‘yes’ ORDER BY size DESC LIMIT 10;”
手順②：不要なものを除外する
もし、プラグインをアンインストールしたのに残っているデータや、本来読み込む必要のない巨大なデータを見つけたら、`autoload` を `no` に変更します。
// データベースを直接いじるのは怖いので、update_option を使うのが安全です
// 一度データを取得して、再保存することで autoload を ‘no’ に書き換えます
$value = get_option( ‘heavy_option_name’ );
update_option( ‘heavy_option_name’, $value, ‘no’ );
—
最後に：なぜこの知識が必要なのか
WordPressを単なるツールとして捉えるか、あるいは高度なアプリケーションフレームワークとして捉えるか。その分かれ道が、この「`autoload`」の理解にあります。
「画面が映ればいい」ではなく、「メモリをどれだけ節約し、データベースのI/Oをどれだけ減らせるか」。この視点を持てば、あなたはもう初心者ではありません。
ここをクリアしたあなたは、WordPressの裏側で何が起きているのかをイメージできるはずです。次はぜひ、WordPressのキャッシュオブジェクト（Transient API）についても深掘りしてみてください。
WordPressの掌握、一緒に頑張りましょう！応援しています。