HTTP Requests vs File Size?之前已经提出了这类问题，但我希望得到更好的答案。在这个相关的问题中，回答者似乎很好地用延迟+传输时间的漂亮公式回答了这个问题，估计延迟为80毫秒，传输速度为5Mb / s。但至少在一个方面似乎存在缺陷。在正常的浏览体验中，多个请求和传输不会同时发生吗？当我检查Chrome中的“网络”标签时，这就是它的样子。这是不是意味着请求延迟不是那么可怕？
还有其他事情需要考虑吗？显然延迟和带宽会有所不同，但80毫秒和5Mb / s是一个很好的经验法则吗？我想到了一个类比，我想知道它是否正确。想象一下火车站只有一个轨道和一个轨道（或者可能是两个轨道）。 Http请求就像发送引擎以在另一个站点获得一堆汽车。他们返回拉长列铁路车辆，代表所下载的文件。所以你可以发送一个引擎并让它带来巨大的负载。或者你可以发送多个引擎，他们每个可以带回较小的负载，当然他们都必须等待轮到他们回到车站。有些引擎在其他引擎进入之前无法发出。这是一个有缺陷的类比吗？
我想那么重要的问题是你如何预测http请求中会有多少重叠，以便你可以知道，例如，在你的页面上有两个大的PNG文件通常是否值得呢？一个webp图像，以及不兼容浏览器的Webpjs js和swf文件。这使请求数量增加了一倍，但总文件大小减少了一半（比如节省了200kB）。
答案 0 :(得分：5)
你的比喻一般来说还不错。显然，如果你想要在所有方面都非常精确，那么就会有过于简单或不正确的事情（但几乎所有类比都会发生这种情况）。
您对80毫秒和5毫升/秒的估计可能听起来合乎逻辑，但即使我们大多数人都喜欢理论，您也应该以另一种方式管理这类问题。
为了做出良好的估算，您应该衡量来获取一些数据并对其进行分析。 每项估算都取决于某些背景，您不应忽视它。
考虑一下3G连接的估计延迟和带宽，日本的ADSL连接或技术较少的国家的ADSL连接。客户是从世界的另一端还是在同一个国家/地区访问？就像你对客户端同时连接的良好观察一样，如果不采取某种措施，就会有数以百万计的问题要问自己，而且很少有高质量的答案。
我知道我没有回答你的问题，因为我认为如果没有关于这个领域的很多细节（加上约束，以及巨大的等等），我就无法回答。
您似乎对如何设计解决方案有一些想法。我最好的建议是实施其中的每一个并对其进行分析。进行测量，尝试确定您的瓶颈是什么，看看您是否对它们有一些控制。
在某些问题中，这类问题可能会有一个最佳解决方案，但最佳和次优之间的差异在实践中可以忽略不计。
答案 1 :(得分：2)
这是我正在寻找的答案。我做了一些简单的测试，以了解许多小文件与一个大文件的速度。
我创建了html页面，从placekitten.com加载了一堆随机大小的图像。我将它们加载到Chrome中，并打开了“网络”标签。
以下是一些结果：
# of imgs Total Size (KB) Time (ms)
1 465 4000, 550
1 307 3000, 800, 350, 550, 400
30 192 1200, 900, 800, 900
30 529 7000, 5000, 6500, 7500
因此需要注意的一件事是，单个文件加载一次后会变得更快。 （逗号分隔的时间列表是页面重新加载）。我做了正常的刷新，还有Empty Cache和Hard Reload。奇怪的是，这似乎与我刷新的方式有很大的不同。
我的连接有延迟或返回时间或大约120-130ms，我的下载速度在4到8Mbps之间变化。 Chrome似乎一次只能处理6个请求。
看看这几个测试，似乎至少在这个文件大小的范围内，当文件大小相等时，显然更好的是减少请求，但是如果你可以将文件大小减半，即使在将http请求数量增加30的费用，这是值得的，至少对于一个新的页面加载。
任何评论或更好的答案都将不胜感激。