单一.js文件与延迟加载

Question

场景:您正在构建一个大型的javascript驱动的web应用程序，在那里您需要尽可能少的页面刷新。想象一下80-100 to的无限制的javascript，只是为了有一个数字来定义"large“。

我的假设是，如果您延迟加载您的javascript文件，您可以在加载时间上获得更好的平衡(这意味着，您不必在每次刷新页面时等待几秒钟)，希望这样会导致用户在加载过程中没有真正注意到延迟。我猜想，在这样的场景中，延迟加载将比典型的小型化.js文件更受欢迎。

现在，理论上，无论文件大小如何，对给定服务器上的任何文件的请求都有固定的成本。因此，太多的要求是不可取的。例如，如果一个小型javascript文件与其他10个中小型文件同时加载，则最好将它们组合在一起，以节省多个请求的成本。

我的问题是，假设有合理的缺省值(假设客户端有一个3-5 5Mbps的连接和一个像样的硬件)，那么--一个文件的理想大小是什么？太大了，而且一次加载太多了；太小了，并且请求的成本变得比您返回的数据量更昂贵，从而减少了数据的第二个经济。

编辑：所有的答案都很棒。我之所以选择本的是因为他给出了一个具体的数字。

Answer 1

我会尝试将显示页面所需的数量(即使只是加载指示符)保持在300 K以下。在此之后，我会一次以高达5MB的块提取更多的数据，并显示一个加载指示符(可能是进度条)。我在咖啡店的宽带wifi上下载了15 OK的失败，否则似乎没问题。如果<5MB下载失败已经够糟糕的话，我可能不会因为网站不工作而责怪它。

我还会考虑一次下载两个文件，超过初始的<300K文件，使用像LabJS或HeadJS这样的加载器以编程方式添加脚本标记。

Answer 2

谷歌的“页面速度计划”()详细介绍了这一点：

intro.html

特指http://code.google.com/speed/page-speed/docs/payload.html

Answer 3

我认为很明显，让客户机在做任何事情之前下载超过一MB的js是不好的。而且，让客户下载更多的东西是必要的，也是不好的。但有一个明显的好处，让所有的缓存。

影响数字的因素：

1. 往返时间
2. 服务器响应时间
3. 标题大小(包括cookie)
4. 缓存技术
5. 浏览器(见http://browserscope.com)

平衡并行下载和不同的缓存需求也是需要担心的因素。凯尔辛普森最近对此进行了部分报道：装载机/c29wza 8