Core/Dash-Dimension: Netzwerkgeschwindigkeit

Dimension: Netzwerkgeschwindigkeit (dl)

Die Dimension dl gibt die effektive Download-Bandbreite der Verbindung jedes Nutzers zum Zeitpunkt des Seitenbesuchs an, gemessen in Megabit pro Sekunde (Mbit/s). CoreDash erfasst diesen Wert über die Network Information API des Browsers und teilt die Besuche in Bandbreiten-Klassen ein. Jede Zeile in der CoreDash-Tabelle stellt einen bestimmten Geschwindigkeitsbereich dar. So kannst du deine Core Web Vitals-Werte für schnelles Breitband, mittlere Geschwindigkeiten sowie langsame oder mobile Verbindungen direkt vergleichen.

Die Bandbreite ist eine von zwei Netzwerkeigenschaften, die die Lade-Performance der Seite bestimmen. Die andere ist die Latenz. Sie bestimmt die Roundtrip-Zeit zum Server. Die Dimension dl von CoreDash isoliert die Variable Bandbreite. So kannst du eine konkrete Frage beantworten: Verschlechtern sich deine Core Web Vitals-Werte bei abnehmender Verbindungsgeschwindigkeit, und um wie viel?

Warum die Netzwerkgeschwindigkeit für die Core Web Vitals wichtig ist

Die Download-Bandbreite hat einen direkten und messbaren Einfluss auf den Largest Contentful Paint. Der LCP wird fast immer durch ein Hero-Bild, ein großes Hintergrundbild oder eine schwere Web-Schriftart ausgelöst. Bei einer Verbindung mit 100 Mbit/s wird ein 400 KB großes Hero-Bild in etwa 32 Millisekunden übertragen. Bei einer Verbindung mit 5 Mbit/s benötigt dasselbe Bild allein für die Übertragung über 640 Millisekunden. Latenzen oder Verarbeitungs-Overhead sind dabei noch nicht eingerechnet. Dieser Unterschied allein kann einen guten LCP-Wert in den Bereich „Optimierungsbedürftig“ verschieben.

Die Time to First Byte reagiert weniger empfindlich auf die Bandbreite. Die TTFB wird durch die Verarbeitungszeit des Servers und die Roundtrip-Latenz des Netzwerks dominiert, nicht durch die Menge der übertragenen Bytes. Eine langsame Serverantwort bleibt bei jeder Verbindungsgeschwindigkeit langsam. Wenn die TTFB über alle Bandbreiten-Klassen in CoreDash hinweg schlecht ist, deutet das auf Server- oder CDN-Probleme hin, nicht auf ein clientseitiges Bandbreitenproblem.

Interaction to Next Paint ist fast vollständig CPU-gebunden. Der INP misst die Zeit zwischen einer Nutzereingabe und dem nächsten visuellen Update. Eine intensive JavaScript-Ausführung, long tasks und eine Blockierung des main thread führen zu schlechten INP-Werten. Eine langsame Verbindung kann den initialen Download von JavaScript-Bundles verzögern. Das kann den INP indirekt verschlechtern, wenn Skripte noch geparst werden, wenn der Nutzer das erste Mal mit der Seite interagiert. Sobald die Skripte geladen sind, wird die INP-Performance jedoch durch die Rechenleistung des Geräts bestimmt, nicht durch das Netzwerk.

In der Praxis zeigen sich Bandbreitenprobleme deutlich in der LCP Load Time. Dieser Teilbereich des LCP misst, wie lange der Browser nach dem Entdecken der LCP-Ressource für deren Download benötigt hat. CoreDash weist die LCP Load Time separat aus. So siehst du sofort, ob langsame Nutzer auf das Netzwerk oder auf etwas anderes warten.

Die Daten lesen

Der CoreDash-Traffic typischer Websites lässt sich in drei Bandbreiten-Klassen unterteilen. Wenn du verstehst, was jede Klasse bedeutet, kannst du Fehlerbehebungen besser priorisieren.

Schnelles Breitband: 50 Mbit/s und mehr

Etwa 35 % des CoreDash-Traffics fallen in diese Klasse. Dazu gehören Glasfaseranschlüsse, Kabel-Breitband und 5G-Mobilfunknutzer bei gutem Empfang. Die durchschnittliche 5G-Download-Geschwindigkeit liegt 2025 bei etwa 184 Mbit/s. Der Durchschnitt für Festnetz-Breitband in den USA hat 214 Mbit/s erreicht. Nutzer in dieser Klasse erleben auf gut optimierten Seiten selten netzwerkbedingte LCP-Verzögerungen. Wenn die LCP-Werte hier schlecht sind, liegt das Problem an der Serverantwortzeit, an render-blocking Ressourcen oder einer verzögerten Erkennung des LCP-Elements – nicht an der Bandbreite.

