前端資源請求速度優(yōu)化

DNS解析

<link rel="dns-prefetch" href="https://fonts.googleapis.com" />

DNS與解析只能解析不同域，同域是不能解析的，因為已經(jīng)解析完了。dns-prefetch要慎用，不要每個頁面都添加，會造成資源浪費。

默認情況下瀏覽器會對當(dāng)前頁面中所有出現(xiàn)的域名進行預(yù)解析，及時沒有寫link標簽，這是隱式解析。

HTTP1.1長鏈接

經(jīng)過DNS解析獲取到IP之后就要進行TCP的鏈接進行數(shù)據(jù)傳輸。

HTTP協(xié)議的初始版本中，每進行一次HTTP通信就要斷開一次TCP鏈接，也就是短連接。

以早期的通信情況來說，因為都是些容量很小的文本傳輸，所以即使這樣也沒有多大問題，但是隨著HTTP的大量普及，文旦中包含大量富文本的情況多了起來。每次的請求都會造成無謂的TCP鏈接建立和斷開，增加通信錄的開銷。

為了解決這個問題，有些瀏覽器在請求時，用了一個非標準的Connection字段。這個字段要求服務(wù)器不要關(guān)閉TCP鏈接，以便其他請求復(fù)用，服務(wù)器同樣回應(yīng)這個字段。

Connection: keep-alive

一個可以復(fù)用的TCP鏈接就建立了，直到客戶端或服務(wù)器主動關(guān)閉鏈接，但是這并非標準字段，不同實現(xiàn)的行為可能不一致，還可能造成混亂。

長鏈接

HTTP1.1版本在1997年1月發(fā)布，最大的變化就是引入了持久鏈接，即TCP鏈接默認不關(guān)閉，可以被多個請求復(fù)用，不需要再聲明Connection: keep-alive。

持久連接減少了TCP鏈接的重復(fù)建立和斷開所造成的的額外開銷，減輕了服務(wù)器端的負載。減少開銷的時間讓HTTP請求和響應(yīng)能夠更早的結(jié)束，這樣Web頁面的速度也就響應(yīng)變快了。

客戶端和服務(wù)器發(fā)現(xiàn)對方一段時間沒有活動，就可以主動關(guān)閉鏈接，不過規(guī)范的做法是客戶端在最后一個請求時發(fā)送Connection: close，明確要求服務(wù)器關(guān)閉鏈接。目前對于同一個域名，大多數(shù)瀏覽器允許同時建立6個持久鏈接。

管道機制

同一個TCP鏈接里面客戶端可以同時發(fā)送多個請求，這樣就進一步改變了HTTP協(xié)議的效率。

從前發(fā)送請求后需等待及接收響應(yīng)，才能發(fā)送下一個請求，管道化技術(shù)出現(xiàn)后不用等待響應(yīng)即可直接發(fā)送下一個請求，這樣就能夠做到同時并行發(fā)送多個請求，而不需要一個接一個的等待響應(yīng)了。

管道化技術(shù)比持久化鏈接還要快，請求數(shù)越多時間差越明顯。

一個TCP鏈接可以傳送多個回應(yīng)，勢必就要有一種機制，區(qū)分數(shù)據(jù)包是屬于哪一個回應(yīng)的，這就是Content-length字段的作用，聲明本次回應(yīng)的數(shù)據(jù)長度。

Content-Length: 3000

上面代碼告訴瀏覽器，本次回應(yīng)的長度是3000個字節(jié)，后面的字節(jié)就屬于下一個回應(yīng)了。

在1.0版本中，Content-Length字段不是必須的，因為瀏覽器發(fā)現(xiàn)服務(wù)器關(guān)閉了TCP鏈接，就表明收到的數(shù)據(jù)包已經(jīng)完成了。

分塊傳輸

使用Content-Length字段的前提條件是，服務(wù)器發(fā)送回應(yīng)之前，必須知道回應(yīng)的數(shù)據(jù)長度。

