Warum deine Website weniger Anfragen senden sollte, nicht kleinere

Der bequeme Mythos von „mach einfach jede Datei kleiner“

Jahrelang klang Web-Performance-Rat einfach: alles komprimieren, alles minifizieren, jedes Asset kleiner machen.

Dieser Rat ist weiterhin im Großen und Ganzen richtig. Ein 40-KB-Script ist in der Regel besser als ein 400-KB-Script. Ein optimiertes Bild ist besser als ein roher Export. Brotli, AVIF, CSS-Minifizierung, Tree Shaking und Font-Subsetting sind alle wichtig.

Aber auf vielen Produktionsseiten ist das größere Problem nicht mehr eine einzelne übergroße Datei. Es ist die Anzahl der Dinge, die der Browser anfragen muss, bevor sich die Seite nutzbar anfühlt.

Eine Seite kann bei den Dateigrößen diszipliniert wirken und trotzdem langsam sein, weil sie 120 Anfragen sendet: CSS-Fragmente, JavaScript-Chunks, Drittanbieter-Tags, Schriftdateien, Tracking-Pixel, Icon-Sprites, JSON-Endpunkte, Preloads, Analytics-Beacons und Cache-Revalidierungen. Jede einzelne kann „klein“ sein. Zusammen erzeugen sie einen langen, fragilen Wasserfall.

Die praktische Regel lautet: Sobald einzelne Assets angemessen komprimiert sind, verbessert die Reduzierung der Anzahl der Anfragen die Nutzererfahrung oft stärker, als aus jeder Datei noch ein paar Kilobyte herauszuschneiden.

Anfragen sind nicht nur Bytes

Eine Netzwerkanfrage ist nicht nur die Übertragung von Daten. Sie ist eine Abfolge von Arbeit.

Der Browser muss die Ressource entdecken, entscheiden, wann sie geladen wird, sie gegenüber anderen Ressourcen einplanen, Header senden, auf den Server warten, Header empfangen, die Antwort parsen, sie oft dekomprimieren und dann etwas Nützliches damit tun.

Dieses „etwas Nützliche“ kann teuer sein. Eine JavaScript-Datei muss geparst, kompiliert und ausgeführt werden. Eine CSS-Datei kann das Rendering blockieren. Eine Schriftdatei kann lesbaren Text verzögern oder Layout-Verschiebungen verursachen. Ein Bild kann das Largest Contentful Paint-Element beeinflussen. Ein Drittanbieter-Script kann seine eigene Abhängigkeitskette mitbringen.

Deshalb ist die Anzahl der Anfragen weiterhin wichtig, selbst wenn Dateien klein sind. Ein 3-KB-Script kann schlechter sein als ein 30-KB-Bild, wenn es das Rendering blockiert, spät ankommt und im falschen Moment auf dem Main Thread ausgeführt wird.

Wenn du einen Lighthouse-Bericht liest und dich von Dutzenden einzelner Warnungen bestraft fühlst, sieh dir zuerst den Anfrage-Wasserfall an, nicht die einzelnen Scores. Wir haben eine praktische Anleitung in how to read a Lighthouse report without panicking, aber die Kurzfassung lautet: Finde heraus, was das erste Rendering blockiert und was den Hauptinhalt verzögert.

„Aber HTTP/2 hat das behoben“, meistens nicht

HTTP/2 und HTTP/3 haben die Ökonomie von Anfragen verändert. Sie brachten Multiplexing, Header-Komprimierung und besseres Verbindungsverhalten. Einfach gesagt: Browser wurden deutlich besser darin, mehrere Anfragen über weniger Verbindungen zu senden.

Das war eine echte Verbesserung. Es hat auch einige alte Gewohnheiten beendet, etwa extreme CSS-Sprites und riesige zusammengefügte Bundles, die nur gebaut wurden, um Verbindungslimits zu vermeiden.

Aber HTTP/2 hat Anfragen nicht kostenlos gemacht.

