作為一個開發(fā)者,我們知道結束網(wǎng)頁的膨脹是一件簡單的事情道批。但是加載一個頁面遠比傳送相同大小的數(shù)據(jù)要的時間多的多。一旦流浪器下載了我們的頁面腳本朴读,他就必須解析和運行它們屹徘。在這里我就深入的來討論JavaScript的這個階段,為什么它會減慢應用程序的啟動速度并且如何的去修復它衅金。
從加載頁面的過程中,我們觀察到是在解析和編譯javascript的過程中并沒有花費很多的時間簿煌。我們看到死腳本立即的被解析和執(zhí)行了氮唯。但是事實并非如此。下面是V8引擎的工作原理姨伟。
看看那些主要的階段惩琉。
是什么讓我們的網(wǎng)絡應用變慢了?
解析夺荒、編譯腳本和執(zhí)行腳本花費了JavaScript引擎的大量時間瞒渠。這延遲了我們與站點交互的時間〖级螅可以想象一下伍玖,但我們在看到一個按鈕時卻不可點擊只能干等著,這大大的降低了用戶體驗剿吻。
一些關鍵性的代碼控制著啟動的時間丽旅。實際過程中椰棘,在類似于facebook這樣的大網(wǎng)站中v8花費了大量的時間在進行代碼的解析與運行。
一般網(wǎng)站的JavaScript解析和編譯瓶頸是什么?
腳本的大小很重要茅撞,但是它并不能代表一切帆卓。就比如說200kb我們的js腳本!==200kb別人的js腳本解析與編譯時間巨朦。代碼的質量也是一個很重要的原因。
目前測量JavaScript解析和編譯工具
Chrome DevTools
下面是Chrome加載的時間
Chrome Tracing
關于跟蹤:Chrome的低級別的跟蹤工具允許我們使用disabled-by-default-v8鳞疲。runtime_stats
范疇更深入地了解那里的V8花時間罪郊。
WebPageTest
WebPageTest的“處理故障”頁面包括洞察V8編譯,evaluatescript和函數(shù)調用的時候我們做了一個跟蹤(捕捉工具開發(fā)時間表啟用)尚洽。
我們現(xiàn)在也可以得到運行時調用屬性指定
disabled-by-default-v8悔橄。runtime_stats
作為自定義跟蹤類
我們可以做什么來降低JavaScript解析時間呢?
- 越少的腳本需要解析的時間越少腺毫。
- 代碼拆分: 只加載用戶所需要的代碼癣疟。實現(xiàn)代碼懶加載,避免解析太多的javasript潮酒。
- 腳本流:在過去睛挚,V8告訴開發(fā)者使用
異步/推遲
選擇腳本流的解析10–20%之間時間的改進。這允許HTML解析器至少提前檢測資源急黎,將工作推送到腳本流線程扎狱,而不是停止文檔解析。現(xiàn)在勃教,這也是為解析器阻塞腳本所做的淤击,我認為這里沒有任何可操作的地方。V8建議早期加載較大的捆綁包故源,因為只有一個流光線程(稍后會詳細介紹)- 庫和框架污抬。