BEMとページスピード｜PageSpeed Insightsから考える軽量化の現実

「BEMはCSSの命名規則だから、PageSpeed Insightsのスコアには関係ないのでは？」
そう考える人は少なくありません。

確かに、BEMを採用したからといって直接 LCP（Largest Contentful Paint） や INP（Interaction to Next Paint） の数値が悪化することはありません。
しかし、現場で実際にBEMを運用していくと、間接的にパフォーマンスへ影響する要素が見えてきます。

HTMLの肥大化とレンダリングコスト

BEMの特徴である「長いクラス名」「多重構造」は、HTMLの記述量を増やします。

• <div class=”product__item–highlight”> のような冗長なクラス
• ネストの深い入れ子構造
• 同じような命名の繰り返し

これらはブラウザにとって大きな負担ではありませんが、数百〜数千要素のECサイト では馬鹿になりません。
特にスマートフォン環境では、DOMサイズの肥大化が CLS（Cumulative Layout Shift）やTBT（Total Blocking Time） に影響を及ぼす可能性があります。

CSSセレクタとレンダリング効率

BEMでは「親子関係を明示する」ためにセレクタが長くなりがちです。

.product__list .product__item .product__price { … }

このような書き方が積み重なると、ブラウザのレンダリング処理において セレクタ解決のコスト が増します。
モダンブラウザは高速化されているため深刻な問題ではありませんが、PageSpeed Insightsの「レンダリングを妨げるリソース」指摘 に繋がりやすくなります。

PageSpeed Insightsが示す“現場の警告”

実際にBEMを使ったサイトをPageSpeed Insightsで計測すると、以下のような指摘が出るケースがあります。

• 使用していないCSSの削減
• CSSの最小化
• 過大なDOMサイズの回避

これらはBEMそのもののせいではありません。
しかし、BEMを採用することでCSSやHTMLの肥大化が進み、結果として PageSpeed Insightsで不利に映る のは現実です。

軽量化とルール遵守のバランス

ここで重要なのは「BEMをやめるべき」という単純な結論ではありません。

• 大規模開発・長期運用 → BEMで秩序を守る
• 小規模・高速開発・軽量化重視 → シンプルな命名で十分

つまり、案件ごとに ルールの重みを調整する ことが必要です。
「BEM完全準拠」にこだわるよりも、パフォーマンスと保守性の最適解を探す姿勢 が成果につながります。

BEM以外の選択肢

最後に、BEMに代わるいくつかのアプローチを紹介します。

• Tailwind CSS：ユーティリティクラスでHTMLとスタイルを直結
• CSS Modules / Scoped CSS：コンポーネント単位でスタイルを閉じ込める
• シンプルな命名規則（例：SMACSSや独自ルール）：小規模案件向けの軽量設計

これらはいずれも 「必要以上にHTMLやCSSを膨らませない」 という点で、PageSpeed Insightsと親和性が高いといえます。

BEMが招く“重いサイト”の落とし穴

PageSpeed Insightsのスコア改善に取り組むと、つい「技術的な施策」にばかり目が行きがちです。
しかし、コード設計そのものが軽量化や速度に影響する ことを忘れてはいけません。

BEMは有効な手段のひとつですが、注意すべき点もあります。

• 案件規模
• 運用体制
• パフォーマンス要件

これらを踏まえて「最適な設計」を選ぶことこそ、スコア改善とビジネス成果を両立させる近道です。

重要なのはBEMを使うこと自体ではなく、サイトを軽く、速くすることも意識すること。PageSpeed Insights改善のためには、設計手法を含めて柔軟に再考する局面が訪れます。