正在加载...

为了实现脚本加载情况的监控和重试,我们在今年引入了loadjs v1(gzip后300bytes左右)。但是由于loadJS v1会引起simple.js对后面JS的阻塞,故需要对其进行一定的优化。9月,casper对labjs进行了代码阅读和输出loadjs v2。11月,webryan重写loadjs v3(herbert bug fix并上线)。下面分享下,我们在做加载器的整个逻辑分析和判断,主要是对pengyou.com进行分析和yuni等人交流一些seajs使用中会遇到的一些问题(比如:seajs动态加载的话会引起的数据丢失问题)。

 

Seajs Labjs Loadjs V3 Doucment.write
压缩后大小 14.5k 5.4k 1.4k 0k
gzip后 4.7k 2.2k 0.7k 0k
使用团队 Pengyou.com(负责人victor),taobao IM Web Qzone(rizen)
优势
  1. 加载器和模块管理一并支持
  2. 避免了全局变量的污染和可能的覆盖。
  3. 单纯的加载器
  4. 支持多种加载方式。
1.尽力做最简单的加载器

2.支持ie重试逻辑

  1. 极简
  2. 无冗余
劣势
  1. seajs对文件管理方式冲击太大,
  2. 无法避免的导致seajs必须第一个串行加载。
  3. 需要对 seajs未加载下来时,对window.seajs进行hack保存变量和路径(hack提供是由玉伯提供的,见pengyou.com官网)
1、有很多加载场景是不适用于我们,比如xhr获取。 1、功能简单,边缘浏览器尚未全部测试

2、未实现webkit重试逻辑

  1. 不支持重试
  2. 未做变量检查
  3. 做不了准确的js加载时间检测

 

根据上述表格的对比和分析,我们不难发现一下几个结论:

  1. 通常情况下document.write是最优的性能处理的选择(虽然document.write在执行过程中会中止页面的加载情况,但通常在文档的最后端)。在不做监控和重试逻辑情况下,默认应该使用document.write。比如ID.QQ.COM,QZONE.QQ.COM
  2. Document.write+setTimeout可以做一定的监控,但是存在误判。不能做重试逻辑。
  3. 由于seajs对文本模块管理方式的冲突比较大,故我们通常项目性能优化过程中,不会采用seajs的处理方式。同时,及时新项目使用seajs的模块管理方式,我们应该也会更倾向于采用自己写一个简单的加载模块。
  4. 使用库加载会存在一个问题,就是通过内联方式还是外链方式引入。外链方式的好处是可以cache,坏处是会增加第一次加载的请求逻辑阻塞(或者类似seajs的hack);内联方式是会导致load模块每次都需要加载。这里需要综合平衡,没有绝对的好。

: http://www.webryan.net/2012/12/how-to-load-javascript-file/

本文相关评论 - 才 4 条评论
2012-12-09 21:03:59

seajs好像是今年才出来的?

错别字啊

[回复]

ryan 回复:

查了下github,是在2010年12月就诞生了。 错别字? 最近打字是不太注意。

[回复]

2012-12-09 21:55:07

查了下github,是在2010年12月就诞生了。 错别字? 最近打字是不太注意。

[回复]

2012-12-11 23:13:20

headjs 怎么样?

[回复]

ryan 回复:

其实类似加载器非常多,最重要是找到适合自己实际情况的。 headjs看了下功能都差不多,core gzip后是1.4k,loader gzip后是1.6k。 但是它不支持串行加载吧?

[回复]

2012-12-12 14:47:27

其实类似加载器非常多,最重要是找到适合自己实际情况的。 headjs看了下功能都差不多,core gzip后是1.4k,loader gzip后是1.6k。 但是它不支持串行加载吧?

[回复]