Effiziente CSS Selektoren

Immer wieder gerne stellt man die Frage nach effizienten und schnellem CSS.  Daher hier ein grober Überblick über die Performance von CSS Selektoren.

Sobald der Browser HTML und CSS geladen hat beginnt der Abgleich des CSS mit dem Dokumentenbaum. Dabei wird sich nach dem Schlüsselelement gerichtet das normalerweise das letzte Element des Selektors ist.

Das CSS wird vom Browser von rechts nach links verarbeitet, d.h. es werden vom Schlüsselelement ausgehend alle Vorfahren die im Selektor notiert sind mit dem Dokumentenbaum abgeglichen bis die Definition zutrifft oder eben nicht.

Ein kleines Beispiel

header div.branding img.logo
{
    margin: 10x 5px;
}

Das Schlüsselelement ist img.logo. Der Browser sucht nun die Klasse .logo. Um sicherzustellen dass auch das richtige Element gefunden wurde wird dann auf das Element img geprüft, dann das Elternelement mit Klasse .branding gesucht. Anschließend wird geprüft ob das Element vom Type div ist und letzlich ob das Elternelement ein header-Element ist.

Zwei Schlüsse lassen sich daraus schließen:

  1. Jede weniger Elemente (bzw. Klassen, IDs) im Selektor notiert sind, desto schneller kann der Browser prüfen ob das Element matcht.
  2. Je eindeutiger das Schlüsselelement im Selektor definiert ist, desto weniger aufwändig ist die Abgleichung mit dem Dokumentenbaum.

Dazu ein Beispiel. Jeder kennt sie die berühmten .active oder .selected Klassen

.filter .active
{
   @include opacity(1);
   border: 1px solid black;
}
.searchresult .active
{
   background-color: #666;
}

Nun mal rein hypothetisch angenommen es gäbe jetzt 15 aktivierte Filter (z.B. in einem Online-Shop) und ein mit der Klasse .active versehenes Suchergebnis. Die Prüfung und Anwendung des Selektors .searchresult .active würde damit 15 aktivierte Filterelemente und deren Elternelemente abgleichen sowie das eigentlich benötigte Suchergebnis und seines Vorfahren.

Daraus ergibt sich folgende effizientere Notation für das aktive Suchergebniss:

.sresult_active
{
   background-color: #666;
}

In diesem Fall wird nur ein Abgleich stattfinden.

Kurz zusammengefasst kann man die Effizienz von CSS Selektoren wie folgt definieren: Es die Zeit die der Browser benötigt um die Selektoren mit dem DOM abzugleichen.

 

 

 

 

Should read 01 / 2014

Ich stöbere so gerne und daher anbei ein paar Links über die ich im Laufe des Monats gestolpert bin und für sehr lesenswert halte.

Ein interessanter Artikel über responsive Images

So, You’re Writing A Responsive Images Script
http://filamentgroup.com/lab/respimg_scripts/

Eine Case-Study zum Thema Frontend Performance

We spent a week making Trello boards load extremely fast. Here’s how we did it.
http://blog.fogcreek.com/we-spent-a-week-making-trello-boards-load-extremely-fast-heres-how-we-did-it/

Sind CSS Regions wirklich so cool?

CSS Regions Considered Harmful
http://alistapart.com/blog/post/css-regions-considered-harmful

Wie ist das noch mal mit nativem JavaScript

A Dive Into Plain JavaScript
http://blog.adtile.me/2014/01/16/a-dive-into-plain-javascript/

Vertikel Zentrierung ist ein Problem ohne Tables? Nein!

Vertical align anything with just 3 lines of CSS
http://zerosixthree.se/vertical-align-anything-with-just-3-lines-of-css/

So klappts auch mit den Icon Fonts

Bulletproof Accessible Icon Fonts
http://filamentgroup.com/lab/bulletproof_icon_fonts/

Neue Features von Sass 3.3 verheiratet mit der BEM Syntax

Sass 3.3 @at-root & BEM!
http://blog.unakravets.com/post/64113156740/sass-3-3-at-root-bem