互聯(lián)網(wǎng)站點服務(wù)加速的14條軍規(guī)

小豬窩969 2015-02-09

展開全文

我們都說互聯(lián)網(wǎng)內(nèi)容制勝，但如果網(wǎng)站的響應(yīng)速度太慢，即使內(nèi)容再好，也更會造成用戶體驗從“抓狂 - 憤怒 - 永遠(yuǎn)離開 - 壞口碑傳播”這樣的毀滅性路線。

Make fewer HTTP requests - 減少http請求次數(shù) 。例如首頁嵌套了4個iframe，那么就是4+1=5個http請求，如果去掉iframe或改成服務(wù)器端包含的話……那么就只剩一個http請求啦。所以，對于訪問量巨大的網(wǎng)站首頁來說，把CSS和JS直接寫在頁面里，也許是個不錯的選擇，盡管這違反了第8條軍規(guī)，但規(guī)矩是死的，實際情況是活的。
Use a CDN - 使用內(nèi)容分發(fā)網(wǎng)絡(luò) 。特殊資源走特殊的網(wǎng)絡(luò)連接從而獲得特殊的加速，例如：網(wǎng)通/電信/教育網(wǎng)分別加速、為北京或上海的用戶建立本地的CDN以加速這種特定地域的訪問、為軟件下載專門加速、為流媒體直播專門加速、為靜態(tài)資源下載提速（css/js/html）……
Add an Expires header - 盡量讓客戶端瀏覽器緩存網(wǎng)站的資源 ，那么就不用每次都從服務(wù)器下載了，這能極大減輕網(wǎng)站服務(wù)器的負(fù)擔(dān)，但是如果資源更新了而客戶端得不到及時通知的話……所以請謹(jǐn)慎設(shè)計、變更你的Web資源頭部過期標(biāo)記，最大化重用客戶端瀏覽器緩存的同時又不至于使用戶看不到最新的更改。
Gzip components - 啟用Gzip壓縮已經(jīng)是網(wǎng)站服務(wù)公認(rèn)的標(biāo)準(zhǔn)了 ，Gzip能極大的壓縮網(wǎng)站數(shù)據(jù)包的體積（一般壓縮率可達到85%！也就是說服務(wù)器端100K 的頁面可以壓縮到15K 左右再發(fā)送到客戶端），傳到客戶端再解包，一般的瀏覽器、搜索引擎爬蟲都支持。強烈建議網(wǎng)站上所有的文本內(nèi)容都走Gzip壓縮，例如：js css html txt 等等。支持Gzip的代理服務(wù)器軟件也很出色，如 Nginx——簡單好用，性能一流，吐血推薦。
Put stylesheets at the top - 把樣式表放在頁面頂端 。如果把樣式表放在底部，如果網(wǎng)絡(luò)稍有延遲的話，頁面樣式得不到及時渲染，將慘不忍睹??！
Put scripts at the bottom - 把腳本（如javascript）放在頁面底部 。有的腳本很大，如果放在頂部半天下載不下來的話，頁面將是一片空白，你肯定不想用戶半天都看著白花花的屏幕發(fā)呆吧——用戶也不想！腳本一般是響應(yīng)頁面載入后的行為，所以放到底下去慢慢下載比較好，讓用戶盡快的看到頁面——這個體驗對用戶來說比較好。腳本引起的另一個問題是它阻塞并行下載數(shù)量。HTTP 1.1規(guī)范建議Web瀏覽器的并行下載數(shù)不超過2個（IE只能為2個，其他瀏覽器如Firefox等都是默認(rèn)設(shè)置為2個，不過IE8可以達到6個），因此如果您把圖像文件分布到多臺機器的話，您可以達到超過2個的并行下載，但是當(dāng)腳本文件下載時，瀏覽器會阻塞圖片并行下載。當(dāng)然，有些情況下還是不得不把腳本放到頂端的，例如在頁面渲染時就需要的計算。
Avoid CSS expressions - 不要使用CSS（樣式表）表達式 。首先CSS表達式不是一個跨瀏覽器的玩意，IE5以后對其支持，其他的瀏覽器不保證。CSS表達式的問題還在于它的計算頻率要比想象的多出很多，不僅僅是在頁面顯示和縮放時，就是在頁面滾動、乃至移動鼠標(biāo)時都可能要重新計算一次。如果樣式屬性必須在頁面周期內(nèi)動態(tài)地改變，使用事件句柄來代替CSS表達式是一個可行辦法。CSS表達式成千上萬次的計算可能會對你頁面的性能產(chǎn)生很大影響，會造成用戶感覺打開你的頁面后機器變的很慢……很慢。這是一個CSS表達式的例子：background-color: expression( (new Date()).getHours()%2 ? "#F00" : "#00F" );
Make JS and CSS external - 把JS腳本、CSS樣式表歸放在單獨的文件里 。首先可以加速整體頁面的展現(xiàn)，我們知道網(wǎng)絡(luò)的突發(fā)傳輸速率大于持續(xù)傳輸速率；其次對SEO有好處，搜索引擎每天分配給你站點的“爬取時間”是有限的，如果把這些與內(nèi)容無關(guān)的、必然會被搜索忽略的東西放在頁面里，浪費了爬蟲的時間，也許會減少整個站點的頁面收錄量；另外，單獨的文件也方便享受靜態(tài)資源“特權(quán)CDN”和特殊壓縮處理的好處不是？
Reduce DNS lookups - 減少DNS解析次數(shù) 。我們知道一個域名需要經(jīng)過從DNS服務(wù)器解析成IP地址這個過程才能把頁面呈現(xiàn)到您老的眼前。一般來說一次DNS的解析過程會消耗20-120毫秒的時間，在DNS解析結(jié)束之前，瀏覽器不會下載該域名下的任何東西。如果您萬一不幸碰上一個無良的DNS解析服務(wù)提供商或者您網(wǎng)頁里的資源在很多不同域名底下，那么，光DNS的解析時間就會讓你的用戶欲仙欲死的。
Minify JS - JS盡量壓縮。JS腳本乃是除圖片、音頻、視頻之外，最常見、最消耗網(wǎng)絡(luò)帶寬的資源了，所以我們除了要將它獨立成文件、放在加速的CDN上之外，最好還把它壓縮一下。這里有個在線處理JS的工具，不僅能壓縮、還能加密JS：http://www./htm/fuckjs.htm
Avoid redirects - 盡量避免URL重定向 。這里的意思主要是指后臺程序能用Forward轉(zhuǎn)發(fā)就盡量用Forward轉(zhuǎn)發(fā)，而非Redirect重定向，為啥呢？因為重定向相對于前者來說消耗的資源更大，相當(dāng)于再發(fā)送一個新的http請求（request），原請求被清空，構(gòu)造出新的請求……另外從SEO的角度來說，重定向表示網(wǎng)址被轉(zhuǎn)移了，表現(xiàn)為瀏覽器地址欄的URL發(fā)生了變化，這時候選擇301永久重定向、還是選擇302臨時重定向（一般默認(rèn)是302），是個很糾結(jié)、很蛋疼的事情，增加了復(fù)雜度，SEO效果也不好說。
Remove duplicate scripts - 移除重復(fù)的腳本 。腳本這玩意屬于客戶端的東西，亂寫一氣最多頁面變形，很難把服務(wù)器整死，所以有些網(wǎng)站不太重視，有很多功能重復(fù)的腳本函數(shù)，殊不知這樣除了會消耗Web應(yīng)用寶貴的帶寬資源，還會加大客戶端的計算量，有時會直接影響用戶體驗，所以盡量歸并和抽象重復(fù)的腳本吧。采用面向?qū)ο蟮腏S編程也許是個不錯的主意。
Configure ETags - 定義ETags 。別被ETags嚇到，其實就是充分利用客戶端瀏覽器緩存減少Web應(yīng)用消耗的帶寬和負(fù)載，具體的實現(xiàn)可以參考此文：http://www./cn/articles/etags 。開啟Web服務(wù)器的ETags選項可以有效的控制客戶端緩存失效，但不利于服務(wù)端緩存，如果使用Squid做代理服務(wù)器緩存，可以不使用ETags，Squid做代理服務(wù)器有啥好處，可以參考此文：http://blog.csdn.net/kthq/archive/2009/08/17/4456385.aspx
Make AJAX cacheable - 注意AJAX緩存 ！AJAX還要去緩存？是的，根據(jù)你的實際需要去防止AJAX緩存。做AJAX請求的時候往往還要增加一個時間戳去避免其緩存。It’s important to remember that “asynchronous” does not imply “instantaneous”.（記住“異步”不是“瞬間”，這一點很重要）。要明白，即使AJAX請求是動態(tài)產(chǎn)生的且只對一個用戶起作用，其依然可以被緩存。