Multiplexing hilft, wenn viele Ressourcen eine Verbindung teilen, aber der Browser muss sie weiterhin priorisieren. Server müssen weiterhin antworten. Der Client muss weiterhin jede Antwort verarbeiten. Überlastung, Paketverlust, TLS-Aushandlung, DNS-Lookup, Cache-Misses und Druck auf den Main Thread existieren weiterhin.

HTTP/3 verbessert bestimmtes Transportverhalten, besonders bei Verbindungsmigration und Head-of-Line-Blocking auf der Transportschicht. Es entfernt nicht die Kosten für Entdecken, Einplanen, Herunterladen, Parsen und Ausführen von Ressourcen.

Das moderne Ziel lautet also nicht „alles in eine enorme Datei bündeln“. Es lautet: „weniger kritische Anfragen senden und die verbleibenden Anfragen bewusst einsetzen“.

Im Wasserfall liegt die Wahrheit

Performance-Probleme kündigen sich selten in einer einzelnen Kennzahl an. Sie zeigen sich als Form.

Öffne das Netzwerk-Panel eines Browsers und sieh dir die ersten Sekunden an. Frag dich:

• Wie viele Anfragen starten, bevor der Hauptinhalt erscheint?
• Welche Anfragen blockieren das Rendering?
• Werden wichtige Ressourcen spät entdeckt?
• Konkurrieren Drittanbieter-Scripts mit First-Party-CSS, Schriftarten oder Bildern?
• Liefern viele Dateien 304-Antworten zurück, statt direkt aus dem Cache bedient zu werden?
• Sind Icons, Schriftarten oder UI-Fragmente in mehr Dateien aufgeteilt, als die Seite braucht?

Eine schnelle Seite hat meist einen langweiligen frühen Wasserfall. Eine kleine Anzahl kritischer Ressourcen kommt früh an. Nicht-kritische Ressourcen warten. Drittanbieter-Scripts werden verzögert, begrenzt oder entfernt. Der Browser wird nicht gezwungen, zwanzig Prioritäten zu jonglieren, bevor er die Seite zeichnen kann.

Eine langsame Seite hat oft einen nervösen Wasserfall: viele kleine Dateien, viele Ursprünge und viele späte Entdeckungen.

Kleinere Dateien sind weiterhin wichtig — nur nicht alle gleich

Das ist kein Argument gegen Komprimierung oder Optimierung. Es ist ein Argument dagegen, Bytes zu optimieren und Koordination zu ignorieren.

Kleinere Dateien sind am wichtigsten, wenn die Ressource groß ist, das Rendering blockiert oder Teil des Hauptinhaltspfads ist. Zum Beispiel:

• Das Hero-Bild sollte korrekt dimensioniert und codiert sein.
• Rendering-blockierendes CSS sollte schlank sein.
• JavaScript, das für die erste Interaktion benötigt wird, sollte minimal sein.
• Schriftarten sollten subsetted, komprimiert und auf die tatsächlich verwendeten Schnitte begrenzt sein.

Schriftarten sind ein häufiges Beispiel. Teams fixieren sich oft darauf, ob eine Schriftdatei 24 KB oder 31 KB groß ist, während sie sechs Schnitte, zwei Stile und mehrere Familien ausliefern. Die bessere Lösung ist nicht, 7 KB aus einer Datei herauszuholen. Sie besteht darin, weniger Schriftdateien zu senden. Wenn Typografie Teil deiner Performance-Arbeit ist, sind web fonts are still one of the easiest wins on most sites weiterhin einer der einfachsten Hebel auf den meisten Websites.

Bei Bildern zeigt sich dasselbe Muster. AVIF oder WebP können spürbar Bytes sparen, aber zehn dekorative Bilder im sichtbaren Bereich zu senden, bleibt ein schlechter Plan. Wähle bessere Formate, ja, aber hinterfrage auch, ob jedes Bild überhaupt angefragt werden muss. Für Formatentscheidungen ist unser Leitfaden zu when AVIF beats WebP and when it does not eine nützliche Ergänzung zu dieser Arbeit an der Anfrageanzahl.

Die versteckten Kosten vieler kleiner Dateien

