场景：您正在构建一个大型的javascript驱动的Web应用程序，您希望尽可能少的页面刷新。想象一下80-100MB的无限制javascript，只是为了有一个数字来定义“大”。
我的假设是，如果你懒加载你的javascript文件，你可以更好地平衡你的加载时间（这意味着，每次页面刷新时你不必等待几秒钟），希望导致用户没有真正注意到加载过程中的滞后。我猜测在这样的场景中，延迟加载比典型的单个缩小.js文件更令人满意。
现在，理论上，无论文件的大小如何，对给定服务器上的任何文件的请求都有固定的成本。因此，太多的请求是不可取的。例如，如果一个小的javascript文件与其他10个小型或中型文件同时加载，最好将它们组合在一起以节省多个请求的成本。
我的问题是，假设合理的默认值（比如客户端有3-5Mbps的连接和一块体面的硬件），要请求的文件的理想大小是什么？太大了，你又回来装了太多东西;太小了，请求的成本变得比你回来的数据量更贵，降低了你的每秒数据。
编辑：所有答案都非常棒。我只选择了Ben，因为他给出了一个具体的数字。
答案 0 :(得分：3)
Google的Page Speed计划详细介绍了这一点：
http://code.google.com/speed/page-speed/docs/rules_intro.html
具体为http://code.google.com/speed/page-speed/docs/payload.html
答案 1 :(得分：2)
我会尝试保持需要加载的金额以显示300K以下的页面（即使只是加载指示符）。之后，我会一次性下载最多5MB的数据块，并显示加载指示符（可能是进度条）。我已经有15MB的下载失败在咖啡店宽带wifi，否则似乎没问题。如果足够糟糕，<5MB下载失败，我可能不会责怪网站不工作。
我还考虑一次下载两个文件，超出初始＆lt; 300K文件，使用LabJS或HeadJS之类的加载器以编程方式添加脚本标记。
答案 2 :(得分：2)
我认为很明显，让客户端下载超过MB的js然后才能做任何事情都是不好的。并且让客户端下载更多不必要的东西也是不好的。但是，将所有内容都缓存起来是一个明显的好处。
影响数字的因素：
平衡并行下载和不同的缓存要求也是需要担心的因素。 Kyle Simpson最近在此部分介绍了这一点：http://www.reddit.com/r/javascript/comments/j7ng4/do_you_use_script_loaders/c29wza8