テンプレートを再設計するという選択｜EC-CUBEを“構造から”軽くする方法

ここまでEC-CUBEとPageSpeed Insights（PSI）の関係、プラグインやクライアント処理が抱える速度課題、そして独自開発による軽量化の方向性を解説してきました。

今回のテーマは、「テンプレート構造の見直し」です。トップ・一覧・詳細ページでEC-CUBEの標準テンプレートを使わず、独自テンプレートを開発する──それは単なるデザイン変更ではなく、システムの軽量化戦略でもあります。

EC-CUBEのテンプレート構造とは

EC-CUBEのフロント画面は app/template/ 以下にある Twig テンプレートによって構築されています。
これらは汎用性を重視しており、以下のような構成になっています。

• 各ブロック（header, footer, sidebar）を include で再利用
• カート情報や商品一覧などを Twig 経由で呼び出し
• JavaScript や jQuery を共通で読み込む

柔軟である反面、標準テンプレートを使う限り不要なリソースが読み込まれやすいという課題を抱えます。

なぜ“独自テンプレート”で軽くなるのか

標準テンプレートをベースにすると、不要な処理・タグ・スクリプトまで全ページ共通で読み込まれます。
一方で、独自テンプレートでは下記のように最適化が可能です。

これにより、HTML出力の段階で不要なCSS・JavaScript・DOM構造を排除できるため、LCP（最大コンテンツの描画）やINP（応答性）に直接効果が現れます。

PSIで改善が見込める主な項目

独自テンプレート化により、PageSpeed Insightsの以下の指標で改善が期待できます。

特にECサイトのトップページは要素が多く、標準構成のままではLCPが2.5秒を下回りにくい傾向があります。
独自テンプレートでは、LCP要素（メインビジュアルや主要テキスト）を最初からHTMLに含めることで劇的な効果が得られます。

独自テンプレート化の具体的なアプローチ

独自開発を行う場合、次のステップで進めると安全です。

1. 標準Twigの構造分析
   　– include や block の依存関係を洗い出す
   　– 使用していない部分を把握する
2. 最小構成テンプレートの作成
   　– header / footer / body を必要最小限に分離
   　– 使用スクリプトを defer / async で制御
3. LCP要素を明示的に配置
   　– メインビジュアル画像やメインコピーをHTMLに直書き
   　– fetchpriority=”high” を設定
4. 静的キャッシュを活用
   　– トップや一覧は静的HTML化
   　– 詳細ページはキャッシュ制御（ETag, Cache-Control）を設定

この設計により、EC-CUBEの柔軟性を保ちながらも、“速度のための最小構成”を実現できます。

ここまでやると、EC-CUBEは変わる

テンプレートを独自化するということは、EC-CUBEを「CMS的に使う」ことから、「フレームワークとして活かす」ことへの転換です。
標準の仕組みを一部手放すことで、システムは軽く、構造はシンプルになります。

また、独自CMSや外部APIと連携しやすくなるため、「商品管理はEC-CUBE、ページ生成は別ロジック」といった構成も可能になります。この分離設計は、速度改善だけでなく保守性・セキュリティ面でも有効です。

EC運営者・開発者への提言：設計を疑うところから始めよう

PageSpeed Insightsでスコアが伸び悩むECサイトの多くは、実は「コード」ではなく「構造」に問題があります。

テンプレートの最適化は時間と工数がかかりますが、それだけでLCP・INP・SEO・UXのすべてを底上げできる最も確実な方法です。

高速化を“追加のテクニック”としてではなく、設計そのものを見直すプロジェクトとして捉えてみてください。EC-CUBEは柔軟なシステムです。構造を整えた分だけ、成果は数字に表れます。