ホームページ >ウェブフロントエンド >htmlチュートリアル >Alibaba 技術記事の共有: ワイヤレス パフォーマンスの最適化: ページの表示時間と非同期読み込み_html/css_WEB-ITnose
特にワイヤレス環境において、ページをできるだけ早くレンダリングし、ページをより早く表示し、白画面時間を短縮する方法は、常にパフォーマンス最適化のトピックです。
ページは次のプロセスを通じて表示されます:
layout
JSはいつでもDOMやCSSOMを変更する可能性があるため、すぐに実行したいページ内に大量のJSがある場合、ブラウザがダウンロードして実行します。 CSSOM のダウンロードが完了するまでは、待機中に DOM ビルドもブロックされます。 JS が DOM と CSSDOM の構築をブロックせず、最初の画面の表示時間に影響を与えないように、いくつかの JS 読み込み戦略がページの表示に与える影響をテストします。
C. document.write: 過去の PC 最適化ではほとんど使用されなかった JS の非同期ロードの戦略: DEMO アドレス
function injectWrite(src){ document.write('<script src="' + src + '"></sc' + 'ript>');} |
D. getScript: の形式 以下は、KISSY 内の getScript 関数の簡単な実装です: デモアドレス
<script> var script = document.createElement('script'); script.src = "//g.tbcdn.com/xx.js"; document.getElementsByTagName('head')[0].appendChild(script);</script> |
E. 非同期属性を追加します: DEMO アドレス
以下の domReady は DOMContentLoaded イベントと同じです。
A (head script) | B (bottom script) | C (document.write) | D (getScript) | E (async) | F (defer) | G (async + defer) | ||
---|---|---|---|---|---|---|---|---|
1 | PC Chrome | 页面白屏长、domReady:5902.545、onLoad:5931.48 | 页面先显示、domReady:5805.21、onLoad:5838.255 | 页面先显示、domReady:5917.95、onLoad:5949.30 | 页面先显示、domReady:244.41、onLoad:5857.645 | 页面先显示、domReady:567.01、onLoad:5709.33 | 页面先显示、domReady:5812.12、onLoad:5845.6 | 页面先显示、domReady:576.12、onLoad:5743.79 |
2 | iOS Safari | 页面白屏长、domReady:6130、onLoad:6268.41 | 页面白屏长、domReady:5175.80、onLoad:5182.75 | 页面白屏长、domReady:5617.645、onLoad:5622.115 | 502s 白屏然后页面显示最后变更 load finish 时间、domReady:502.71、onLoad:6032.95 | 508s 白屏然后页面显示最后变更 load finish time domReady:508.95、onLoad:5538.135 | 页面白屏长、domReady:5178.98、onLoad:5193.58 | 556s 白屏然后页面显示最后变更 load finish 时间、domReady:556、onLoad:5171.95 |
3 | iOS 手淘 WebView | 页面白屏长、页面出现 loading 消失、domReady: 5291.29、onLoad:5292.78 | 页面白屏长、页面未跳转 loading 消失、domReady: 5123.46、onLoad:5127.85 | 页面白屏长、页面未跳转 loading 消失、domReady: 5074.86、onLoad:5079.875 | 页面可见快、loading 消失快在 domReady 稍后、domReady:14.06、load finish:5141.735 | 页面可见快、loading 消失快在 domReady 稍后、domReady:13.89、load finish:5157.15 | 页面白屏长、loading 先消失再出现页面、domReady: 5132.395、onLoad:5137.52 | 页面可见快、然后 loading 消失、domReady:13.49、load finish:5124.08 |
4 | Android browser | 页面白屏长、domReady: 5097.29、onLoad:5100.37 | 页面白屏长、domReady: 5177.48、onLoad:5193.66 | 页面白屏长、domReady: 5125.96、onLoad:5165.06 | 页面可见快、等 5s 后更新 load finish 时间 domReady:463.33、load finish:5092.90 | 页面可见快、等 5s 后更新 load finish 时间 domReady:39.34、load finish:5136.55 | 页面白屏长、domReady: 5092.45、onLoad:5119.81 | 页面可见快、等 5s 后更新 load finish 时间 domReady:50.49、load finish:5507.668 |
5 | Android 手淘 WebView | 白屏时间长、一直 loading 直接页面可见、domReady:5058.91、onLoad:5073.81 | 页面立即可见、loading 消失快、等 5s 后更新 domReady 时间和 load 时间 domReady:4176.34、onLoad:4209.50 | 页面立即可见、loading 消失快、domReady:6011.18、onLoad:6031.93 | 页面可见快、loading 之后消失、等 5s 后更新 load finish 时间 domReady:36.31、load finish:5081.76 | 页面可见快、loading 随后消失、等 5s 后更新 load finish 时间 domReady:25.11、load finish:5113.81 | 页面可见快、loading 随后消失、等 5s 后更新 domReady 时间和 load 时间 domReady:5213.11、load finish:5312.19 | 页面可见快、loading 随后消失、等 5s 后更新 load finish 时间 domReady:89.67、load finish:5589.95 |
从以上测试结果可以看出以下结论:
didFinishLoad 是 native 定义的事件,该事件触发时手淘 loading 菊花消失,并且 windvane 中的发出请求不再收集,也就是 native 统计出的 pageLoad 时间。在用户数据平台看到的瀑布流请求,就是在 didFinishLoad 触发前收集到的所有请求。
经过上方测试,客户端的 didFinisheLoad 事件的触发和 JS 中的 domReady(DOMContentLoaded)和 onLoad 触发没有任何关联。可能在 domReady 之前或之后,也可能在 onLoad 之前或之后。
那它到底是什么时候触发呢? iOS 官方文档 是 Sent after a web view finishes loading a frame。 结合收集的用户请求和测试,didFinishLoad 是在连续发起的请求结束之后触发,监听一段时间内无请求则触发。
所以经常会看到 data_sufei 这个 JS 文件,在有些用户的瀑布流里面有,在有些用户的又没有。原因是这个 JS 是 aplus_wap.js 故意 setTimeout 1s 后发出的,如果页面在 1s 前所有的请求都发完了则触发 didFinishLoad,后面的 data_sufei.js 的时间就不算到 pageLoad 的时间;反之如果接近 1s 页面还有图片等请求还在发,则 data_sufei.js 的时间也会被算到里面。
因此在 JS 中用 setTimeout 来延迟发送请求也有可能会影响 didFinishLoad 的时间,建议 setTimeout 的时间设置得更长一点,如 3s。
script 标签上可以添加 defer 和 async 属性来优化此 script 的下载和执行。
HTML 4.0 规范,其作用是,告诉浏览器,等到 DOM+CSSOM 渲染完成,再执行指定脚本。
<script defer src="xx.js"></script> |
下载的脚本文件在 DOMContentLoaded 事件触发前执行(即刚刚读取完\ffcfa9cf6eaa5476ca5cdb4e90c503a8标签),而且可以保证执行顺序就是它们在页面上出现的顺序。所以 添加 defer 属性后,domReady 的时间并没有提前,但它可以让页面更快显示出来。
将放在页面上方的 script 加 defer,在 PC Chrome 下其效果相当于 把这个 script 放在底部,页面会先显示。 但对 iOS Safari 和 iOS WebView 加 defer 和 script 放底部一样都是长时间白屏。
HTML 5 规范,其作用是,使用另一个进程下载脚本,下载时不会阻塞渲染,并且下载完成后立刻执行。
<script async src="yy.js"></script> |
async 属性可以保证脚本下载的同时,浏览器继续渲染。但是 async 无法保证脚本的执行顺序。哪个脚本先下载结束,就先执行那个脚本。
也许大家会说,现在 CSS/JS 都预加载到客户端了,怎么加载不重要。但页面有可能分享出去也有可能运行在浏览器中,也有可能预加载失效。
综合上面 async 和 defer,推荐以下用法。
<!-- 现代浏览器用 'async', ie9-用 'defer' --><script src="//g.alicdn.com/alilog/mlog/aplus_wap.js" async defer></script> |
実際、現在、ワイヤレス サイト aplus.js は、PC 上の元のスクリプト挿入メソッドの代わりに、DOM と CSSOM をブロックしたり、ページ全体の onLoad 時間を延長したりすることのないこの方法で完全に導入できるようになりました。
PC で aplus.js がこのように使用される場合、IE 8/IE 9 は defer 属性を使用するため、ページのレンダリングはブロックされませんが、この JS は domReady (DOMContentLoaded) イベントをトリガーする前に実行する必要があります。 , そのため、IE 8/IE 9 では domReady の時間が影響を受ける可能性があります。