Mittlere Geschwindigkeit: 10 bis 50 Mbit/s

Etwa 40 % des CoreDash-Traffics liegen in diesem Bereich. Diese Klasse umfasst ältere Kabelanschlüsse, 4G LTE bei durchschnittlichem Empfang (typische reale 4G-Geschwindigkeiten liegen zwischen 10 und 50 Mbit/s) und einige Fixed-Wireless-Nutzer. Ein 300 KB großes Hero-Bild benötigt bei diesen Geschwindigkeiten zwischen 48 und 240 Millisekunden Übertragungszeit. Seiten mit nicht optimierten Bildern oder mehreren render-blocking Ressourcen verfehlen in dieser Klasse die LCP-Grenzwerte. Hier machen die Wahl des Bildformats (WebP, AVIF) und aggressives Preloading mit fetchpriority="high" einen messbaren Unterschied.

Langsam und mobil: Unter 10 Mbit/s

Etwa 25 % des CoreDash-Traffics stammen von Verbindungen unter 10 Mbit/s. Dazu gehören 3G-Mobilfunknutzer, Festnetzanschlüsse im ländlichen Raum sowie 4G-Nutzer mit schlechtem Empfang oder in überlasteten Mobilfunkzellen. Bei 5 Mbit/s dauert die Übertragung eines 400 KB großen Bildes über 640 Millisekunden. LCP-Fehler sind in dieser Klasse fast sicher, es sei denn, das LCP-Bild wurde aggressiv komprimiert, über einen CDN-Edge-Node nahe am Nutzer bereitgestellt und korrekt vorab geladen. Wenn dein Unternehmen Nutzer in Regionen mit historisch langsamerer Infrastruktur bedient, vergleiche die CoreDash-Dimension „Country“ mit „dl“. So siehst du, ob sich der langsame Traffic geografisch konzentriert.

Debugging-Workflow

1. Filtere in CoreDash nach der Klasse unter 10 Mbit/s und prüfe die LCP Load Time. Wenn die LCP Load Time der Hauptfaktor für einen schlechten LCP-Wert ist, ist die LCP-Ressource zu groß für langsame Verbindungen. Komprimiere das Bild stärker, wechsle zum AVIF-Format und stelle sicher, dass die Ressource von einem CDN mit einem nahen Edge-Node für die betroffenen Nutzer bereitgestellt wird.
2. Gleiche die Daten mit der Dimension „Country“ ab. Wenn sich langsame Nutzer in bestimmten Ländern konzentrieren, prüfe die Abdeckung deines CDN in diesen Regionen. Ein Nutzer mit einer 15-Mbit/s-Verbindung, der von einem 200 ms entfernten CDN-Edge-Node bedient wird, hat eine weitaus schlechtere Erfahrung als ein Nutzer mit der gleichen Geschwindigkeit, dessen Node nur 10 ms entfernt ist.
3. Überprüfe die INP- und TTFB-Werte über die Klassen hinweg. Wenn sich der INP bei niedrigen Bandbreiten-Klassen verschlechtert, nicht aber bei hohen, laden große JavaScript-Bundles noch herunter, während die Nutzer bereits das erste Mal interagieren. Teile dein JavaScript auf, verschiebe unkritische Skripte (defer) und ziehe ein yielding to the main thread während der Initialisierung in Betracht. Das verringert die INP-Anfälligkeit in der Parsing-Phase.

Entwickler-Faustregeln

• Strebe eine Dateigröße des LCP-Bildes von unter 100 KB (AVIF oder WebP) an. Das hält die LCP Load Time selbst bei 5 Mbit/s unter 200 ms.
• Das Gesamtgewicht aller Ressourcen für den direkt sichtbaren Bereich (above the fold) sollte unter 500 KB liegen. So erreichst du auch bei 10 Mbit/s einen soliden LCP innerhalb des Grenzwerts von 2,5 Sekunden.
• Nutze fetchpriority="high" für das LCP-Bild und lade es im <head> des Dokuments vorab. So verschwendet der Browser keine Bandbreite für Ressourcen mit niedrigerer Priorität.
• Stelle alle statischen Assets über ein CDN bereit. Die Bandbreitenwerte in CoreDash messen die Verbindung des Clients, nicht die des Servers. Eine schnelle Client-Verbindung nützt nichts, wenn der Server geografisch weit entfernt ist und bis zum ersten Byte 300 ms Latenz hinzufügt.
• Wenn mehr als 15 % deines Traffics in die Klasse unter 10 Mbit/s fallen und der LCP für diese Nutzer fehlschlägt, behandle Bildoptimierung und CDN-Abdeckung als P1-Themen, bevor du andere Probleme angehst.