一、前言
相信很多前端開發者在做項目時同時也都做過頁面性能優化，這不單是前端的必備職業技能，也是考驗一個前端基礎是否紮實的考點，而性能名額也通常是每一個開發者的績效之一。尤其馬上接近年關，頁面白屏時間是否過長、首屏加載速度是否達标、動畫是否能流暢運作，諸如此類關于性能更具體的名額和感受，很可能也是決定着年底你能拿多少年終獎回家過年的晴雨表。
關于性能優化，我們一般從以下四個方面考慮：
- 開發時性能優化
- 編譯時性能優化
- 加載時性能優化
- 運作時性能優化
而本文将從第三個方面展開，講一講哪些因素将影響到頁面加載總時長，談到總時長，那總是避免不了要談及 window.onload，這不但是本文的重點，也是常見頁面性能監控工具中必要的API之一，如果你對自己頁面加載的總時長不滿意，歡迎讀完本文後在評論區交流。
二、關于 window.onload
這個挂載到 window 上的方法，是我剛接觸前端時就掌握的技能，我記得尤為深刻，當時老師說，“對于初學者，隻要在這個方法裡寫邏輯，一定沒錯兒，它是整個文檔加載完畢後執行的生命周期函數”，于是從那之後，幾乎所有的練習demo，我都寫在這裡，也确實沒出過錯。
在 MDN 上，關于 onload 的解釋是這樣的：load 事件在整個頁面及所有依賴資源如樣式表和圖檔都已完成加載時觸發。它與 DOMContentLoaded 不同，後者隻要頁面 DOM 加載完成就觸發，無需等待依賴資源的加載。該事件不可取消，也不會冒泡。
後來随着前端知識的不斷擴充，這個方法後來因為有了“更先進”的 DOMContentLoaded，在我的代碼裡而逐漸被替代了，目前除了一些極其特殊的情況，否則我幾乎很難用到 window.onload 這個API，直到認識到它影響到頁面加載的整體時長名額，我才又一次拾起來它。
三、哪些因素會影響 window.onload
本章節主要會通過幾個常用的業務場景展開描述，但是有個前提，就是如何準确記錄各種類型資源加載耗時對頁面整體加載的影響，為此，有必要先介紹一下前提。
為了準确描述資源加載耗時，我在本地環境啟動了一個用于資源請求的 node 服務，所有的資源都會從這個服務中擷取，之是以不用遠端伺服器資源的有主要原因是，使用本地服務的資源可以在通路的資源連結中設定延遲時間，如通路腳本資源
http://localhost:3010/index.js?delay=300，因連結中存在 delay=300，即可使資源在300毫秒後傳回，這樣即可準确控制每個資源加載的時間。
以下是 node 資源請求服務延遲相關代碼，僅僅是一個中間件：
const express = require("express")
const app = express()
app.use(function (req, res, next) {
Number(req.query.delay) > 0
? setTimeout(next, req.query.delay)
: next()
}) 場景一： 使用 async 異步加載腳本場景對 onload 的影響
示例代碼：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
<!-- 請求時長為1秒的js資源 -->
<script src="http://localhost:3010/index.js?delay=1000" async></script>
</head>
<body>
</body>
</html> 浏覽器表現如下：
通過上圖可以看到，瀑布圖中深藍色豎線表示觸發了 DOMContentLoaded 事件，而紅色豎線表示觸發了 window.onload 事件（下文中無特殊情況，不會再進行特殊辨別），由圖可以得知使用了 async 屬性進行腳本的異步加載，仍會影響頁面加載總體時長。
場景二：使用 defer 異步加載腳本場景對 onload 的影響
示例代碼：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
<!-- 請求時長為1秒的js資源 -->
<script src="http://localhost:3010/index.js?delay=1000" defer></script>
</head>
<body>
</body>
</html> 浏覽器表現如下：
由圖可以得知使用了 defer 屬性進行腳本的異步加載，除了正常的在 DOMContentLoaded 之後觸發腳本執行，也影響頁面加載總體時長。
場景三：異步腳本中再次加載腳本，也就是常見的動态加載腳本、樣式資源的情況
html 代碼保持不變，index.js内示例代碼：
const script = document.createElement('script')
// 請求時長為0.6秒的js資源
script.src = 'http://localhost:3010/index2.js?delay=600'
script.onload = () => {
console.log('js 2 異步加載完畢')
}
document.body.appendChild(script) 結果如下：
從瀑布圖可以看出，資源的連續加載，導緻了onload事件整體延後了，這也是我們再頁面中非常常見的一種操作，通常懶加載一些不重要或者首屏外的資源，其實這樣也會導緻頁面整體名額的下降。
不過值得強調的一點是，這裡有個有意思的地方，如果我們把上述代碼進行改造，删除最後一行的 document.body.appendChild(script)，發現 index2 的資源請求并沒有發出，也就是說，腳本元素不向頁面中插入，腳本的請求是不會發出的，但是也會有反例，這個我們下面再說。
在本示例中，後來我又把腳本請求換成了 css 請求，結果是一緻的。
場景四：圖檔的懶加載/預加載
html 保持不變，index.js 用于加載圖檔，内容如下：
const img = document.createElement('img')
// 請求時長為0.5秒的圖檔資源
img.src = 'http://localhost:3010/index.png?delay=500'
document.body.appendChild(img) 結果示意：
表現是與場景三一樣的，這個不再多說，但是有意思的來了，不一樣的是，經過測試發現，哪怕删除最後一行代碼：document.body.appendChild(img)，不向頁面中插入元素，圖檔也會送出請求，也同樣延長了頁面加載時長，是以部分同學就要注意了，這是一把雙刃劍：當你真的需要懶加載圖檔時，可以少寫最後一行插入元素的代碼了，但是如果大量的圖檔加載請求發出，哪怕不向頁面插入圖檔，也真的會拖慢頁面的時長。
趁着這個場景，再多說一句，一些埋點資料的上報，也正是借着圖檔有不需要插入dom即可發送請求的特性，實作成功上傳的。
場景五：普通接口請求
html 保持不變，index.js 内容如下：
// 請求時長為500毫秒的請求接口
fetch('http://localhost:3010/api?delay=500') 結果如下圖：
可以發現普通接口請求的發出，并不會影響頁面加載，但是我們再把場景弄複雜一些，見場景六。
場景六：同時加載樣式、腳本，腳本加載完成後，内部http接口請求，等請求結果傳回後，再發出圖檔請求或修改dom，這也是更貼近生産環境的真實場景
html 代碼：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
<!-- 請求時長為1.2秒的css -->
<link rel="stylesheet" href="http://localhost:3010/index.css?delay=1200">
<!-- 請求時長為0.4秒的js -->
<script src="http://localhost:3010/index.js?delay=400" async></script>
</head>
<body>
</body>
</html> index.js 代碼：
async function getImage () {
// 請求時長為0.5秒的接口請求
await fetch('http://localhost:3010/api?delay=500')
const img = document.createElement('img')
// 請求時長為0.5秒的圖檔資源
img.src = 'http://localhost:3010/index.png?delay=500'
document.body.appendChild(img)
}
getImage() 結果圖如下：
如圖所示，結合場景五記的結果，雖然普通的 api 請求并不會影響頁面加載時長，但是因為api請求過後，重新請求了圖檔資源（或大量操作 dom），依然會導緻頁面加載時間變長。這也是我們日常開發中最常見的場景，頁面加載了js，js發出網絡請求，用于擷取頁面渲染資料，頁面渲染時加載圖檔或進行dom操作。
場景七：頁面多媒體資源的加載
示例代碼：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
</head>
<body>
<video src="http://localhost:3010/video.mp4?delay=500" controls></video>
</body>
</html> 結果如圖：
對于視訊這種多媒體資源的加載比較有意思，video 标簽對于資源的加載是預設開啟 preload 的，是以資源會預設進行網絡請求（如需關閉，要把 preload 設定為 none ），可以看到紅色豎線基本處于圖中綠色條和藍色條中間（實際上更偏右一些），圖檔綠色部分代表資源等待時長，藍色部分代表資源真正的加載時長，且藍色加載條在onload的豎線右側，這說明多媒體的資源确實影響了 onload 時長，但是又沒完全影響，因為設定了500ms的延遲傳回資源，是以 onload 也被延遲了500ms左右，但一旦視訊真正開始下載下傳，這段時長已經不記錄在 onload 的時長中了。
其實這種行為也算合理，畢竟多媒體資源通常很大，占用的帶寬也多，如果一直延遲 onload，意味着很多依賴 onload 的事件都無法及時觸發。
接下來我們把這種情況再複雜一些，貼近實際的生産場景，通常video元素是包含封面圖 poster 屬性的，我們設定一張延遲1秒的封面圖，看看會發生什麼，結果如下：
不出意外，果然封面圖影響了整體的加載時長，魔鬼都在細節中，封面圖也需要注意優化壓縮。
場景八：異步腳本和樣式資源一同請求
示例代碼：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
<!-- 請求時長為1秒的css -->
<link rel="stylesheet" href="http://localhost:3010/index.css?delay=1000">
<!-- 請求時長為0.5秒的js -->
<script src="http://localhost:3010/index.js?delay=500" async></script>
</head>
<body>
</body>
</html> 浏覽器表現如下：
可以看出 css 資源雖然沒有阻塞腳本的加載，但是卻延遲了整體頁面加載時長，其中原因是css資源的加載會影響 render tree 的生成，導緻頁面遲遲不能完成渲染。
如果嘗試把 async 換成 defer，或者幹脆使用同步的方式加載腳本，結果也是一樣，因結果相同，本處不再舉例。
場景九：樣式資源先請求，再執行内聯腳本邏輯，最後加載異步腳本
我們把場景八的代碼做一個改造，在樣式标簽和異步腳本标簽之間，加上一個隻包含空格的内聯腳本，讓我們看看會發生什麼，代碼如下：
<!DOCTYPE html>
<html lang="en">
<head>
<script>
console.log('頁面js 開始執行')
</script>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
<!-- 請求時長為1秒的css -->
<link rel="stylesheet" href="http://localhost:3010/index.css?delay=2000">
<!-- 此标簽僅有一個空格 -->
<script> </script>
<!-- 請求時長為0.5秒的js -->
<script src="http://localhost:3010/index.js?delay=500" async></script>
</head>
<body>
</body>
</html> index.js 中的内容如下：
console.log("腳本 js 開始執行"); 結果如下，這是一張 GIF，加載可能有點慢：
這個結果非常有意思，他到底發生了什麼呢？
- 腳本請求是0.5秒的延遲，樣式請求是2秒
- 腳本資源是 async 的請求，異步發出，應該什麼時候加載完什麼時候執行
- 但是圖中的結果卻是等待樣式資源加載完畢後才執行
答案就在那個僅有一個空格的腳本标簽中，經反複測試，如果把标簽換成注釋，也會出現一樣的現象，如果是一個完全空的标簽，或者根本沒有這個腳本标簽，那下方的index.js 通過 async 異步加載，并不會違反直覺，加載完畢後直接執行了，是以這是為什麼呢？
這其實是因為樣式資源下方的 script 雖然僅有一個空格，但是被浏覽器認為了它内部可能是包含邏輯，一定機率會存在樣式的修改、更新 dom 結構等操作，因為樣式資源沒有加載完（被延遲了2秒），導緻同步 js （隻有一個空格的腳本）的執行被阻塞了，衆所周知頁面的渲染和運作是單線程的，既然前面已經有了一個未執行完成的 js，是以也導緻了後面異步加載的 js 需要在隊列中等待。這也就是為什麼 async 雖然異步加載了，但是沒有在加載後立即執行的原因。
場景十：字型資源的加載
示例代碼：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>test</title>
<style>
@font-face {
font-family: font-custom;
src: url('http://localhost:3010/font.ttf?delay=500');
}
body {
font-family: font-custom;
}
</style>
</head>
<body></body>
</html> 結果如下：
可以看到，此情況下字型的加載是對 onload 有影響的，然後我們又測試了一下隻聲明字型、不使用的情況，也就是删除上面代碼中 body 設定的字型，發現這種情況下，字型是不會送出請求的，僅僅是造成了代碼的備援。
四、總結
前面列舉了大量的案例，接下來我們做個總結，實質性影響 onload 其實就是幾個方面。
- 圖檔資源的影響毋庸置疑，無論是在頁面中直接加載，還是通過 js 懶加載，隻要加載過程是在 onload 之前，都會導緻頁面 onload 時長增加。
- 多媒體資源的等待時長會被記入 onload，但是實際加載過程不會。
- 字型資源的加載會影響 onload。
- 網絡接口請求，不會影響 onload，但需要注意的是接口傳回後，如果此時頁面還未 onload，又進行了圖檔或者dom操作，是會導緻 onload 延後的。
- 樣式不會影響腳本的加載和解析，隻會阻塞腳本的執行。
- 異步腳本請求不會影響頁面解析，但是腳本的執行同樣影響 onload。
五、優化舉措
- 圖檔或其他資源的預加載可以通過 preload 或 prefetch 請求，這兩種方式都不會影響 onload 時長。
- 一定注意壓縮圖檔，頁面中圖檔的加載速度可能對整體時長有決定性影響。
- 盡量不要做串行請求，沒有依賴關系的情況下，推薦并行。
- 中文字型包非常大，可以使用 字蛛 壓縮、或用圖檔代替。
- 靜态資源上 cdn 很重要，壓縮也很重要。
- 删除你認為可有可無的代碼，沒準哪一行代碼就會影響加載速度，并且可能很難排查。
- 視訊資源如果在首屏以外，不要開啟預加載，合理使用視訊的 preload 屬性。
- async 和 defer 記得用，很好用。
- 非必要的内容，可以在 onload 之後執行，是時候重新拾起來這個 api 了。
文章來源：京東科技_孫凱_https://zhuanlan.zhihu.com/p/619011010