如何讓網(wǎng)站加載速度變快（干貨！）

作者：橙紅年代

鏈接：https://juejin.cn/post/6844904078447755271

從剛學(xué)前端開(kāi)始就開(kāi)始折騰博客，一直在嘗試如何讓博客訪問(wèn)變快，本文總結(jié)了一些從前端的角度讓站點(diǎn)打開(kāi)速度變快的方案。

這里的網(wǎng)站加載速度，指的是從輸入地址欄，到頁(yè)面完整展示整個(gè)頁(yè)面的過(guò)程，包括加載HTML文檔、加載頁(yè)面靜態(tài)資源等過(guò)程。

提前請(qǐng)求

可以把一些資源提前準(zhǔn)備好，當(dāng)訪問(wèn)頁(yè)面時(shí)就可以加快加載速度。

DNS預(yù)解析

DNS查詢(xún)也是需要消耗網(wǎng)絡(luò)資源的，可以通過(guò)DNS預(yù)解析來(lái)優(yōu)化頁(yè)面的加載速度，X-DNS-Prefetch-Control頭控制著瀏覽器的 DNS 預(yù)讀取功能。

DNS 預(yù)讀取是一項(xiàng)使瀏覽器主動(dòng)去執(zhí)行域名解析的功能，其范圍包括文檔的所有鏈接，無(wú)論是圖片的，CSS 的，還是 JavaScript 等其他用戶(hù)能夠點(diǎn)擊的 URL。

因?yàn)轭A(yù)讀取會(huì)在后臺(tái)執(zhí)行，所以 DNS 很可能在鏈接對(duì)應(yīng)的東西出現(xiàn)之前就已經(jīng)解析完畢。這能夠減少用戶(hù)點(diǎn)擊鏈接時(shí)的延遲，詳情參考DNS預(yù)讀取-MDN^[1]。預(yù)解析的實(shí)現(xiàn)有如下方式：

用meta信息來(lái)告知瀏覽器, 當(dāng)前頁(yè)面要做DNS預(yù)解析:

"x-dns-prefetch-control"?content="on"?/>
復(fù)制代碼

在頁(yè)面header中使用link標(biāo)簽來(lái)強(qiáng)制對(duì)DNS預(yù)解析:

"dns-prefetch"?href="http://bdimg.share.baidu.com"?/>
復(fù)制代碼

Chrome內(nèi)置了DNS Prefetching技術(shù)，F(xiàn)irefox 3.5 也引入了這一特性，由于Chrome和Firefox 3.5本身對(duì)DNS預(yù)解析做了相應(yīng)優(yōu)化設(shè)置，所以設(shè)置DNS預(yù)解析的不良影響之一就是可能會(huì)降低使用上述瀏覽器的用戶(hù)體驗(yàn)。

preload

由于script標(biāo)簽加載同步腳本文件會(huì)阻塞文檔的解析，可以通過(guò)link標(biāo)簽的preload標(biāo)簽預(yù)加載腳本文件，并將文件內(nèi)容保存在內(nèi)容中，但是不會(huì)執(zhí)行，只有當(dāng)遇到script標(biāo)簽加載的也是preload相同的腳本資源時(shí)，才會(huì)執(zhí)行預(yù)加載的腳本

"preload"?href="/index.js"?as="script">


復(fù)制代碼

prefetch

在瀏覽器空閑的時(shí)候，現(xiàn)在對(duì)應(yīng)資源，并緩存到磁盤(pán)上，當(dāng)有頁(yè)面使用該資源時(shí)，直接從磁盤(pán)緩存讀取。

"/index.js"?rel="prefetch">
復(fù)制代碼

需要注意的是，如果prefetch還沒(méi)下載完之前，瀏覽器發(fā)現(xiàn)script標(biāo)簽也引用了同樣的資源，就會(huì)重復(fù)再次發(fā)起請(qǐng)求，因此不要再馬上需要使用資源的頁(yè)面上使用prefetch，此時(shí)應(yīng)該換用preload

加快請(qǐng)求資源

在當(dāng)前頁(yè)面的加載中，我們需要盡可能保證資源加載的速度。

瀏覽器最大請(qǐng)求域名限制

參考：

