navigator.connection 提供的是启发式网络等级而非精确带宽,需结合 downlink、savedata 及加载失败兜底才能准确适配弱网;ios 全系 effectivetype 恒为 unknown,必须依赖轮询 downlink 和 onerror 降级。

navigator.connection 能拿到的不是“精确带宽”,而是浏览器基于 rtt 和 downlink 估算出的启发式网络等级(effectiveType),直接拿它当 Mbps 切图会误判。必须结合 downlink 数值、saveData 开关和加载失败兜底,才能真正适配弱网。
判断 navigator.connection 是否可用并读取基础字段
先检查 API 是否存在,再取值——navigator.connection 在 Safari 桌面版、部分旧 Android WebView 中不可用,且 effectiveType 在 iOS 全系始终返回 unknown。
实际检测逻辑要写成:
const connection = navigator.connection ||
navigator.mozConnection ||
navigator.webkitConnection;
<p>if (!connection || !('effectiveType' in connection)) {
// 降级为 navigator.onLine + 定时 fetch 测速
return 'unknown';
}</p><p>// 这三个字段才是关键决策依据
const effectiveType = connection.effectiveType; // '4g', '3g', '2g', 'slow-2g'
const downlink = connection.downlink; // number, 单位 Mbps,可能为 undefined
const saveData = connection.saveData; // boolean,用户是否开了省流模式</p>
注意:downlink 在 Chrome 100+ 才稳定返回,Firefox 仍常为 undefined;saveData 一旦为 true,应无条件切最低清资源,比 effectiveType 优先级更高。
按 effectiveType + downlink 组合决定图片清晰度策略
只看 effectiveType 容易翻车:比如 effectiveType === '4g' 但 downlink === 0.8(实为拥堵 Wi-Fi),或 effectiveType === '3g' 但 downlink === 12(高速 5G 覆盖区)。必须做交叉判断。
- 如果
saveData === true→ 强制使用320w.webp?q=30,忽略其他字段 - 如果
effectiveType === 'slow-2g' || effectiveType === '2g'→ 用320w.webp?q=40,禁用懒加载 - 如果
effectiveType === '3g' && downlink → 用 <code>750w.webp?q=50 - 如果
effectiveType === '3g' && downlink >= 2或effectiveType === '4g'→ 用1080w.webp?q=70 - 如果
effectiveType === 'unknown'或downlink未定义 → 回退到750w.jpg(兼容性兜底)
监听 change 事件但别全信它
connection.addEventListener('change') 触发不及时,也不保证每次带宽波动都通知。实测中,从 4G 掉到 3G 可能延迟 8–12 秒,高丢包场景下甚至根本不触发。
稳妥做法是:
- 首次加载用当前
connection值决策 - 启动一个
setInterval(() => { /* 重读 downlink / effectiveType */ }, 5000),每 5 秒轮询一次 - 对轮询结果加防抖:连续 2 次读到
downlink 才认为进入弱网,避免抖动误判 - 不做实时切换已渲染图片,只影响后续新
<img>的src设置
必须搭配 onerror 和超时控制做最终兜底
Network API 是估算,真实链路可能因 DNS、CDN、服务器拥塞而远差于预期。一张图加载超过 3 秒没响应,或触发 onerror,就得立刻降级。
示例逻辑片段:
function loadImgWithFallback(img, src) {
const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), 3000);
<p>fetch(src, { signal: controller.signal })
.then(res => {
if (res.ok) {
img.src = src;
} else {
throw new Error(<code>HTTP ${res.status}</code>);
}
})
.catch(() => {
const fallbackSrc = getLowQualitySrc(src); // 如加 ?q=30&w=320
if (!img.dataset.attemptedFallback) {
img.dataset.attemptedFallback = '1';
loadImgWithFallback(img, fallbackSrc);
} else {
img.src = '/placeholder.svg'; // 不再重试
}
})
.finally(() => clearTimeout(timeoutId));
}</p>
重点:单张图最多降级 1 次,否则容易陷入“越切越糊→越失败→再切”的死循环;AbortController 要配 fetch,不能只靠 <img> 的 onload/onerror——后者无法感知卡在 DNS 或 TLS 握手阶段的请求。
最易被忽略的是:iOS Safari 完全不支持 connection.change 事件,且 effectiveType 永远是 unknown,所以轮询 + downlink + onerror 这套组合拳,在 iOS 上反而是主力判断方式。