對于一些耗時的動態(tài)操作來說，意味著，服務(wù)器要等到所有操作完成，才能發(fā)送數(shù)據(jù)，顯然這樣的效率不高，更好的方法是產(chǎn)生一塊數(shù)據(jù)就發(fā)送一塊，采用流模式取代緩存模式。

因此1，1規(guī)定可以不使用content-length字段，而是用分塊傳輸編碼，只要請求或響應(yīng)頭信息有Transfer-Encoding字段，就表明響應(yīng)將又數(shù)量未定的數(shù)據(jù)塊組成。

Transfer-Encoding: chunked

每個非空數(shù)據(jù)塊之前會有一個16進制的數(shù)值，表示這個塊的的長度，最后是一個大小為0的塊，表示本次回應(yīng)的數(shù)據(jù)發(fā)送完了。

HTTP/1.1 200 OK...25This is the data in the first chunk...2...4...0...

雖然HTTP1.1允許復(fù)用TCP鏈接，但是同一個TCP鏈接里面，所有的數(shù)據(jù)通信是按次序進行的，服務(wù)器只有處理完一個回應(yīng)才會進行下一個回應(yīng)。

如果前面的請求慢，后面就會有需要請求排隊，稱為對頭阻塞。

為了避免這種問題，可以減少請求數(shù)或者同事多開持續(xù)請求。

這就出現(xiàn)了很多的優(yōu)化技巧，比如說。合并腳本和樣式表，將圖片嵌入css代碼，域名分片等等。

其實如果HTTP協(xié)議設(shè)計的更好一些，這些額外的工作都是可以避免的。

HTTP2協(xié)議

為了解決響應(yīng)阻塞問題2015年推出了HTTP2。

HTTP2主要用于解決HTTP1.1效率不高的問題，他不叫HTTP2.0是因為不打算發(fā)布子版本了，下一個版本直接就叫HTTP3。

二進制協(xié)議

HTTP1.1頭信息肯定是文本，數(shù)據(jù)體可以是文本也可以是二進制，HTTP2則是一個徹底的二進制協(xié)議，頭信息和數(shù)據(jù)體都是二進制，并且統(tǒng)稱為幀，頭信息幀和數(shù)據(jù)幀。

二進制協(xié)議的一個好處是可以定義額外的幀，HTTP2定了一近十種幀，為將來的高級應(yīng)用打好基礎(chǔ)，如果使用文本實現(xiàn)這種功能，解析數(shù)據(jù)將會變得非常麻煩，二進制解析則方便很多。

多工

HTTP2復(fù)用TCP鏈接，在一個鏈接里，客戶端和瀏覽器都可以同時發(fā)送多個請求或回應(yīng)，而且不用按照順序一一對應(yīng)，這樣就避免了堵塞。

在一個TCP鏈接里面，服務(wù)器同時收到了A請求和B請求，先回應(yīng)了A請求結(jié)果發(fā)現(xiàn)處理過程非常耗時，先發(fā)送A請求已經(jīng)處理好的部分，再回應(yīng)B請求，完成后再發(fā)送A請求剩余的部分。

這種雙向的，實時通信就叫做多工。

效果地址: https:http2.akamai.com/demo

數(shù)據(jù)流

因為HTTP2的數(shù)據(jù)包是不按順序發(fā)送的，同一個鏈接里面連續(xù)的數(shù)據(jù)包，可能屬于不同的回應(yīng)，因此必須要對數(shù)據(jù)包做標記，指出他屬于哪個回應(yīng)。

HTTP2將每個請求或回應(yīng)的所有數(shù)據(jù)包，稱為一個數(shù)據(jù)流，每個數(shù)據(jù)流都有一個獨一無二的編號，數(shù)據(jù)包發(fā)送的時候，都必須標記數(shù)據(jù)流ID，用來區(qū)分它屬于哪個數(shù)據(jù)流，另外還規(guī)定，客戶端發(fā)出的數(shù)據(jù)流，ID一律為奇數(shù)，服務(wù)器發(fā)布的，ID為偶數(shù)。