• 瀏覽器同域名請(qǐng)求的最大并發(fā)數(shù)限制^[2]
• 為什么利用多個(gè)域名來(lái)存儲(chǔ)網(wǎng)絡(luò)資源會(huì)更有效^[3]
• 瀏覽器允許的并發(fā)請(qǐng)求資源數(shù)是什么意思？^[4]

瀏覽器對(duì)同一個(gè)服務(wù)器的并發(fā)連接個(gè)數(shù)都是有限制，如果請(qǐng)求的文件數(shù)量過(guò)多，瀏覽器只會(huì)先下載最大并發(fā)數(shù)的文件，后續(xù)文件需要等待前面文件下載完畢后才會(huì)繼續(xù)請(qǐng)求，這就導(dǎo)致文件下載完畢的總體時(shí)間增加，參考不同瀏覽器對(duì)于同一域名請(qǐng)求并發(fā)數(shù)目限制^[5]

常見(jiàn)的處理方式是：通過(guò)多個(gè)域名增加瀏覽器對(duì)來(lái)自同一網(wǎng)頁(yè)的文件請(qǐng)求并發(fā)數(shù)。一般來(lái)講，在線上項(xiàng)目中，靜態(tài)資源都會(huì)使用單獨(dú)的域名來(lái)進(jìn)行加載

• 靜態(tài)內(nèi)容和動(dòng)態(tài)內(nèi)容分服務(wù)器存放，使用不同的服務(wù)器處理請(qǐng)求。數(shù)據(jù)服務(wù)器處理動(dòng)態(tài)內(nèi)容，CDN服務(wù)器提供靜態(tài)資源，這樣各司其職，且使得CDN緩存更方便

• 突破瀏覽器并發(fā)限制，瀏覽器同一時(shí)間可以從一個(gè)域名下載資源的數(shù)目有限制，這種技術(shù)被稱(chēng)為domain hash

