javascript - 用于 http 传输的 html/js/css/jpg/png 的推荐文件大小范围

Question

在优化网站时，我使用连接和 spriting 将相关的、可重用的位组合在一起，但我经常想知道打包多少 Assets 以交付给浏览器(有时自动化工具并不总是我的一部分构建过程，尽管我更喜欢它们)。

我很好奇在组合 Assets 以交付给浏览器时，是否仅在文件大小方面有一些明智的指导方针。假设没有压缩或缓存，只是使用或不使用 AJAX 从服务器到浏览器的直接 http 传输。

1. 推荐的最大最小文件大小是多少？
   我听说，由于数据包大小(对吗？如果不当，请道歉)，1kb 和 2kb 的数据将以基本相同的速度传输 - 是否有一个以 kb 为单位的一般阈值，额外的字节开始影响传输速率.

2. 传输速度是随文件大小线性变化，还是阶梯式变化？
   延伸第一个问题，每千字节是否以相当线性的方式增加传输速度？或者它是否以数据包大小的间隔步进(同样，可能是不恰当的单词选择)？

3. 是否有最大尺寸
   同样，我知道有很多上下文推理会影响这一点，但是否有文件大小在当前网络、浏览器的情况下过大，或者它是否严重依赖于服务器和网络？如果有一个很好的概括，那就是我所好奇的。

这可能不言而喻，但我不是服务器/网络专家，只是寻找一些合理的默认值来指导 Assets 优化的快速决策的前端开发人员。

Answer 1

这真的取决于服务器、网络和客户端。

使用常识，这是基本的答案:不要尝试发送几兆字节的位图，否则页面的加载时间将与该人试图下载任何其他几兆字节的文件一样长。另一方面，单个页面上的一堆 PNG 对大多数现代用户来说并不会真正引起注意。在比您要求更多的计算领域，不要滥用 iframe 将人们重定向到其他网页的几个步骤。

如果您想了解有关实际传输的更多信息，单个 TCP 数据包的最大大小在技术上是 64kB，但您实际上不会在单个数据包中发送超过 1.5kB 的数据。但是，TCP 是基于流的，因此数据包大小几乎无关紧要。您应该更关心现代机器的带宽，考虑到我们现在视频 Assets 流的效率如何，我真的认为您不应该过分担心向您的用户提供未压缩的 Assets 。

由于实际交付错误(必须通过 TCP 纠正)的相对频率较低，而且相对于大多数现代网页的大小而言，数据包的大小很小，因此交付时间的增加几乎与总时间成线性关系大小(同样，就像一个巨大的文件)。我省略了有关多阶段网页交付的一些详细信息，但当您交付高 Assets 数量的网页时，它们大多会被忽略。

编辑:为了解决您对传输实际 html/js 文件的担忧(在标题中)，它们只是传输中的文本。浏览器为您完成所有渲染和代码运行。如果您只有一个 jpg，它会盖过页面上的任何 html/js。

传输大小:maximum packet size for a TCP connection

http 流程(粗略查看):http://www.http.header.free.fr/http.html

基本上，当您获得表示整个页面的主要 html 文档(来自您访问页面的初始请求)时，您解析指定为图像或脚本的其他 URL，并从服务器请求这些 URL 以进行传送到你的 session 。链接的页面很旧但仍然相关，并且(我希望)易于理解。

如果您想要现代用户的实际带宽统计数据，我可能无法追踪。但如果您需要更多技术信息，维基百科关于 HTTP 和 TCP 的页面非常棒。