數(shù)據(jù)流發(fā)送到一半的時候，客戶端和服務(wù)器都可以發(fā)送信號取消這個數(shù)據(jù)流。

1.1版本取消數(shù)據(jù)的唯一方法就是關(guān)閉TCP鏈接，HTTP2可以取消某一次請求，同時保證TCP鏈接還開著，可以被其他請求使用。

客戶端還可以指定數(shù)據(jù)流的優(yōu)先級，優(yōu)先級越高，服務(wù)器就會越早回應(yīng)。

壓縮頭信息

HTTP協(xié)議不帶有狀態(tài)，每次請求都必須附上所有信息，所以請求的很多字段都是重復(fù)的，比如Cookie和User Agent，一模一樣的內(nèi)容每次請求都必須附帶，這會浪費很多帶寬也影響速度。

HTTP2對這一點做了優(yōu)化，引入了頭信息壓縮機制，一方面頭信息使用gzip或compress壓縮后再發(fā)送。

另一方面，客戶端和服務(wù)器同時維護一張頭信息表，所有字段都會存入這個表，生成一個索引號，以后就不發(fā)送這個字段只發(fā)送索引號這樣就提高速度了。

服務(wù)器推送

HTTP2允許服務(wù)器未經(jīng)過請求主動向客戶端發(fā)送資源，這就叫服務(wù)器推送。

常見場景是客戶端請求一個網(wǎng)頁，這個網(wǎng)頁包含很多靜態(tài)資源，正常情況下，客戶端必須收到網(wǎng)頁后解析html編碼，發(fā)現(xiàn)有靜態(tài)資源再發(fā)出靜態(tài)資源請求，其實服務(wù)器可以預(yù)期到客戶端請求網(wǎng)頁后很可能會再請求靜態(tài)資源，所有就主動把這些靜態(tài)資源隨著網(wǎng)頁一起發(fā)給客戶端了。

這個功能還是建議考慮自身的需要，會增加一部分成本開銷。

壓縮傳輸數(shù)據(jù)資源

通過壓縮傳輸數(shù)據(jù)資源提升性能體驗。默認HTTP進行數(shù)據(jù)傳輸數(shù)據(jù)是沒有進行壓縮的，原始數(shù)據(jù)多大傳輸?shù)臄?shù)據(jù)就多大。

我們都知道文件壓縮之后數(shù)據(jù)體積減少是很客觀的。

響應(yīng)數(shù)據(jù)壓縮

HTTP響應(yīng)數(shù)據(jù)一般會根據(jù)數(shù)據(jù)的類型進行壓縮方案的處理，比如文本最常用的方案就是Gzip的壓縮方案，目前大部分的網(wǎng)站都采用這種壓縮方式。

gzip

瀏覽器再請求服務(wù)器的時候會在請求頭中通過Accept-Encoding字段標識可以接收gzip壓縮方案，服務(wù)器在收到請求后可以獲取到這種壓縮方案，將資源壓縮后返回給瀏覽器，并且在響應(yīng)頭中加入Content-Encoding字段，值為gzip。

如果客戶端不添加Accept-Encoding頭，服務(wù)器返回了Content-Encoding，客戶端如果支持的話也會正常解析。

Accept-Encoding基本是瀏覽器自動添加的。

const zlib = require('zlib');const fs = require('fs');const rs = fs.cerateReadStream('jquery.js');const ws = fs.cerateWriteStream('jquery.js.gz');const gz = zlib.createGzip();rs.pipe(gz).pipe(ws);ws.on('error', (err) => {   console.log('失敗');})ws.on('finish', () => {   console.log('完成')})

正常工作中g(shù)zip一般可以在nginx服務(wù)器中開啟，不需要自己編寫。還是比較簡單的。

gzip一般是針對文本文件，比如js，css，對于圖片來說一般是在開發(fā)階段壓縮。