• 獨(dú)立的域名不會(huì)攜帶Cookie等用戶(hù)身份信息，減少了請(qǐng)求頭的大小，可以節(jié)省帶寬，這種技術(shù)被稱(chēng)為``cookie free`

但是過(guò)多的域名會(huì)增加DNS解析耗時(shí)問(wèn)題，可以通過(guò)前面的DNS預(yù)解析來(lái)減緩這個(gè)問(wèn)題

減少請(qǐng)求數(shù)量

http協(xié)議是無(wú)狀態(tài)的應(yīng)用層協(xié)議，意味著每次http請(qǐng)求都需要建立通信鏈路、進(jìn)行數(shù)據(jù)傳輸，而在服務(wù)器端，每個(gè)http都需要啟動(dòng)獨(dú)立的線程去處理。這些通信和服務(wù)的開(kāi)銷(xiāo)都很昂貴，減少http請(qǐng)求的數(shù)目可有效提高訪問(wèn)性能。

減少http請(qǐng)求數(shù)量的主要手段是合并CSS、JavaScript、圖片等靜態(tài)資源。

• 通過(guò)webpack等打包工具，將Javascript和CSS進(jìn)行合并
• 將圖片合并成雪碧圖或者直接轉(zhuǎn)換成base64內(nèi)聯(lián)，可以控制小圖標(biāo)的請(qǐng)求數(shù)量和體積
• 按需加載資源，圖片懶加載，優(yōu)先加載首屏資源等方式
• 使用字體圖標(biāo)替代圖片小圖標(biāo)

此外，恰當(dāng)?shù)木彺嬖O(shè)置可以大大的減少 HTTP請(qǐng)求，因?yàn)楸粸g覽器緩存的資源在有效期內(nèi)不會(huì)重新發(fā)送請(qǐng)求。

合并文件帶來(lái)的一個(gè)問(wèn)題是：如果是單個(gè)一個(gè)模塊改動(dòng)，也會(huì)導(dǎo)致整個(gè)合并文件并重新下載，對(duì)于緩存來(lái)說(shuō)是很不利的，因?yàn)槠渌锤牡哪K內(nèi)部完全是不需要更新下載的。因此，目前的打包策略是：將不經(jīng)常修改的庫(kù)文件打包到一個(gè)文件如vendor.js，而經(jīng)常變化的業(yè)務(wù)代碼打包到一個(gè)文件如index.js。

壓縮文件體積

在服務(wù)器端對(duì)文件進(jìn)行壓縮，在瀏覽器端對(duì)文件解壓縮，可有效減少通信傳輸?shù)臄?shù)據(jù)量，加快文件傳輸速度。在目前的項(xiàng)目中，一般會(huì)使用下面

• 使用UglifyJS壓縮JS文件，
• 使用PostCSS壓縮CSS文件
• 使用imagemin來(lái)壓縮圖片，這里推薦一個(gè)超級(jí)好用的圖片壓縮工具TinyPNG^[6]。

壓縮代碼文件還可以達(dá)到混淆代碼的目的。一套比較完善的前端開(kāi)發(fā)環(huán)境下，一般提供了內(nèi)置的工具來(lái)實(shí)現(xiàn)上述需求。

此外，由于文本文件的壓縮效率可達(dá)到80%以上，因此HTML、CSS、javascript等靜態(tài)資源文件啟用GZip壓縮可達(dá)到較好的效果。由于GZip壓縮對(duì)服務(wù)器和瀏覽器產(chǎn)生一定的壓力，在通信帶寬良好，而服務(wù)器資源不足的情況下要權(quán)衡考慮。

HTTP2帶來(lái)的影響

參考：淺析HTTP/2的多路復(fù)用^[7]。

HTTP2提供了一些新的特性，如Keep-Alive、多路復(fù)用等，基于這些特性，我們的一些優(yōu)化措施可能就不再是必要的了

Keep-Alive可以實(shí)現(xiàn)：一定時(shí)間內(nèi)，同一域名多次請(qǐng)求數(shù)據(jù)，只建立一次HTTP請(qǐng)求，其他請(qǐng)求可復(fù)用每一次建立的連接通道，以達(dá)到提高請(qǐng)求效率的問(wèn)題，此時(shí)我們也就不再需要合并靜態(tài)資源文件。

多路復(fù)用基于新增的二進(jìn)制分幀層。二進(jìn)制分幀層將數(shù)據(jù)轉(zhuǎn)換成二進(jìn)制，也就是說(shuō)HTTP/2中所有的內(nèi)容都是采用二進(jìn)制傳輸。

*?幀是HTTP2中數(shù)據(jù)傳輸?shù)淖钚挝唬?br>*?每個(gè)幀都有stream_ID字段，表示這個(gè)幀屬于哪個(gè)流
*?接收方把stream_ID相同的所有幀組合到一起就是被傳輸?shù)膬?nèi)容了。
復(fù)制代碼

在這種傳輸模式下，HTTP請(qǐng)求變得十分廉價(jià)，我們不需要再時(shí)刻顧慮網(wǎng)站的http請(qǐng)求數(shù)是否太多、TCP連接數(shù)是否太多、是否會(huì)產(chǎn)生阻塞等問(wèn)題了，同樣地，我們也就不再需要為靜態(tài)資源分配多個(gè)域名，節(jié)省了DNS開(kāi)銷(xiāo)。

由于目前并非所有服務(wù)器和瀏覽器都支持HTTP2協(xié)議，因此這里主要是做一點(diǎn)擴(kuò)展，前面提到的文件合并、并發(fā)限制還是有必要在項(xiàng)目中進(jìn)行優(yōu)化的。

使用瀏覽器緩存

靜態(tài)資源本身具有訪問(wèn)頻率高、承接流量大的特點(diǎn)，因此靜態(tài)資源加載速度始終是前端性能的一個(gè)非常關(guān)鍵的指標(biāo)。

由于靜態(tài)資源的更新頻率很低，如果將這些文件緩存在瀏覽器中，可以極大程度低減少文件請(qǐng)求數(shù)量，加快資源加載。

瀏覽器緩存機(jī)制有四個(gè)方面，它們按照獲取資源時(shí)請(qǐng)求的優(yōu)先級(jí)依次排列如下：

• Memory Cache，放在內(nèi)存中的資源緩存，如base64圖片，體積較小的JS和CSS代碼
• Service Worker Cache，Service Worker 是一種獨(dú)立于主線程之外的 Javascript 線程，可以幫我們實(shí)現(xiàn)離線緩存、消息推送和網(wǎng)絡(luò)代理等功能
• HTTP Cache，分為強(qiáng)緩存和協(xié)商緩存，是我們需要著重處理的緩存
• Push Cache，是指 HTTP2 在 server push 階段存在的緩存，這種一種會(huì)在與會(huì)話階段的緩存，session終止時(shí)緩存就會(huì)被釋放

Service Worker Cache

參考：

• Cache - MDN^[8]
• Service Worker API^[9]

Service worker是一個(gè)注冊(cè)在指定源和路徑下的事件驅(qū)動(dòng)worker^[10]，它采用JavaScript控制關(guān)聯(lián)的頁(yè)面或者網(wǎng)站，攔截并修改訪問(wèn)和資源請(qǐng)求，細(xì)粒度地緩存資源。你可以完全控制應(yīng)用在特定情形（最常見(jiàn)的情形是網(wǎng)絡(luò)不可用）下的表現(xiàn)。

這里有一個(gè)官方的demo^[11]，展示了使用Service Worker來(lái)控制緩存，其大致實(shí)現(xiàn)思路是

• 在worker中監(jiān)聽(tīng)fetch事件，判斷請(qǐng)求資源是否匹配cache.match
• 如果命中worker緩存，則直接返回；如果未命中，則繼續(xù)發(fā)送請(qǐng)求到服務(wù)器
• 獲取響應(yīng)結(jié)果，catch.put緩存到本地，然后返回響應(yīng)，下次請(qǐng)求時(shí)則可以直接返回緩存

這種方式提供了讓前端控制請(qǐng)求和響應(yīng)的API，可以實(shí)現(xiàn)顆粒化的緩存。

HTTP Cache

參考：前端必須要懂的瀏覽器緩存機(jī)制](juejin.cn/post/684490…^[12])

當(dāng)客戶(hù)端請(qǐng)求某個(gè)資源時(shí)，緩存的工作流程如下：

• 首先判斷請(qǐng)求資源是否緩存在本地，如果存在，則通過(guò)max-age等字段進(jìn)行新鮮度校驗(yàn)
• 校驗(yàn)通過(guò)，直接返回本地緩存文件200(from cache)
• 校驗(yàn)不通過(guò)，則向服務(wù)器發(fā)送再驗(yàn)證請(qǐng)求
• 服務(wù)器接收到再驗(yàn)證請(qǐng)求，檢測(cè)文件是否通過(guò)再驗(yàn)證
• 不存在，返回404，瀏覽器刪除本地緩存，返回404(not found)
• 存在，返回新資源，瀏覽器將新資源緩存到本地，返回200
• 再驗(yàn)證通過(guò)，文件未更新，返回304，瀏覽器更新本地文件新鮮度，返回緩存文件304(not modified)
• 再驗(yàn)證未通過(guò)，檢測(cè)資源是否存在
• 當(dāng)首次請(qǐng)求新資源時(shí)，同上述檢測(cè)資源存在后的處理流程

根據(jù)上面流程，我們可以看見(jiàn)兩處檢測(cè)，針對(duì)本地緩存文件的新鮮度校驗(yàn)和服務(wù)器的再驗(yàn)證，這兩步也可以看做是瀏覽器的強(qiáng)緩存和協(xié)商緩存策略。

強(qiáng)緩存

新鮮度校驗(yàn)的主要作用是瀏覽器自己檢測(cè)本地緩存文件是否已經(jīng)失效，與下面幾個(gè)字段有關(guān)

• Expires，該字段是 http1.0 時(shí)的規(guī)范，值為一個(gè)絕對(duì)時(shí)間的 GMT 格式的時(shí)間字符串，代表緩存資源的過(guò)期時(shí)間。由于很多服務(wù)器跟客戶(hù)端存在時(shí)鐘不一致的情況，因此該字段代表的過(guò)期時(shí)間并不是十分準(zhǔn)確
• Cache-Control:max-age，該字段是 http1.1 的規(guī)范，強(qiáng)緩存利用其 max-age 值來(lái)判斷緩存資源的最大生命周期，它的值單位為秒
• 如果如果同時(shí)設(shè)置了Cache-Control和Expires，Cache-Control會(huì)覆蓋Expires

協(xié)商緩存

再驗(yàn)證主要用于瀏覽器向服務(wù)器詢(xún)問(wèn)本地緩存是否已經(jīng)失效，有兩種方式。

一種是詢(xún)問(wèn)文件的最后修改

• Last-Modified，值為資源最后更新時(shí)間，單位精確到秒，隨服務(wù)器response返回
• If-Modified-Since，通過(guò)比較兩個(gè)時(shí)間來(lái)判斷資源在兩次請(qǐng)求期間是否有過(guò)修改，如果沒(méi)有修改，則命中協(xié)商緩存

另外一種是詢(xún)問(wèn)文件的內(nèi)容是否發(fā)生變化

• ETag，表示資源內(nèi)容的唯一標(biāo)識(shí)，隨服務(wù)器response返回
• If-None-Match，服務(wù)器通過(guò)比較請(qǐng)求頭部的If-None-Match與當(dāng)前資源的ETag是否一致來(lái)判斷資源是否在兩次請(qǐng)求之間有過(guò)修改，如果沒(méi)有修改，則命中協(xié)商緩存

從字面意義可以看出，文件內(nèi)容的變換比最后修改時(shí)間的變化更具有參考性，因此If-None-Match的優(yōu)先級(jí)要大于If-modified-Since。

如果請(qǐng)求報(bào)文中同時(shí)包含這兩個(gè)首部，服務(wù)器會(huì)優(yōu)先驗(yàn)證資源標(biāo)識(shí)符而不是資源修改時(shí)間，則只有當(dāng)他們都滿(mǎn)足時(shí)，服務(wù)器才返回304 NOT Modified。

緩存更新策略

當(dāng)然靜態(tài)資源文件變化后，需要及時(shí)應(yīng)用到瀏覽器，在版本更新后，修改模板內(nèi)引用的資源名文件名，這樣就相當(dāng)于第一次訪問(wèn)新的資源，從而直接更新文件。在前端單頁(yè)應(yīng)用中，可以通過(guò)webpack-html-plugin等工具自動(dòng)更新打包資源文件名，從而繞開(kāi)緩存直接更新文件。

在這種更新策略下，

• HTML文件會(huì)使用協(xié)商緩存，每次訪問(wèn)時(shí)都校驗(yàn)新鮮度，避免HTML緩存導(dǎo)致用戶(hù)無(wú)法及時(shí)更新到新版本
• CSS、JS、圖片等靜態(tài)資源文件使用強(qiáng)緩存，設(shè)置較長(zhǎng)的過(guò)期時(shí)間，并通過(guò)文件hash區(qū)分舊版資源

另外使用瀏覽器緩存策略的網(wǎng)站在更新靜態(tài)資源時(shí)，應(yīng)采用逐量更新的方法，比如需要更新10個(gè)圖標(biāo)文件，不宜把10個(gè)文件一次全部更新，而是應(yīng)該一個(gè)文件一個(gè)文件逐步更新，并有一定的間隔時(shí)間，以免用戶(hù)瀏覽器忽然大量緩存失效，集中更新緩存，造成服務(wù)器負(fù)載驟增、網(wǎng)絡(luò)堵塞的情況。

使用不同方式刷新瀏覽器，也會(huì)觸發(fā)不同的緩存校驗(yàn)機(jī)制

• 當(dāng) ctrl+f5 強(qiáng)制刷新網(wǎng)頁(yè)時(shí)，直接從服務(wù)器加載，跳過(guò)強(qiáng)緩存和協(xié)商緩存；
• 當(dāng) f5 刷新網(wǎng)頁(yè)時(shí)，跳過(guò)強(qiáng)緩存，但是會(huì)檢查協(xié)商緩存；

使用CDN

CDN是靜態(tài)資源提速的重要手段。

基本原理

參考

• CDN工作原理^[13]
• 《CDN 之我見(jiàn)》原理篇——CDN的由來(lái)與調(diào)度^[14]

CDN網(wǎng)絡(luò)是在用戶(hù)和服務(wù)器之間增加Cache層，如何將用戶(hù)的請(qǐng)求引導(dǎo)到Cache上獲得源服務(wù)器的數(shù)據(jù)，主要是通過(guò)接管DNS實(shí)現(xiàn)

當(dāng)業(yè)務(wù)需要接入到CDN時(shí)，用戶(hù)只需調(diào)整自己的DNS配置信息，從直接指向自己的源服務(wù)器，修改為CNAME類(lèi)型記錄，將域名指向CDN廠商所提供的接入域名即可。

未使用CDN，請(qǐng)求資源時(shí)解析域名過(guò)程如下

• 用戶(hù)向?yàn)g覽器提供要訪問(wèn)的域名，瀏覽器通過(guò)調(diào)用DNS解析服務(wù)，獲得該域名對(duì)應(yīng)的IP
• 瀏覽器使用該IP，建立連接并發(fā)送請(qǐng)求，最后根據(jù)服務(wù)器返回的數(shù)據(jù)顯示網(wǎng)頁(yè)內(nèi)容

使用了CDN，請(qǐng)求資源時(shí)解析域名過(guò)程如下

• 用戶(hù)向?yàn)g覽器提供要訪問(wèn)的域名，瀏覽器通過(guò)調(diào)用DNS解析服務(wù)，獲取到的是該域名對(duì)應(yīng)的CNAME記錄
• 由于CNAME實(shí)際還是域名，瀏覽器再次對(duì)獲得的CNAME域名進(jìn)行解析，以得到CND服務(wù)器的IP地址，在此過(guò)程中，會(huì)根據(jù)地理位置信息等解析返回距離用戶(hù)最近的IP地址
• 瀏覽器在得到最近CDN服務(wù)器的IP地址以后，發(fā)出請(qǐng)求，并根據(jù)服務(wù)器返回的數(shù)據(jù)顯示網(wǎng)頁(yè)內(nèi)容
• 此外，CND緩存服務(wù)器還會(huì)根據(jù)瀏覽器訪問(wèn)的原始域名，通過(guò)Cache內(nèi)部專(zhuān)用DNS解析得到此域名原始服務(wù)器的實(shí)際IP地址，再由緩存服務(wù)器向此實(shí)際IP地址提交訪問(wèn)請(qǐng)求，判斷是否需要更新CND服務(wù)器上的緩存數(shù)據(jù)

配置CNAME

下面是配置七牛cdn加速的操作流程，通過(guò)配置可以體會(huì)到CNAME的工作原理

• 首先去七牛管理后臺(tái)添加一個(gè)域名^[15]，如cdn.shymean.com，后續(xù)內(nèi)容管理里面的資源都可以通過(guò)該域名進(jìn)行訪問(wèn)。
• 添加完畢后，可以得到一個(gè)CNAMEcdn.shymean.com.qiniudns.com，復(fù)制該CNAME，然后去域名管理后臺(tái)（我的域名是阿里云萬(wàn)網(wǎng)購(gòu)買(mǎi)的），新增域名解析，將cdn.shymean.com選擇CNAME解析方式，解析到cdn.shymean.com.qiniudns.com上
• 然后就大功告成了。

可以看見(jiàn)，CNMAE實(shí)際上就是CDN服務(wù)商提供的一個(gè)域名， 由于靜態(tài)資源往往不需要用戶(hù)信息如Cookie等，因此可以使用獨(dú)立的cdn域名來(lái)訪問(wèn)。

總結(jié)

本文總結(jié)了前端性能優(yōu)化中一個(gè)比較重要的場(chǎng)景：讓網(wǎng)站加載速度變快

• 提前準(zhǔn)備請(qǐng)求需要的DNS、靜態(tài)文件等資源
• 加快資源訪問(wèn)速度，如繞開(kāi)瀏覽器統(tǒng)一域名并發(fā)數(shù)量限制、合并請(qǐng)求文件、壓縮體積等
• 了解瀏覽器緩存原理，通過(guò)緩存進(jìn)一步減少文件請(qǐng)求數(shù)量
• 了解CDN使用及相關(guān)原理，配置CDN加快靜態(tài)資源的訪問(wèn)

此外，還整理了在HTTP2為當(dāng)前某些優(yōu)化手段帶來(lái)的一些影響。前端性能優(yōu)化除了頁(yè)面訪問(wèn)速度之外，還有其他如交互性能流暢等方面的優(yōu)化，后續(xù)會(huì)繼續(xù)整理。

參考

• 首屏?xí)r間從12.67s到1.06s，我是如何做到的？^[16]
• 你必須懂的前端性能優(yōu)化^[17]
• 《HTTP權(quán)威指南》讀書(shū)筆記^[18]

參考資料