Core/Dash 维度： 网络速度

按用户下载速度对 Core Web Vitals 进行细分，找出哪些带宽层级正在损害你的 LCP。

免费试用

Trusted by market leaders · Client results

adevintaworkivasaturncomparedpg mediawhowhatwearfotocasasnvnestleebaymonarchnina careloopearplugsharvardaleteiaerasmusmcperionkpnmarktplaatshappyhorizonmy work featured on web.devvpn

维度：网络速度 (dl)

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

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

coredash metric table urls

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

下载带宽对 Largest Contentful Paint 有着直接且可衡量的影响。LCP 几乎总是由首屏大图 (hero image)、大型背景图像或大体积 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 Load Time（LCP 的一个子部分，衡量浏览器在发现 LCP 资源后花费多长时间下载它）中清晰地显现出来。CoreDash 单独报告 LCP Load Time，从而可以直接确认连接较慢的用户是在等待网络还是在等待其他东西。

读取数据

在典型网站中，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 几乎注定会失败。如果你的业务面向基础设施历史较慢地区的用户，请结合 CoreDash Country 维度和 dl 维度进行检查，以确认慢速流量是否在地理上集中。

调试工作流

  1. 在 CoreDash 中过滤到低于 10 Mbps 的层级并检查 LCP Load Time。如果 LCP Load Time 是导致 LCP 分数不及格的主要原因，说明该 LCP 资源对于慢速连接来说太大了。进一步压缩图像，切换到 AVIF 格式，并确认该资源是通过带有靠近受影响用户的边缘节点的 CDN 提供的。
  2. 与 Country 维度进行交叉引用。如果慢速用户集中在特定国家/地区，请检查你的 CDN 在这些地区是否有良好的覆盖。一个 15 Mbps 连接的用户如果连接到 200 毫秒之外的 CDN 边缘节点，其体验将远差于同样速度但连接到 10 毫秒之外节点的用户。
  3. 检查各个层级的 INP 和 TTFB 分数。如果 INP 在低带宽层级恶化但在高带宽层级没有，说明当用户首次交互时，大型 JavaScript 包仍在下载。拆分你的 JavaScript，延迟加载非关键脚本，并考虑在初始化期间yielding 到主线程，以减少解析阶段对 INP 的负面影响。

工程经验法则

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