WooCommerce.comがプラグイン読み込みを最適化、応答時間を最大400ms短縮

WooCommerce.comがプラグイン読み込みを最適化、応答時間を最大400ms短縮

WooCommerce.comが大規模WordPressサイトのパフォーマンスを大幅に改善した手法が公開された。特定のリクエストで不要なプラグインを読み込まない「選択的プラグイン読み込み」である。この手法により、WooCommerce.comの内部APIエンドポイントではメモリ使用量が50%以上削減され、主要エンドポイントの応答時間が最大400ミリ秒以上短縮されたという。

WordPressはリクエストのたびにすべての有効化プラグインを読み込む仕組みだ。大多数のサイトでは問題にならないが、WooCommerce.comのように100を超えるプラグインが稼働する大規模サイトでは無視できないオーバーヘッドになる。今回の事例は、大規模WordPressサイトのパフォーマンスチューニングに新たな選択肢を示すものだ。

プラグインの一括読み込みは大規模サイトの足かせになる

WordPressのプラグインモデルはシンプルだ。有効化されているプラグインは、フロントエンドの表示でも管理画面の操作でも、REST APIの呼び出しでも、すべてのリクエストで例外なく読み込まれる。ほとんどのサイトにとってこれは合理的な設計である。挙動が予測しやすく、プラグイン同士の依存関係を意識せずに組み合わせられる。

しかしWooCommerce.comのように、マーケットプレイス、決済、アカウント管理、API、チェックアウト、パートナー向けワークフロー、検索連携、トラッキング、そして運用コードが複雑に絡み合う大規模アプリケーションでは、事情が異なる。100個以上のプラグインのうち、特定のリクエストで実際に必要なのはごく一部であることが多いのだ。

WooCommerce.comの開発者ブログで紹介された実例を見てみよう。商品の検索・表示ページは、マーケットプレイスへの出品ツールを必要としない。キャッシュされた内部APIは、チェックアウト処理と同じプラグイン群を必要としない。公開ドキュメントの表示に注文番号の採番ロジックは不要だ。にもかかわらず、これらすべてのリクエストが同じプラグインセットを読み込んでいる。

各プラグインは読み込み時にフックの登録、サービスの初期化、オプションの読み出し、翻訳ファイルのロード、カスタム投稿タイプの定義、RESTルートの追加、アセットのキューイング、互換性コードの実行などを行う。1つひとつは小さなコストでも、成熟したWooCommerceアプリケーションで積み重なると無視できない負荷になる。

ページキャッシュやエッジキャッシュはこの問題をある程度隠すが、根本的な解決にはならない。キャッシュミスは依然として発生する。APIリクエストは動的なものが多い。ログイン状態のリクエストはキャッシュをバイパスする。トラフィックが急増するタイミングで、運用系のエンドポイントが高いレイテンシに悩まされることもある。大規模WordPressサイトにとって、ブートストラップ処理の削減は確かなパフォーマンス向上手段だ。

選択的プラグイン読み込みの基本的な仕組み

WordPressは有効化プラグインの一覧を active_plugins オプションに保持している。ブートストラップ時にこのオプションを読み取り、リストにある各プラグインのメインファイルを順に読み込んでいく。

ここに介入する仕組みがオプションフィルターだ。pre_option_active_plugins または option_active_plugins フィルターを使えば、WordPressが実際にプラグインを読み込む前にリストを書き換えられる。重要なのは、このフィルターを通常のプラグインより先に実行される mu-plugin（Must-Use Plugin）に配置することだ。

add_filter(
    'option_active_plugins',
    function ( array $plugins ): array {
        if ( ! should_limit_plugins_for_this_request() ) {
            return $plugins;
        }
        return array_values(
            array_diff(
                $plugins,
                plugins_to_skip_for_this_request()
            )
        );
    }
);

このコードの要点は3つある。どのリクエストでフィルターを適用するか、そのリクエストにとって安全に除外できるプラグインはどれか、そしてプラグインの一部を読み込まなかったことでサイト全体の状態が破損しないか、という点だ。

WooCommerce.comでは、mu-pluginでルートルールを早期に登録し、リクエストURIを完全一致、前方一致、または正規表現で照合する。ルールがマッチすると、あらかじめ定義されたプラグインを読み込み対象から外す仕組みだ。

この仕組みは、APIエンドポイントやブログ記事の表示など「ほとんどのプラグインが不要なリクエスト」で高い効果を発揮する。

ルール設計と安全性のトレードオフ

許可リストと除外リスト

選択的プラグイン読み込みの設計で最初に直面するのが、読み込むプラグインを決める方式だ。大きく分けて許可リスト方式と除外リスト方式がある。

