大規模、高流量互連網站效能調優的22條準則

     關於大規模、高流量Web2.0網站效能調優的14條準則，已近成了業界web2.0網站前端最佳化的準則，國內外也有很多文章和書籍介紹這些準則。14條準則其實是美國雅虎Performance部門這幾年的工作成果之一，他們還研究並提出了許多有效網站效能調優技術。美國Performance團隊負責將雅虎產品和應用改進得更快、更好、更有效率。

1。Make Fewer HTTP Requests

（盡量減少http請求數量）

首先面臨的一個問題是把所有的 JavaScript 與 CSS 放到一個檔案中好呢，還是分割成多個檔案 ?

從減少網路請求的角度上考慮, 前者更好，後者差。但是從並行的角度考慮, IE 與 Firefox 預設情況下都只能同時從一個域請求兩個資源. 這會在很多情況下給使用者帶來不良的使用體驗–必須所有的檔案都下載完畢才可以看到像樣的頁面. Flickr 採用了折衷的辦法–在保持檔案數量儘可能少的情況下，把 JavaScript 與 CSS 分成多個子檔案. 這在開發上帶來了複雜性，但是對效能的收益是巨大的。

2。Use a Content Delivery Network

（使用CDN）

3。Add an Expires Header

（在下載的css、js、image組件裡增加到期時間）

4。Gzip Components

（對下載的組件進行壓縮）

毫無疑問，對網站內容進行壓縮是一個比較常用的 Web 最佳化手段．但是並不一定都能達到理想的效果．原因在於 mod-gzip 模組不但消耗伺服器端 CPU 資源，也消耗用戶端 CPU 資源. 而且, mod_gzip 壓縮檔後建立的臨時檔案是放到磁碟上的，這也會給磁碟 IO 帶來嚴重的問題.

Flickr 採用的是 Httpd 2.x 以後支援的　mod_deflate 模組．壓縮操作都在記憶體中進行．mod_deflate 在 Httpd 1.x 是停用, 不過可以通過建立 RAM 盤的方式來間接提高效能．

當然, mod_gzip 到也不是一無是處, 對於預壓縮的檔案, 還是有好處的. 而且, 採用壓縮的時候,也要注意策略. 圖片檔案壓縮就沒什麼必要了(Flickr 像多, 而且壓縮得不到什麼好處). Flickr 只對JavaScript 和 CSS 進行壓縮. mod_gzip 新一點的版本能夠自動通過配置 mod_gzip_update_static 選項自動處理 預壓縮的檔案. Cal 也指出這個特性在一些舊版本的瀏覽器上會出問題.

壓縮的另一個主要手段是內容的壓縮. 針對 JavaScript 可以進行通過減少注釋、合并空格、使用緊湊的文法等小技巧(Google 的所有指令碼都非常難讀，而且非常緊湊，思想類似).當然，經過這樣處理的 JavaScript 可能帶了很多括弧不容易解析，Flickr 使用了 Dojo Compressor 來構建解析樹。Dojo Compressor 開銷很低，而且對於終端使用者是透明的. JavaScript 的處理方法介紹過，CSS 處理則相對簡單.通過簡單的Regex替換(比如把多個空格替換為一個空格符), 最高可以獲得 50% 的壓縮比。

5。Put CSS components at the top of the page.

（css檔案儘可能放在頁面的最上面）

6。Put JS components as close to the bottom of the page as possible.

（js檔案儘可能放在頁面的最下面）

7。Avoid CSS Expressions

（在css檔案中慎用運算式）

8。Make JavaScript and CSS External

（在外部包含js和css檔案）

9。Reduce DNS Lookups

（減少請求中網域名稱的解析次數）

10。Minify JavaScript

（js代碼壓縮）

11。Avoid doing redirects.

（避免重新導向）

12。Remove Duplicates Scripts

（避免請求重複的js檔案）

13。Configure ETags

（配置好ETag）

Flickr 的開發人員充分利用了 Http 1.1 規範定義的 Etag 與 Last-Modified 機制 來提高 Caching 的效率. 值得注意的是，Cal 介紹了一個在負載平衡條件下的 e-Tag 小技巧. 即可以設定 Apache 通過檔案調整時間與檔案大小獲得 E-Tag ,而預設情況下, Apache 是通過檔案節點擷取 e-Tag 的。當然，這也不是很完美，因為會影響 if-modified-since 。

但是有的網站的e-Tag，如yahoo，其產生規則是基於節點的。相同的css或js指令碼在不同節點伺服器上的e-Tag不同，所以如果有n個伺服器，那麼瀏覽器獲得304應答訊息的機率是1/n。

14。Make Ajax Cacheable

（緩衝Ajax請求）

以下幾點是新增的準則。

15。Flush the Header

（先發送Header裡的資訊）

We improved the page load times by flushing the apache output buffer after the document HEAD was generated.This had two benefits.

First, the HEAD contains SCRIPT and LINK tags for scripts and stylesheets. By flushing the HEAD, those tags are received and parsed by the browser sooner, and in turn the browser starts downloading those components earlier.

Second, the HEAD is flushed before actually generating the search results. This is a win for any property doing a significant backend computation or especially making one or more backend web service calls.

16。Split Static Content Across Multiple Hostnames

（把較大的靜態檔案分割成不同域的請求）

If you have many (10 or more) components downloaded from a single hostname, it might be better to split those across two hostnames.

17。Reduce the Size of Cookies

（不要讓Cookie內容過大）

Reduce the amount of data in the cookie by storing state information on the backend, and abbreviating names and values stored in the cookie. Set expiration dates on your cookies, and make them as short as possible.

18。Host Static Content on a Different Top-Level Domain

（把靜態檔案放在不同的頂級網域名稱下）

19。Minify CSS

（Css代碼壓縮）

20。Use GET for XHR

（有XHR時使用GET請求）

Iain Lamb did a deep study of how using POST for XMLHttpRequests is inefficient, especially in IE. His recommendation: “If the amount of data you have to send to the server is small (less than 2k), I suggest you design your webservice / client application to use GET rather than POST。

21。Avoid IFrames

（盡量避免使用IFrame）

Don’t use SRC (set it via JS instead). Each IFrame takes 20-50ms, even if it contains nothing

22。Optimize images

（最佳化圖片）