navigator.connection.effectiveType 提供基于 RTT 和吞吐量的网速类型（slow-2g/2g/3g/4g），需 HTTPS/localhost 环境且兼容性有限，应配合 onchange 监听与 class 切换实现资源分级加载。
用 navigator.connection.effectiveType 判断当前网速类型
浏览器原生支持的网络质量探测，比单纯查 window.innerWidth 更贴近真实体验。它返回 "slow-2g"、"2g"、"3g"、"4g" 四种值，不是带宽数字，而是基于 RTT 和下行吞吐量的综合分类。
注意：该 API 仅在 HTTPS 或 localhost 下可用；部分安卓 WebView 和旧版 Safari 不支持。
- 检查前先判断是否存在：
if ('connection' in navigator && navigator.connection && 'effectiveType' in navigator.connection) - 不要直接依赖
navigator.connection.downlink（单位 Mbps），它在 iOS 上长期返回0或不更新 - 首次获取可能延迟几百毫秒，不适合做首屏关键 CSS 的同步切换
CSS 中如何按网速加载不同资源
纯 CSS 无法主动读取 navigator.connection，必须靠 JS 驱动：根据 effectiveType 给 <html> 加 class，再用 CSS 选择器区分样式。
例如：
立即学习 “ 前端免费学习笔记（深入）”；
document.documentElement.classList.add(`net-${navigator.connection.effectiveType}`);对应 CSS 就可以写：
.net-slow-2g img {content: url(/img/avatar-low.jpg); } .net-4g img {content: url(/img/avatar-high.jpg); }-
content替换图片仅适用于伪元素（::before/::after），普通<img>标签得用 JS 换src - 慎用
prefers-reduced-data媒体查询——它反映用户设置，和实际网速无关，两者不能混用 - 服务端做适配更可靠（如通过
Sec-CH-ECT请求头），但需要后端配合，前端单独做只能打辅助
避免“网速切换”引发的布局抖动
图片尺寸突变、字体加载延迟、背景图重绘，都可能让页面跳动。核心是提前预留空间、控制加载节奏。
- 所有响应式图片必须设固定宽高或
aspect-ratio，否则低网速下占位塌陷 - 用
loading="lazy"+decoding="async"配合网速 class 控制懒加载阈值（比如net-slow-2g下设loading="eager"） - 字体建议只在
net-4g下加载非系统字体，其余情况回退到system-ui，避免 FOIT/FOUT 叠加网络延迟
真机测试时最常被忽略的点
开发工具里的“Network Throttling”模拟的是带宽和延迟，但不会触发 navigator.connection.effectiveType 改变——Chrome DevTools 需手动勾选“Throttle connection type”才会同步更新该字段。
- iOS Safari 永远返回
"4g"，哪怕你在地铁隧道里；别把它当真实依据 - 某些 Android 定制 ROM 会屏蔽
connectionAPI，降级方案得 fallback 到 UA + 屏幕密度 + 首屏渲染耗时估算 - 用户切 WiFi/ 移动网络时，
effectiveType不会自动触发事件，需监听navigator.connection.onchange并重新应用逻辑
网速感知不是开关，是连续谱；能做的只是分段妥协。真正卡顿往往不在判断本身，而在后续资源加载没对齐这个判断节奏。
