Code komprimieren

Eine einmal komprimierte CSS-Datei spart bei jedem Seitenaufruf Daten, bei jedem Besucher und bei jedem Crawler-Zugriff. Ich erkläre, welche Dateitypen sich überhaupt komprimieren lassen, warum Aufräumen vor dem Komprimieren kommt und wie Du mit PageSpeed-Test und Logfile-Auswertung nachweist, was die Maßnahme wirklich gebracht hat.

Eine Maßnahme, die bei jedem Abruf wirkt

Die meisten Optimierungen an einer Website musst Du Seite für Seite umsetzen. Die Code-Komprimierung nicht. Wenn Du Dein Stylesheet und Deine JavaScript-Dateien einmal komprimierst, profitiert davon jeder Besucher auf jeder Unterseite. Das ist der Grund, warum ich dieses technische Thema für so lohnend halte: einmaliger Aufwand, dauerhafte Wirkung.

Fast immer übersehen wird dabei ein dritter Hebel. Google, Bing und inzwischen auch die Crawler der KI-Anbieter holen sich Deine Seiten regelmäßig ab. Diese automatisierten Zugriffe verursachen Datenverkehr und zahlen genauso auf die CO₂-Bilanz Deiner Website ein wie menschliche Besucher. Bei vielen Seiten machen sie sogar den größeren Anteil aus.

Was sich komprimieren lässt und was nicht

Die Komprimierung funktioniert ausschließlich bei textbasierten Formaten: HTML, CSS, JavaScript, SVG-Grafiken, XML, RSS-Feeds und Sitemaps. Also alles, was Du im Texteditor oder in der Browser-Konsole lesen kannst. Bilder, Schriften, Audio und Video brauchen einen eigenen Weg, den ich in Folge 9 beschrieben habe.

Technisch passieren dabei zwei Dinge nacheinander. Zuerst entfernt ein Minifier alle Zeilenumbrüche, Tabulatoren, überflüssigen Leerzeichen und Kommentare. Danach komprimiert der Server die Datei noch einmal für die Übertragung und der Browser packt sie wieder aus.

Info

Standard für diese Übertragungskomprimierung ist bis heute gzip. Brotli arbeitet bei Textinhalten effizienter und holt noch einmal einige Prozent heraus. Ein Blick in die Serverkonfiguration lohnt sich, denn viele Hoster liefern Brotli inzwischen mit, ohne dass es aktiv genutzt wird.

Erst aufräumen, dann komprimieren

Bevor ich komprimiere, lasse ich den HTML-Validator über die Seite laufen. Er findet nicht nur Fehler, sondern zeigt auch, wo überflüssiger Code steht. Typische Fundstücke aus meiner Beratung: Container ohne jede Funktion und leere Absätze, die als Abstandshalter missbraucht werden. Beides gehört ins Stylesheet, nicht ins HTML.

Sauberer, valider Code ist außerdem eine Grundlage für Barrierefreiheit. Seit Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz für viele digitale Angebote. Selbst wenn Du formal nicht betroffen bist: Ich halte es für selbstverständlich, dass auch eine Ein-Personen-Website zugänglich ist.

Der Code, der gar nicht erst geladen wird

Hier gehe ich über die reine Komprimierung hinaus. Rund 98 Prozent aller Websites setzen JavaScript ein. Für eine moderne Website mit modernem CSS brauchst Du davon fast nichts.

Achtung

Komprimierung macht überflüssigen Code kleiner, nicht überflüssig. Bevor Du ein Skript minifizierst, stelle die Frage, ob Du es überhaupt ausliefern musst. Das ersparte Skript spart hundert Prozent, die Komprimierung vielleicht dreißig.

Prüfen, was es gebracht hat

Für den schnellen Vergleich reichen die Browser-Konsole oder der Website Carbon Calculator, wenn Du Dir die Dateigrößen vorher notiert hast. Aussagekräftiger ist der PageSpeed-Test von Google, weil er die tatsächlich übertragenen Größen inklusive Serverkomprimierung zeigt.

Die Königsklasse bleibt die Logfile-Auswertung, die ich in Ausgabe 80 der Website Boosting beschrieben habe. Dort siehst Du, wie viele Megabyte pro Monat tatsächlich wegfallen, wenn Du auf die Zahl der Seitenaufrufe normierst. Das sind Zahlen, die in einen Nachhaltigkeitsbericht gehören.

Jedes Byte, das nicht übertragen wird, verbraucht keinen Strom. Die Komprimierung ist der bequemste Weg dorthin, das Weglassen der wirksamste.