全方位提速網(wǎng)站的技術(shù)手段

邱麗娟

【摘要】 平時我們搭建的一個網(wǎng)站，特別是較大的企業(yè)網(wǎng)站，都希望客戶訪問時能更快地響應(yīng)。本文將從全方位的四個層次來討論怎樣提速網(wǎng)站。

【關(guān)鍵字】 網(wǎng)站提速 域名規(guī)劃 代理緩存 前端編譯 域名預(yù)解析 網(wǎng)站預(yù)連接 資源預(yù)加載

一般網(wǎng)站的技術(shù)架構(gòu)：通過負載均衡設(shè)備接入外網(wǎng)請求，執(zhí)行SSL解密，根據(jù)域名或URL分發(fā)請求；以Nginx為負載分發(fā)服務(wù)器；靜態(tài)資源與動態(tài)程序分開部署。

順應(yīng)這一架構(gòu)層次，本文從域名規(guī)劃、代理服務(wù)器端緩存、前端編譯、頁面制作四個層次闡述網(wǎng)站提速的技術(shù)手段。

一、域名規(guī)劃

瀏覽器有一個限制：針對一個遠程主機（域名），同時存在的并發(fā)請求數(shù)不能超出上限。換言之，將文件部署在不同的服務(wù)器（域名）上，將增強瀏覽器的并發(fā)能力。

以電商網(wǎng)站為例，規(guī)劃其域名：

www：網(wǎng)站首頁。

news：二級頁面。

app：移動App的服務(wù)端地址。

weixin：微信公眾號的服務(wù)端地址。

pdt-img-1：商品圖片服務(wù)器。為充分利用瀏覽器并發(fā)獲取圖片的能力，建立5個圖片服務(wù)器域名，即pdtimg-2、pdt-img-3、pdt-img-4、pdt-img-5。

二、 代理緩存

當使用Nginx作為Web請求和移動App請求的負載分發(fā)器時，在Nginx上配置代理緩存策略，定義負載分發(fā)器與應(yīng)用服務(wù)器/靜態(tài)資源服務(wù)器之間的緩存規(guī)則，這樣在緩存過期之前負載分發(fā)器就不用從應(yīng)用服務(wù)器/靜態(tài)資源服務(wù)器獲取文件。

proxy_cache_path data/cache/cache_my levels=1：2 keys_ zone=cache_my：200m inactive=1d max_size=1g；

server {

location ～* ＼.（？：ico|css|js|gif|jpe？g|png）$ {

include proxy.conf；

proxy_cache cache_my；

proxy_pass http：//my_servers；

}

}

當新應(yīng)用發(fā)布時，要注意清除緩存目錄。

三、動靜分離/瀏覽器緩存/文件壓縮/圖片合并

減少靜態(tài)文件對應(yīng)用服務(wù)器的影響、請求次數(shù)、網(wǎng)絡(luò)流量、連接次數(shù)，這些是前端開發(fā)的標準要求和強制要求。如果拿服務(wù)端代碼編譯來類比，就相當于對前端開發(fā)的成果文件（包括HTML、CSS、JS、圖片等）進行一次檢查和再處理，這正是“前端編譯”的觀點。FIS3是百度的前端編譯解決方案，可一次性達到上述四個目的。FIS3的統(tǒng)一配置文件是fis-conf.js。

3.1 實施動靜分離

在一個高并發(fā)的場景中，瀏覽器并發(fā)獲取資源，無疑將加速頁面的顯示，增強用戶體驗，但這又對服務(wù)器應(yīng)對并發(fā)訪問的能力提出更高要求。根據(jù)文件類型，在服務(wù)端針對動、靜文件實施分開部署，動態(tài)文件部署在應(yīng)用服務(wù)器，靜態(tài)文件部署在靜態(tài)資源服務(wù)器，正是為了降低應(yīng)用服務(wù)器在I/O方面的消耗，從整體上增強服務(wù)端響應(yīng)文件請求的能力。大型網(wǎng)站部署CDN的目的之一，便是分散部署靜態(tài)資源文件，結(jié)合智能DNS，就近返回靜態(tài)資源文件。