請求數(shù)據(jù)壓縮

HTTP2以前請求頭是不可以壓縮的，HTTP2引入了頭信息壓縮機制，一方面頭信息使用gzip或express壓縮后再發(fā)送。

另一方面，客戶端和服務(wù)器同時維護一張頭信息表，通過索引字段來傳輸，減少廳信息數(shù)據(jù)體積。

實際工作中會存在請求正文非常大的場景，比如發(fā)表長篇博客，上報用于調(diào)試網(wǎng)絡(luò)數(shù)據(jù)等等，這些數(shù)據(jù)如果能在本地壓縮后再提交就可以節(jié)省網(wǎng)絡(luò)流量，減少傳輸時間。

DFLATE是一種使用Lempel-Ziv壓縮算法的哈夫曼編碼壓縮格式。

ZLIB是一種使用DEFLATE的壓縮格式。

GZIP是一種使用DEFLATE的壓縮格式。

Content-Encoding中的deflate實際上是ZLIB。

前端發(fā)送的時候可以進行壓縮：

const rawBody = 'content=test';const rawLen = rawBody.length;const bufBody = new Unit8Array(rawLen);for (let i = 0; i < rawLen; i++) {   bufBody[i] = rawBody.charCodeAt(i);}const format = 'gzip';let buf;switch (format) {   case gzip': buf = window.pako.gzip(bufBody); break;}const xhr = new XMLHttpRequest();xhr.open('POST', '/service/');xhr.setRequestHeader('Content-Encoding', format);xhr.setRequestHeader('Content-type', 'application/x-www-form-urlencoded')xhr.send(buf);

服務(wù)器端進行解壓

const http = require('http');const zlib = require('zlib');http.createServer((req, res) => {   let zlibStream;   const encoding = req.headers['content-encoding']   switch (encoding) {       case 'gzip' : zlibStream = zlib.createGunzip(); break;   }   res.writeHead(200, { 'Content-Type': 'text/plain' });   req.pipe(zlibStream).pipe(res);}).listen(3000)

這種壓縮一半也只適用于文本，如果數(shù)據(jù)量太大壓縮過程也是比較耗時的。

緩存

緩存的原理是在客戶端首次請求后保存一份請求資源的響應(yīng)副本存儲在客戶端中，當(dāng)用戶再次發(fā)起相同的請求后，如果判斷緩存命中則攔截請求，將之前緩存的響應(yīng)副本返回給用戶，從而避免重新向服務(wù)器發(fā)起資源請求。

緩存的技術(shù)種類有很多，比如代理緩存，瀏覽器緩存，網(wǎng)關(guān)緩存，負載均衡器及內(nèi)容分發(fā)網(wǎng)絡(luò)等，大致可以分為兩類，共享緩存和私有緩存。

共享緩存指的是緩存內(nèi)容可以被多個用戶使用，如公司內(nèi)部架設(shè)的Web代理，私有緩存是只能單獨被用戶使用的緩存，如瀏覽器緩存。

HTTP緩存是前端開發(fā)中最常接觸的緩存機制之一，他又可細分為強制緩存與協(xié)商緩存，二者最大的區(qū)別在于判斷緩存命中時瀏覽器是否需要向服務(wù)器進行詢問。

強制緩存不會去詢問，協(xié)商緩存則仍舊需要詢問服務(wù)器。

強制緩存

對于強制緩存而言，如果瀏覽器判斷所請求的目標資源有效命中則可直接從強制緩存中返回請求的響應(yīng)，無需與服務(wù)器進行任何通信。

也就是說強制緩存是在客戶端進行的，這樣速度就會很快。

強制緩存相關(guān)的兩個字段是expires和cache-control。

expires是在HTTP1.0協(xié)議中聲明的用來控制緩存失效日期的時間戳字段，他由服務(wù)器指定并通過響應(yīng)頭告訴瀏覽器，瀏覽器在收到帶有該字段的響應(yīng)體后進行緩存。

之后瀏覽器再發(fā)送相同的請求便會對比expires與本地當(dāng)前的時間戳，如果當(dāng)前請求的本地時間戳小于expires的值，則說明緩存還未過期，可以直接使用。

否則緩存過期重新向服務(wù)器發(fā)送請求獲取響應(yīng)體。

res.writeHEAD(200, {   Expires: new Date('2021-6-18 12: 51: 00').toUTCString(),})

expires存在一個很大的漏洞就是對本地時間戳過分依賴，如果客戶端本地的時間與服務(wù)器時間不同步，或者客戶端時間被修改，那么緩存過期的判斷可能就無法和預(yù)期相符。

為了解決這個問題，HTTP1.1新增了cache-control字段來對expires的功能進行擴展和完善。

cache-control的值為maxage=xxx來控制響應(yīng)資源的有效期，xxx是一個以秒為單位的時間長度，表示該資源在被請求到的一段時間內(nèi)有效，以此便可避免服務(wù)端和客戶端時間戳不同步而造成的問題。

res.writeHEAD(200, {   'Cache-Control': 'maxage=1000',})

除了maxage還可以設(shè)置其他參數(shù)，比如no-cache和no-store。

no-cache表示強制進行協(xié)商緩存，對于每次發(fā)起的請求不會再去判斷強制緩存是否過期，而是直接進行協(xié)商緩存。協(xié)商緩存后面會說到。

no-store表示禁止使用任何緩存策略，客戶端的每次請求都直接從服務(wù)器獲取。也就是無緩存。

no-cache和no-store是互斥的，不能同時設(shè)置。

res.writeHEAD(200, {   'Cache-Control': 'no-cache',})

還有private和public，他們也是cache-control的一組互斥屬性值，他們用來明確響應(yīng)資源是否可被代理服務(wù)器進行緩存。

publicb表示響應(yīng)資源即可被瀏覽器緩存又可以被代理服務(wù)器緩存。private限制了響應(yīng)資源只能被瀏覽器緩存。

對于應(yīng)用程序中不會改變的文件比如圖片，js,css, 字體庫等通常可以使用公共緩存。

res.writeHEAD(200, {   'Cache-Control': 'public, max-age=31600',})

除了max-age還有s-maxage，max-age表示服務(wù)器告知瀏覽器的響應(yīng)資源的過期時長。一般使用它就足夠了了。

但如果是大型項目架構(gòu)通常會涉及代理服務(wù)器緩存，這就需要考慮緩存在代理服務(wù)器上的有效性問題，這便是s-maxage存在的意義。

他表示緩存在代理服務(wù)器上的過期時長，需要配合public來使用。

cache-control能作為expires的完全替代方案，目前expires只作為兼容使用。

協(xié)商緩存

協(xié)商緩存就是在使用本地緩存之前，需要向服務(wù)器發(fā)起一次GET請求，與之協(xié)商當(dāng)前瀏覽器保存的本地緩存是否已經(jīng)過期。

協(xié)商緩存主要解決的問題就是在強制緩存下資源不更新的問題。

客戶端在獲取到本地緩存后需要向服務(wù)器發(fā)送一次GET請求，這個請求的請求頭中包含if-modified-since字段，值是響應(yīng)頭中的last-modified字段，也就是這個資源的最后修改時間。

也就是說客戶端請求資源的時候服務(wù)器會返回響應(yīng)內(nèi)容及內(nèi)容的修改時間，修改時間存在last-modified字段中。

客戶端在請求的時候如果客戶端存儲了last-modified就將它的值放在if-modified-since字段中發(fā)送到服務(wù)器。

服務(wù)器接收到請求后通過比對前端傳過來的時間和資源的修改時間，如果二者相同則說明緩存未過期，就告訴瀏覽器直接使用緩存中的文件，如果過期了就返回對應(yīng)文件并且將新的修改日期重新返回。

客戶端繼續(xù)緩存新的修改時間。

const http = require('http');const fs = require('fs');const url = require(''url');http.creatServer((req, res) => {   const { pathname } = url.parse(req.url);   // 獲取文件日期   fs.stat(`www/${pathname}`, (err, stat) => {     if (err) {       res.writeHeader(404);       res.write('Not Found');       res.end();     } else {       if (req.headers['if-modified-since']) {         const oDate = new Date(req.headers['if-modified-since']);         const time_client = Math.floor(oDate.getTime() / 1000);         const time_server = Math.floor(stat.mtime.getTime() / 1000);         if (time_server > time_client) { // 服務(wù)器的文件時間大于客戶端           sendFileToClient();         } else {           res.writeHeader(304);           res.write('Not Modified');           res.end();         }       } else {         sendFileToClient();       }       function sendFileToClient() {         let rs = fs.createReadStream(`www/${pathname}`);         res.setHeader('Last-Modifyed', state.mtime.toGMTString());         rs.pipe(res);         rs.on('error', err => {           res.writeHeader(404);           res.write('Not Found');           res.end();         })       }     }   })}).listen(8080);

上面的這種緩存方式存在兩個問題，首先他只是根據(jù)資源最后的修改時間戳進行判斷，如果文件沒有變更只是保存了一下修改時間也會變化。

其次標識時間是秒，如果修改特別快在毫秒內(nèi)完成(程序修改會有這樣的速度)，那么就無法識別緩存過期。

主要原因就是服務(wù)器無法僅依據(jù)資源修改的時間戳識別出真正的更新，進而導(dǎo)致緩存不準確。

為了解決這個問題從HTTP1.1規(guī)范開始新增了一個ETag的頭信息, 實體標簽。

其內(nèi)容主要是服務(wù)器為不同資源進行哈希運算生成的一個字符串，該字符串類似于文件指紋，只要文件內(nèi)容編碼存在差異，對應(yīng)的ETag標簽值就會不同，因此可以使用ETag對文件資源進行更精準的變化感知。

const etag = require('etag')res.setHeader('etag', etag(data));

基于ETag發(fā)送的請求會在請求頭中以If-None-Match傳遞給服務(wù)器。

在協(xié)商緩存中ETag并非last-modified的替代方案而是一種補充方案，因為他也存在一些問題。

首先，服務(wù)器對生成文件資源的ETag需要付出額外的計算開銷，如果資源體積較大，數(shù)量較多且修改較頻繁，那么生成ETag的過程會影響服務(wù)器的性能。

其次，ETag的值分為強驗證和弱驗證，強驗證根據(jù)資源內(nèi)容進行生成，能夠保證每個字節(jié)都相同。

弱驗證則根據(jù)資源的部分屬性值來生成，生成速度快但無法確保每次字節(jié)都相同。并且在服務(wù)器集群場景下，也會因為不夠準確而降低協(xié)商緩存的有效性和校驗的成功性。

恰當(dāng)?shù)姆绞绞歉鶕?jù)具體的資源使用場景選擇恰當(dāng)?shù)木彺嫘ｒ灧绞健?/span>

