ワードプレス

WordPressの自動ロード：wp_optionsがサイトを遅くする理由

ワードプレスのオートロード は、ページ・リクエストごとに wp_options テーブルから大量のオプションをメモリにロードするため、TTFB、CPU、RAM の要件が高くなります。自動ロードされたデータがここに蓄積されすぎると、このテーブルはサイトの速度を著しく低下させます。.

中心点

autoloadされたオプションが速度を低下させているかどうかをすぐに評価できるように、最も重要な事実を要約します。WordPressはリクエストのたびに、必要かどうかにかかわらず、autoload=yesのすべてのエントリーを読み込みます。これは、プラグインをインストールするたびに重くなる、目に見えないバックパックのようなものです。オートロードのサイズが1MB程度になると、パフォーマンスはすぐに低下し、小規模なホストでは特に顕著になります。いくつかの的を絞ったステップで、負荷を恒久的に減らし wp_options クリーンだ。

オートロード負荷autoload=yesを指定すると、すべてのページがリクエストされるたびに保存されます。.
クリティカル・サイズTTFBは～1MBから急激に増加し、2～3MBが警戒範囲とされる。.
メインドライバープラグイン、トランジェント、ログ、不具合のあるクーロンジョブ。.
測定SQL/WP-CLIはすぐにサイズとトップ発信者を表示します。.
救済清掃、「いいえ」への自動ロード、外注、定期的なチェック。.

オートロードが遅くなる理由

オートロードされたオプションは、ページが現在それを必要としているかどうかに関係なく、リクエストごとにメモリに着地する。 リソース. .小さな値ではほとんど気にならないが、多くのプラグインを使用すると、合計がすぐに数百キロバイト、あるいは数メガバイトに増大する。1MB前後から、TTFBが増加し、管理ページが遅くなり、CPUのピークが増えるのを定期的に目にします。共有ホスティングでは、並列リクエストによって データベース・ワードプレス さらにオートロード・ブロックが大きければ大きいほど、デシリアライズにかかる時間が長くなり、サーバーが最初のバイトを取得するまでの時間を浪費することになる。.

WordPressの内部的な読み込み方法（alloptionsとオブジェクトキャッシュ）

WordPressは、すべてのオートロードオプションを1つの大きなブロックにまとめます。最初のリクエストで、このブロックは単一のクエリでロードされ、集合キー オプション はオブジェクト・キャッシュに保存される。これによってデータベース・クエリの回数は減るが、処理するデータ量は減らない：ブロック全体がデシリアライズされ、メモリ上に保持されなければならない。ブロック全体をデシリアライズしてメモリに保持しなければなりません。 永続オブジェクトキャッシュ (RedisやMemcachedなど) を使用すると、データベースの負荷はなくなりますが、PHPプロセスはデータをアンパックしてRAMに保持しなければなりません。つまり、大きなオートロード・ブロックは、データがキャッシュから来る場合にも有害です。.

このことは、特に次のような場合に重要である：

