用JavaScript测量客户端到服务器的网速，核心思路是向服务器发起一个已知大小的资源请求，记录下载耗时，再通过“资源大小÷耗时”算出带宽；延迟则通过轻量请求的往返时间（RTT）估算。这套逻辑不依赖任何第三方库，纯浏览器原生API就能实现，但想测得准，得处理好缓存、并发和浏览器限制这几个坑，下面直接拆解可落地的方案和代码。
为什么前端需要自己测网速
服务端日志能看到请求量,但看不到用户屏幕前的真实感受，一个用户打开页面用了8秒，可能是网络差，也可能是DNS解析慢，甚至是他电脑开了几十个浏览器标签页，前端主动测速，核心价值在于把“网络质量”这个变量从用户体验里剥离出来。
典型的应用场景包括：视频网站根据实时带宽自动切换清晰度；在线教育平台在用户网络抖动时提示切换音频模式；云办公系统在弱网环境下自动关闭非核心资源的预加载，这些动作的前提，都是得先有一个实时、可用的网速数据。
前端测网速的三个核心指标
下行带宽（下载速度）
衡量单位时间内能从服务器拉到多少数据，单位是Mbps或MB/s，这是用户感知最强的指标，加载视频卡不卡、图片转圈快不快，都由它决定。网络延迟（RTT）
数据包从客户端到服务器再返回的往返时间，单位毫秒，延迟高会导致操作“发出去没反应”，比如游戏中的技能施放延迟，在线文档输入字符后滞后显示。抖动
多次延迟测量值的离散程度，延迟稳定但数值高，体验尚可；延迟忽高忽低，就会表现为视频通话卡顿、语音断续。基于XMLHttpRequest的图片探测法
这是最经典、兼容性最好的方案，原理是请求一张预先知道体积的图片文件，通过onprogress事件监听到达的字节数，或者干脆用onload算总耗时。
// 准备一张体积约200KB的图片，放到服务器同目录下
const imageUrl = '/speedtest/test.jpg?t=' + Date.now(); // 加时间戳防缓存
const startTime = performance.now();
const img = new Image();
img.onload = () => {
const endTime = performance.now();
const duration = (endTime - startTime) / 1000; // 秒
// 假设图片大小为204800字节
const speedBps = (204800 * 8) / duration; // bit/s
const speedMbps = speedBps / (1024 * 1024);
console.log(`当前下行带宽：${speedMbps.toFixed(2)} Mbps`);
};
img.onerror = () => {
console.error('测速图片加载失败，请检查服务器路径');
};
img.src = imageUrl;
这个方法有两个隐患,一是图片体积是“假设”的，如果CDN压缩或服务器实际返回了不同体积，结果就失真；二是new Image()走的是浏览器自身资源加载通道，可能受HTTP缓存、Service Worker拦截等影响，更稳妥的做法是用fetch()手动控制请求头，并用Content-Length头获取真实体积。
推荐改用fetch实现（支持现代浏览器）
async function measureDownloadSpeed(url) {
// 禁用缓存，确保拿到的是真实网络传输
const response = await fetch(url + '?t=' + Date.now(), {
cache: 'no-store',
mode: 'cors',
});
const contentLength = response.headers.get('Content-Length');
if (!contentLength) {
throw new Error('服务器未返回Content-Length头，无法计算带宽');
}
const totalBytes = parseInt(contentLength, 10);
const startTime = performance.now();
const reader = response.body.getReader();
let receivedBytes = 0;
while (true) {
const { done, value } = await reader.read();
if (done) break;
receivedBytes += value.length;
// 这里可以实时计算瞬时速度
const elapsed = (performance.now() - startTime) / 1000;
const instantSpeed = (receivedBytes * 8) / elapsed / (1024 * 1024);
console.log(`瞬时速度：${instantSpeed.toFixed(2)} Mbps`);
}
const totalTime = (performance.now() - startTime) / 1000;
const averageSpeedMbps = (totalBytes * 8) / totalTime / (1024 * 1024);
return { averageSpeedMbps, totalBytes, totalTime };
}
用fetch的好处是能直接拿到Content-Length头，并且通过ReadableStream（response.body.getReader()）可以监控下载进度，为实时速度曲线的绘制提供数据。
基于WebSocket的精准测速法
HTTP方案适合测“页面资源加载”场景，但如果你做的是实时通信类应用（视频会议、在线游戏），WebSocket的测速结果更贴近真实用户感知。
原理是客户端向服务端发送一条指令,服务端收到后立即推送一段固定大小的二进制数据（比如2MB的随机字节），客户端记录收到完整数据所需的时间。
const ws = new WebSocket('wss://your-server.com/speedtest');
const testPayloadSize = 2 * 1024 * 1024; // 2MB
ws.onopen = () => {
ws.send(JSON.stringify({ action: 'startTest', size: testPayloadSize }));
};
ws.onmessage = (event) => {
if (event.data instanceof Blob) {
const startTime = performance.now();
event.data.arrayBuffer().then(() => {
const duration = (performance.now() - startTime) / 1000;
const speedMbps = (testPayloadSize * 8) / duration / (1024 * 1024);
console.log(`WebSocket下行速度：${speedMbps.toFixed(2)} Mbps`);
ws.close();
});
}
};
服务端需要配合实现：收到startTest后，生成指定字节大小的二进制帧（可用Buffer.alloc填充随机数），一次性或分块发送。
WebSocket方案的优势与局限
优势在于：
- 能同时测上行和下行（上行需要客户端发数据给服务端）
- 模拟的是长连接场景,更贴近实时通信应用的真实体验
- 不受HTTP缓存机制干扰
局限在于：浏览器对WebSocket单帧大小有限制（Chrome最大约2GB），且服务端需要额外开发，如果只是给运营看个参考数据，用图片探测法就足够了。
通过Performance API读取浏览器自带数据
如果不想自己写探测逻辑,可以直接用PerformanceResourceTiming接口，读取页面所有已加载资源的耗时详情，这个方法零请求开销，适合做被动监控。
// 监听资源加载完成事件
window.addEventListener('load', () => {
const resources = performance.getEntriesByType('resource');
const targetResource = resources.find(r => r.name.includes('test.jpg'));
if (targetResource) {
// 关键指标：传输时间（不含DNS、TCP握手等环节）
const transferTime = targetResource.transferSize / 8; // 字节转比特
const duration = targetResource.duration / 1000; // 毫秒转秒
const speedMbps = transferTime / duration / (1024 * 1024);
console.log(`浏览器实测下载速度：${speedMbps.toFixed(2)} Mbps`);
}
});
PerformanceResourceTiming能拆解出DNS查询时间、TCP连接时间、TLS握手时间、请求发送时间、响应接收时间等详细指标，这对于分析“慢”的具体瓶颈非常有价值——是DNS解析慢了，还是网络传输本身带宽不足，一目了然。
计算上行带宽（上传速度）的常见做法
下行带宽决定了你能多快获取数据,上传带宽则影响你发送数据的速度，比如发邮件附件、上传视频、云端备份，测上行带宽比下行难，因为需要客户端主动生成数据发给服务器，并让服务器反馈收到多少。
常见做法是向服务器发送一段固定大小的数据（比如1MB随机字符串），服务端记录接收到的字节数和时间，再返回给客户端计算结果。
async function measureUploadSpeed(url) {
// 生成1MB随机数据（注意：字符串占用的字节数与编码有关）
const uploadData = new Uint8Array(1024 * 1024); // 1MB
for (let i = 0; i < uploadData.length; i++) {
uploadData[i] = Math.floor(Math.random() * 256);
}
const startTime = performance.now();
const response = await fetch(url, {
method: 'POST',
body: uploadData, // 传Uint8Array会作为二进制发送
});
const endTime = performance.now();
const duration = (endTime - startTime) / 1000;
const speedMbps = (uploadData.length * 8) / duration / (1024 * 1024);
console.log(`上行带宽：${speedMbps.toFixed(2)} Mbps`);
return speedMbps;
}
服务端要做的验证是,接收完请求体后，检查Content-Length头与收到的字节数是否一致，再将实际接收到的字节数放进响应体返回给客户端，用于计算真实速度。
影响测速准确性的关键因素
浏览器HTTP并发连接数限制
Chrome对同一域名的HTTP/1.1并发连接数限制为6个，如果你同时发起多个测速请求，它们会排队，导致测出来的速度远低于实际带宽，解决办法是使用HTTP/2（多路复用不受此限制），或者确保测速时只有单个请求在运行，如果用HTTP/2测试，需要注意服务器端是否开启了多路复用支持，部分廉价虚拟主机的HTTP/2并未真正生效。
测试资源体积的选择
- 测100Mbps以上的高带宽：需要至少5MB的测试文件，否则传输瞬间就完成了，计时误差太大
- 测10Mbps以下窄带：200KB就够，用大文件反而会增加等待感，用户容易失去耐心
- 移动端建议分两档测：先用小文件快速测出初始速度，再据此前向加载大文件精细测量
网络拥塞与多轮测试
单次测试结果只能反映瞬间状态,宽带网络的带宽是动态分配的，高峰期和凌晨测出来的数据可能差好几倍，合理做法是连续测3-5次，取中位数作为参考，测速代码里的startTime一定要在await fetch()之前获取，如果在fetch内部写会导致初始化延迟被计入，测出的速度偏低。
HTTPS与HTTP的区别
如果页面是HTTPS,测速请求也必须走HTTPS，否则浏览器会阻止混合内容，TLS握手本身会消耗一定时间，在计算带宽时建议直接用PerformanceResourceTiming里的transferStart和transferEnd，剔除握手耗时，只算纯传输时间。
测速功能上线到生产环境的注意事项
别用免费公共测速文件
很多教程会让你用speedtest.net或者某些公共图片链接做测试资源，这个做法在生产环境是不可取的，公共资源的服务器不在你的控制范围内，它的负载状况会直接影响你的测速结果，而且一旦资源被移除或限流，你的功能就失效了。
正确做法是：在自己服务器或CDN上放一个固定体积的文件（建议放到独立子域名下，比如speed.yourdomain.com），并配置响应头Cache-Control: no-store确保不被缓存，同时记录服务端的日志，定期检查该文件的下载耗时是否异常（比如CDN回源波动），避免结果失真。
带宽测试资源占资源问题
一个2MB的测试文件,如果同时有1000个用户触发测速，就会产生2GB的流量消耗，这在地域性CDN上的费用成本相当可观，建议操作：
- 设置测速操作冷却时间（比如同一IP 10分钟内最多测2次）
- 把测试文件压缩到最小可用体积
- 仅在用户主动点击“测速”按钮时才触发，不做页面自动测速
这些运营层面的配套设施,直接影响着测速功能可持续运行的成本，服务器带宽成本并不是静止的，它像水费电费一样，随规模递增，若你的站点需要长期稳定地提供测速服务，就需要一个能扛突发流量、带宽资源充足的服务器底座，以国内资源较为充沛的机房服务商为例，酷番云（增值电信业务经营许可证覆盖IDC/CDN/ISP三类业务）提供的高带宽云服务器，在应对百人同时测速的场景时，仍能保持测速数据的稳定性和准确性，其持牌自营机房的带宽储备明显优于转租型服务商。
测速结果的展示与异常处理
将计算结果转成可理解的文案
不要直接把“12.35 Mbps”甩给用户看，普通人没有这个概念，通用的换算逻辑是：
- 低于2Mbps：建议用户切换至省流量模式，停止视频自动播放，适合仅提供文本页面
- 2-5Mbps：标准清晰度视频可流畅播放，但大型图片较多时会有明显等待感
- 5-20Mbps：高清视频无压力，属于家用宽带的常见带宽范围
- 20Mbps以上：4K视频、大文件下载都不在话下，用户体验良好
超时与异常的处理
// 测速请求超时兜底，防页面长时间无响应
function withTimeout(promise, timeoutMs = 10000) {
return Promise.race([
promise,
new Promise((_, reject) => {
setTimeout(() => reject(new Error('测速超时')), timeoutMs);
}),
]);
}
// 使用示例
const speedData = await withTimeout(measureDownloadSpeed('/speedtest/5mb.bin'), 15000);
超时的原因通常是用户网络极不稳定,或设备进入了省电模式限制了请求并发，此时应给出友好提示，而不是报一个“测速失败”的冷冰冰错误，可以把测速过程做成三步走：先测延迟（发一个几十字节的小请求），通得过再测下载，防止在网络极差的状况下让用户等太久。
网友评论