Core/Dash-Dimension: Netzwerkgeschwindigkeit

Dimension: Netzwerkgeschwindigkeit (dl)

Die dl-Dimension gibt die effektive Download-Bandbreite der Verbindung jedes Nutzers zum Zeitpunkt des Seitenbesuchs in Megabit pro Sekunde (Mbps) an. CoreDash erfasst diesen Wert über die Network Information API des Browsers und gruppiert die Besuche in Bandbreiten-Stufen. Jede Zeile in der CoreDash-Tabelle repräsentiert eine bestimmte Geschwindigkeitsklasse, sodass Sie Ihre Core Web Vitals-Werte von Nutzern mit schnellem Breitband, mittelschnellen Verbindungen und langsamen oder mobilen Verbindungen direkt miteinander vergleichen können.

Die Bandbreite ist eine von zwei Netzwerkeigenschaften, die die Ladeleistung einer Seite bestimmen. Die andere ist die Latenz, die die Round-Trip-Zeit zum Server steuert. Die dl-Dimension von CoreDash isoliert die Variable Bandbreite, damit Sie eine konkrete Frage beantworten können: Verschlechtern sich Ihre Core Web Vitals-Werte, wenn die Verbindungsgeschwindigkeit sinkt, und um wie viel?

Warum die Netzwerkgeschwindigkeit für 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-Image, ein großes Hintergrundbild oder einen großen Webfont ausgelöst. Bei einer 100-Mbps-Verbindung wird ein 400 KB großes Hero-Image in etwa 32 Millisekunden Übertragungszeit heruntergeladen. Bei einer 5-Mbps-Verbindung benötigt dasselbe Bild allein für die Übertragung über 640 Millisekunden, bevor Latenz oder Verarbeitungsaufwand berücksichtigt werden. Dieser Unterschied allein kann einen eigentlich guten LCP-Wert in den Bereich „Verbesserung erforderlich“ drücken.

Die Time to First Byte ist weniger abhängig von der Bandbreite. Die TTFB wird von der Serververarbeitungszeit und der Netzwerk-Round-Trip-Latenz dominiert, nicht vom übertragenen Datenvolumen. Eine langsame Serverantwort ist bei jeder Verbindungsgeschwindigkeit langsam. Wenn die TTFB über alle Bandbreiten-Stufen in CoreDash hinweg schlecht ist, deutet dies eher auf Server- oder CDN-Probleme hin als auf ein clientseitiges Bandbreitenproblem.

Der Interaction to Next Paint ist fast ausschließlich CPU-gebunden. Der INP misst die Zeit zwischen der Nutzereingabe und der nächsten visuellen Aktualisierung. Starke JavaScript-Ausführung, lange Aufgaben (Long Tasks) und das Blockieren des Main Threads führen zu schlechten INP-Werten. Eine langsame Verbindung kann den anfänglichen Download von JavaScript-Bundles verzögern, was den INP indirekt verschlechtern kann, wenn Skripte noch geparst werden, während der Nutzer zum ersten Mal mit der Seite interagiert. Sobald die Skripte jedoch geladen sind, wird die INP-Leistung von der Rechenleistung des Geräts bestimmt, nicht vom Netzwerk.

In der Praxis zeigen sich Bandbreitenprobleme deutlich in der LCP Load Time, dem Teilbereich des LCP, der misst, wie lange der Browser gebraucht hat, um die LCP-Ressource herunterzuladen, nachdem sie entdeckt wurde. CoreDash weist die LCP Load Time separat aus, sodass sich leicht überprüfen lässt, ob Nutzer mit langsamer Verbindung auf das Netzwerk oder auf etwas anderes warten.

Die Daten lesen

Der CoreDash-Traffic auf typischen Websites teilt sich in drei Bandbreiten-Stufen auf. Zu verstehen, was jede Stufe repräsentiert, hilft Ihnen bei der Priorisierung von Fehlerbehebungen.

Schnelles Breitband: 50 Mbps und mehr

Ungefähr 35 % des CoreDash-Traffics fallen in diese Stufe. Dies umfasst Glasfaserverbindungen, Kabel-Breitband und 5G-Mobilfunknutzer bei guten Signalbedingungen. Die durchschnittlichen 5G-Download-Geschwindigkeiten liegen im Jahr 2025 bei etwa 184 Mbps, und die Durchschnittswerte für festes Breitband haben in den USA 214 Mbps erreicht. Nutzer in dieser Stufe werden auf gut optimierten Seiten wahrscheinlich keine netzwerkbedingten LCP-Verzögerungen erleben. Wenn die LCP-Werte hier schlecht sind, liegt das Problem an der Serverantwortzeit, renderblockierenden Ressourcen oder einer Verzögerung bei der Entdeckung des LCP-Elements, nicht an der Bandbreite.

Mittlere Geschwindigkeit: 10 bis 50 Mbps

