CoreDash 维度： 网络速度

按用户下载速度细分 Core Web Vitals，以找出影响您的 LCP 的带宽层级。

免费试用

Trusted by market leaders · Client results

my work featured on web.devmonarchsnvnina careloopearplugsadevintaharvarderasmusmckpnworkivawhowhatwearperionmarktplaatshappyhorizonnestlealeteiacomparevpndpg mediaebayfotocasasaturn

维度：网络速度 (dl)

dl 维度报告了每次页面访问时用户连接的有效下载带宽，以兆比特每秒 (Mbps) 为单位。CoreDash 从浏览器的 Network Information API 收集此值，并将访问分组到不同的带宽层级。CoreDash 表格中的每一行代表一个特定的速度区间，因此您可以并排比较快速宽带用户、中速连接用户以及慢速或移动连接用户的 Core Web Vitals 分数。

带宽是影响页面加载性能的两个网络特征之一。另一个是延迟，它控制着到服务器的往返时间。CoreDash 的 dl 维度隔离了带宽变量，因此您可以回答一个具体的问题：您的 Core Web Vitals 分数是否随着连接速度的下降而降低，降低了多少？

为什么网络速度对 Core Web Vitals 很重要

下载带宽对 Largest Contentful Paint 有直接且可衡量的影响。LCP 几乎总是由首屏大图、大型背景图像或重量级 web 字体触发。在 100 Mbps 的连接下，一张 400 KB 的首屏大图只需大约 32 毫秒的传输时间。而在 5 Mbps 的连接下，同样的图像仅传输时间就超过 640 毫秒，这还没算上任何延迟或处理开销。仅仅是这种差异就足以将一个合格的 LCP 分数推入“需要改进”的范围。

Time to First Byte 对带宽不太敏感。TTFB 主要由服务器处理时间和网络往返延迟决定，而不是传输的字节量。缓慢的服务器响应在任何连接速度下都很慢。如果 CoreDash 中所有带宽层级的 TTFB 都很差，这表明是服务器或 CDN 问题，而不是客户端的带宽问题。

Interaction to Next Paint 几乎完全受限于 CPU。INP 衡量的是从用户输入到下一次视觉更新之间的时间。繁重的 JavaScript 执行、长任务和主线程阻塞会导致 INP 分数变差。缓慢的连接会延迟 JavaScript 包的初始下载，如果用户首次与页面交互时脚本仍在解析，这可能会间接恶化 INP。但一旦脚本加载完毕，INP 性能将由设备的处理能力决定，而非网络。

在实践中，带宽问题会清晰地反映在 LCP 加载时间上，这是 LCP 的一个子部分，衡量浏览器在发现 LCP 资源后花费多长时间进行下载。CoreDash 单独报告 LCP 加载时间，这使得确认速度慢的用户是在等待网络还是其他因素变得简单明了。

读取数据

在典型站点中，CoreDash 的流量分为三个带宽层级。了解每个层级代表什么有助于您确定修复的优先级。

快速宽带：50 Mbps 及以上

大约 35% 的 CoreDash 流量属于这个层级。这包括光纤连接、有线宽带以及信号条件良好的 5G 移动用户。2025 年的平均 5G 下载速度约为 184 Mbps，而美国固定宽带平均速度已达到 214 Mbps。在此层级中的用户在优化良好的页面上不太可能遇到网络驱动的 LCP 延迟。如果这里的 LCP 分数很差，问题出在服务器响应时间、渲染阻塞资源或 LCP 元素发现延迟，而不是带宽。

中等速度：10 到 50 Mbps

大约 40% 的 CoreDash 流量落在该范围内。该层级涵盖较旧的有线连接、平均信号条件下的 4G LTE（典型的 4G 实际速度在 10 到 50 Mbps 之间），以及一些固定无线用户。在此类速度下，一张 300 KB 的首屏大图需要 48 到 240 毫秒的传输时间。带有未优化图像或多个渲染阻塞资源的页面将开始在这个层级中无法达到 LCP 阈值。正是在这个层级中，图像格式的选择（WebP、AVIF）和使用 fetchpriority="high" 进行的激进预加载会产生可衡量的差异。

慢速和移动：10 Mbps 以下

大约 25% 的 CoreDash 流量来自 10 Mbps 以下的连接。这包括 3G 移动用户、农村固定连接以及处于信号不良或网络拥塞条件下的 4G 用户。在 5 Mbps 下，一张 400 KB 的图像需要超过 640 毫秒的传输时间。除非对 LCP 图像进行了极度压缩、通过靠近用户的 CDN 边缘节点提供服务并正确进行了预加载，否则在此层级中几乎肯定会出现 LCP 失败。如果您的业务服务于基础设施历史上较慢地区的用户，请结合 dl 一起查看 CoreDash 的国家/地区维度，以确认低速流量是否在地理上集中。

调试工作流

  1. 在 CoreDash 中筛选至 10 Mbps 以下层级并检查 LCP 加载时间。如果 LCP 加载时间是导致 LCP 分数不合格的主要因素，则说明 LCP 资源对于慢速连接而言太大了。进一步压缩图像，切换到 AVIF 格式，并确认资源是从拥有靠近受影响用户边缘节点的 CDN 提供的。
  2. 与国家/地区维度交叉引用。如果低速用户集中在特定国家/地区，请检查您的 CDN 在这些区域是否有良好的覆盖范围。一个在 15 Mbps 连接下由 200 毫秒外的 CDN 边缘节点提供服务的用户，其体验将远比同等速度下由 10 毫秒外的节点提供服务的用户糟糕得多。
  3. 检查跨层级的 INP 和 TTFB 分数。如果 INP 在低带宽层级恶化但在高带宽层级没有，说明在用户首次交互时大型 JavaScript 包仍在下载。拆分您的 JavaScript，推迟非关键脚本，并考虑在初始化期间 yielding 到主线程以减少解析阶段的 INP 风险。

工程经验法则

  • 将 LCP 图像文件大小目标设定在 100 KB（AVIF 或 WebP）以下，以便即使在 5 Mbps 连接下也能将 LCP 加载时间保持在 200 毫秒以内。
  • 首屏资源的总页面权重应保持在 500 KB 以下，以便在 10 Mbps 连接下在 2.5 秒的阈值内提供合理的 LCP。
  • 在 LCP 图像上使用 fetchpriority="high" 并在文档的 <head> 中预加载它，这样浏览器就不会先将带宽浪费在较低优先级的资源上。
  • 通过 CDN 提供所有静态资产。CoreDash 中的带宽数字衡量的是客户端的连接，而不是服务器的。如果服务器在地理上很远，并在第一个字节到达之前增加了 300 毫秒的延迟，那么客户端连接再快也没有用。
  • 如果超过 15% 的流量位于 10 Mbps 以下层级，并且这些用户的 LCP 不合格，请在解决任何其他问题之前，将图像优化和 CDN 覆盖范围视为 P1（最高优先级）问题。