在fis-conf.js中配置規(guī)則，將*.js、*.css、*.png文件發(fā)布到另一個絕對路徑下，該路徑將來可以是靜態(tài)資源服務(wù)器上的任意路徑。

fis.match（‘*.{png，js，css}， {

release： ‘/static/$0

}）；

3.2 充分利用瀏覽器緩存

瀏覽器緩存的工作原理是，與服務(wù)器之間建立一種契約，服務(wù)器依據(jù)文件修改時間來決定是否需要向瀏覽器返回該文件。瀏覽器每次請求遠程文件時，從自身緩存中提取該文件的最后修改時間，放在If-Modified-Since頭中隨請求發(fā)出；服務(wù)器取出If-Modified-Since頭數(shù)據(jù)，比對最新的文件修改時間，如相同，說明文件未曾修改，返回304狀態(tài)代碼，如不同，則正常返回文件。在這種工作模式下，即使文件沒修改，瀏覽器也要發(fā)出一次請求。改進方案是，服務(wù)器告知瀏覽器文件將永不過期，服務(wù)器將能夠代表文件是否變動的標識（最后修改時間、內(nèi)容哈希）作為文件URI的一部分，一旦文件內(nèi)容改變，URI隨之變化，這樣瀏覽器根據(jù)文件URI便能判斷是否需要下載新的文件。

應(yīng)用系統(tǒng)的靜態(tài)資源文件、商品圖片，均適用這一技巧。

fis.match（‘*.{js，css，png}， {

useHash： true

}）；

3.3 實施文件壓縮

文件GZIP壓縮是主流的Web服務(wù)器都支持的功能，其目的是減少網(wǎng)絡(luò)傳輸?shù)淖止?jié)數(shù)，因為相對壓縮和解壓的運算能力的消耗，網(wǎng)絡(luò)傳輸能力無疑是更大的制約。

fis.match（‘*.js， {//fis-optimizer-uglify-js插件進行壓縮，已內(nèi)置

optimizer： fis.plugin（‘uglify-js）

}）；

fis.match（‘*.css， {//fis-optimizer-clean-css插件進行壓縮，已內(nèi)置

optimizer： fis.plugin（‘clean-css）

}）；

fis.match（‘*.png， {//fis-optimizer-png-compressor插件進行壓縮，已內(nèi)置

optimizer： fis.plugin（‘png-compressor）

}）；

3.4 實施圖片合并

一次Web請求，需要經(jīng)歷域名解析、建立連接、傳輸內(nèi)容三個階段，其中建立連接比較耗時，因此瀏覽器一般具有保持一段時間的長連接以供復(fù)用的機制。服務(wù)端將多張圖片合并成一個文件，正是一種主動減少連接次數(shù)的機制。

//啟用fis-spriter-csssprites插件

fis.match（‘：：package， {

spriter： fis.plugin（‘csssprites）

}）

//對CSS進行圖片合并

fis.match（‘*.css， {//給匹配到的文件分配屬性

useSprite： true

}）；

四、域名預(yù)解析/網(wǎng)站預(yù)連接/資源預(yù)加載

根據(jù)大型網(wǎng)站的監(jiān)測結(jié)果，在一次資源請求的過程中，大量時間耗費在建立連接方面；對于初次請求一個新網(wǎng)站來說，域名解析也需要耗費一段時間；對于一次請求大文件的過程來說，需要耗費的時間相對更長，而在這段相對更長的時間內(nèi)，用戶只能等待。針對域名解析、建立連接、資源文件加載這三個問題，分別開辟一個提前量，在用戶執(zhí)行其它操作的間歇期，并行執(zhí)行域名預(yù)解析、網(wǎng)站預(yù)連接、資源預(yù)加載。例如：

域名預(yù)解析：

網(wǎng)站預(yù)連接：

資源預(yù)加載：

目前并不是所有的瀏覽器都支持以上聲明，但是將有越來越多的瀏覽器支持。