Core/Dash Dimension: Network Speed
Segment Core Web Vitals by user download speed to find which bandwidth tiers are hurting your LCP.
Dimension: Network Speed (dl)
The dl dimension reports the effective download bandwidth of each user's connection at the time of the page visit, measured in Megabits per second (Mbps). CoreDash collects this value from the browser's Network Information API and groups visits into bandwidth tiers. Each row in the CoreDash table represents a specific speed bucket, so you can compare your Core Web Vitals scores across fast broadband users, moderate-speed connections, and slow or mobile connections side by side.
Bandwidth is one of two network characteristics that shape page load performance. The other is latency, which controls round-trip time to the server. CoreDash's dl dimension isolates the bandwidth variable so you can answer a concrete question: are your Core Web Vitals scores degrading as connection speed drops, and by how much?

Why Network Speed Matters for Core Web Vitals
Download bandwidth has a direct and measurable impact on Largest Contentful Paint. LCP is almost always triggered by a hero image, a large background image, or a heavyweight web font. On a 100 Mbps connection, a 400 KB hero image arrives in roughly 32 milliseconds of transfer time. On a 5 Mbps connection, that same image takes over 640 milliseconds in transfer time alone, before accounting for any latency or processing overhead. That difference alone can push a passing LCP score into the "needs improvement" range.
Time to First Byte is less sensitive to bandwidth. TTFB is dominated by server processing time and network round-trip latency, not the volume of bytes transferred. A slow server response is slow on any connection speed. If TTFB is poor across all bandwidth tiers in CoreDash, that points to server or CDN issues rather than a client-side bandwidth problem.
Interaction to Next Paint is almost entirely CPU-bound. INP measures the time between user input and the next visual update. Heavy JavaScript execution, long tasks, and main thread blocking drive poor INP scores. A slow connection can delay the initial download of JavaScript bundles, which can indirectly worsen INP if scripts are still parsing when the user first interacts with the page. But once scripts are loaded, INP performance is determined by the device's processing power, not the network.
In practice, bandwidth problems surface clearly in LCP Load Time, the sub-part of LCP that measures how long the browser spent downloading the LCP resource after it was discovered. CoreDash reports LCP Load Time separately, making it straightforward to confirm whether slow users are waiting on the network or on something else.
Reading the Data
CoreDash traffic across typical sites breaks down into three bandwidth tiers. Understanding what each tier represents helps you prioritize fixes.
Fast Broadband: 50 Mbps and above
Approximately 35% of CoreDash traffic falls in this tier. This includes fiber connections, cable broadband, and 5G mobile users in good signal conditions. Average 5G download speeds in 2025 sit around 184 Mbps, and fixed broadband averages in the US have reached 214 Mbps. Users in this tier are unlikely to experience network-driven LCP delays on well-optimized pages. If LCP scores are poor here, the problem is server response time, render-blocking resources, or LCP element discovery delay, not bandwidth.
Moderate Speed: 10 to 50 Mbps
Approximately 40% of CoreDash traffic lands in this range. This tier covers older cable connections, 4G LTE in average signal conditions (typical 4G real-world speeds sit between 10 and 50 Mbps), and some fixed-wireless users. A 300 KB hero image takes between 48 and 240 milliseconds of transfer time at these speeds. Pages with unoptimized images or multiple render-blocking resources will start failing LCP thresholds in this tier. This is the tier where image format choices (WebP, AVIF) and aggressive preloading with fetchpriority="high" make a measurable difference.
Slow and Mobile: Below 10 Mbps
Approximately 25% of CoreDash traffic comes from connections below 10 Mbps. This includes 3G mobile users, rural fixed connections, and 4G users in poor signal or congested network conditions. At 5 Mbps, a 400 KB image takes over 640 milliseconds of transfer time. LCP failures in this tier are almost certain unless the LCP image has been compressed aggressively, served via a CDN edge node close to the user, and preloaded correctly. If your business serves users in regions with historically slower infrastructure, check the CoreDash Country dimension alongside dl to confirm whether slow-speed traffic concentrates geographically.
Debugging Workflow
- Filter to the sub-10 Mbps tier in CoreDash and check LCP Load Time. If LCP Load Time is the dominant contributor to a failing LCP score, the LCP resource is too large for slow connections. Compress the image further, switch to AVIF format, and confirm the resource is served from a CDN with a nearby edge node to the affected users.
- Cross-reference with the Country dimension. If slow-speed users concentrate in specific countries, check whether your CDN has good coverage in those regions. A user on a 15 Mbps connection served by a CDN edge node 200 ms away will have a far worse experience than a user on the same speed served by a node 10 ms away.
- Check INP and TTFB scores across tiers. If INP worsens at low bandwidth tiers but not at high ones, large JavaScript bundles are still downloading when users first interact. Split your JavaScript, defer non-critical scripts, and consider yielding to the main thread during initialization to reduce INP exposure during the parse phase.
Engineering Rule of Thumb
- Target an LCP image file size below 100 KB (AVIF or WebP) to keep LCP Load Time under 200 ms even on 5 Mbps connections.
- Total page weight for above-the-fold resources should stay under 500 KB to give a reasonable LCP on 10 Mbps connections within the 2.5 second threshold.
- Use
fetchpriority="high"on the LCP image and preload it in the document<head>so the browser does not waste bandwidth on lower-priority resources first. - Serve all static assets from a CDN. Bandwidth numbers in CoreDash measure the client's connection, not the server's. A fast client connection does not help if the server is geographically distant and adds 300 ms of latency before the first byte arrives.
- If more than 15% of your traffic is in the sub-10 Mbps tier and LCP is failing for those users, treat image optimization and CDN coverage as P1 issues before addressing anything else.