こんにちは。WordPressの深淵へようこそ。
今日は、WordPressの心臓部であり、同時に多くのエンジニアを苦しめる「サイレントキラー」とも言える `wp_options` テーブルの `autoload` について深く掘り下げていきます。
「なぜかサイトの初期応答（TTFB）が遅い」「サーバーのCPU負荷が高い」……その原因、実はSQLクエリの複雑さではなく、WordPressが起動した瞬間に読み込む「荷物」の重さにあるかもしれません。
—
1. WordPressの「起動」という名の重労働
WordPressでページにアクセスしたとき、内部で何が起きているかご存知でしょうか。
実は、リクエストの最初の数ミリ秒で、`wp_settings.php` が実行され、その中で以下のSQLが走ります。
SELECT option_name, option_value FROM wp_options WHERE autoload = ‘yes’;
このクエリが実行されると、`autoload` カラムが `’yes’` になっているすべてのデータが、一気にメモリへ展開されます。ここでのポイントは、「どれほど巨大なデータであっても、WordPressは有無を言わさず全件ロードする」という仕様です。
イメージで理解する `autoload`
- 良い例: サイトのタイトル、管理者のメールアドレス（これらは小さく、常に必要）。
- 悪い例: 数千行に及ぶプラグインのキャッシュデータ、APIのログ（これらが `autoload = ‘yes’` だと、ページの表示に関係なく毎回メモリを圧迫し、MySQLの初期接続時間を引き延ばします）。
—
2. 自分のサイトの「荷物」を可視化する
まずは、あなたのサイトで何がロードされているのか、その実態を見てみましょう。以下のコードをテーマの `functions.php` に一時的に追加し、管理者画面で確認してみてください。
/
- wp_optionsテーブルのautoloadデータの重さを可視化する
/
add_action(‘admin_init’, function() {
global $wpdb;
// autoload=’yes’のオプションの合計バイト数を取得
$results = $wpdb->get_results(“SELECT SUM(LENGTH(option_value)) as total_size FROM {$wpdb->options} WHERE autoload = ‘yes'”);
$size_kb = round($results[0]->total_size / 1024, 2);
// 管理画面のフッターに表示
add_action(‘admin_footer’, function() use ($size_kb) {
echo “
echo “Autoload合計サイズ: {$size_kb} KB”;
echo “
“;
});
});
目安: この数値が 800KB〜1MB を超えているなら、要注意です。あなたのサイトは、表示するたびに1MBのゴミを読み込んでいることになります。
—
3. 「不要な荷物」を切り離す最適化手法
もし、ロードされているデータの中に「特定ページでしか使わないデータ」があれば、迷わず `autoload` を `no` に変更しましょう。
WordPressの標準関数 `add_option()` には、第4引数に `autoload` を制御するフラグがあります。
// 悪い例: 毎回ロードしてしまう（デフォルト）
add_option(‘my_custom_plugin_data’, $huge_data);
// 良い例: 明示的にautoloadをオフにする
add_option(‘my_custom_plugin_data’, $huge_data, ”, ‘no’);
すでに登録されているデータを修正する場合
すでに `wp_options` に存在しているデータであれば、`wp_load_alloptions` フィルターをフックするか、SQLで直接変更するのが最速です。
— 危険なデータを特定し、autoloadを無効化するSQL
UPDATE wp_options SET autoload = ‘no’ WHERE option_name = ‘対象のオプション名’;
※実行後は必ず `wp_cache_flush()` を行い、オブジェクトキャッシュをクリアしてください。
—
4. 陥りやすい罠：なぜ「全て読み込む」のか？
初学者の頃は「必要な時に必要なだけ取ってくればいいのに」と思いますよね。しかし、WordPressの設計思想は「一度のクエリで全ての基本設定をメモリに持ち、その後のデータベースアクセスを最小限にする」というトレードオフを選択しています。
陥りやすいエラー:
- キャッシュデータを含める: 「とりあえず」とオプションテーブルに巨大な配列を保存するのは禁物です。一時的なデータは `wp_cache_set`（RedisやMemcached）を利用すべきであり、`wp_options` はあくまで「サイトの設定値」を置く場所です。
—
最後に：WordPressを「掌握」するということ
WordPressのパフォーマンスを極めるということは、「いつ、どこで、どれだけのデータがメモリに乗るのか」をコントロールすることに他なりません。
`wp_options` のクリーンアップは、目に見える派手なチューニングではありません。しかし、ここを最適化するだけで、サーバーのレスポンスは確実に「軽やか」になります。
ここをクリアすれば、あなたはもうWordPressの表面的な使い手ではなく、内部構造を制御する「エンジニア」の領域に足を踏み入れたと言えるでしょう。
また何か疑問があれば、いつでも聞いてください。一緒にこの巨大で美しいフレームワークをハックしていきましょう。