CSSセレクタのパフォーマンスへの影響

Performance Impact of CSS Selectors

高速化する6大原則として『4.CSS セレクターは短く最適化せよ！』とこの記事では挙げられているのですが、原則というのはちょっと言い過ぎではないかと。少なくとも『3.HTTPリクエストは最小にせよ！』などと同列に考えるのは避けた方が良いかもしれません。

というのも、ハイパフォーマンスWebサイトの著者であるSteve Soudersはこんなことを言っています。

CSSセレクタを最適化するために時間を費やすのは価値のあることだとは思わない。もし、明日起きて世界中のサイトのCSSセレクタが奇跡的に最適化されていたのなら、私は遠くに行ってこう叫びたい。『誰も気づいてないですやん！！』

Steve Soudersがなぜこう考えるのでしょうか？

彼はセレクタの違い（ベースライン、タグ、クラス、子、子孫セレクタ）によってレンダリング速度に違いが出るかテストを行いました。テストページには2000個のアンカーと2000個のCSSルールを含んでいます。

CSS Selector Performance

図；Performance Impact of CSS Selectors より

上記のグラフのような結果になったのですが、ここではブラウザ毎の比較は考慮せずにCSSセレクタのパフォーマンスに対する影響に注目してみると、最も早いケースと最も遅いケースで平均で50ミリ秒しか違わないと言うことです。さらに（今日の70%のユーザーにあたる）IE 6&7,Fx3に限って言えば、CSSセレクタ最適化をしても20ミリ秒しか改善されません。

テストケースを見てもらえれば分かると思いますが、あり得ない量のCSSコードになってます。一応、これは考えられうる最悪なケース（米国の主な大規模サイトの平均のCSSルール数は1000）を想定して考えられたテストなので、実際のサイトはもっと少ないのは言わずもがなです。

テストの結果を基にSteve Soudersはこう述べています。

大半のサイトにとって、CSSセレクタを最適化することで得られるメリットは小さいし、コストに見合わない。ただ、CSSセレクタのいくつかの種類やJavaScriptと影響しあうものに関しては極めて遅くなることがある。このあたり(offsetWidth, :hoverなど)は今後調べていきたい。

個人的雑感

とまぁ、そんな感じで費用対効果が見えませんね。既存サイトのCSSセレクタを書き換えていくようなことはお薦めいたしません。ゼロの状態からサイト構築するときに頭の隅に置いておくぐらいが良いのではないでしょうか。

また、子セレクタなり、子孫セレクタなり、適用範囲を狭めていくやり方は階層化されていて個人的には分かりやすいかなと思ったりもします。

/* こっちの方が好き */
#main .sentence {color:#000}
#sub  .sentence {color:#fff}
    
/* こっちの方がパフォ的に（程度は別として）良い */
.main-sentence {color:#000}
.sub-sentence {color:#fff}

このあたりは各自のコーディングスタイルを尊重すれば良いかと思います。パフォーマンスとメンテナンス性はトレードオフなところがあるのでどこかのGoogleみたいに偏執狂な感じになるのもどうかなとも思います。

あと、ユニバーサルセレクタもめんどくさいときは使いますね。全称セレクタも使うケースを考えたらmargin/paddingのリセットぐらいなもので、これも気に する程度ではないかなと思っています。（気になる人はテストしてみて＞＜）

２年前の僕みたいに不安になって藁をもすがる思いで質問してしまう子もでてくるかもしれません。（ググレオレｗ）

まぁそんなわけで、CSSセレクタで悩むぐらいならHTTPリクエストを減らしたほうが効果的なのでは。

参考サイト