Was sind Netzwerkverbindungen für die Seitengeschwindigkeit?

Was sind Netzwerkverbindungen für die Seitengeschwindigkeit?

Eine Netzwerkverbindung ist der Kanal, den ein Browser zu einem Server öffnet, bevor er etwas abrufen kann. Der Aufbau kostet Zeit: eine DNS-Abfrage, ein TCP-Handshake und bei HTTPS eine TLS-Aushandlung. Eine Seite, die Dateien von vielen verschiedenen Servern lädt, zahlt diesen Preis mehrfach. Wie Verbindungen geöffnet, wiederverwendet und geteilt werden, wiegt deshalb oft so schwer wie die Dateigröße.

Was eine neue Verbindung kostet

Die erste Anfrage an einen Server umfasst eine DNS-Abfrage, einen TCP-Handshake und die gesicherte TLS-Aushandlung. Spätere Anfragen sind schneller, weil die Verbindung schon steht (MDN, "Understanding latency"). Jeder Schritt ist ein Netzwerk-Roundtrip, die Kosten wachsen also mit der Entfernung zwischen Besucher und Server. Darum schmerzt eine neue Verbindung im Mobilfunk und bei weit entfernten Besuchern am meisten.

Beispiel: Eine Seite lädt eigene Dateien, ein Analytics-Skript, einen Schriften-Host, ein Werbenetzwerk und ein Chat-Widget. Das sind fünf Origins, also fünf DNS-Abfragen und fünf Verbindungsaufbauten, bevor das letzte Byte ankommen kann, auch wenn jede Datei klein ist.

Verbindungen wiederverwenden

• Persistente Verbindungen (Keep-Alive). Eine persistente Verbindung bleibt offen und wird für mehrere Anfragen genutzt, der Handshake entfällt. In HTTP/1.1 ist Persistenz der Standard, ungenutzte Verbindungen werden nach einer Weile geschlossen (MDN, "Connection management in HTTP/1.x").
• Parallelität in HTTP/1.x. HTTP/1.x bearbeitet Anfragen auf einer Verbindung nacheinander, daher öffnen Browser mehrere Verbindungen pro Domain. Üblich sind 6 parallele Verbindungen, laut MDN ein typischer Wert und kein fester Standard.
• Multiplexing in HTTP/2. HTTP/2 lässt parallele Anfragen eine Verbindung teilen und komprimiert wiederkehrende Header. Alte HTTP/1-Tricks wie Domain Sharding helfen dann nicht mehr und können schaden, nutze lieber weniger Origins. Auch HTTP/3 ist gemultiplext und blockiert nicht alle Streams, wenn ein Paket verloren geht (MDN, "Evolution of HTTP").

Verbindungen früh aufwärmen

Wenn du weißt, dass die Seite einen weiteren Origin braucht, sag es dem Browser früh. <link rel="preconnect"> startet DNS-, TCP- und TLS-Arbeit vorab und hilft nur bei Cross-Origin-Anfragen. MDN rät, es nur für die wichtigsten Origins zu nutzen, da Preconnect auf viele Drittanbieter nach hinten losgehen kann. Für weniger wichtige Origins spart <link rel="dns-prefetch"> nur den DNS-Schritt. Verwandte Hinweise findest du unter Prefetching von Ressourcen, die genaue Syntax in der MDN-Referenz zu preconnect.

Weitere Wege, Verbindungskosten zu senken

• Weniger Origins. Hoste wichtige Schriften und Skripte selbst und streiche Drittanbieter-Tags, die du nicht brauchst.
• Aus der Nähe ausliefern. Ein CDN verkürzt jeden Roundtrip und senkt die Time to First Byte.
• Nicht auf Drittanbieter warten. Lade unkritische Skripte mit asynchronem Laden, damit eine langsame Verbindung das Rendern nicht aufhält.
• Moderne TLS- und HTTP-Versionen auf Server und CDN nutzen.

Häufige Fehler

• Preconnect auf ein Dutzend Origins "für alle Fälle". Jeder belegt eine Verbindung und CPU-Zeit.
• HTTP/1-Gewohnheiten nach dem Umstieg auf HTTP/2 beibehalten, etwa Assets auf Subdomains verteilen.
• Nur von einem Standort testen. Verbindungskosten hängen von der Entfernung ab, eine Seite, die nahe am Server schnell wirkt, kann anderswo langsam sein.
• Die Dateigröße beschuldigen, obwohl das Wasserfalldiagramm lange DNS-, Connect- oder TLS-Balken zeigt.

So misst du es

Das Netzwerk-Panel des Browsers teilt jede Anfrage in DNS-Abfrage, Verbindungsaufbau, TLS, Warten und Download auf und zeigt, wann Anfragen auf eine Verbindung warten (MDN, "Understanding latency"). Achte auf wiederholte Verbindungsbalken zum selben Origin und auf viele kleine Origins. Um es über die Zeit zu verfolgen, führt LoadFocus Page-Speed-Monitoring geplante Lighthouse-Audits aus 25 Cloud-Regionen aus, sodass du vergleichst, wie dieselbe Seite aus verschiedenen Entfernungen lädt. Für einen schnellen Check gibt es den kostenlosen Core-Web-Vitals-Checker. Für deine APIs teilt API-Monitoring jede Antwortzeit in DNS, TCP-Verbindung, erstes Byte und Download auf. Wenn du Protokollversionen abwägst, lies die Blogbeiträge zu HTTP/3 und Load Testing und Netzwerkprotokollen für Performance-Tests. Hintergrund zur Verzögerung selbst steht unter Latenz.

Häufige Fragen

Warum ist die erste Anfrage an eine Website langsamer als spätere?

Die erste Anfrage braucht eine DNS-Abfrage, einen TCP-Handshake und eine TLS-Aushandlung. Spätere Anfragen nutzen die offene Verbindung und überspringen diese Schritte.

Wie viele Verbindungen öffnet ein Browser zu einem Server?

Bei HTTP/1.x öffnen Browser üblicherweise 6 parallele Verbindungen pro Domain. Bei HTTP/2 und HTTP/3 teilen sich Anfragen per Multiplexing eine Verbindung, meist reicht eine.

Was macht preconnect?

Es weist den Browser an, DNS-, TCP- und TLS-Arbeit für einen weiteren Origin zu starten, bevor die Seite ihn anfragt. Es hilft nur bei Anfragen an einen anderen Origin und sollte auf die wichtigsten beschränkt bleiben.

Behebt eine schnellere Verbindung eine langsame Seite?

Nicht immer. Bandbreite hilft bei großen Downloads, doch die meisten Seiten werden von Roundtrips und der Zahl der Origins begrenzt. Weniger Verbindungen und kürzere Wege helfen oft mehr als mehr Bandbreite.

Was ist der Unterschied zwischen dns-prefetch und preconnect?

dns-prefetch löst nur den Domainnamen auf. preconnect öffnet zusätzlich die TCP-Verbindung und schließt bei HTTPS die TLS-Aushandlung ab. Das spart mehr Zeit, kostet aber auch mehr.