WooCommerce 11.2のライフサイクルフック変更。保存と並び替えでSQL最大45%削減

WooCommerce 11.2のライフサイクルフック変更。保存と並び替えでSQL最大45%削減

WooCommerce 11.1と11.2で、商品保存と商品並び替えの内部処理が大きく変わった。商品保存時のSQLクエリ数は最大45%削減され、並び替えアルゴリズムは大規模カタログ向けに再設計された。

プラグインやカスタムコードで商品データを操作している場合、レガシーフックの移行が必要になる。本記事では変更の全体像、技術的な詳細、そして移行の具体的な手順を解説する。

WooCommerce 11.1と11.2の変更点を俯瞰する

2つの変更はいずれも、後方互換性を優先しつつ、大規模な商品カタログでパフォーマンスを改善することを目的としている。

大規模カタログ向けのパフォーマンス改善

WooCommerceチームは、商品数が数千・数万を超えるストアで発生する管理画面の遅延やデータベース負荷を問題視していた。特に商品保存と並び替えは、カタログ全体に影響が及ぶ処理であり、これまでの実装ではカタログが大きくなるほど処理時間が線形に悪化する構造だった。

今回の変更は、商品データストアが不要な書き込みを行わないようにし、並び替えでは全カタログの再インデックスを避ける設計へと置き換えるものだ。これにより、大規模ストアの管理画面レスポンスが大幅に改善される見込みである。

後方互換性の優先とレガシーフックの扱い

重要なのは、非推奨になったフックを使い続けた場合、自動的に旧アルゴリズムへフォールバックする点だ。互換性は保たれるが、その分パフォーマンス改善の恩恵は受けられない。

プラグイン開発者にとっては、古いフックへの依存を解消し、新しいフックへ移行するかどうかの判断が必要になる。次のセクションから、各変更の詳細を見ていく。

商品保存処理の最適化でSQL数を45%削減

商品保存時の動作が変わり、値に変更がない場合はAPI呼び出しをスキップする。この最適化により、保存1回あたりのSQLクエリ数が最大45%削減される。

no-op書き込みの削減がもたらす効果

今回の最適化は、wp_set_object_terms() と delete_post_meta() というWordPressの関数に着目したものだ。これらの関数は、データが変わっていない場合でも呼び出されるとキャッシュを無効化する動作をしていた。いわば「変更がないのに掃除をする」ような無駄が毎回発生していた。

WooCommerce 11.1以降では、保存前の値と保存後の値を比較し、同じ値であればこれらのAPIを呼び出さない。この小さな変更が、商品保存を頻繁に行う大規模ストアでは大きなDB負荷の削減につながる。

フック発火頻度の変化による副作用

ただし注意点がある。set_object_terms フックは、これまで商品保存のたびに発火していた。最適化後は、値が変わった場合のみ発火するようになる。このフックに依存して何らかの処理を実行しているカスタムコードがある場合、想定よりも発火回数が減る可能性がある。

具体的には、商品タイプが変わっていなくても毎回の保存で処理を行うことを前提としたコールバックは、移行が必要だ。次のセクションで確認手順を詳しく解説する。

商品並び替えアルゴリズムの刷新とフック移行

並び替えに関わるフックは2つが非推奨になり、2つの新しいフックが追加された。非推奨フックを使うと旧アルゴリズムにフォールバックする。

旧アルゴリズムから新アルゴリズムへ

従来の商品並び替えは、管理画面の「商品 → すべての商品 → 並び替え」で操作するたびに、カタログ全体を再インデックスしていた。商品数が1万件を超えると、この処理は数十秒かかることもあり、実用に耐えないケースがあった。

新しいアルゴリズムは、大規模カタログを前提に設計されている。再インデックスを高速化し、範囲ベースの並び替えを採用することで、変更された範囲だけを効率的に処理する。これにより、大規模ストアでも並び替え操作が快適になる。

非推奨フックと新フックの対応表

以下の表が、今回変更されたフックの全体像だ。非推奨になったフックを今も使っている場合、対応する新しいフックへの移行を検討する必要がある。

• woocommerce_after_single_product_ordering は非推奨。カタログ再インデックス中に商品ごとに発火していた
• woocommerce_after_product_ordering は非推奨。並び替え完了後に一度だけ発火していた
• clean_post_cache は変更なし。レガシーと高速パスの両方で影響を受けた商品ごとに発火する
• woocommerce_product_ordering_process_reindexed_products は新設。フルカタログ再インデックス後に発火する
• woocommerce_product_ordering_process_moved_products は新設。商品が再配置された後に発火する

元の動作を再現するには、clean_post_cache、wp_ajax_woocommerce_product_ordering、woocommerce_product_ordering_process_reindexed_products、woocommerce_product_ordering_process_moved_products をプリミティブとして組み合わせる方法が公式に案内されている。

既存サイトが受ける影響と確認手順

公式ブログでは、AIツールを使ってカスタムコードを確認する方法が提示されている。上の手順で、フックへの依存を洗い出せる。

カスタムコードの確認方法

まず、アクティブなプラグイン、MUプラグイン、テーマの functions.php を対象に、add_action('set_object_terms', ...) というコールバックを検索する。該当があれば、そのコールバックが「商品タイプが変わっていなくても毎回発火すること」を前提にしていないかを確認する。

もし前提にしていた場合、そのコールバックは woocommerce_update_product や save_post_product など、より適切なフックへ移動する必要がある。

移行が必要なケースと不要なケース

移行が必要なのは、set_object_terms フックが毎回発火することを前提にしたコードが存在する場合だ。逆に、商品タイプの変更やカテゴリの変更など、実際に値が変わる場合のみ処理を行いたいというコードは、そのままでも問題ない。

並び替え関連では、woocommerce_after_single_product_ordering と woocommerce_after_product_ordering を使っているコードは、新しいフックへの移行を検討する。非推奨フックを使い続けても動作はするが、旧アルゴリズムにフォールバックするため、パフォーマンス改善の効果を得られない。

この記事のポイント

• 商品保存処理は、値が変わらない場合はAPI呼び出しをスキップしてSQL数を最大45%削減する
• 商品並び替えは、全カタログ再インデックスから範囲ベースの新アルゴリズムへ刷新された
• set_object_terms フックの発火頻度が変わるため、毎回発火を前提としたコードは移行が必要
• 並び替えの旧フック2つは非推奨になり、新フック2つが追加された
• 非推奨フックを使い続けると旧アルゴリズムにフォールバックし、高速化の恩恵を受けられない

海田 洋祐

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