场景：您正在构建一个大型的javascript驱动的Web应用程序,您希望尽可能少的页面刷新.想象一下80-100MB的无限制javascript,只是为了有一个数字来定义“大”.
我的假设是,如果你懒加载你的javascript文件,你可以更好地平衡你的加载时间(意思是,你不必每次页面刷新时等待几秒钟),希望导致用户没有真正注意到装载时滞后.我猜测在这样的场景中,延迟加载比典型的单个缩小的.js文件更令人满意.
现在,理论上,无论文件的大小如何,对给定服务器上的任何文件的请求都有固定的成本.因此,太多的请求是不可取的.例如,如果一个小的javascript文件与其他10个小型或中型文件同时加载,最好将它们组合在一起以节省多个请求的成本.
我的问题是,假设合理的默认值(比如客户端有3-5Mbps的连接和一块体面的硬件),请求的文件的理想大小是多少？太大了,你一次又回来装载太多了;太小了,请求的成本变得比您回来的数据量更高,从而降低了每秒数据的经济性.
编辑：所有答案都很棒.我只选择了Ben,因为他给出了一个特定的号码.
解决方法:
我会尝试保持需要加载的金额以显示300K以下的页面(即使只是加载指示器).之后,我会一次性下载最多5MB的数据块,并显示加载指示符(可能是进度条).我已经有15MB的下载失败在咖啡店宽带wifi,否则似乎没问题.如果足够糟糕,<5MB下载失败,我可能不会责怪网站不工作. 我还会考虑一次下载两个文件,超过初始< 300K文件,使用像LabJS或HeadJS这样的加载程序以编程方式添加脚本标记.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
