內(nèi)聯(lián)腳本對頁面性能的影響

1、內(nèi)聯(lián)腳本對頁面性能的影響懌飛 / 圓心Whos this guy? http:/ 懌飛 / 圓心 Technology Evangelist Front-End Engineerin Taobao UED案例分析http:/ 腳本執(zhí)行結(jié)束，第二張圖才開始下載。2. 頁面加載之后，至少5秒頁面無任何內(nèi)容顯示。影響的主要方面 阻塞頁面資源的并行下載 阻塞頁面的逐步渲染影響的主要原因 保持執(zhí)行順序 對 document.write 的依賴關(guān)系問題的解決方案 將內(nèi)聯(lián)腳本移至底部。 使用異步回調(diào)。 使用 script 的 defer 屬性。將內(nèi)聯(lián)腳本移至底部 避免了下載阻塞，實現(xiàn)了并行下載。 此方法適用

2、于：執(zhí)行時間小于 300毫秒的內(nèi)聯(lián)腳本。 無法解決阻塞頁面的逐步渲染的問題。使用異步回調(diào)使用異步回調(diào)： setTimeout最簡單的異步調(diào)用就是使用 setTimeout：使用異步回調(diào)： setTimeout 避免了下載阻塞，實現(xiàn)了并行下載。 在 Internet Explorer 中實現(xiàn)了逐步渲染。 Firefox中依舊阻塞頁面的逐步渲染。使用異步回調(diào)： setTimeout Firefox中將毫秒數(shù)增加到250毫秒，也可實現(xiàn)頁面的逐步渲染。Note: 神奇數(shù)字 250源于 nglayout.initialpaint.delay（“顯示頁面之前的等待毫秒數(shù)”） 的默認值。如果 longCod

3、e 在250毫秒之前就開始執(zhí)行，所有渲染在它執(zhí)行完畢之前都會被阻塞，如果我們等待250毫秒之后再調(diào)用 longCode，F(xiàn)irefox 就能渲染頁面頂部的文本。使用異步回調(diào)： setTimeout在這兩種情況下（IE中0ms和FF中250ms）: 都只有文本被快速渲染。 圖片雖然在1 秒之后返回，但直到 longCode 在 5 秒鐘之后執(zhí)行完畢時才在頁面中顯示。Note: 渲染事件在1秒之后進入隊列，而瀏覽器在 longCode 執(zhí)行的同時不能響應(yīng)這個事件。瀏覽器是單線程的，JavaScript 執(zhí)行的同時所有渲染事件都會被阻塞。我們可以通過增加 setTimeout 的毫秒數(shù)來解決它，該毫

4、秒數(shù)比1秒的圖片下載時間稍大，比如1500毫秒。使用異步回調(diào)： onload如果想異步執(zhí)行 longCode 而不阻塞瀏覽器渲染，更好的做法是使用 onload 事件來觸發(fā)代碼運行 ：使用異步回調(diào)：總結(jié) 如果內(nèi)聯(lián)腳本很短，使用 setTimeout 的 0 毫秒延遲是一個兼顧快速渲染和JavaScript快速執(zhí)行的不錯方案。 如果腳本很長，更好的選擇是使用 onload。使用 script 的 defer 屬性 defer 屬性對內(nèi)聯(lián)腳本也有效，它允許瀏覽器繼續(xù)解析頁面，同時延遲內(nèi)聯(lián)腳本的執(zhí)行。 避免了下載阻塞，實現(xiàn)了并行下載。 直到腳本執(zhí)行完成后頁面才開始渲染。 僅 Internet Explorer 和 Firefox3.1+ 支持。解決方案的回顧 將內(nèi)聯(lián)腳