47% users on this site use *nix
- 异步、模拟多线程式的JavaScript,防止界面锁死。例如Google Gears,Firefox3.5 WebWorker异步API。
- 拆分JavaScript文件,即需即载入即运行,避免首次载入的高代价。类似dojo的分包机制。
- 普通的script会阻塞页面的载入直至脚本下载执行完成,采用其它方法可以改变这种情况:XHR Evel, XHR Inject, Script DOM, Script Defer, Script in Iframe, Document.write Script Tag。
- 由于外部script和内联代码异步载入造成的冲突,解决方法1. 在外部编码种硬编码回调,2. 在Window.onload中调用 3. 用timer监控载入情况 4.scripttag.onreadystatechange
- 把异步载入外部脚本的方法编写为可复用的module
- 处理内联脚本,解决方法:1.将内联脚本移至页面尾部 2.异步执行JavaScript回调(setTimeout(0)) 3.使用script defer属性 内联脚本执行会被
- 语言级别上提高JavaScript执行效率的一些手段,Zakas
- Comet的前景和现阶段实现,以及WebSocket
- 优化HTML文件
- 优化图片的utilities和几种格式的特点
- sharding文件到不同的服务器上增加并行下载
- 正确地使用flush提高部分页面的加载速度 影响因素1.是否开启了Output_Buffer,2.是否使用了chunked encoding, 3.是否启用了gzip并在apache228上运行 4. 是否被代理和AV软件影响了 5.是否因为相同的域名的文件下载被block了 6.是否是webkit阈值以下不能渲染
- 慎用iframe,DOM操作代价过高,在html中设置src的iframe会阻塞onload,iframe与style script标签的位置
- 高性能的CSS选择器,避免全局rule,避免div#sele,避免div.sele,避免使用长选择器,避免使用decendant选择器,避免使用tag-child选择器,查看所有child选择器,使用继承
避免div#sele,避免div.sele
—————-
这句不明白是什么意思,避免这样写,难道写成 #sele | .sele 之类的?
@小马 对,直接写就可以,尤其是id的那种情况,避免浏览器去找相应类型的元素
是仅指 divi 这个标签?其它的呢,比如 h2.sele 如何
@小马 哦,对所有tag都一样~
我最新的想法是简化主义,尽可能避免任何hack,像ext那样深dom结构模拟web control或者jquery那样模拟的css selector都不是future promise的。我现在觉得理想的js封装方式是这样的:
1 在onreadystatechange中加载一个bootstrap.js。
2 在这个自启动脚本中判断浏览器类型,根据不同浏览器类型下载具体的代码。在编写js时,可以考虑用语言机制来自动生成,比如gwt那种,然后flash develop里支持的一个语言也可以按照要求编译成js,我现在记不清了
3 尽可能不要hack,不要模拟任何东西,客户端看到的应该是input type=”button”这样的封装好的控件,具体的控件实现可以考虑用flash实现,但调用时看到的只有js的接口
4 异步机制的确很重要,我觉得最好有个全局控制点,不然很难维护
5 dojo那种动态加载方式其实得不偿失,js的模块化不需要那么动态,最好事先分解好,然后压缩,具体的应用还是一次性下载完比较好
用户操纵的如果只是控件级别的api,而不是各种各样的层,那么以后html5普及了,在库的内部替换为html5原生控件就可以了,否则就用flash组件来实现,这样的效率必然是最高的。
层还是用来做它最擅长的事-布局吧
我现在觉得特性的简单性非常重要,如果一个特性可以节省10行代码,但是需要多研究10个小时,或者增加10%的出错概率,那还是不使用这样的特性为好
@axel 嗯,你应该写一篇然后trackback过来~