軽量化の本質は「仕組みの置き場所」｜独自開発で叶える高速EC構築

前回は、EC-CUBEプラグインの多くがクライアント側処理を採用しており、PageSpeed Insights（PSI）のスコアに影響を及ぼすことがあると解説しました。

今回はその延長として、「同じ機能でも実装の仕方で速度は大きく変わる」というテーマを掘り下げます。
キーワードは、サーバー処理（Server-side processing）への回帰です。

プラグインを“使わない”選択肢とは？

ECサイトに機能を追加したい場合、もっとも手軽なのはプラグインの導入です。
しかし、サイトの特性や運営方針によっては、独自開発による軽量実装のほうが適しているケースもあります。

特に以下のような処理は、プラグインではなくカスタマイズ開発で実装することで性能面に優位性が生まれます。

これらはすべて、「処理の主体をクライアント→サーバーに移す」 という考え方です。

“サーバー処理化”がもたらす速度改善の理由

PageSpeed Insights の指標において、LCP（最大コンテンツの描画）は「ブラウザが安定した描画を完了するまでの時間」です。
クライアント処理では、LCP要素（メインビジュアルや主要テキスト）の描画が後ろ倒しになりがちですが、サーバー側で完結していれば、HTMLの初期レンダリング時にすでに完成しています。

つまり、次のような構造の違いが生じます。

【クライアント処理型】
HTML表示 → JavaScript実行 → Ajax取得 → 描画確定（LCP計測ここ）

【サーバー処理型】
HTML生成時に完結 → 即時描画（LCP計測早期に確定）


この違いが、LCPやINPなど主要指標の差につながります。

EC特有の“リアルタイム更新”をどう扱うか

「ランキング」や「おすすめ商品」のように、データが日々変化する要素を完全に静的化するのは難しいでしょう。そのため、リアルタイム更新を“サーバー定期処理”に置き換えるという手法が有効です。

例として、cron（定期ジョブ）を使うとします。

• 1時間ごと、または1日1回の自動集計
• 商品販売数・閲覧数をもとにランキング生成
• 生成結果をキャッシュに保存して即時表示

これにより、ユーザーアクセス時には単なるHTML読み込みになるため、LCPへの負荷はほぼゼロになります。

Ajaxが悪ではない。ただし“設計次第”

Ajax通信や動的表示そのものが問題なのではありません。問題は「メイン描画と同タイミングでリソースを取りに行っている」ことです。

• LCP要素より下の要素にAjaxを使用する
• JavaScriptの発火をwindow.onloadではなくrequestIdleCallbackで遅らせる
• LCP画像にfetchpriority=”high”を設定する

上記のようなチューニングにより、JSを残したままでも速度を確保できます。独自開発ではこうした制御が柔軟にできるため、プラグインでは困難な細かい最適化が可能になります。

「開発コスト」と「運用コスト」のバランスを取る

プラグインの強みは“即時導入”であり、独自開発は“柔軟制御”です。
どちらを選ぶべきかは、運用フェーズの長さと更新頻度によって変わります。

短期的にはプラグインが優れていますが、運用が安定するほど「自社設計」が最適化コストを下げるというのが現場の実感です。

スコア改善は“仕組みの置き方”で変わる

• プラグインは「どこでも動く」ように設計されるため、ブラウザ依存の処理が多い
• 同じ機能でも、サーバー側に処理を移せばLCP・INPへの影響を抑えられる
• リアルタイム更新はcronやキャッシュで対応できる
• プラグイン導入＝悪ではないが、目的によって“構造の置き場所”を見直す価値がある

次回は、EC-CUBE本体そのものの構造に踏み込みます。
「プラグインを使っていなくても重い」──そんなケースに共通するボトルネックを整理し、サーバー設定・データ構造・商品数など、システム全体での最適化を考えます。