Direkt am nächsten Tag schaute ich mir den Quelltext von Erdmann & Freunde an, der ja nun auch schon ein 3/4 Jahr alt war. Damals hatte ich mich für LESS entschieden, im Laufe des Jahres aber neue Projekte immer häufiger Projekte mit SCSS umgesetzt, so dass ich gerne mal Mixin-Aufrufe und Variablen falsch schrieb, wenn ich mal wieder in einem LESS-Projekt arbeitete. Ich entschloss mich, Erdmann & Freunde auf SCSS umzubauen und erhoffte mir dadurch auch, ein paar KB Anweisungen in meiner master.css Datei zu sparen. Nichtmal für „ein Paar“ hat es gereicht. Lediglich 1 KB sparte ich durch den Wechsel von LESS auf SCSS ein.
Aber schon während ich die LESS-Syntax gegen die SCSS-Syntax ersetzte, stellte ich fest, wie häufig ich mich an manchen Stellen wiederholte und dadurch unnötig meine CSS-Datei aufblähte. Es wurde Zeit für ein CSS-Refactoring.
Was ist Refactoring?
Bei wikipedia heißt es
„Refactoring […] bezeichnet in der Software-Entwicklung die manuelle oder automatisierte Strukturverbesserung von Quelltexten unter Beibehaltung des beobachtbaren Programmverhaltens. Dabei sollen die Lesbarkeit, Verständlichkeit, Wartbarkeit und Erweiterbarkeit verbessert werden, mit dem Ziel, den jeweiligen Aufwand für Fehleranalyse und funktionale Erweiterungen deutlich zu senken.“
In dem Buch Responsible Responsive Design aber auch in Designing for Performance wird empfohlen, sich ein Performance Budget zu setzen. Mit meiner 56KB großen CSS-Datei liege ich zwar voll im Trend, allerdings gemessen am Umfang meiner Website sind 56KB doch ne ganze Menge. Und so definierte ich mein Ziel für meine master.css:
Ich möchte durch das Refactoring meine CSS-Datei von 56KB auf 40KB verringern.
So sah es vorher aus: Erdmann & Freunde vor dem CSS-Refactoring
Tatsächlich hört sich das einfacher an, als es ist. Eine einfache aber effektive Maßnahme ist, seine CSS-Dateien zusammenzufassen, zu minifizieren und zu komprimieren. Das hatte ich bei meiner 56KB Datei allerdings schon gemacht.
Also untersuchte ich meine Anweisungen auf Gemeinsamkeiten und unnötigen Wiederholungen und begann sie modularer und nach dem DRY-Ansatz (Don’t Repeat Yourself) aufzubauen. Ich fand etwa 12 Anweisungsblöcke, die sich bis auf wenige Abweichungen doppelten, zum Beispiel diese hier:
.howwework {
@extend %bg-gray;
padding: 1em 0 3em;
.inside > * {
@include make-sm-column(10);
@include make-sm-column-offset(1);
}
[…]
}
.why-contao {
@extend %bg-black;
padding: 1em 0 3em;
.inside > * {
@include make-sm-column(10);
@include make-sm-column-offset(1);
}
[…]
}
Also schuf ich allgemeingültige, gemeinsame Klassen, verzichtete auf minimale Abweichungen im Design oder belegte sie mit einer eigenen Varianten-Klasse und ordnete die neuen Klassen den Inhalten zu. In freudiger Erwartung ließ ich die Dateien erneut minifizieren und stellte fest, dass diese Änderungen wieder nur einen relativ kleinen Effekt hatten: 5KB weniger. Kacke!
Wo stecken die überflüssigen CSS-Anweisungen?
Da Erdmann & Freunde auf dem Bootstrap-Framework basiert, warf ich einen weiteren Blick in meine master.scss. Zwar hatte ich sehr gewissenhaft darauf geachtet, nur SCSS-Dateien einzubinden, in denen, so dachte ich, absolut notwendige Anweisungen standen. Wenn man aber mit einem CSS-Framework arbeitet, muss man immer damit rechnen, dass sich noch irgendwo ungenutzte CSS-Anweisungen verstecken. Und auch Doppelungen.
Ein paar Doppelungen fand ich in dem Contao CSS-Reset und dem Bootstrap CSS-Normalize. Teilweise wurden Anweisungen aber auch gleich wieder überschrieben (man sollte sowieso nicht beides gleichzeitig nutzen). Ich fügte also die beiden Dateien zusammen, fand ein paar weitere Doppelungen in meinen eigenen Styles und konnte so wieder ein paar KB einsparen.
Die letzten 5KB auf dem Weg zu einer 40KB großen CSS-Datei fand ich erst, als ich meine master.css noch einmal nicht-minifiziert Zeile für Zeile analysierte und siehe da ein paar Zeilen CSS Helper für Responsive Layouts, die ich nicht nutzte. Klar, wenn man für jeden Viewport ein paar Helper hat, dann kommt am Ende einiges zusammen.
Zum Vergleich: Erdmann & Freunde nach dem CSS-Refactoring
Fazit:
Man liest ja immer, dass Prä-Prozessoren wie LESS oder SASS schnell mal dafür sorgen können, dass sich die Größe der CSS-Datei still und heimlich vervielfacht. Genauso, dass der Einsatz von CSS-Frameworks eine Menge unnötigen Ballast mit sich bringt. Wenn ich mir meine ersten Projekte mit LESS anschaue, stimmt das auch ohne Zweifel.
Befolgt man aber die wichtigsten Grundregeln zur Verwendung von Prä-Prozessoren – zum Beispiel nicht mehr als 3 Ebenen zu verschachteln – dann sieht das eigentlich gar nicht so übel aus. Stattdessen sollte man bei seinen eigenen Anweisungen besser darauf achten, dass man sich so wenig wie möglich wiederholt und Gemeinsamkeiten frühzeitig erkennt und zusammenfasst.
Was die Größe betrifft, so habe ich mein Ziel erreicht. Aber wie man schon bei CSS Stats sehen konnte, gibt es noch ein paar weitere Bereiche, die ich früher oder später mal angehen sollte. Die Zahl der Farben habe ich bereits ein wenig reduziert (den Unterschied sieht man sowieso nicht). Aber was die Zahl der unterschiedlichen Schriftgrößen und auch den CSS-Specifity-Score angeht, gibt es noch einiges zu tun.
Habt ihr Erfahrungen mit CSS-Refactoring? Welche Tools nutzt ihr, um unnötige CSS-Anweisungen zu finden und eure Projekte schlanker zu machen?