Eコマース基盤の選定において、Headless構成（Next.js + WP GraphQL）は保守コストとプラグインエコシステムの分断というトレードオフを伴う。結果として、運用コストとTime-to-Marketの観点からWordPress/WooCommerceのモノリス構成を選択するケースは依然として多い。

しかし、一般的な商用テーマを導入すると、過剰なDOM深度（いわゆるdiv soup）やレンダリングブロック、非効率なSQLクエリによってCore Web Vitals（特にLCPとINP）が壊滅するケースが散見される。

本稿では、WooCommerce特有のパフォーマンスボトルネックを整理した上で、軽量設計が施された**WoodMart – Multipurpose WooCommerce Theme**の内部構造と、本番運用に耐えうる最適化パイプラインについて技術的に考察する。

1. WooCommerceにおける典型的なボトルネック

WooCommerceをスケールさせる際、フロントエンドで真っ先に問題となるのが以下の3点である。

(1) `cart-fragments.js` によるサーバーリソースの枯渇

標準のWooCommerceは、動的なカート状態を更新するために、ページロードごとに非キャッシュのAdmin-AJAXリクエスト（?wc-ajax=get_refreshed_fragments）を発行する。同時アクセスが増加した際、PHP-FPMのワーカープロセスがこの単純なセッション取得処理で飽和し、TTFBが跳ね上がる原因となる。

(2) EAVモデルに起因するクエリの増大

商品属性やメタデータがwp_postmetaに集中しているため、バリエーションの多い商品詳細ページや複雑なファセット検索では、JOINが多発してMySQLのI/Oを圧迫する。

(3) モノリシックなCSS/JSバンドルの配信

一般的なテーマは、全ページの機能を1〜2枚の巨大なCSS/JSファイルにまとめて配信するため、未使用のCSS（Unused CSS）とメインスレッドの占有が発生する。

2. WoodMartのレンダリング機構の特異点

数あるテーマの中で、なぜWoodMartが比較的高速なスコアを叩き出すのか。設計レベルで以下の最適化が組み込まれているためだ。

モジュール型アセットローディング

WoodMartは単一の巨大なアセットを読み込ませるのではなく、ページ内で実際に使用されているUIコンポーネント（カルーセル、AJAX検索、スウォッチ等）を検知し、該当するスクリプトのみを条件付きで非同期ロード（defer / 依存関係に基づく動的キューイング）する設計をとっている。これにより、初回ペイント時のメインスレッド拘束時間を最小限に抑えている。

独自のフラグメントキャッシュとLocal Storage連携

標準のwc-ajax=get_refreshed_fragmentsをバイパスし、クライアント側のlocalStorageにカート状態を保持。カート内容に変更があった時のみ最小限のエンドポイントを叩く仕様に変更されているため、サーバー側のCPUスパイクを回避できる。

DOM構造の最適化

ElementorやWPBakeryなどのページビルダーを内包しつつも、ラッパー要素のネストを極力浅く保つようテンプレートファイル（PHP）がオーバーライドされており、Lighthouseの「過度なDOMツリーの回避」基準をクリアしやすい。

3. 検証環境でのプロファイリングとコード監査

商用案件でテーマを選定・導入する場合、本番ライセンスを購入する前のステージング環境（Docker/DDEV等）で、フックの呼び出し回数、クエリ負荷、サードパーティ製スクリプトの依存関係を厳密にプロファイリングする必要がある。

開発フェーズにおけるコード監査やローカルでのストレステスト用リソースとしては、GPLライセンスに基づいてテーマやプラグインのコードを配布している**gplpal**のような検証プラットフォームを活用する選択肢がある。本番投入前に実際のコードベースを展開し、Query Monitor等のツールを用いてデータベースへの影響やアセットの依存関係を事前に検証しておくことは、手戻りを防ぐ上で極めて合理的である。

4. 本番デプロイにおける追加の最適化構成

WoodMartの特性を活かし、90点以上のPageSpeed Insightsスコアを担保するには、サーバーレイヤーでの以下のチューニングが前提となる。

# Nginx: 静的アセットのキャッシュとgzip/Brotli圧縮
location ~* \.(js|css|png|jpg|jpeg|gif|ico|woff2)$ {
    expires 365d;
    add_header Cache-Control "public, no-transform";
    access_log off;
    try_files $uri =404;
}

HPOS（High-Performance Order Storage）の有効化: 注文データを独自テーブルに逃がし、wp_postsのインデックス肥大化を防ぐ。
Object Cache（Redis）の導入: 永続的なオブジェクトキャッシュにより、テーマのオプション値やナビゲーションメニューのシリアライズデータ取得に伴うDBオーバーヘッドを排除する。
SVGアイコンのインライン化: WoodMartの標準機能にある「Inline SVG」を有効化し、フォントファイルのダウンロードによるFOIT（不可視テキストの表示）を防止する。

まとめ

モノリスなWordPressであっても、内部設計がモジュール化されたテーマを選択し、適切なキャッシュアーキテクチャと組み合わせることで、Headless構成に近いレンダリングパフォーマンスを実現できる。

選定にあたっては、デザインの表層にとらわれず、アセットの分割配信戦略とAJAXリクエストの制御機構がどう実装されているかをコードレベルで精査することが肝要である。