作者：京東科技 孫凱

一、前言

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

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

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

二、關于 window.

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

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

后來隨著前端知識的不斷擴充，這個方法后來因為有了“更先進”的DOMContentLoaded，在我的代碼里而逐漸被替代了，目前除了一些極其特殊的情況，否則我?guī)缀鹾茈y用到window.這個API，直到認識到它影響到頁面加載的整體時長指標，我才又一次拾起來它。

三、哪些因素會影響 window.

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

為了準確描述資源加載耗時，我在本地環(huán)境啟動了一個用于資源請求的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 異步加載腳本場景對 的影響

示例代碼：

!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

!-- 請求時長為1秒的js資源 --

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

/head

body

/body

/html

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

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

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

示例代碼：

!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

!-- 請求時長為1秒的js資源 --

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

/head

body

/body

/html

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

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

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

html 代碼保持不變，index.js內示例代碼：

const script = document.('script')

// 請求時長為0.6秒的js資源

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

script. = () = {

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

}

document.body.(script)

結果如下：

從瀑布圖可以看出，資源的連續(xù)加載，導致了事件整體延后了，這也是我們再頁面中非常常見的一種操作，通常懶加載一些不重要或者首屏外的資源，其實這樣也會導致頁面整體指標的下降。

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

在本示例中，后來我又把腳本請求換成了 css 請求，結果是一致的。

場景四：圖片的懶加載/預加載

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

const img = document.('img')

// 請求時長為0.5秒的圖片資源

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

document.body.(img)

結果示意：

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

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

場景五：普通接口請求

html 保持不變，index.js 內容如下：

// 請求時長為500毫秒的請求接口

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

結果如下圖：

可以發(fā)現(xiàn)普通接口請求的發(fā)出，并不會影響頁面加載，但是我們再把場景弄復雜一些，見場景六。

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

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

!-- 請求時長為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.('img')

// 請求時長為0.5秒的圖片資源

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

document.body.(img)

}

getImage()

結果圖如下：

如圖所示，結合場景五記的結果，雖然普通的 api 請求并不會影響頁面加載時長，但是因為api請求過后，重新請求了圖片資源（或大量操作 dom），依然會導致頁面加載時間變長。這也是我們日常開發(fā)中最常見的場景，頁面加載了js，js發(fā)出網(wǎng)絡請求，用于獲取頁面渲染數(shù)據(jù)，頁面渲染時加載圖片或進行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

結果如圖：

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

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

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

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

場景八：異步腳本和樣式資源一同請求

示例代碼：

!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

!-- 請求時長為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

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

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

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

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

我們把場景八的代碼做一個改造，在樣式標簽和異步腳本標簽之間，加上一個只包含空格的內聯(lián)腳本，讓我們看看會發(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

!-- 請求時長為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 開始執(zhí)行");

結果如下，這是一張 GIF，加載可能有點慢：

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

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

這其實是因為樣式資源下方的 script 雖然僅有一個空格，但是被瀏覽器認為了它內部可能是包含邏輯，一定概率會存在樣式的修改、更新 dom 結構等操作，因為樣式資源沒有加載完（被延遲了2秒），導致同步 js （只有一個空格的腳本）的執(zhí)行被阻塞了，眾所周知頁面的渲染和運行是單線程的，既然前面已經(jīng)有了一個未執(zhí)行完成的 js，所以也導致了后面異步加載的 js 需要在隊列中等待。這也就是為什么 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

結果如下：

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

四、總結

前面列舉了大量的案例，接下來我們做個總結，實質性影響 其實就是幾個方面。

五、優(yōu)化舉措