Etwa 40 % des CoreDash-Traffics liegen in diesem Bereich. Diese Stufe umfasst ältere Kabelverbindungen, 4G LTE bei durchschnittlichen Signalbedingungen (typische 4G-Geschwindigkeiten in der Praxis liegen zwischen 10 und 50 Mbps) sowie einige Nutzer von Fixed Wireless. Ein 300 KB großes Hero-Image benötigt bei diesen Geschwindigkeiten zwischen 48 und 240 Millisekunden Übertragungszeit. Seiten mit nicht optimierten Bildern oder mehreren renderblockierenden Ressourcen werden in dieser Stufe beginnen, die LCP-Grenzwerte zu verfehlen. In dieser Stufe machen die Wahl des Bildformats (WebP, AVIF) und aggressives Preloading mit fetchpriority="high" einen messbaren Unterschied.

Langsam und Mobile: Unter 10 Mbps

Etwa 25 % des CoreDash-Traffics stammen von Verbindungen mit weniger als 10 Mbps. Dazu gehören 3G-Mobilfunknutzer, ländliche Festnetzverbindungen und 4G-Nutzer bei schlechtem Signal oder überlasteten Netzwerkbedingungen. Bei 5 Mbps benötigt ein 400 KB großes Bild über 640 Millisekunden für die Übertragung. LCP-Fehlschläge in dieser Stufe sind fast sicher, es sei denn, das LCP-Bild wurde aggressiv komprimiert, wird über einen CDN-Edge-Knoten in der Nähe des Nutzers bereitgestellt und korrekt im Voraus geladen (Preload). Wenn Ihr Unternehmen Nutzer in Regionen mit historisch langsamerer Infrastruktur bedient, prüfen Sie die CoreDash-Dimension „Country“ zusammen mit „dl“, um zu bestätigen, ob sich langsamer Traffic geografisch konzentriert.

Debugging-Workflow

1. Filtern Sie auf die Stufe unter 10 Mbps in CoreDash und überprüfen Sie die LCP Load Time. Wenn die LCP Load Time der Hauptfaktor für einen unzureichenden LCP-Wert ist, ist die LCP-Ressource für langsame Verbindungen zu groß. Komprimieren Sie das Bild stärker, wechseln Sie zum AVIF-Format und stellen Sie sicher, dass die Ressource über ein CDN mit einem nahegelegenen Edge-Knoten für die betroffenen Nutzer bereitgestellt wird.
2. Gleichen Sie die Daten mit der Dimension „Country“ ab. Wenn sich Nutzer mit langsamer Geschwindigkeit in bestimmten Ländern konzentrieren, prüfen Sie, ob Ihr CDN in diesen Regionen eine gute Abdeckung bietet. Ein Nutzer mit einer 15-Mbps-Verbindung, der von einem 200 ms entfernten CDN-Edge-Knoten bedient wird, hat eine wesentlich schlechtere User Experience als ein Nutzer mit derselben Geschwindigkeit, der von einem 10 ms entfernten Knoten bedient wird.
3. Überprüfen Sie die INP- und TTFB-Werte über alle Stufen hinweg. Wenn sich der INP bei niedrigen Bandbreiten-Stufen verschlechtert, bei hohen jedoch nicht, werden große JavaScript-Bundles noch heruntergeladen, wenn Nutzer zum ersten Mal interagieren. Splitten Sie Ihr JavaScript, stellen Sie die Ausführung nicht-kritischer Skripte zurück (defer) und erwägen Sie ein Yielding an den Main Thread während der Initialisierung, um das INP-Risiko während der Parse-Phase zu reduzieren.

Faustregel für Entwickler

• Zielen Sie auf eine Dateigröße des LCP-Bildes von unter 100 KB (AVIF oder WebP) ab, um die LCP Load Time selbst bei 5-Mbps-Verbindungen unter 200 ms zu halten.
• Das Gesamtgewicht der Seite für Ressourcen "Above the Fold" sollte unter 500 KB bleiben, um bei 10-Mbps-Verbindungen innerhalb des Grenzwerts von 2,5 Sekunden einen angemessenen LCP zu ermöglichen.
• Verwenden Sie fetchpriority="high" für das LCP-Bild und laden Sie es im <head> des Dokuments im Voraus (Preload), damit der Browser keine Bandbreite zuerst für Ressourcen mit niedrigerer Priorität verschwendet.
• Stellen Sie alle statischen Assets über ein CDN bereit. Die Bandbreiten-Zahlen in CoreDash messen die Verbindung des Clients, nicht die des Servers. Eine schnelle Clientverbindung nützt nichts, wenn der Server geografisch weit entfernt ist und 300 ms Latenz hinzufügt, bevor das erste Byte ankommt.
• Wenn mehr als 15 % Ihres Traffics in der Stufe unter 10 Mbps liegen und der LCP für diese Nutzer fehlschlägt, behandeln Sie Bildoptimierung und CDN-Abdeckung als P1-Probleme, bevor Sie etwas anderes angehen.