Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

按需加载+合并请求

  在很多大型项目中,为了节省请求数会把可以合并的资源都合并在一起加载。而且,现在的各种先进工具已经包揽了这些工作,省去了手动合并压缩的麻烦。但这样真的有必要吗?实际上一个大项目中JS代码量是非常庞大的,合并加载可能影响首次用户体验。
  把资源合并起来加载会造成单次加载的数据量增大,从而增加单次加载的耗时。这些合并在一起的资源只有等到整个合并后的资源加载完成后才能被使用,这比起传统加载模式的加载一个使用一个,其使用时间显然要更晚一些。如果真的使用这种合并资源的形式加载,我觉得应该为其加载过程添加一个可靠的进度条,以免用户认为页面打不开而过早关闭。
  不过比起这种合并加载的方案,我更喜欢按需加载。当然,在以前的文章中也讨论过合并请求和按需加载的选择问题,当时提供的方案是以页面跳出率为依据来选择加载方式。但我现在觉得,按需加载之后在客户端的网络空闲时期再继续加载其它资源也许会更科学。以页面跳出率作为判断会受到用户基数的影响,如果用户量本身就很少,跳出率的统计可能会不准确。而要是用户量多的话,即使只有1%的用户没有跳出,这1%也是个庞大的数字。
  按需加载的目的是让页面不加载暂时当前用不到的资源,因为这样可以腾出带宽和连接去加载更急用的资源。对,我们的目的是以最快的速度加载最紧急的资源。所以按需加载能够让用户更快看到结果,让用户觉得页面打开的更快。但如果仅此而已的话,用户可以在某些操作时由于资源没有加载齐全而临时去加载,从而让操作产生等待现象,影响用户体验。只要解决掉这个问题,对于前端而言,按需加载就完胜合并请求。但合并请求的目的毕竟主要为了缓解后端的请求处理压力,这是按需加载很难做到的方面。
  我更希望能对前端优化,做出更好的用户体验,而服务器多处理一些请求又何妨呢?所以我提倡默认采用按需加载,并且在所有必要的资源加载完成后开始加载不紧急的资源,以便用户操作时不再临时加载。当然,这些不紧急的资源还可以考虑使用合并请求来加载。
  我是不是越说越绕了?按需加载和合并加载虽然是完全相反的两个东西,但有时候不仅是选择其中一种加载方式,而是要根据项目的需求斟酌损益,适当的使用它们,甚至可以两种加载方式同时用于一个页面中。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^