許可リスト方式は、そのルートに絶対必要なプラグインだけをゼロからリストアップする。理論上は最も効果が高いが、大規模サイトでは脆さが問題になる。テーマ関数が別プラグインのクラスに依存しているケース、RESTハンドラが間接的に他のプラグインのヘルパー関数を呼んでいるケース、キャッシュミス時にのみ実行されるコードパスなど、暗黙の依存関係を見落とすとルートが壊れる。見落としはテストをすり抜けやすい。

除外リスト方式は、通常のアクティブプラグインリストから「このルートでは確実に不要」とわかっているものだけを取り除く。理想的な最小化にはならないが、安全性が段違いに高い。管理画面専用ツール、決済ゲートウェイ、メール配信処理など、明らかに関係ないグループをまとめて外すので、予期せぬ依存による障害が起こりにくい。

WooCommerce.comのチームは後者を主軸に採用している。開発者ブログの言葉を借りれば「各ルールをコードレビューの差分として確認でき、どのプラグインを残したか、なぜ外したかをコメントで説明できる」状態が、運用上の安心感をもたらすという。

除外が危険なリクエスト

すべてのリクエストが選択的読み込みの対象になるわけではない。WooCommerce.comでは以下のリクエストタイプを一律で除外対象から外している。

• wc-ajax
• wc-api
• rest_route（広範なクエリ文字列エントリポイント）
• クエリパラメータを含むダウンロードリクエスト

これらは動的に多様なコードパスに分岐する可能性があり、副作用の範囲を予測しにくいためだ。チェックアウト、カート、アカウント、管理画面、cron、Webhook、決済コールバック、ダウンロードといった「金銭・顧客データ・認証・権利確認・メール送信・サードパーティ連携」に触れるリクエストには、特に慎重な扱いが求められる。

依存関係の発見が最大の難所

動的なWordPressアプリケーションでは、あるルートが実際にどのプラグインに依存しているかを静的に解析する方法は存在しない。WooCommerce.comのチームは、ルートのコードを読み込み、明白な依存関係を追跡し、手動でリクエストフローを検証し、URLマッチングとエンドポイント動作のテストを書き、段階的にロールアウトしてエラーログとパフォーマンスデータを監視する、という実践的なアプローチを取っている。

注意すべきは、問題が特定の条件下でのみ表面化することだ。特定の商品ページ、特定のロケール、特定のリクエストパラメータ、キャッシュミス時、ログイン状態など、組み合わせは膨大になる。プラグインの読み込み不足によるエラーは再現条件が狭く、発見が遅れやすい。

WooCommerce.comで得られた具体的な効果

WooCommerce.comの開発者ブログでは、いくつかのエンドポイントで測定された具体的な数値が公開されている。

• 必要なプラグインのみを読み込んだリクエストでは、メモリ使用量が50%以上削減された
• 接続ストアが所有する有料サブスクリプション情報を返すエンドポイントは、約800msから約475msに短縮
• ストアにインストールされたプラグインの利用可能アップデートを通知するエンドポイントは、約880msから約550msに短縮
• WooCommerceオンボーディングフローで毎回呼ばれるエンドポイントも、同様の大幅改善
• 商品ページに対して決済ゲートウェイと無関係な拡張機能を除外した初期テストでは、ページ生成時間が約10%改善

これらの改善は、高トラフィックで責務が限定されたエンドポイントや、大規模なプラグイン構成を持つ匿名ユーザー向けページで特に顕著だった。逆に、ほぼすべてのプラグインが関与しうる動的なステートフルフローでは、相対的な効果は小さくなる。

監視すべき指標は、レスポンスタイム、PHPメモリ使用量、データベースクエリ数、高コストなプラグインのブートストラップ処理、デプロイ後のエラー率、予期しないリライトルールの変更、キャッシュミス時のルート固有の致命的エラーなど、多岐にわたる。

この手法が適するサイトと適さないサイト

この手法が効果を発揮するのは、以下の条件が揃っているサイトだ。

繰り返しになるが、これは最初に手をつけるべき最適化ではない。キャッシュ戦略の見直し、クエリパフォーマンスの改善、アセット読み込みの最適化、オブジェクトキャッシュの導入、明らかに不要なプラグインの整理といった基本的な施策を先に済ませてから検討するのが現実的な順序だ。

この記事のポイント

• 特定のリクエストで不要なプラグインを読み飛ばす「選択的プラグイン読み込み」により、WooCommerce.comの大規模サイトでメモリ使用量50%以上の削減と大幅な応答時間短縮が達成された
• 仕組みは option_active_plugins フィルターとmu-pluginの組み合わせで実装でき、技術的なハードル自体は高くない
• 安全性を確保するには「許可リスト」より「除外リスト」方式が現実的であり、ルールをコードとして管理しテストと監視を徹底することが不可欠
• この手法は大規模サイト向けの「最後の一手」であり、キャッシュやクエリ最適化といった基本的な施策を先に実施すべき

海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験