Core/Dash 维度： 网络速度

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

免费试用

Trusted by market leaders · Client results

harvarderasmusmcnestlenina careperionworkivamarktplaatsfotocasasaturnloopearplugsmonarchvpnkpnadevintacomparesnvaleteiadpg mediamy work featured on web.devwhowhatwearhappyhorizonebay

维度：网络速度 (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 几乎总是由首图、大型背景图片或大体积 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 执行、long task 和 main thread 阻塞会导致 INP 分数差。慢速连接会延迟 JavaScript 包的初始下载。如果用户首次与页面交互时脚本仍在解析，这会间接恶化 INP。但只要脚本加载完毕，INP 性能就取决于设备的处理能力，而不是网络。

在实践中，带宽问题在 LCP 加载时间中表现得很明显。它是 LCP 的一部分，用于测量浏览器在发现 LCP 资源后花了多长时间来下载它。CoreDash 单独报告 LCP 加载时间。这让你能直接确认慢速用户到底是在等待网络，还是在等待其他资源。

解读数据

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

快速宽带：50 Mbps 及以上

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

中等速度：10 到 50 Mbps

大约 40% 的 CoreDash 流量落在这一区间。该层级包括较旧的有线连接、信号一般的 4G LTE（典型的 4G 实际速度在 10 到 50 Mbps 之间），以及部分固定无线用户。在这个速度下，传输一张 300 KB 首图需要 48 到 240 毫秒。如果图片未优化，或有多个 render blocking 资源，页面在此层级就会开始达不到 LCP 及格线。在这个层级，选择合适的图片格式（WebP、AVIF）以及使用 fetchpriority="high" 进行积极预加载，会带来明显的改善。

慢速与移动：10 Mbps 以下

大约 25% 的 CoreDash 流量来自 10 Mbps 以下的连接。这包括 3G 移动用户、农村固定连接，以及信号差或网络拥堵的 4G 用户。在 5 Mbps 下，传输一张 400 KB 图片需要 640 多毫秒。在这个层级，除非 LCP 图片经过极限压缩，通过靠近用户的 CDN 边缘节点分发，并且正确预加载，否则 LCP 几乎注定不及格。如果你的业务覆盖基础设施落后的地区，请将 CoreDash 的国家维度与 dl 结合查看，确认慢速流量是否有地理集中趋势。

调试工作流

  1. 在 CoreDash 中筛选出 10 Mbps 以下的层级，并检查 LCP 加载时间。如果 LCP 加载时间是导致 LCP 不及格的主要原因，说明 LCP 资源对慢速连接来说太大了。进一步压缩图片，改用 AVIF 格式，并确认该资源是通过靠近受影响用户的 CDN 边缘节点分发的。
  2. 与国家维度交叉对比。如果慢速用户集中在特定国家，检查你的 CDN 在这些地区是否有良好的覆盖。同样是 15 Mbps 的连接，CDN 边缘节点在 200 毫秒外的用户，体验会比节点仅在 10 毫秒外的用户差得多。
  3. 检查各层级的 INP 和 TTFB 分数。如果 INP 在低带宽层级恶化，而在高带宽层级正常，说明用户首次交互时大型 JavaScript 包仍在下载。拆分 JavaScript，延迟非关键脚本，并考虑在初始化时 yielding 到 main thread，以降低解析阶段对 INP 的影响。

工程经验法则

  • 将 LCP 图片大小控制在 100 KB 以下（AVIF 或 WebP），确保在 5 Mbps 连接下，LCP 加载时间也能低于 200 毫秒。
  • 首屏资源的总页面体积应保持在 500 KB 以下。这样在 10 Mbps 连接下，LCP 才能稳在 2.5 秒的及格线内。
  • 在 LCP 图片上使用 fetchpriority="high"，并在文档的 <head> 中预加载它。这样浏览器就不会把带宽浪费在低优先级资源上。
  • 通过 CDN 提供所有静态资源。CoreDash 中的带宽数据测量的是客户端连接，而不是服务器连接。如果服务器地理位置遥远，在第一个字节到达前就增加了 300 毫秒延迟，那么客户端连接再快也没用。
  • 如果超过 15% 的流量处于 10 Mbps 以下层级，且这些用户的 LCP 不及格，请将图片优化和 CDN 覆盖率作为 P1 级别的问题优先处理，然后再解决其他问题。