緩存策略

HTTP的緩存技術(shù)主要是為了提升網(wǎng)站的性能，如果不考慮客戶端緩存容量和服務(wù)器計算能力的理想情況，我們當(dāng)然希望客戶端瀏覽器上的緩存觸發(fā)率盡可能高，留存時間盡可能長，同時還要ETag實現(xiàn)當(dāng)資源更新時進行高效的重新驗證。

但實際情況往往是容量和計算能力都有限，因此就需要指定合適的緩存策略，利用有效的資源達到最優(yōu)的性能效果。

明確需求邊界，力求在邊界內(nèi)做到最好。

在使用緩存技術(shù)優(yōu)化性能的過程中，有一個問題是不可逾越的，我們既希望緩存能在客戶端盡可能長久的保存，又希望他能在資源發(fā)生修改時進行及時更新。這是兩個互斥的需求。

如何兼顧二者呢？

可以將網(wǎng)站所需要的資源按照不同的類型去拆解，為不同類型的資源制定相應(yīng)的緩存策略。

首先html文件是包含其他文件的主文件，為保證當(dāng)其發(fā)生改變能及時更新，應(yīng)該將其設(shè)置為協(xié)商緩存。

cache-control: no-cache

圖片文件的修改基本都是替換，同時考慮圖片文件的數(shù)量及大小可能對客戶端緩存空間造成不小的開銷，所以可以采用強制緩存且過期時間不宜過長。