Viele kleine Anfragen erzeugen häufig Probleme, die nicht sichtbar werden, wenn du nur auf die insgesamt übertragenen Bytes schaust.

1. Späte Entdeckung

Browser können nicht anfragen, was sie noch nicht entdeckt haben. Eine CSS-Datei kann eine Schriftart referenzieren. Ein Script kann ein weiteres Script importieren. Eine Komponente kann nach der Hydration JSON anfordern. Jede Abhängigkeit erzeugt einen weiteren Schritt in der Kette.

Je tiefer die Kette, desto später beginnt wichtige Arbeit.

2. Header-Overhead

Jede Anfrage und jede Antwort enthält Header. Header-Komprimierung hilft, besonders über HTTP/2 und HTTP/3, aber sie beseitigt den Overhead nicht. Cookies können das erheblich verschlimmern. Wenn deine Website bei jeder Anfrage große Cookies sendet, sind winzige Assets in der Praxis weniger winzig.

Das ist ein Grund, warum statische Assets oft auf cookie-freien Pfaden oder Domains liegen sollten und warum Cache-Header Aufmerksamkeit verdienen. Wenn sich Header in Produktion seltsam verhalten, ist debugging redirects and HTTP headers meist schneller als Raten.

3. Unterbrechung des Main Thread

Viele JavaScript-Chunks können wiederholte Parse- und Ausführungsarbeit erzeugen. Auch wenn jeder Chunk klein ist, kann der Browser immer wieder anhalten, um Code auszuwerten. Das kann Interaction to Next Paint beeinträchtigen und die Seite unruhig wirken lassen.

Dem Nutzer ist es egal, dass jede Datei klein war. Er merkt, dass das Antippen eines Menüs 600 Millisekunden gedauert hat.

4. Cache-Komplexität

Das Aufteilen von Assets kann Caching verbessern, wenn es sorgfältig gemacht wird. Ein stabiles Vendor-Bundle und ein sich änderndes App-Bundle können eine gute Aufteilung sein.

Aber übermäßiges Chunking kann nach hinten losgehen. Mehr Dateien bedeuten mehr Cache-Lookups, mehr Gelegenheiten zur Revalidierung, mehr Versionskoordination und mehr Wege, versehentlich Ressourcen zu invalidieren, die sich gar nicht ändern mussten.

Bundling ist zurück, aber mit Augenmaß

Die erste Ära der Web-Performance liebte Bundling, weil Browser strenge Verbindungslimits hatten. Dann kam HTTP/2, und viele Teams schwenkten stark zu aggressivem Code Splitting. Ein Teil davon war nützlich. Ein Teil wurde Aberglaube.

Die sinnvolle Mitte ist routenbewusstes Bundling.

Für eine typische Marketing-Website oder Content-Website:

• Inline nur das CSS, das für das initiale Rendering benötigt wird, oder lade nur dieses.
• Halte globales JavaScript klein.
• Vermeide es, winzige Module in separate Netzwerkanfragen aufzuteilen.
• Verzögere interaktive Funktionen, die nicht sofort benötigt werden.
• Entferne Drittanbieter-Scripts, die ihre Kosten nicht rechtfertigen.

Für eine Anwendung:

• Teile nach Route oder größerem Feature auf, nicht nach jeder Komponente.
• Halte gemeinsame Abhängigkeiten stabil und cachebar.
• Preloade nur Ressourcen, die sehr wahrscheinlich bald benötigt werden.
• Vermeide es, Admin-, Dashboard-, Editor- oder Experiment-Code auf öffentlichen Seiten zu laden.
• Miss die Interaktionskosten, nicht nur die Bundle-Größe.

Bundling ist nicht automatisch gut. Code Splitting ist nicht automatisch gut. Die nützliche Frage lautet: Hilft diese Aufteilung dem Browser, die nächste bedeutsame Nutzererfahrung früher zu liefern?

Drittanbieter-Anfragen verdienen besonderes Misstrauen