高並列 (多数の同時リクエスト)：各 PHP ワーカーが個別にブロックをロードします。.
短いプロセス時間 (FPM/サーバーレス）：オーバヘッドは、新しいプロセスごとに再度発生する。.
管理エリアとクーロンキャッシュが迂回されたり無効にされたりする頻度は高く、オートロード・ブロックはその都度カウントされる。.

オートロード最大の違反者を見つける方法

で直接サイズを測ることから始める。 wp_options. .SQLで合計を取得します： SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_options WHERE autoload = 'yes'；;. .1MB以上の値は重要で、2-3MBからは、特にトラフィックによって危険になります。次に、サイズ順に並べ替えます： SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload = 'yes' ORDER BY BYtes DESC LIMIT 20；;. .これが、大きな配列や古い配列を識別する方法だ。 トランジェント やプラグインのエントリーは、オートロードする必要がないことが多い。ステップ・バイ・ステップ結果を確実に評価するのに役立つ。.

高度な診断：カウント、グループ化、パターン認識

合計サイズに加えて、私はエントリーの数と出所もチェックする：

オートロードされるオプションの数: SELECT COUNT(* FROM wp_options WHERE autoload='yes'；;
トップの名前空間 (発見的に接頭辞を介して)： SELECT SUBSTRING_INDEX(option_name,'_',1) AS ns, COUNT(* AS cnt, SUM(LENGTH(option_value)) AS bytes FROM wp_options WHERE autoload='yes' GROUP BY ns ORDER BY bytes DESC LIMIT 10；;
誤ってオートロードされるトランジェント: SELECT option_name FROM wp_options WHERE autoload='yes' AND option_name LIKE '_transient_%' ESCAPE ''；;

私はこれらのクエリを使って、統計情報のキャッシュ、ページビルダーの残骸、ログの残骸などを素早く見つける。分析プラグインからの数千の小さなエントリや、ビルダーからのいくつかの非常に大きな配列など、パターンはしばしば明確に認識できる。.

限界値と対策

迅速な評価のために、私は固定のしきい値を使用し、そのしきい値を使って次の査定を行う。 ステップ オフ。これにより、直感で時間を無駄にすることなく決断を下すことができる。この表は分類に役立ち、各分野における行動の明確な選択肢を提供してくれる。多くのプロジェクトで確実に機能するからだ。特にリソースが乏しいときには クラリティ 1分もかからずに。.

オートロードサイズ	リスク	推奨措置
0-500 KB	ロー	書類状況、時々チェック
500 KB-1 MB	ミディアム	最大のエントリーをチェックし、不要なエントリーを削除する
> 1 MB	高い	トップ・オリジネーターを特定、オートロード・フラグを „no “に設定“
> 2-3 MB	クリティカル	系統的なクリーンアップ、過渡現象の除去

安全な清掃：ステップ・バイ・ステップ

データベースを変更するたびにバックアップを取る。 エラー. .WP-CLIを使えば、素早く簡単にできる： wp dbエクスポート. .私は期限切れのトランジションを削除している： wp transient delete --期限切れ そして、必要であれば、そのすべてである： wp transient delete --all. .私は特に、孤児となったプラグインオプションを削除しています。 wp option delete my_plugin_option. .オートロードする必要のない大きなエントリーには、このフラグを実装している： wp option update option_name 'value' --autoload=no; フロントエンドと バックエンド 徹底的に。.

セーフティネット、テスト、ロールバック

各変更の後、私は次の順序でこれらの領域をチェックします：トップページ（ゲストとして）、深いサブページ、ログイン/ログアウト、管理者ダッシュボード、投稿の保存。また、Cronも起動させています： wp cron event run --due-now そしてエラーログをチェックする。何かが壊れたら、特にリセットする： wp option update option_name 'value' --autoload=yes またはバックアップを設定します。大きなアレイの場合は、あらかじめ wp option get option_name > backup.json, いつでも復元できる。.

autoload=no „に設定していないもの

WordPressは、ブートストラップの初期段階やリクエスト処理のたびに、いくつかのオプションを使用します。たとえそれが大きなものであっても、やみくもに自動ロードフラグを変更することはしない：

siteurl、ホーム基本的なURLは、早い段階で必要。.
パーマリンク構造、書き換えルールリクエスト解決に不可欠。 オプション, さらにデータベースのヒットが続く。.
テンプレート、スタイルシートテーマの決定.
blog_charset, timezone_string といったコア・デフォルトがある。.

基本的なルール：コアオプションと、ほとんどすべてのリクエストで使われるものはオートロードのままにしておく。私は大きくてめったに使われないプラグインエントリ、キャッシュアーティファクト、ログと古いトランジェントに集中します。.

オプションを大きく維持しなければならない場合

データによっては大きなものもあるが、リクエストのたびにメモリに保存する必要はない。 ランド. .大規模な設定の場合、私はwp_optionsの代わりに独自のテーブルを使用します。これにより、オートロード量を小さく保つことができます。ユーザー関連の情報は、グローバルオプションではなく、ユーザーメタに属します。私は、長いCSS/JS文字列のような静的コンテンツをファイルとして保存し、特別に読み込みます。保存する際、例えば以下のように直接オートロードを „no “に設定します。 add_option('name', $data, '', 'no')；;, 不必要な ローディング を避けなければならない。

開発者ガイドスケールするパターン

開発者としては、すべてを配列に集めた巨大な「メガ・オプション」は避けたい。狭いコア・セット（autoload=yes）＋ターゲットとなる遅延ロード（autoload=no）の方が良い。実用的なパターン

分割オプション: my_plugin_core (小, autoload=yes)と my_plugin_cache_* (large、autoload=no）。.
ターゲット・キャッシングで頻繁に必要とされるサブセット。 wp_cache_set() 大きなオプションをオートロードする代わりに、キャッシュを使用する。.
トランジェントを正しく使うデフォルトでは、オートロードを保存せず、意識的に取り出す。.
オプションの成長を止める最大サイズとTTLを強制する。.

修理ではなく予防

私はプラグインに無駄がないようにしていて、明確な利点がないものは無効にしている。 小さい. .月に一度、SQLかWP-CLIでサイズをチェックし、その値を記録している。ツール > ウェブサイトの状態」で、自動的に読み込まれるオプションのメモを監視している。トラフィックの多いサイトでは、WP-CLIを最適化するホスティングを使う価値がある。 データベース・ワードプレス wp_optionsを効率的にクリーンな状態に保ちます。テスト済みのチューニング戦略問題を早期に発見し、深刻な事態になるのを未然に防ぐことができるからだ。.

オートメーション：小さな仕事、大きな影響

私は定期的なクリーンアップをスケジュールしています。毎晩のクーロンジョブ（またはWP-CLIを実行するサーバークーロン）は期限切れのトランジェントを削除し、オートロードのサイズをファイルまたはテーブルに記録します。これによって、ユーザーが気づく前に傾向を見ることができます。プロセスの例（簡略化）：

wp transient delete --expired
wp dbクエリ "SELECT NOW(), SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';" >> autoload_stats.log

上位10件を日付付きで保存する小さなヘルスチェックは便利です。ログを一目見るだけで、異常値を特定の時間-通常はプラグインの更新や新しい機能の後-に割り当てるのに十分です。.

実例：60分間の清掃

あるプロジェクトでは、オートロードされたオプションが5,500個、合計2MBほどありました。 1.900 msとなった。バックアップ、トランジェント削除、トップ20チェック、フラグ調整後、ロード時間は約500ミリ秒に半減した。CPU使用率は89 %から約2.5 %に低下し、バックエンドのレスポンスは格段に速くなった。測定、クリーニング、テスト、文書化というシンプルな手順だった。これはまさに、私が定期的に wp_options 恒久的なものだ。.

典型的な原因と対策

ページビルダーはオプションで大きなキャッシュ配列を書くことを好むが、私はファイルに書くことを好む。破棄. .私は統計情報を自動的にロードされないトランジェントとして保存し、特別に取得します。ログはwp_optionsの中ではなく、ローテートファイルの中にあります。失敗したcronジョブは古いtransientsの原因になります; ここで私は間隔とタイムアウトを調整します。これらの簡単な変更で、自動ロードの量を素早く減らし、長期的に安定させることができます。厩舎.

キャッシュ、FPC、ホスティングの影響

上流のフルページキャッシュ（FPC）は主に匿名の訪問者を保護します。しかし、ログインユーザー、ショッピングバスケット、チェックアウト、管理者、cron、WP-CLIなど、キャッシュがバイパスされる場所では、オートロードブロックが完全に機能します。高速なデータベースサーバーはI/O負荷を隠しますが、デシリアライズのためのCPU時間とRAM消費は残ります。特にFPMワーカーが少ない小規模なインスタンスでは、データが「キャッシュから」来るにもかかわらず、大きなオートロードブロックはキューとタイムアウトにつながります。そのため、ソースを高速化するだけでなく、ブロックそのものを常に小さく保つことを目指します。.

モニタリングと主な数値

TTFB、最初のContentful Paint、バックエンドのロード時間をそれぞれの前後で追跡しています。 後片付け. .同時に、オートロードのサイズ、オートロードされたオプションの数、最大のエントリーを記録する。明確な傾向を示すには、日付、サイズ、TTFBを記載した小さなシートで十分です。メンテナンスのために、私は毎月SQLクエリーを使用します。データベースの管理-チェックリスト。これによって、私は早い段階で異常値を認識することができる。 データベース・ワードプレス 永久にスリム。.

マルチサイト一目でわかる2つの建設現場

マルチサイトのセットアップでは、サイト単位とネットワークレベルの両方で自動ロードの負荷が発生します。そのため wp_options 各サイトの（ブログごとのテーブル・プレフィックス）、さらにネットワーク・オプション。グローバルに使用される大きな配列は、すべてのサイトに影響する。単一のセットアップと同じように進める: 測定、トップ・エントリーの特定、大きな値のアウトソース、または autoload=no もしリクエストごとに必要でなければ。この削減は、特にネットワーク管理者においては、すぐに気づくことができる。.

よくある誤解-簡単に説明する

„「レディスが問題を解決する“ DBクエリーは減るが、オートロードブロックのサイズは減らない。CPUとRAMのコストは残る。.
„FPCはオートロードを無意味にする“ ログインユーザー、Cron、Adminには適用されません。FPCのアドバンテージは適用されません。.
„すべてのトランジションを削除するのは危険だ“ 安全ではあるが、新たな蓄積を招くだけである。的を絞って計画的に使用すること。.
„「エントリー数が少なければ、大きなブロックでも構わない。“ バイト数とデシリアライズの合計が重要なのであって、数だけが重要なのではない。.

清掃後のテスト計画

フロントエンドホームページ、ランダムアーカイブ、詳細ページ、ゲストおよびログインユーザーとして。.
機能検索、コンタクトフォーム、ショッピングバスケット/チェックアウト（ショップの場合）。.
管理者ダッシュボード、投稿リスト、投稿/商品の保存、プラグインページ。.
背景スケジュールされたクーロンイベントを実行し、エラーログをチェックし、ランダムにTTFBを測定する。.

迅速な決断のためのまとめ

オートロードされたオプションは静かなパフォーマンスキラーである。捕獲. .サイズを測定し、古いトランジェントを削除し、不要なエントリーをautoload=noに設定し、大きなデータをアウトソースする。その後、フロントエンドとバックエンドをテストし、測定ポイントを記録します。1時間の集中作業で、オートロードの負荷を30～70 %減らし、ロード時間を半分にすることがよくある。このルーチンを毎月繰り返せば wp_options 高速で、サイトのレスポンスも際立っている。.