navigator.connection.rtt是Network Information API提供的估算往返延迟（毫秒），可用于粗粒度网络质量判断，但兼容性差（Safari/Firefox不支持）、精度低（非实时、受HTTP/3和丢包影响），仅建议与downlink等组合用于初始资源降级决策。
navigator.connection.rtt 是什么，它真的能用吗
navigator.connection.rtt 是 Network Information API 的一部分，返回浏览器估算的往返时延（单位：毫秒），理论上可用于感知网络质量。但它**不是所有环境都可用**：Chrome 61+ 支持，Firefox 和 Safari 完全不支持（截至 2024 年），且仅在 HTTPS 或 localhost 下生效；更关键的是，它返回的是 TCP 层 RTT 估算值，和实际资源加载延迟相关性弱——尤其在高丢包、弱信号或使用 HTTP/3 的场景下，rtt 可能长期稳定在 50–100ms，完全无法反映真实体验。
所以别把它当“网络测速仪”用。它更适合做粗粒度兜底判断：比如 rtt > 300 时禁用 WebP、跳过懒加载首屏外图片、或强制降级为 720p 视频源。
如何安全读取并监听 RTT 变化
navigator.connection 是只读对象，rtt 本身不可监听，但其所属的 connection 对象支持 change 事件——不过该事件**不保证每次 RTT 变动都会触发**，只在连接类型（如 type）、有效带宽（downlink）等明确变化时抛出。
实操建议：
- 首次进入页面时立即读取
navigator.connection.rtt，若为0或undefined，视为不可用，直接 fallback 到 UA + 屏幕密度 + 首屏渲染耗时等组合策略 - 绑定
connection.addEventListener('change', ...)，但不要依赖它更新 RTT——每次事件回调里都要重新读取connection.rtt - 避免高频轮询（比如 setInterval 每 500ms 查一次），这既无意义又可能触发浏览器警告
- 注意：某些安卓 WebView 中
rtt始终返回0，需结合navigator.connection.downlink交叉验证
RTT 值怎么映射到高清素材分级逻辑
单纯看 rtt 数值容易误判。更可靠的做法是分段+加权：把 rtt 和 downlink 组合起来做决策。例如：
假设你有三档图片质量：srcset 中的 1x（普通）、2x（Retina）、webp-2x（高压缩 WebP）：
-
rtt = 10→ 启用webp-2x -
rtt = 5→ 启用2x，禁用 WebP rtt > 150 || downlink → 强制1x+ JPEG（兼容性好、解码快）
注意：不要用 rtt 直接控制视频码率（比如 “RTT > 200 就切 480p”），因为视频首帧加载受 CDN 缓存、TCP 慢启动影响更大，此时 rtt 已滞后。更适合用它做初始选择，后续交由 MSE 或 hls.js 的自适应逻辑接管。
绕过 RTT 限制的替代方案有哪些
当 navigator.connection.rtt 不可用或不准时，可快速 fallback 到以下信号：
- 用
performance.getEntriesByType('navigation')[0].domContentLoadedEventEnd 估算首屏加载质量：> 3000ms 可视为弱网，触发降级
- 监听
document.readyState 和图像 load 事件超时（如首张关键图 > 5s 未加载），动态切换 img.src 为低清版本
- 轻量级探测：预加载一个 1KB 的空
.txt 文件，记录 fetch().then(performance.now()) 耗时，作为本地 RTT 近似值（注意跨域和缓存）
- 服务端注入：通过 SSR 或 Edge Function 在 HTML 中写入
window.__NETWORK_HINT = { rtt: 120, downlink: 7.2 }，比客户端采集更及时
performance.getEntriesByType('navigation')[0].domContentLoadedEventEnd 估算首屏加载质量：> 3000ms 可视为弱网，触发降级document.readyState 和图像 load 事件超时（如首张关键图 > 5s 未加载），动态切换 img.src 为低清版本.txt 文件，记录 fetch().then(performance.now()) 耗时，作为本地 RTT 近似值（注意跨域和缓存）window.__NETWORK_HINT = { rtt: 120, downlink: 7.2 }，比客户端采集更及时真正难处理的不是“怎么拿到 RTT”，而是如何让降级行为不破坏用户体验：比如切换高清图时避免白屏、视频切档时不卡顿、WebP 回退到 JPEG 时不重排布局。这些细节比 RTT 本身更消耗调试时间。
