Core/Dash 维度： 网络速度

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

免费试用

Trusted by market leaders · Client results

periondpg medianestleharvardsnvwhowhatwearworkivahappyhorizonfotocasanina careebaymonarchsaturnadevintaerasmusmcmarktplaatskpnvpnmy work featured on web.devaleteiacompareloopearplugs

维度：网络速度 (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 失败几乎是肯定的，除非对 LCP 图片进行了积极压缩，通过靠近用户的 CDN 边缘节点进行提供，并正确地进行了预加载。如果您的业务服务于基础设施历史较慢地区的用户，请结合使用 dl 与 CoreDash 的国家/地区维度，以确认慢速流量是否在地理上集中。

调试工作流

  1. 在 CoreDash 中过滤出低于 10 Mbps 的层级 并检查 LCP Load Time。如果 LCP Load Time 是导致 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 Load Time 也能保持在 200 毫秒以下。
  • 首屏资源的总页面权重应保持在 500 KB 以下，以便在 10 Mbps 连接上能在 2.5 秒阈值内提供合理的 LCP。
  • 在 LCP 图片上使用 fetchpriority="high"，并在文档 <head> 中预加载它，以防浏览器优先将带宽浪费在低优先级资源上。
  • 通过 CDN 提供所有静态资产。CoreDash 中的带宽数字测量的是客户端连接，而不是服务器连接。如果服务器在地理上相距甚远并在第一个字节到达之前增加了 300 毫秒的延迟，那么快速的客户端连接也是无济于事的。
  • 如果超过 15% 的流量位于低于 10 Mbps 的层级，并且这些用户的 LCP 不合格，请在解决其他任何问题之前，将图片优化和 CDN 覆盖率视为 P1 级问题处理。