Kies-MediaCSS performance: CSS effizient rendern
Ich vermute, dass sich kaum ein Webentwickler gedanken macht wie effizient das von ihm entwickelte CSS-File ist. Mit „effizient“ meine ich, wie schnell der Browser eine Regel verarbeiten, d.h. die Designanpassung darstellen kann. Da das ganze (für mich) nicht messbar ist, verlasse ich mich bei diesem Bericht auf die, die es wissen müssen: zum einen hat Mozilla einen Artikel über „best practices“ und Google einen Artikel „ways to make the web faster“ veröffentlicht. Ich werde die Ideen beider Artikel zusammenfassen und Ratschläge geben.
Von rechts nach links
Hey, wir in Deutschland lesen doch von links nach rechts? Das stimmt – dein Browser aber nicht. Browser lesen immer von rechts nach links. Das bedeutet, dass bei Selectoren wie:
ul > li a[title="mein-title"]
der Teil
a[title="mein-title"]
als erstes interpretiert wird. Dieser erste Teil wird „key selector“ genannt.
Welcher Selektor ist der Schnellste?
ID s sind die mit Abstand effizientesten Selektoren. Doch wie sieht es mit den anderen Selektoren aus? Zuerst werden Selektoren in 4 große Gruppen eingeteilt, wobei Selektoren innerhalb einer Gruppe eine ähnlich
Effizienz aufweisen. Diese Gruppen sind: id, class, tag, und universal.
| #haupt-menue { } | ID (schnellste) |
| body.home #wrapper { } | ID |
| .haupt-navigation { } | Class |
| ul li a.aktuell { } | Class |
| ul { } | Tag |
| ul li a { } | Tag |
| * { } | Universal (langsamstes) |
| #content [title=’home‘] | Universal |
Verbesserungsvorschläge
1.) Selector Reihenfolge
Untersuchen wir die folgende CSS-Regel:
#haupt-navigation li { }
Auf den ersten Blick ist diese Regel super effizient, weil sie einen ID-Selector hat. In Wirklichkeit wird die Regel von rechts nach links gelesen, was bedeutet, dass erst der langsame Tag-selektor „li“ verwendet wird. Besser wäre also der folgende Code:
#haupt-navigation { }
2.) So genau wie nötig
Untersuchen wir die folgenden CSS-Regel:
#haupt-navigation li { }
Diese Regel kennen wir schon? Stimmt! Zum dem eben genannten Nachteil kommt ein Weiterer: weil ein ID-Element nur einmal im HTML-Code vorkommen kann, ist eine weitere CSS Beschreibung des ID-Selektors niemals notwendig.
Hinweis: Bei Klassen-Selektoren álla p.fett ist es sehr oft ähnlich. Auch hier sollte man auf eine weitere Beschreibung verzichten (falls möglich).
Hinweis 2:Ganz schlimm sind Konstruke wie:
html body ul li a { }
weil hier 5 Tag-Selektoren untersucht werden müssen. Viel besser wäre hier 1 Klassenselektor.
3. Überleg dir genau welchen Zweck ein Selektor erfüllen soll
Oft möchte man beispielsweise die Schriftart einer Liste verändern. Dann schreibt man schnell:
#haupt-navigation ul li a { font-family: Georgia, Serif; }
Jetzt würde der Browser alle a-attribute suchen. Sehr viel effizienter wäre wenn man gleich die ganze liste bzw. sogar den umgebenden DIV-Container verwendet:
#haupt-navigation { font-family: Georgia, Serif; }
4. Effizienz von CSS3-Selektoren
Sehr schlechte Nachrichten von David Hyatt für euch:
The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance.
zu deutsch: die Wahrheit ist, dass CSS3-Selektoren prinzipiell nicht genutzt werden sollten, wenn man sich gedanken über Performance macht.
CSS3-Selectoren wie z.B. :nth-child sind natürlich äußerst nützlich, allerdings verbrauchen sie auch extrem viele Browser-Resourcen. Ich für meinen Teil werde sie natürlich trotzdem weiter verwenden, allerdings erst wenn ich mir überlegt habe, ob es nicht eine Alternative gibt.
Fazit
Ich für meinen Teil bin der Meinung, dass die Selector-Wahl auf heutigen Computern nahezu irrelevant ist, weil sich der Seitenaufbau innerhalb des Browsers im milisekundenbereich bewegt. Der Performance-Flaschenhals ist eher die Übertragungsgeschwindigkeit des Internets und damit die größe der CSS-Datei. Einige der Selektoren verbessern auch die Dateigröße…immerhin 🙂
Schreibe einen Kommentar