JavaScript-Bundle verkleinern: schnellere Seiten mit weniger Last

Eine schnelle Website braucht nicht automatisch mehr Technik. Oft braucht sie weniger unnötiges JavaScript im ersten Blick. Jedes Kilobyte, das beim Laden mitkommt, kostet Parse-, Compile- und oft auch Interaktionszeit. Googles people-first guidance erinnert daran, dass gute Page Experience über mehrere Signale entsteht, nicht über einen einzelnen Trick.

Die gute Nachricht: Viele Teams können mit drei Schritten viel erreichen — messen, weglassen, durch native Browser-Features ersetzen. Der Rest sollte nur dann geladen werden, wenn er wirklich gebraucht wird.

Warum die Bundle-Größe direkt spürbar wird

Große Bundles sind nicht nur ein Build-Thema. Sie verlängern die Zeit bis zur ersten sinnvollen Interaktion und können den Main Thread belasten. web.dev beschreibt Code Splitting als Weg, JavaScript in kleinere Chunks zu zerlegen, damit der Browser nur das lädt, was die aktuelle Seite wirklich braucht.

Für Service-Websites und CMS-getriebene Seiten ist das besonders relevant: Navigation, Formulare, Dialoge und Teaser sind oft nicht der eigentliche Kern der Seite. Wenn diese Teile unnötig schwer sind, zahlt der Nutzer zuerst mit Wartezeit.

Deshalb lohnt es sich, Bundle-Größe nicht als Schönheitsfehler zu behandeln. Sie ist ein Bestandteil von UX, Conversion und im weiteren Sinn auch von SEO, weil langsame und träge Seiten mehr Reibung erzeugen.

Erst messen, dann kürzen

Bevor du etwas entfernst, miss den Ist-Zustand. Öffne das Network-Tab, prüfe die erste Route und suche nach doppelten Bibliotheken, ungenutztem Code und großen Hilfsbibliotheken. Oft sind Datumslibraries, Icon-Sets oder UI-Komponenten der größte Brocken.

Praktisch sind drei Fragen: Was wird beim ersten Render wirklich gebraucht? Was kann später geladen werden? Was wurde nur eingebaut, weil es früher kein gutes natives Gegenstück gab?

• Ein Bundle Analyzer zeigt, welche Pakete das meiste Gewicht erzeugen.

• Ein Performance-Check im Browser zeigt, ob die Last beim Laden oder beim ersten Klick entsteht.

• Ein Blick auf die Dependency-Liste zeigt, welche Bibliotheken nur deshalb da sind, weil niemand sie je hinterfragt hat.

• Ein einfaches Budget pro Route verhindert, dass jede neue Funktion das Laden unbemerkt schwerer macht.

Der Ablauf zeigt die vier Schritte des Bundle-Audits.

Wenn du einen Budgetwert brauchst, arbeite mit einer klaren Obergrenze pro Route oder Seitentyp und prüfe die Entwicklung in CI. Ein Budget ist nicht die ganze Lösung, aber es verhindert, dass jede neue Funktion das Laden unbemerkt schwerer macht.

Welche Dinge sich heute oft nativ lösen lassen

Nicht jede Komponente braucht ein Framework. MDN beschreibt <dialog> als Element für modale und nicht-modale Dialoge; <details> ist ein weit verbreitetes Disclosure-Element; popover ist seit 2024 breit verfügbar; und Lazy Loading verkürzt den kritischen Rendering-Pfad, weil unkritische Ressourcen erst später laden.

In der Praxis heißt das: FAQ-Akkordeons, einfache Hinweise, Overlay-Dialoge, Bildgalerien oder zunächst unsichtbare Inhalte können oft mit deutlich weniger JavaScript umgesetzt werden. Das ist kein Dogma gegen JavaScript — nur ein Check, ob die Library wirklich einen Mehrwert bringt.

Für viele DACH-Seiten ist das besonders attraktiv, weil man damit Verhalten und Inhalte sauberer trennt: Die UI bleibt leichter, die Redaktion bleibt verständlich, und der Browser übernimmt mehr Standardarbeit.

Die Karte zeigt, welche Browser-Features Custom-JavaScript ersetzen können.

Was du nicht blind ersetzen solltest

Native Features sind kein Freifahrtschein. Prüfe Browser-Support, Tastaturbedienung, Fokusverhalten und Fallbacks. Wenn eine Interaktion geschäftskritisch ist oder sich sehr speziell verhält, kann eine gut gebaute Komponente immer noch die bessere Wahl sein.

Die bessere Frage lautet nicht: „Kann ich das ohne JavaScript bauen?“, sondern: „Kann ich mit weniger JavaScript dieselbe Aufgabe sauber, stabil und zugänglich lösen?“

• Behalte JavaScript dort, wo der Ablauf ohne Script wirklich schlechter oder unzugänglich wird.

• Behalte Bibliotheken, wenn sie eine harte Browser-Lücke schließen und der native Weg keinen echten Vorteil bringt.

• Entferne nur das, was nicht mehr gebraucht wird — nicht das, was gerade einfach nur alt aussieht.

Ein Rollout, der wirklich etwas ändert

Ein guter Rollout beginnt mit den größten Gewinnen: route-basiertes Code Splitting, dynamische Imports für seltene Interaktionen, kleinere Vendor-Bundles und Lazy Loading für alles, was nicht sofort gebraucht wird.

Danach kommen Teamregeln: neue Dependencies nur mit Begründung, Performance Budgets in CI, regelmäßige Reviews von Bundle Reports und ein klarer Besitzer für jede größere Frontend-Erweiterung.

So wird aus Optimierung kein einmaliger Sprint, sondern eine Pflege-Routine. Genau das passt zu Content- und Service-Websites: schnellere First Loads, klarere Entscheidungen, weniger technische Schulden.

Die Checkliste verbindet Performance-Budgets mit einem klaren Rollout.

Wenn du diese Schritte in ein Redaktions- oder Entwicklungsritual übersetzt, bleibt die Seite auch dann leicht, wenn neue Funktionen dazukommen. Der Trick ist nicht Verzicht um jeden Preis, sondern Auswahl mit klaren Kriterien.

Quellen und Einordnung

Google Search Central: Creating Helpful, Reliable, People-First Content

web.dev: Reduce JavaScript payloads with code splitting

MDN: <dialog>, <details>, popover und Lazy loading

Die Auswahl der Beispiele folgt bewusst dem gleichen Muster: Erst prüfen, dann kürzen, dann nur dort vereinfachen, wo der Browser bereits eine gute Standardlösung mitbringt.