cache-control: max-age=86400

css樣式表屬于文本文件，可能存在的內(nèi)容不定期修改，還想使用強制緩存來提高重用效率，故可以考慮在樣式表文件的命名中增加指紋或版本號(一般為hash值)，這樣發(fā)生修改后不同的文件便會有不同的文件指紋，也就是請求的url不同。

所以css的緩存時間可以設(shè)置長一些, 一年。

cache-control: max-age=31536000

js腳本文件可以類似樣式表的設(shè)置，采用指紋和較長的過期時間，如果js中包含了用戶的私人信息而不想讓中間代理緩存，可添加private屬性。

cache-control: private, max-age=31536000

緩存策略就是為不同的資源進行組合使用強制緩存，協(xié)商緩存及文件指紋或版本號，這樣可以做到一舉多得，及時修改更新，較長緩存過期時間及控制所能進行緩存的位置。

緩存設(shè)置需要注意不存在適用于所有場景下的最佳緩存策略，凡是恰當(dāng)?shù)木彺娌呗远夹枰鶕?jù)具體的場景考慮制定。

緩存決策要考慮下面幾種情況。

1）、拆分源碼，分包加載

對于大型項目來說，代碼里是非常龐大的，如果發(fā)生修改的部分集中在幾個重要的模塊中，那么進行全量的代碼更新顯然比較冗雜，因此可以考慮在代碼構(gòu)建過程中按照模塊拆分將其打包成多個單獨的文件。

