作者：京東科技 孫凱

一、前言

相信很多前端開發(fā)者在做項(xiàng)目時(shí)同時(shí)也都做過頁面性能優(yōu)化，這不單是前端的必備職業(yè)技能，也是考驗(yàn)一個(gè)前端基礎(chǔ)是否扎實(shí)的考點(diǎn)，而性能指標(biāo)也通常是每一個(gè)開發(fā)者的績效之一。尤其馬上接近年關(guān)，頁面白屏?xí)r間是否過長、首屏加載速度是否達(dá)標(biāo)、動(dòng)畫是否能流暢運(yùn)行，諸如此類關(guān)于性能更具體的指標(biāo)和感受，很可能也是決定著年底你能拿多少年終獎(jiǎng)回家過年的晴雨表。

關(guān)于性能優(yōu)化，我們一般從以下四個(gè)方面考慮：

而本文將從第三個(gè)方面展開，講一講哪些因素將影響到頁面加載總時(shí)長，談到總時(shí)長，那總是避免不了要談及window.，這不但是本文的重點(diǎn)，也是常見頁面性能監(jiān)控工具中必要的API之一，如果你對(duì)自己頁面加載的總時(shí)長不滿意，歡迎讀完本文后在評(píng)論區(qū)交流。

二、關(guān)于 window.

這個(gè)掛載到window上的方法，是我剛接觸前端時(shí)就掌握的技能，我記得尤為深刻，當(dāng)時(shí)老師說，“對(duì)于初學(xué)者，只要在這個(gè)方法里寫邏輯，一定沒錯(cuò)兒，它是整個(gè)文檔加載完畢后執(zhí)行的生命周期函數(shù)”，于是從那之后，幾乎所有的練習(xí)demo，我都寫在這里，也確實(shí)沒出過錯(cuò)。

在MDN上，關(guān)于的解釋是這樣的：load 事件在整個(gè)頁面及所有依賴資源如樣式表和圖片都已完成加載時(shí)觸發(fā)。它與DOMContentLoaded不同，后者只要頁面 DOM 加載完成就觸發(fā)，無需等待依賴資源的加載。該事件不可取消，也不會(huì)冒泡。

后來隨著前端知識(shí)的不斷擴(kuò)充，這個(gè)方法后來因?yàn)橛辛恕案冗M(jìn)”的DOMContentLoaded，在我的代碼里而逐漸被替代了，目前除了一些極其特殊的情況，否則我?guī)缀鹾茈y用到window.這個(gè)API，直到認(rèn)識(shí)到它影響到頁面加載的整體時(shí)長指標(biāo)，我才又一次拾起來它。

三、哪些因素會(huì)影響 window.

本章節(jié)主要會(huì)通過幾個(gè)常用的業(yè)務(wù)場景展開描述，但是有個(gè)前提，就是如何準(zhǔn)確記錄各種類型資源加載耗時(shí)對(duì)頁面整體加載的影響，為此，有必要先介紹一下前提。

為了準(zhǔn)確描述資源加載耗時(shí)，我在本地環(huán)境啟動(dòng)了一個(gè)用于資源請(qǐng)求的node服務(wù)，所有的資源都會(huì)從這個(gè)服務(wù)中獲取，之所以不用遠(yuǎn)程服務(wù)器資源的有主要原因是，使用本地服務(wù)的資源可以在訪問的資源鏈接中設(shè)置延遲時(shí)間，如訪問腳本資源http://localhost:3010/index.js?delay=300，因鏈接中存在delay=300，即可使資源在300毫秒后返回，這樣即可準(zhǔn)確控制每個(gè)資源加載的時(shí)間。

以下是node資源請(qǐng)求服務(wù)延遲相關(guān)代碼，僅僅是一個(gè)中間件：

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 異步加載腳本場景對(duì) 的影響

示例代碼：

!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"

titletest/title

!-- 請(qǐng)求時(shí)長為1秒的js資源 --

