Der epische Krieg um die Performance (Oder: Brauchst du wirklich 200 MB Node_Modules für ein Dropdown-Menü?)

Es gibt im Webdesign eine ungeschriebene, fast schon religiöse Trennlinie. Auf der einen Seite stehen die CSS-Puristen – Menschen, die nachts von perfekt ausgerichteten Flexbox-Rastern träumen, Farben im Hexadezimalsystem fließend sprechen und fest davon überzeugt sind, dass man die Relativitätstheorie rein mit Selektoren nachbauen könnte.

Auf der anderen Seite steht die JavaScript-Fraktion. Eine dynamische Truppe, die der festen Überzeugung ist, dass ein Stück Software unvollständig ist, wenn es nicht beim Laden erst einmal 45 npm-Pakete herunterlädt, die CPU-Temperatur deines Laptops auf die Innentemperatur der Sonne ansteigen lässt und die komplette Seite in ein monolithisches Single-Page-Application-Monster verwandelt.

In den letzten Jahren ist in dieser Beziehung jedoch etwas Faszinierendes passiert: CSS hat heimlich die Weltherrschaft übernommen. Während die JavaScript-Welt alle zwei Wochen ein neues Framework erfindet, um das alte Framework zu ersetzen, das das vorletzte Framework ersetzen sollte, hat das gute alte CSS3 still und leise Muskeln aufgebaut.

Als jemand, der in seinem eigenen Blog penibel darauf achtet, dass der Code schlank bleibt (denn jede Millisekunde Ladezeit entscheidet darüber, ob der Leser bleibt oder frustriert wegzappt), liebe ich diesen technologischen Kleinkrieg. Werfen wir also einen Blick auf das Schlachtfeld der Web-Performance – mit harten Fakten und einer gesunden Prise Galgenhumor.

Das 200-Megabyte-Dropdown: Die Auswüchse des JavaScript-Wahnsinns

Machen wir ein kurzes Gedankenexperiment. Du willst eine moderne Website bauen. Die Seite braucht ein animiertes Burger-Menü, einen Akkordeon-Bereich für FAQs und ein nettes Popup-Fenster (Modal).

Vor einigen Jahren lief der typische JavaScript-Workflow so ab:

1. Man installierte ein Framework (React, Vue, Angular – such dir eins aus).

2. Man stellte fest, dass das Framework Plugins braucht. Also installierte man eine Animationsbibliothek.

3. Am Ende wog der node_modules-Ordner auf der Festplatte mehr als das Betriebssystem von Apollo 11, und der Browser des Nutzers musste beim Laden der Seite erst einmal ein paar Megabyte komprimierten JavaScript-Code parsen und ausführen.

Das Ergebnis? Die sogenannten Core Web Vitals von Google (die offiziellen Metriken für Website-Performance) rutschten tief in den roten Bereich. Der Interaction to Next Paint (INP) – also die Zeit, die verstreicht, bis die Seite auf einen Klick reagiert – fühlte sich an wie eine Ewigkeit, weil der Browser noch damit beschäftigt war, tonnenweise JS-Logik im Hintergrund zu verarbeiten.

Die Rache des Stylesheets: Was CSS heute nativ kann

Während die JS-Entwickler noch mit Webpack-Konfigurationen kämpften, hat das W3C-Konsortium CSS3 ein paar absolut geniale Upgrades spendiert. Dinge, für die man früher zwingend JavaScript-Bibliotheken oder komplexe jQuery-Skripte brauchte, erledigt der Browser heute nativ, blitzschnell und direkt auf der Grafikkarte (GPU-beschleunigt).

Hier ist die offizielle Mängelliste der Dinge, für die JavaScript heute offiziell entlassen ist:

1. Das Modal (Popup) & Burger-Menü

Früher: Eine JS-Funktion, die Klassen toggelt, das Event abfängt und den Hintergrund sperrt.

Heute: Das native HTML5-Element <dialog> in Kombination mit ein paar Zeilen CSS. Oder der gute alte Trick über den :checked-Zustand einer unsichtbaren Checkbox. Läuft garantiert ohne eine einzige Zeile Skript-Code.

2. Komplexe Animationen & Scroll-Effekte

Früher: JS-Bibliotheken, die bei jedem Scroll-Event die Pixelwerte neu berechneten und das Rendering blockierten.

Heute: CSS transition, animation und die neuen Scroll-Driven Animations (animation-timeline). Der Browser weiß selbst am besten, wann die Grafikkarte das Element flüssig bewegen kann.

3. Container Queries

Früher mussten wir mit JavaScript die Breite eines Elements überwachen (ResizeObserver), um das Design anzupassen, wenn eine Komponente in einer Sidebar kleiner wurde. Heute tippen wir einfach @container in unser CSS-Stylesheet (oder nutzen die entsprechenden Klassen in Tailwind) und das Element reagiert völlig autonom auf seinen Platz im Raum.

Die nackten Zahlen: Warum weniger JS glücklich macht

Warum ist dieser Kampf so wichtig? Weil die Nutzer (und Google) keine Geduld haben. Jede Millisekunde zählt.

Statistiken von HTTP Archive zeigen, dass das durchschnittliche Transfervolumen von JavaScript auf Webseiten in den letzten Jahren kontinuierlich angestiegen ist. Gleichzeitig zeigt die Conversion-Optimierung: Jede Sekunde zusätzliche Ladezeit senkt die Konversionsrate einer Website um rund 7 % bis 11 %. Wenn deine Seite also nur deshalb langsam ist, weil du ein cooles, aber unnötiges JS-Skript für den Hover-Effekt nutzt, verbrennst du bares Geld.

Das Fazit: Nutze das richtige Werkzeug!

Versteh mich nicht falsch: JavaScript ist eine fantastische Sprache. Wenn du eine komplexe Web-Applikation wie ein Online-Banking-Portal, einen Echtzeit-Chat oder ein browserbasiertes Grafiktool baust, kommst du ohne JS nicht weit.

Aber für das klassische Webdesign – für Layouts, Interaktionen, responsives Verhalten und visuelle Effekte – ist CSS heute die unangefochtene Nummer Eins. Es ist performanter, sicherer, wartbarer und bricht nicht zusammen, wenn der Nutzer in seinem Browser JavaScript deaktiviert hat.

Wenn du also das nächste Mal vor einer Design-Herausforderung stehst, stelle dir die goldene Frage: „Kann ich das nicht eigentlich mit reinem CSS lösen?“ In 90 % der Fälle lautet die Antwort heute: Ja, du kannst. Und deine Nutzer werden es dir mit rasanten Ladezeiten danken.

In diesem Sinne: Weniger Skripte, mehr Style!