這樣在每次修改后更新提取時，僅需拉取發(fā)生改變的模塊代碼包，從而大大降低了需要下載的內(nèi)容大小。

2）、預(yù)估資源的緩存時效

根據(jù)不同資源的不同需求特點來規(guī)劃響應(yīng)的緩存更新失效，為強制緩存指定合適的max-age，為協(xié)商緩存提供驗證更新的ETag實體標簽。

3）、控制中間代理的緩存

凡是涉及用戶隱私信息的盡量避免中間代理的緩存，如果對所有用戶響應(yīng)相同的資源，則可以考慮讓中間代理也進行緩存。

4）、避免網(wǎng)址的冗余

緩存是根據(jù)請求資源的URL進行的，不同的資源會有不同的URL，所以盡量不要將相同的資源設(shè)置為不同的URL。這會導(dǎo)致緩存失效。

5）、規(guī)劃緩存的層次結(jié)構(gòu)

不僅請求的資源類型，文件資源的層次結(jié)構(gòu)也會對制定緩存策略有一定的影響。

CDN緩存

CND全程是Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)，他是構(gòu)建在現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)上的虛擬智能網(wǎng)絡(luò)，依靠部署在各地的邊緣服務(wù)器，通過中心平臺的負載均衡，調(diào)度及內(nèi)容分發(fā)等功能模塊，使用戶在請求所需訪問的內(nèi)容時能夠就近獲取，以此來降低網(wǎng)絡(luò)阻塞，提高資源對用戶的響應(yīng)速度。

如果沒有CDN，假設(shè)我們的服務(wù)器在北京，那么海南的用戶訪問我們的網(wǎng)站的時候需要不遠萬里鏈接北京的服務(wù)器獲取資源，這樣的速度是比較慢的。

