JS Ajax测速与fast.com结果差异原因及脚本合理性问询

差异原因 #

• 测试资源与节点的差距：fast.com、Ookla这类专业服务用的是遍布全球的CDN节点，会自动选离你最近、链路最优的节点，而且测试用的是专门准备的大体积静态文件（动辄几百MB甚至GB级），能直接占满你的带宽上限。你在google.com控制台跑的脚本，只能请求google的普通页面资源，这些资源体积小，就算google服务器再快，也没法让你的带宽跑满，测出来的自然不是真实网速。
• 测试逻辑的复杂度不同：专业测速不会只发一次请求，而是会开多个并发请求模拟真实下载场景，同时还会测试上传速度（你的脚本只做了GET下载请求），另外会剔除网络抖动、临时丢包的干扰，取多次测试的峰值或平均值。你的脚本只做单次请求，结果受当时网络波动影响极大，偶然性太强。
• 浏览器环境的限制：浏览器对单域名的并发请求数有上限，而且Ajax请求的计时精度（比如Date.now()）不如专业工具的底层计时。专业测速工具很多是基于底层网络库实现，能绕过浏览器的部分网络栈开销，而你的脚本完全依赖浏览器的XMLHttpRequest/fetch API，这些API本身有额外的处理耗时。
• CORS规避带来的局限：为了绕CORS你只能在google.com页面请求同域资源，没法使用专业测速用的大体积测速专属资源，这直接导致测试场景不符合带宽测速的基本要求，结果偏差必然极大。

你的JS测速脚本是否合理？ #

仅用来做简单的网络连通性验证、单请求延迟测试的话，勉强能用，但完全不能作为准确的带宽测速工具。

脚本里“加随机参数避免缓存、计算请求耗时和资源大小”的核心逻辑本身没毛病，但缺少专业测速的关键环节：多并发请求、大体积测试资源、多节点选择、上传测速、多次采样优化。再加上受CORS限制只能请求小体积同域资源，根本无法触发带宽饱和，测出的只是单个请求的瞬时速度，不是你的真实最大带宽。

内容的提问来源于stack exchange，提问作者user20537415