为什么chrome和firefox在下载一个超小的javascript文件时比curl慢10倍？

我在一个web应用程序上工作，在这个应用程序中，开发环境从本地web服务器加载了大约500个js文件（我尝试了IIS和apache）。这些文件在prod中进行了优化，但对于开发，这就是我们所拥有的。我知道还有其他一些策略选项可以避免加载这么多js文件，但这是我目前无法控制的。我想做的是加速这些请求。我是否疯狂地认为每个请求只需要10毫秒，所以整个请求需要5秒（10毫秒*500个请求）？目前，chrome和firefox都报告说，这些请求大约需要100毫秒（甚至304秒）

我将其降到最小公分母，并创建了一个1行js文件。我通过firefox和chrome向这个文件发出请求，每个报告都需要>100毫秒。但奇怪的是，当我从curl发出相同的请求时，只需要5毫秒：

$ curl 'http://10.222.139.56:81/js/ben.js' -o /dev/null -w '%{time_total}'
0.005

---

有什么好处？我认为卷曲数是正确的？为什么chrome和firefox要花更长的时间？

我的猜测是，对于firefox和chrome加载的每个js文件，报告的时间包括浏览器解析、缓存文件等。即使是一行程序文件也需要少量的工作来处理。

---

另一方面，curl只是将内容拉下来并保存到磁盘或标准输出。这个操作要快得多。

对我来说答案很简单：cookies

在作为“Content-Type:application/json”的单个json文件上，Chrome的网络标签始终显示约1400ms，而curl显示约300ms（即使设置了浏览器用户代理）。浏览器应该不需要解析这个，因为我禁用了漂亮的打印插件，并在Chrome的开发工具中签入了“禁用缓存”

---

最后，我在一个不知名的窗口中尝试了它，并看到了与Curl相同的时间结果。然后，我回到原来的窗口，删除了cookies，没有其他内容，并且获得了相同的速度提升。我终于意识到，我的web应用程序在对另一个服务的请求中使用了一个特定的身份验证cookie来验证它。

500个JavaScript文件。。。wowAre我们确信FF/Chrome只是对实际下载进行计时，还是包括将其转换为字节码等？我不知道，但这会造成不同。您的本地Web服务器是否从您的本地存储中加载js文件？我刚刚检查了我的，一半的JS文件从缓存（0ms）中取出，一半加载约10ms。“我们确定FF/Chrome只是在计时实际下载”不，这可能是最好的猜测。。。但是你会认为浏览器会报告差异，不是吗？这也是我得到的最好的理论。所以，不管我的响应速度有多快，500个js文件的加载都需要一段时间。。。如果是这样的话，那么同样数量的js打包到一个文件中不会花费同样长的时间吗？（它没有）@andersonbd1我猜这里设置了一些开销，每个文件的开销是固定的。考虑到Chrome在其JS引擎中的自豪感，解析可能只是这100毫秒中的一小部分。其余的可能更多地是缓存、注册文件等。