CDN的工作原理就是就近響應(yīng)，如果我們將資源放置在CDN上，當(dāng)海南的用戶訪問網(wǎng)站時，資源請求首先進行DNS解析，這個時候DNS會詢問CDN服務(wù)器有沒有就近的服務(wù)器，如果有就鏈接就近服務(wù)的IP地址獲取資源。

由于DNS服務(wù)器將CDN的域名解析權(quán)交給了CNAME指向的專用DNS服務(wù)器，所以用戶輸入域名的解析最終是在CDN專用的DNS服務(wù)器上完成的。

解析出的IP地址并非確定的CDN緩存服務(wù)器地址，而是CDN負載均衡器的地址。

瀏覽器會重新向該負載均衡器發(fā)起請求，經(jīng)過對用戶IP地址的距離，所請求資源內(nèi)容的位置及各個服務(wù)器狀態(tài)的綜合計算，返回給用戶確定的緩存服務(wù)器IP地址。

如果這個過程發(fā)生所需資源未找到的情況，那么此時便會依次向上一級緩存服務(wù)器繼續(xù)請求查詢，直至追溯到網(wǎng)站所在的跟服務(wù)器并將資源拉取到本地進行緩存。

雖然這個過程看起來稍微復(fù)雜一些，但是用戶是無感知的，并且能帶來比較明顯的資源加載速度的提升，因此對目前所有一線互聯(lián)網(wǎng)產(chǎn)品來說，使用CDN已經(jīng)不再是一條建議而是規(guī)定。

CDN主要針對的是靜態(tài)資源并非適用網(wǎng)站所有的資源類型。所謂靜態(tài)資源就是不需要業(yè)務(wù)服務(wù)器參與計算的資源，比如第三方的庫，js腳本文件，css樣式文件，圖片等。

如果是動態(tài)資源比如依賴服務(wù)端渲染的html就不適合放在CDN上。

CDN網(wǎng)絡(luò)的核心功能包括兩點，緩存與回源，緩存指的是將所需的靜態(tài)資源文件復(fù)制一份到CDN緩存服務(wù)器上，回源指的是如果未在CDN緩存服務(wù)器上查找到目標資源，或者CDN緩存服務(wù)器上的資源已經(jīng)過期，則重新追溯到網(wǎng)站根服務(wù)器獲取相關(guān)資源的過程。

CDN的優(yōu)化有很多方面，比如CDN自身的性能優(yōu)化，靜態(tài)資源邊緣化，域名合并優(yōu)化和多級緩存架構(gòu)優(yōu)化。這些可能需要前后端一起配合完成。

一般情況CDN會和主站域名區(qū)分，這樣的好處是避免靜態(tài)資源請求攜帶不必要的cookie信息，還有就是考慮瀏覽器對同一域名下并發(fā)請求的限制。

cookie的訪問遵循同源策略，同一域名下的所有請求都會攜帶全部cookie信息，雖然cookie存儲空間并不大，但是如果所有資源都放在主站域名下所有的請求全部攜帶數(shù)據(jù)量也是很大的。

所以將CDN服務(wù)器的域名和主站域名進行區(qū)分是非常有價值的。

其次因為瀏覽器對于同域名下的并發(fā)請求存在限制，通常Chrome的并發(fā)限制是6。可以通過增加類似域名的方式來提高并發(fā)請求數(shù)。

當(dāng)然這種方式對緩存命中是不友好的，如果并發(fā)請求了相同的資源使用了不同的域名，那么之前的緩存就失去了意義。

• 本文作者：隱冬

• 本文鏈接：https://zhiqianduan.com/javascript/資源請求速度優(yōu)化.html

往期推薦

2021 TWeb 騰訊前端技術(shù)大會精彩回顧(附PPT)

面試題：說說事件循環(huán)機制(滿分答案來了)

專心工作只想搞錢的前端女程序員的2020

最后

• 歡迎加我微信，拉你進技術(shù)群，長期交流學(xué)習(xí)...
  

• 歡迎關(guān)注「前端Q」,認真學(xué)前端，做個專業(yè)的技術(shù)人...

點個在看支持我吧