script src="http://localhost:3010/index.js?delay=1000" async/script

/head

body

/body

/html

瀏覽器表現(xiàn)如下：

通過上圖可以看到，瀑布圖中深藍(lán)色豎線表示觸發(fā)了DOMContentLoaded事件，而紅色豎線表示觸發(fā)了window.事件（下文中無特殊情況，不會(huì)再進(jìn)行特殊標(biāo)識(shí)），由圖可以得知使用了 async 屬性進(jìn)行腳本的異步加載，仍會(huì)影響頁面加載總體時(shí)長。

場景二：使用 defer 異步加載腳本場景對(duì) 的影響

示例代碼：

!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"

titletest/title

!-- 請(qǐng)求時(shí)長為1秒的js資源 --

script src="http://localhost:3010/index.js?delay=1000" defer/script

/head

body

/body

/html

瀏覽器表現(xiàn)如下：

由圖可以得知使用了 defer 屬性進(jìn)行腳本的異步加載，除了正常的在DOMContentLoaded之后觸發(fā)腳本執(zhí)行，也影響頁面加載總體時(shí)長。

場景三：異步腳本中再次加載腳本，也就是常見的動(dòng)態(tài)加載腳本、樣式資源的情況

html 代碼保持不變，index.js內(nèi)示例代碼：

const script = document.('script')

// 請(qǐng)求時(shí)長為0.6秒的js資源

script.src = 'http://localhost:3010/index2.js?delay=600'

script. = () = {

console.log('js 2 異步加載完畢')

}

document.body.(script)

結(jié)果如下：

從瀑布圖可以看出，資源的連續(xù)加載，導(dǎo)致了事件整體延后了，這也是我們?cè)夙撁嬷蟹浅３Ｒ姷囊环N操作，通常懶加載一些不重要或者首屏外的資源，其實(shí)這樣也會(huì)導(dǎo)致頁面整體指標(biāo)的下降。

不過值得強(qiáng)調(diào)的一點(diǎn)是，這里有個(gè)有意思的地方，如果我們把上述代碼進(jìn)行改造，刪除最后一行的document.body.(script)，發(fā)現(xiàn) index2 的資源請(qǐng)求并沒有發(fā)出，也就是說，腳本元素不向頁面中插入，腳本的請(qǐng)求是不會(huì)發(fā)出的，但是也會(huì)有反例，這個(gè)我們下面再說。

在本示例中，后來我又把腳本請(qǐng)求換成了 css 請(qǐng)求，結(jié)果是一致的。

場景四：圖片的懶加載/預(yù)加載

html 保持不變，index.js 用于加載圖片，內(nèi)容如下：

const img = document.('img')

// 請(qǐng)求時(shí)長為0.5秒的圖片資源

img.src = 'http://localhost:3010/index.png?delay=500'

document.body.(img)

結(jié)果示意：

表現(xiàn)是與場景三一樣的，這個(gè)不再多說，但是有意思的來了，不一樣的是，經(jīng)過測試發(fā)現(xiàn)，哪怕刪除最后一行代碼：document.body.(img)，不向頁面中插入元素，圖片也會(huì)發(fā)出請(qǐng)求，也同樣延長了頁面加載時(shí)長，所以部分同學(xué)就要注意了，這是一把雙刃劍：當(dāng)你真的需要懶加載圖片時(shí)，可以少寫最后一行插入元素的代碼了，但是如果大量的圖片加載請(qǐng)求發(fā)出，哪怕不向頁面插入圖片，也真的會(huì)拖慢頁面的時(shí)長。

趁著這個(gè)場景，再多說一句，一些埋點(diǎn)數(shù)據(jù)的上報(bào)，也正是借著圖片有不需要插入dom即可發(fā)送請(qǐng)求的特性，實(shí)現(xiàn)成功上傳的。

場景五：普通接口請(qǐng)求

html 保持不變，index.js 內(nèi)容如下：