First-Party-Anfragen stehen zumindest unter deiner Kontrolle. Drittanbieter-Anfragen sind oft langsamer, weniger vorhersehbar und teurer, als sie aussehen.

Ein einzelner Tag Manager kann Analytics, Werbung, Heatmaps, Chat-Widgets, A/B-Testing, Consent-Tools und Personalisierungs-Scripts auslösen. Jeder Anbieter kann weitere Anfragen mitbringen. Manche laufen früh. Manche blockieren den Main Thread. Manche ändern sich ohne deinen Release-Prozess.

Die beste Drittanbieter-Optimierung ist Löschung. Die zweitbeste ist Verzögerung.

Bevor du ein Drittanbieter-Script hinzufügst, frag:

• Muss das laden, bevor der Nutzer die Seite sieht?
• Muss es auf jeder Seite laden?
• Kann es nach Consent, Interaktion oder Idle-Zeit laden?
• Wer ist intern dafür verantwortlich?
• Welche Kennzahl beweist, dass es die Performance-Kosten wert ist?

Hier wird Performance zu Governance. Jemand muss Nein sagen dürfen.

Eine praktische Checkliste zur Reduzierung von Anfragen

Beginne mit den Seiten, die am wichtigsten sind: Homepage, Preisseite, Produktseite, Checkout, Registrierung oder wichtigste Landingpages. Arbeite dich dann durch den Wasserfall.

Entfernen

• Lösche ungenutztes JavaScript und CSS.
• Entferne alte Experimente, verlassene Pixel und doppelte Analytics.
• Streiche ungenutzte Schriftschnitte und Icon-Bibliotheken.
• Ersetze dekorative Bilder durch CSS, wo es sinnvoll ist.

Durchdacht kombinieren

• Bündle winzige JavaScript-Module, die immer gemeinsam geladen werden.
• Fasse kleine CSS-Dateien zusammen, die denselben Rendering-Pfad blockieren.
• Nutze SVG-Sprites oder Inline-SVG für wiederholte Icons, wenn es Anfragen reduziert, ohne die Wartbarkeit zu verschlechtern.

Verzögern

• Lazy-loade Bilder unterhalb des sichtbaren Bereichs.
• Verzögere nicht-kritische Scripts bis nach dem ersten Paint oder bis zur Nutzerinteraktion.
• Lade Kommentare, Embeds, Karten, Chat und Video-Player nur bei Bedarf.

Richtig cachen

• Nutze langlebiges Caching für versionierte statische Assets.
• Vermeide unnötige Revalidierung für Dateien, die sich selten ändern.
• Halte HTML frisch, aber lass gehashte Assets im Cache bleiben.

Erneut messen

Prüfe nach jeder Änderung den Wasserfall erneut. Das Ziel ist kein perfekter Score. Das Ziel sind weniger kritische Anfragen, früheres nützliches Rendering und weniger Störung des Main Thread.

Wie gut aussieht

Eine gesunde Seite hat nicht zwangsläufig die geringstmögliche Anzahl an Anfragen. Sie hat einen kleinen, bewussten kritischen Pfad.

Der Browser erhält HTML, essentielles CSS, gegebenenfalls das Hauptbild, vielleicht ein kleines Script, das für Navigation oder Interaktion im sichtbaren Bereich benötigt wird, und den minimalen Schriftsatz, der nötig ist, um Text lesbar zu machen. Alles andere wartet, bis es an der Reihe ist.

Das ist der Unterschied zwischen einer Seite, die lediglich optimiert ist, und einer Seite, die sich schnell anfühlt.

Dateien zu verkleinern lohnt sich weiterhin. Aber wenn die Website bereits angemessen komprimiert ist, ist der nächste Performance-Gewinn meist nicht ein weiteres Bundle, aus dem 2 KB gespart werden. Es ist eine blockierende Anfrage weniger, eine Schriftdatei weniger, ein Drittanbieter-Script weniger, eine Abhängigkeitskette weniger.

Weniger Anfragen machen die Arbeit des Browsers einfacher. Einfach ist häufiger schnell, als wir gern zugeben.