プラグインが“速度の敵”になるとき｜EC-CUBEが抱える構造的ボトルネック

前回は、EC-CUBEプラグインがEC運営における“拡張の自由”を支える仕組みであることを紹介しました。
しかしその利便性の裏には、PageSpeed Insights（PSI）での評価に影響する構造的な課題が潜んでいます。
今回は、なぜプラグイン導入がサイトを重く見せてしまうのか、その仕組みを掘り下げます。

便利さの裏にある「クライアント処理構造」

EC-CUBEのプラグインは、できるだけ多くの環境で動作するよう設計されています。
そのため、サーバー設定（cron や CLI コマンド）を前提としない クライアント側での処理 が採用されるケースが多くあります。

たとえば、以下のような機能が典型的です。

• バナークリックの計測や表示切り替え
• おすすめ商品・ランキング商品の動的読み込み
• 閲覧履歴に応じたレコメンド表示
• ポップアップやスライダーのアニメーション処理

これらはページの読み込み後に JavaScript や Ajax を使って実行される構造になっており、HTML の初期描画とは独立して動作します。

クライアント処理で発生する「見えない遅延」

こうした構造はユーザーにとって一見スムーズに見えるものの、PageSpeed Insights の測定上では「LCP（最大コンテンツの描画）」や「INP（操作応答）」などに影響します。

ブラウザ側での処理は以下のような流れをたどります。

ユーザーがページを開く
　↓
HTMLが読み込まれる
　↓
JavaScriptが解析・実行される（ここで一時的に停止）
　↓
Ajaxなどで追加データを取得
　↓
DOM更新 → 画面に反映

この「JavaScript解析・実行 → DOM更新」の間は、ブラウザが再描画を保留するため、画像やテキストの最終的な配置が確定せず、LCP の測定が完了しません。つまり、「見えているけれどまだ安定していない」という状態が続くのです。

PageSpeed Insights における影響の出方

PageSpeed Insights の指標では、こうしたクライアント側処理が以下のように分類されます。

数値そのものがすべて悪化するわけではありませんが、JavaScriptの動作タイミングによって計測の基準が後ろにずれるため、「スコアが伸びにくい」状態が起こります。

サーバー側処理との違い

本来、こうした更新・集計・レコメンド処理はサーバーサイドで定期的に行うことが可能です。
しかし、プラグイン形式では以下のような制約が存在します。

つまり、配布型プラグインは「誰でも導入できる」ことを優先するため、ブラウザ側の負荷を前提にした設計になりやすいのです。

なぜ「非同期設計でも遅く見える」のか

中には非同期通信（async / defer）を導入しているプラグインもあります。
それでも速度評価に影響が出るのは、「LCPの要素が確定する前にJavaScriptが描画を制御している」 ためです。

• メインビジュアルの切り替え制御をJavaScriptで行っている
• Ajaxで商品情報を後から挿入している
• jQueryライブラリが複数ロードされている

例えば上記のような構成では、ブラウザが再描画を繰り返すため、体感よりも評価指標が低く出ます。

どのように付き合うべきか

プラグインは導入のしやすさが最大の利点です。しかし、PageSpeed Insights のスコア改善を目的とするなら、以下の観点で“影響の少ない構成”を意識することが重要です。

1. LCP要素（メイン画像・テキスト）をJavaScript制御の外に置く
2. Ajax処理は非同期化し、描画をブロックしない構造にする
3. 不要なライブラリを削除・統合する
4. ユーザーアクセスで発火する処理をサーバー側に移せないか検討する

次回は、同じ「おすすめ商品」「ランキング表示」といった機能を、独自開発（サーバー側処理）で軽量に実装する方法を解説します。PageSpeed Insights のスコアを落とさずに動的コンテンツを扱う実践的アプローチをご紹介します。