// 請(qǐng)求時(shí)長為500毫秒的請(qǐng)求接口

fetch('http://localhost:3010/api?delay=500')

結(jié)果如下圖：

可以發(fā)現(xiàn)普通接口請(qǐng)求的發(fā)出，并不會(huì)影響頁面加載，但是我們?cè)侔褕鼍芭獜?fù)雜一些，見場景六。

場景六：同時(shí)加載樣式、腳本，腳本加載完成后，內(nèi)部http接口請(qǐng)求，等請(qǐng)求結(jié)果返回后，再發(fā)出圖片請(qǐng)求或修改dom，這也是更貼近生產(chǎn)環(huán)境的真實(shí)場景

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"

titletest/title

!-- 請(qǐng)求時(shí)長為1.2秒的css --

link rel="stylesheet" href="http://localhost:3010/index.css?delay=1200"

!-- 請(qǐng)求時(shí)長為0.4秒的js --

script src="http://localhost:3010/index.js?delay=400" async/script

/head

body

/body

/html

index.js 代碼：

async function getImage () {

// 請(qǐng)求時(shí)長為0.5秒的接口請(qǐng)求

await fetch('http://localhost:3010/api?delay=500')

const img = document.('img')

// 請(qǐng)求時(shí)長為0.5秒的圖片資源

img.src = 'http://localhost:3010/index.png?delay=500'

document.body.(img)

}

getImage()

結(jié)果圖如下：

如圖所示，結(jié)合場景五記的結(jié)果，雖然普通的 api 請(qǐng)求并不會(huì)影響頁面加載時(shí)長，但是因?yàn)閍pi請(qǐng)求過后，重新請(qǐng)求了圖片資源（或大量操作 dom），依然會(huì)導(dǎo)致頁面加載時(shí)間變長。這也是我們?nèi)粘ｉ_發(fā)中最常見的場景，頁面加載了js，js發(fā)出網(wǎng)絡(luò)請(qǐng)求，用于獲取頁面渲染數(shù)據(jù)，頁面渲染時(shí)加載圖片或進(jìn)行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"

titletest/title

/head

body

video src="http://localhost:3010/video.mp4?delay=500" controls/video

/body

/html

結(jié)果如圖：

對(duì)于視頻這種多媒體資源的加載比較有意思，video 標(biāo)簽對(duì)于資源的加載是默認(rèn)開啟 preload 的，所以資源會(huì)默認(rèn)進(jìn)行網(wǎng)絡(luò)請(qǐng)求（如需關(guān)閉，要把 preload 設(shè)置為 none ），可以看到紅色豎線基本處于圖中綠色條和藍(lán)色條中間（實(shí)際上更偏右一些），圖片綠色部分代表資源等待時(shí)長，藍(lán)色部分代表資源真正的加載時(shí)長，且藍(lán)色加載條在的豎線右側(cè)，這說明多媒體的資源確實(shí)影響了 時(shí)長，但是又沒完全影響，因?yàn)樵O(shè)置了500ms的延遲返回資源，所以 也被延遲了500ms左右，但一旦視頻真正開始下載，這段時(shí)長已經(jīng)不記錄在 的時(shí)長中了。

其實(shí)這種行為也算合理，畢竟多媒體資源通常很大，占用的帶寬也多，如果一直延遲 ，意味著很多依賴 的事件都無法及時(shí)觸發(fā)。

接下來我們把這種情況再復(fù)雜一些，貼近實(shí)際的生產(chǎn)場景，通常video元素是包含封面圖 poster 屬性的，我們?cè)O(shè)置一張延遲1秒的封面圖，看看會(huì)發(fā)生什么，結(jié)果如下：

不出意外，果然封面圖影響了整體的加載時(shí)長，魔鬼都在細(xì)節(jié)中，封面圖也需要注意優(yōu)化壓縮。

場景八：異步腳本和樣式資源一同請(qǐng)求

示例代碼：

!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"

titletest/title

