BEMのデメリット｜保守とスピードの狭間で考える
»
当記事はWebの間コーポレート記事の転載です。元記事はこちら。
BEMは「役割を明確化する」という思想に基づいており、大規模開発や多数人での協業には適しています。
しかし、このルールが逆に "縛り" になるケースも少なくありません。
特に小規模案件やスピード重視の開発において、ルール遵守のために余計な工数が発生しやすいのです。
BEMの"強み"が裏返るとき
- デメリット①：クラス名の肥大化
- BEMは「Block__Element-Modifier」という形式を守るため、header__nav__item-active のように クラス名が長文化 します。
- コードが読みにくい
- HTMLが冗長になる
- メンテナンス時にタイプ量が増える
- デメリット②：学習コストと浸透の難しさ
- BEMはルール自体がシンプルとはいえ、新人や外部パートナーにとっては "名前の付け方に迷う" 壁があります。
- BlockとElementの境界をどこで引くか
- Modifierは必須か、別クラスに分けるべきか
- デメリット③：小規模サイトでは過剰設計
- 10ページ程度のコーポレートサイトや、短納期のキャンペーンLPなどでは、BEMの厳格な命名を守るよりも 「シンプルなクラス付け」 の方が早く・軽く仕上がります。
BEMは「将来的な拡張性」に価値がある一方で、使わない機能にコストを払うリスクも忘れてはなりません。 - デメリット④：パフォーマンスへの影響
- HTMLが冗長になることで、理論上は レンダリング速度やSEOに影響します。 特にGoogleが強調する「軽量化」「不要な複雑性を排除」という観点では、BEMのような冗長な命名規則は、必ずしもプラスに働くとは限りません。
すべての現場に万能ではない
BEMは大規模開発や複数人での長期運用には確かに有効です。
しかし、小規模・短期・軽量化重視のプロジェクトでは 「重すぎるルール」 になることもあります。
つまり、BEMは「採用すべきか／すべきでないか」という二択ではなく、
案件ごとに最適なルールを選び分ける視点 が重要です。
次回はこの視点を踏まえ、「BEMとPageSpeed Insightsの関係」から、さらに最適解を探っていきます。
SpecialPR