!-- 請(qǐng)求時(shí)長為1秒的css --

link rel="stylesheet" href="http://localhost:3010/index.css?delay=1000"

!-- 請(qǐng)求時(shí)長為0.5秒的js --

script src="http://localhost:3010/index.js?delay=500" async/script

/head

body

/body

/html

瀏覽器表現(xiàn)如下：

可以看出 css 資源雖然沒有阻塞腳本的加載，但是卻延遲了整體頁面加載時(shí)長，其中原因是css資源的加載會(huì)影響 render tree 的生成，導(dǎo)致頁面遲遲不能完成渲染。

如果嘗試把 async 換成 defer，或者干脆使用同步的方式加載腳本，結(jié)果也是一樣，因結(jié)果相同，本處不再舉例。

場景九：樣式資源先請(qǐng)求，再執(zhí)行內(nèi)聯(lián)腳本邏輯，最后加載異步腳本

我們把場景八的代碼做一個(gè)改造，在樣式標(biāo)簽和異步腳本標(biāo)簽之間，加上一個(gè)只包含空格的內(nèi)聯(lián)腳本，讓我們看看會(huì)發(fā)生什么，代碼如下：

!DOCTYPE html

html lang="en"

head

script

console.log('頁面js 開始執(zhí)行')

/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"

titletest/title

!-- 請(qǐng)求時(shí)長為1秒的css --

link rel="stylesheet" href="http://localhost:3010/index.css?delay=2000"

!-- 此標(biāo)簽僅有一個(gè)空格 --

script /script

!-- 請(qǐng)求時(shí)長為0.5秒的js --

script src="http://localhost:3010/index.js?delay=500" async/script

/head

body

/body

/html

index.js 中的內(nèi)容如下：

console.log("腳本 js 開始執(zhí)行");

結(jié)果如下，這是一張 GIF，加載可能有點(diǎn)慢：

這個(gè)結(jié)果非常有意思，他到底發(fā)生了什么呢？

答案就在那個(gè)僅有一個(gè)空格的腳本標(biāo)簽中，經(jīng)反復(fù)測試，如果把標(biāo)簽換成注釋，也會(huì)出現(xiàn)一樣的現(xiàn)象，如果是一個(gè)完全空的標(biāo)簽，或者根本沒有這個(gè)腳本標(biāo)簽，那下方的index.js 通過 async 異步加載，并不會(huì)違反直覺，加載完畢后直接執(zhí)行了，所以這是為什么呢？

這其實(shí)是因?yàn)闃邮劫Y源下方的 script 雖然僅有一個(gè)空格，但是被瀏覽器認(rèn)為了它內(nèi)部可能是包含邏輯，一定概率會(huì)存在樣式的修改、更新 dom 結(jié)構(gòu)等操作，因?yàn)闃邮劫Y源沒有加載完（被延遲了2秒），導(dǎo)致同步 js （只有一個(gè)空格的腳本）的執(zhí)行被阻塞了，眾所周知頁面的渲染和運(yùn)行是單線程的，既然前面已經(jīng)有了一個(gè)未執(zhí)行完成的 js，所以也導(dǎo)致了后面異步加載的 js 需要在隊(duì)列中等待。這也就是為什么 async 雖然異步加載了，但是沒有在加載后立即執(zhí)行的原因。

場景十：字體資源的加載

示例代碼：

!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"

titletest/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

結(jié)果如下：

可以看到，此情況下字體的加載是對(duì) 有影響的，然后我們又測試了一下只聲明字體、不使用的情況，也就是刪除上面代碼中 body 設(shè)置的字體，發(fā)現(xiàn)這種情況下，字體是不會(huì)發(fā)出請(qǐng)求的，僅僅是造成了代碼的冗余。

四、總結(jié)

前面列舉了大量的案例，接下來我們做個(gè)總結(jié)，實(shí)質(zhì)性影響 其實(shí)就是幾個(gè)方面。

五、優(yōu)化舉措