Yahoo 34條軍規

1.儘量減少HTTP請求數

  • 80%的終端用戶響應時間都花在了前端上,其中大部分時間都在下載頁面上的各種組件:圖片,樣式表,腳本,Flash等等。減少組件數必然能夠減少頁面提交的HTTP請求數。這是讓頁面更快的關鍵。
  • 減少頁面組件數的一種方式是簡化頁面設計。
  • 合併文件是通過把所有腳本放在一個文件中的方式來減少請求數的,當然,也可以合併所有的CSS。
  • CSS Sprites是減少圖片請求數量的首選方式。
  • 圖像映射可以把多張圖片合併成單張圖
  • 減少頁面的HTTP請求數是個起點,這是提升站點首次訪問速度的重要指導原則。

2.減少DNS查找

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
    <meta http-equiv="x-dns-prefetch-control" content="on">
    <link rel="dns-prefetch" href="http://wwww.baidu.com">
    <link rel="dns-prefetch" href="https://www.csdn.net/">
</head>
<body>
<a href="https://www.csdn.net/">https://www.csdn.net/</a>
</body>
</html>

3.避免重定向

重定向用301和302狀態碼,下面是一個有301狀態碼的HTTP頭:

HTTP/1.1 301 Moved Permanently
      Location: http://example.com/newuri
      Content-Type: text/html

有一種常見的極其浪費資源的重定向,而且web開發人員一般都意識不到這一點,就是URL尾部缺少一個斜線的時候。例如,跳轉到http://astrology.yahoo.com/astrology 會返回一個重定向到http://astrology.yahoo.com/astrology/

4.讓Ajax可緩存

 要提高性能,優化這些Ajax響應至關重要。最重要的提高Ajax性能的方法就是讓響應變得可緩存,就像在添上Expires與Cache-control頭中討論的一樣。下面適用於Ajax的其它規則:
 這裏寫圖片描述
- Gzip組件
- 減少DNS查找
- 壓縮JavaScript
- 避免重定向
- 配置ETags
Ajax請求與瀏覽器緩存

    ```
     $.ajax({
        type: "GET",
         url: "default.aspx",
         beforeSend: function(request) {
             request.setRequestHeader("Test", "Chenxizhang");
         },
         success: function(result) {
             alert(result);
         }
    });
    ```

5.延遲加載組件

6.預加載組件

  1. 無條件預加載——觸發onload事件時,直接加載額外的頁面內容。
  2. 條件性預加載——根據用戶操作猜測用戶將要跳轉到哪裏並據此預加載。
  3. 提前預加載——在推出新設計之前預加載。
<!-- 頁面,可以使用絕對或者相對路徑 --> 
<link rel="prefetch" href="page2.html" /> 
<!-- 圖片,也可以是其他類型的文件 --> 
<link rel="prefetch" href="sprite.png" /> 
從上面的HTML代碼可以看出,預加載使用 <link> 標籤,並指定 rel="prefetch" 屬性,而href屬性就是需要預加載的文件路徑。而Mozilla還實現了一些類似的 link rel 屬性: 
<link rel="prefetch alternate stylesheet" title="Designed for Mozilla" href="mozspecific.css" /> 
<link rel="next" href="2.html" /> 

7、減少DOM元素數量

一個複雜的頁面意味着需要下載更多數據,同時也意味着JavaScript遍歷DOM的效率越慢。比如當你增加一個事件句柄時在500和5000個DOM元素中循環效果肯定是不一樣的。

大量的DOM元素的存在意味着頁面中有可以不用移除內容只需要替換元素標籤就可以精簡的部分。你在頁面佈局中使用表格了嗎?你有沒有僅僅爲了佈局而引入更多的

元素呢?也許會存在一個適合或者在語意是更貼切的標籤可以供你使用。

YUI CSS utilities可以給你的佈局帶來巨大幫助:grids.css可以幫你實現整體佈局,font.css和reset.css可以幫助你移除瀏覽器默 認格式。它提供了一個重新審視你頁面中標籤的機會,比如只有在語意上有意義時才使用

,而不是因爲它具有換行效果才使用它。

DOM元素數量很容易計算出來,只需要在Firebug的控制檯內輸入:

document.getElementsByTagName(‘*’).length

那麼多少個DOM元素算是多呢?這可以對照有很好標記使用的類似頁面。比如Yahoo!主頁是一個內容非常多的頁面,但是它只使用了700個元素(HTML標籤)。

8、根據域名劃分頁面內容

把頁面內容劃分成若干部分可以使你最大限度地實現平行下載。由於DNS查找帶來的影響你首先要確保你使用的域名數量在2個到4個之間。例如,你可以 把用到的HTML內容和動態內容放在www.52maomao.info上,而把頁面各種組件(圖片、腳本、CSS)分別存放在 statics1.52maomao.info和statics.52maomao.info上。

你可在Tenni Theurer和Patty Chi合寫的文章《Maximizing Parallel Downloads in the Carpool Lane》找到更多相關信息。

9、使iframe的數量最小

ifrmae元素可以在父文檔中插入一個新的HTML文檔。瞭解iframe的工作理然後才能更加有效地使用它,這一點很重要。

優點:

1、解決加載緩慢的第三方內容如圖標和廣告等的加載問題;

2、Security sandbox;

3、並行加載腳本。

缺點:

1、即時內容爲空,加載也需要時間;

2、會阻止頁面加載;

3、沒有語意。

10、不要出現404錯誤

HTTP請求時間消耗是很大的,因此使用HTTP請求來獲得一個沒有用處的響應(例如404沒有找到頁面)是完全沒有必要的,它只會降低用戶體驗而不會有一點好處。
有些站點把404錯誤響應頁面改爲“你是不是要找*”,這雖然改進了用戶體驗但是同樣也會浪費服務器資源(如數據庫等)。最糟糕的情況是指向外部 JavaScript的鏈接出現問題並返回404代碼。首先,這種加載會破壞並行加載;其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分當 作JavaScript代碼來執行。

11、使用內容分發網絡

用戶與你網站服務器的接近程度會影響響應時間的長短。把你的網站內容分散到多個、處於不同地域位置的服務器上可以加快下載速度。但是首先我們應該做些什麼呢?

按地域佈置網站內容的第一步並不是要嘗試重新架構你的網站讓他們在分發服務器上正常運行。根據應用的需求來改變網站結構,這可能會包括一些比較複雜 的任務,如在服務器間同步Session狀態和合並數據庫更新等。要想縮短用戶和內容服務器的距離,這些架構步驟可能是不可避免的。

要記住,在終端用戶的響應時間中有80%到90%的響應時間用於下載圖像、樣式表、腳本、Flash等頁面內容。這就是網站性能黃金守則。和重新設 計你的應用程序架構這樣比較困難的任務相比,首先來分佈靜態內容會更好一點。這不僅會縮短響應時間,而且對於內容分發網絡來說它更容易實現。

內容分發網絡(Content Delivery Network,CDN)是由一系列分散到各個不同地理位置上的Web服務器組成的,它提高了網站內容的傳輸速度。用於向用戶傳輸內容的服務器主要是根據 和用戶在網絡上的靠近程度來指定的。例如,擁有最少網絡跳數(network hops)和響應速度最快的服務器會被選定。

一些大型的網絡公司擁有自己的CDN,但是使用像Akamai Technologies,Mirror Image Internet, 或者Limelight Networks這樣的CDN服務成本卻非常高。對於剛剛起步的企業和個人網站來說,可能沒有使用CDN的成本預算,但是隨着目標用戶羣的不斷擴大和更加 全球化,CDN就是實現快速響應所必需的了。以Yahoo來說,他們轉移到CDN上的網站程序靜態內容節省了終端用戶20%以上的響應時間。使用CDN是 一個只需要相對簡單地修改代碼實現顯著改善網站訪問速度的方法。

12、爲文件頭指定Expires或Cache-Control

這條守則包括兩方面的內容:

對於靜態內容:設置文件頭過期時間Expires的值爲“Never expire”(永不過期);

對於動態內容:使用恰當的Cache-Control文件頭來幫助瀏覽器進行有條件的請求。

網頁內容設計現在越來越豐富,這就意味着頁面中要包含更多的腳本、樣式表、圖片和Flash。第一次訪問你頁面的用戶就意味着進行多次的HTTP請 求,但是通過使用Expires文件頭就可以使這樣內容具有緩存性。它避免了接下來的頁面訪問中不必要的HTTP請求。Expires文件頭經常用於圖像 文件, 但是應該在所有的內容都使用他,包括腳本、樣式表和Flash等。

瀏覽器(和代理)使用緩存來減少HTTP請求的大小和次數以加快頁面訪問速度。Web服務器在HTTP響應中使用Expires文件頭來告訴客戶端 內容需 要緩存多長時間。下面這個例子是一個較長時間的Expires文件頭,它告訴瀏覽器這個響應直到2010年4月15日才過期。

Expires: Thu, 15 Apr 2010 20:00:00 GMT

如果你使用的是Apache服務器,可以使用ExpiresDefault來設定相對當前日期的過期時間。

下面這個例子是使用 ExpiresDefault來設定請求時間後10年過期的文件頭:

ExpiresDefault “access plus 10 years”

要切記,如果使用了Expires文件頭,當頁面內容改變時就必須改變內容的文件名。依Yahoo!來說我們經常使用這樣的步驟:在內容的文件名中加上版本號,yahoo_2.0.6.js。

使用Expires文件頭只有會在用戶已經訪問過你的網站後纔會起作用。當用戶首次訪問你的網站時這對減少HTTP請求次數來說是無效的,因爲瀏覽 器的緩存是空的。因此這種方法對於你網站性能的改進情況要依據他們“預緩存”存在時對你頁面的點擊頻率(“預緩存”中已經包含了頁面中的所有內容)。 Yahoo!建立了一套測量方法,我們發現所有的頁面瀏覽量中有75~85%都有“預緩存”。通過使用Expires文件頭,增加了緩存在瀏覽器中內容的 數量,並且可以在用戶接下來的請求中再次使用這些內容,這甚至都不需要通過用戶發送一個字節的請求。

13、Gzip壓縮文件內容

網絡傳輸中的HTTP請求和應答時間可以通過前端機制得到顯著改善。的確,終端用戶的帶寬、互聯網提供者、與對等交換點的靠近程度等都不是網站開發者所能決定的。但是還有其他因素影響着響應時間。通過減小HTTP響應的大小可以節省HTTP響應時間。

從HTTP/1.1開始,web客戶端都默認支持HTTP請求中有Accept-Encoding文件頭的壓縮格式:

Accept-Encoding: gzip, deflate

如果web服務器在請求的文件頭中檢測到上面的代碼,就會以客戶端列出的方式壓縮響應內容。Web服務器把壓縮方式通過響應文件頭中的Content- Encoding來返回給瀏覽器。

Content-Encoding: gzip

Gzip是目前最流行也是最有效的壓縮方式。這是由GNU項目開發並通過RFC 1952來標準化的。另外僅有的一個壓縮格式是deflate,但是它的使用範圍有限效果也稍稍遜色。

Gzip大概可以減少70%的響應規模。目前大約有90%通過瀏覽器傳輸的互聯網交換支持gzip格式。如果你使用的是Apache,gzip模塊配置和你的版本有關:Apache 1.3使用mod_zip,而Apache 2.x使用moflate。

瀏覽器和代理都會存在這樣的問題:瀏覽器期望收到的和實際接收到的內容會存在不匹配的現象。幸好,這種特殊情況隨着舊式瀏覽器使用量的減少在減少。 Apache模塊會通過自動添加適當的Vary響應文件頭來避免這種狀況的出現。

服務器根據文件類型來選擇需要進行gzip壓縮的文件,但是這過於限制了可壓縮的文件。大多數web服務器會壓縮HTML文檔。對腳本和樣式表進行 壓縮同 樣也是值得做的事情,但是很多web服務器都沒有這個功能。實際上,壓縮任何一個文本類型的響應,包括XML和JSON,都值得的。圖像和PDF文件由於 已經壓縮過了所以不能再進行gzip壓縮。如果試圖gizp壓縮這些文件的話不但會浪費CPU資源還會增加文件的大小。

Gzip壓縮所有可能的文件類型是減少文件體積增加用戶體驗的簡單方法。

更多詳細的GZIP壓縮信息請參考我的另外兩篇文章:《GZIP頁面壓縮原理》和《WEB性能優化之GZIP壓縮》

14、配置ETag

Entity tags(ETags)(實體標籤)是web服務器和瀏覽器用於判斷瀏覽器緩存中的內容和服務器中的原始內容是否匹配的一種機制(“實體”就是所說的“內 容”,包括圖片、腳本、樣式表等)。增加ETag爲實體的驗證提供了一個比使用“last-modified date(上次編輯時間)”更加靈活的機制。Etag是一個識別內容版本號的唯一字符串。唯一的格式限制就是它必須包含在雙引號內。原始服務器通過含有 ETag文件頭的響應指定頁面內容的ETag。

HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: “10c24bc-4ab-457e1c1f”
Content-Length: 12195
稍後,如果瀏覽器要驗證一個文件,它會使用If-None-Match文件頭來把ETag傳回給原始服務器。在這個例子中,如果ETag匹配,就會返回一 個304狀態碼,這就節省了12195字節的響應。

GET /i/yahoo.gif HTTP/1.1
Host: love.52maomao.info
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
If-None-Match: “10c24bc-4ab-457e1c1f”
HTTP/1.1 304 Not Modified
ETag的問題在於,它是根據可以辨別網站所在的服務器的具有唯一性的屬性來生成的。當瀏覽器從一臺服務器上獲得頁面內容後到另外一臺服務器上進行 驗證時ETag就會不匹配,這種情況對於使用服務器組和處理請求的網站來說是非常常見的。默認情況下,Apache和IIS都會把數據嵌入ETag中,這 會顯著減少多服務器間的文件驗證衝突。

Apache 1.3和2.x中的ETag格式爲inode-size-timestamp,即使某個文件在不同的服務器上會處於相同的目錄下,文件大小、權限、時間戳等都完全相同,但是在不同服務器上他們的內碼也是不同的。

IIS 5.0和IIS 6.0處理ETag的機制相似。IIS中的ETag格式爲Filetimestamp:ChangeNumber。用ChangeNumber來跟蹤 IIS配置的改變。網站所用的不同IIS服務器間ChangeNumber也不相同。 不同的服務器上的Apache和IIS即使對於完全相同的內容產生的ETag在也不相同,用戶並不會接收到一個小而快的304響應;相反他們會接收一個正 常的200響應並下載全部內容。

如果你的網站只放在一臺服務器上,就不會存在這個問題。但是如果你的網站是架設在多個服務器上,並且使用Apache和IIS產生默認的ETag配 置,你的用戶獲得頁面就會相對慢一點,服務器會傳輸更多的內容,佔用更多的帶寬,代理也不會有效地緩存你的網站內容。即使你的內容擁有Expires文件 頭,無論用戶什麼時候點擊“刷新”或者“重載”按鈕都會發送相應的GET請求。

如果你沒有使用ETag提供的靈活的驗證模式,那麼幹脆把所有的ETag都去掉會更好。Last-Modified文件頭驗證是基於內容的時間戳 的。去掉 ETag文件頭會減少響應和下次請求中文件的大小。微軟的這篇支持文稿講述瞭如何去掉ETag。在Apache中,只需要在配置文件中簡單添加下面一行代 碼就可以了:FileETag none。

15、儘早刷新輸出緩衝

當用戶請求一個頁面時,無論如何都會花費200到500毫秒用於後臺組織HTML文件。在這期間,瀏覽器會一直空閒等待數據返回。在PHP中,你可 以使用flush()方法,它允許你把已經編譯的好的部分HTML響應文件先發送給瀏覽器,這時瀏覽器就會可以下載文件中的內容(腳本等)而後臺同時處理 剩餘的 HTML頁面。這樣做的效果會在後臺煩惱或者前臺較空閒時更加明顯。

輸出緩衝應用最好的一個地方就是緊跟在之後,因爲HTML的頭部分容易生成而且頭部往往包含CSS和JavaScript文件,這樣瀏覽器就可以在後臺編譯剩餘HTML的同時並行下載它們。 例子:

16、使用GET來完成AJAX請求

Yahoo! Mail團隊發現,當使用XMLHttpRequest時,瀏覽器中的POST方法是一個“兩步走”的過程:首先發送文件頭,然後才發送數據。因此使用 GET最爲恰當,因爲它只需發送一個TCP包(除非你有很多cookie)。IE中URL的最大長度爲2K,因此如果你要發送一個超過2K的數據時就不能 使用GET了。

一個有趣的不同就是POST並不像GET那樣實際發送數據。根據HTTP規範,GET意味着“獲取”數據,因此當你僅僅獲取數據時使用GET更加有意義(從語意上講也是如此),相反,發送並在服務端保存數據時使用POST。

17、把樣式表置於頂部

在研究Yahoo!的性能表現時,我們發現把樣式表放到文檔的內部似乎會加快頁面的下載速度。這是因爲把樣式表放到內會使頁面有步驟的加載顯示。
注重性能的前端服務器往往希望頁面有秩序地加載。同時,我們也希望瀏覽器把已經接收到內容儘可能顯示出來。這對於擁有較多內容的頁面和網速較慢的用戶來說 特別重要。向用戶返回可視化的反饋,比如進程指針,已經有了較好的研究並形成了正式文檔。在我們的研究中HTML頁面就是進程指針。當瀏覽器有序地加載文 件頭、導航欄、頂部的logo等對於等待頁面加載的用戶來說都可以作爲可視化的反饋。這從整體上改善了用戶體驗。
把樣式表放在文檔底部的問題是在包括Internet Explorer在內的很多瀏覽器中這會中止內容的有序呈現。瀏覽器中止呈現是爲了避免樣式改變引起的頁面元素重繪,用戶不得不面對一個空白頁面。

HTML規範清楚指出樣式表要放包含在頁面的區域內:“和不同,只能出現在文檔的區域內,儘管它可以多次使用它”。無論是引起白屏還是出現沒有樣式化的內容都不值得去嘗試。最好的方案就是按照HTML規範在文 檔內加載你的樣式表。

18、避免使用CSS表達式(Expression)

CSS表達式是動態設置CSS屬性的強大(但危險)方法。Internet Explorer從第5個版本開始支持CSS表達式。下面的例子中,使用CSS表達式可以實現隔一個小時切換一次背景顏色:

background-color: expression( (new Date()).getHours()%2 ? “#B8D4FF” : “#F08A00″ );

如上所示,expression中使用了JavaScript表達式。CSS屬性根據JavaScript表達式的計算結果來設置。 expression方法在其它瀏覽器中不起作用,因此在跨瀏覽器的設計中單獨針對Internet Explorer設置時會比較有用。

表達式的問題就在於它的計算頻率要比我們想象的多。不僅僅是在頁面顯示和縮放時,就是在頁面滾動、乃至移動鼠標時都會要重新計算一次。給CSS表達式增加一個計數器可以跟蹤表達式的計算頻率。在頁面中隨便移動鼠標都可以輕鬆達到10000次以上的計算量。

一個減少CSS表達式計算次數的方法就是使用一次性的表達式,它在第一次運行時將結果賦給指定的樣式屬性,並用這個屬性來代替CSS表達式。如果樣 式屬性必須在頁面週期內動態地改變,使用事件句柄來代替CSS表達式是一個可行辦法。如果必須使用CSS表達式,一定要記住它們要計算成千上萬次並且可能 會對你頁面的性能產生影響。

19、使用外部JavaScript和CSS

很多性能規則都是關於如何處理外部文件的。但是,在你採取這些措施前你可能會問到一個更基本的問題:JavaScript和CSS是應該放在外部文件中呢還是把它們放在頁面本身之內呢?

在實際應用中使用外部文件可以提高頁面速度,因爲JavaScript和CSS文件都能在瀏覽器中產生緩存。內置在HTML文檔中的 JavaScript和CSS則會在每次請求中隨HTML文檔重新下載。這雖然減少了HTTP請求的次數,卻增加了HTML文檔的大小。從另一方面來說, 如果外部文件中的JavaScript和CSS被瀏覽器緩存,在沒有增加HTTP請求次數的同時可以減少HTML文檔的大小。

關鍵問題是,外部JavaScript和CSS文件緩存的頻率和請求HTML文檔的次數有關。雖然有一定的難度,但是仍然有一些指標可以一測量它。 如果一個會話中用戶會瀏覽你網站中的多個頁面,並且這些頁面中會重複使用相同的腳本和樣式表,緩存外部文件就會帶來更大的益處。

許多網站沒有功能建立這些指標。對於這些網站來說,最好的堅決方法就是把JavaScript和CSS作爲外部文件引用。比較適合使用內置代碼的例 外就是網站的主頁,如Yahoo!主頁和My Yahoo!。主頁在一次會話中擁有較少(可能只有一次)的瀏覽量,你可以發現內置JavaScript和CSS對於終端用戶來說會加快響應時間。

對於擁有較大瀏覽量的首頁來說,有一種技術可以平衡內置代碼帶來的HTTP請求減少與通過使用外部文件進行緩存帶來的好處。其中一個就是在首頁中內 置 JavaScript和CSS,但是在頁面下載完成後動態下載外部文件,在子頁面中使用到這些文件時,它們已經緩存到瀏覽器了。

20、削減JavaScript和CSS

精簡是指從去除代碼不必要的字符減少文件大小從而節省下載時間。消減代碼時,所有的註釋、不需要的空白字符(空格、換行、tab縮進)等都要去掉。 在 JavaScript中,由於需要下載的文件體積變小了從而節省了響應時間。精簡JavaScript中目前用到的最廣泛的兩個工具是JSMin和YUI Compressor。YUI Compressor還可用於精簡CSS。

混淆是另外一種可用於源代碼優化的方法。這種方法要比精簡複雜一些並且在混淆的過程更易產生問題。在對美國前10大網站的調查中發現,精簡也可以縮 小原來代碼體積的21%,而混淆可以達到25%。儘管混淆法可以更好地縮減代碼,但是對於JavaScript來說精簡的風險更小。

除消減外部的腳本和樣式表文件外,

21、用代替@import

前面的最佳實現中提到CSS應該放置在頂端以利於有序加載呈現。
在IE中,頁面底部@import和使用作用是一樣的,因此最好不要使用它。
22、避免使用濾鏡
IE獨有屬性AlphaImageLoader用於修正7.0以下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在於瀏覽器加載圖片時它會終止內容的呈現並且凍結瀏覽器。在每一個元素(不僅僅是圖片)它都會運算一次,增加了內存開支,因此它的問題是多方面的。

完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替,這種格式能在IE中很好地工作。如果你確實需要使用 AlphaImageLoader,請使用下劃線_filter又使之對IE7以上版本的用戶無效。

23、把腳本置於頁面底部

腳本帶來的問題就是它阻止了頁面的平行下載。HTTP/1.1 規範建議,瀏覽器每個主機名的並行下載內容不超過兩個。如果你的圖片放在多個主機名上,你可以在每個並行下載中同時下載2個以上的文件。但是當下載腳本 時,瀏覽器就不會同時下載其它文件了,即便是主機名不相同。

在某些情況下把腳本移到頁面底部可能不太容易。比如說,如果腳本中使用了document.write來插入頁面內容,它就不能被往下移動了。這裏可能還會有作用域的問題。很多情況下,都會遇到這方面的問題。

一個經常用到的替代方法就是使用延遲腳本。DEFER屬性表明腳本中沒有包含document.write,它告訴瀏覽器繼續顯示。不幸的 是,Firefox並不支持DEFER屬性。在Internet Explorer中,腳本可能會被延遲但效果也不會像我們所期望的那樣。如果腳本可以被延遲,那麼它就可以移到頁面的底部,這會讓你的頁面加載的快一點。

24、剔除重複腳本

在同一個頁面中重複引用JavaScript文件會影響頁面的性能。你可能會認爲這種情況並不多見。對於美國前10大網站的調查顯示其中有兩家存在 重複引用腳本的情況。有兩種主要因素導致一個腳本被重複引用的奇怪現象發生:團隊規模和腳本數量。如果真的存在這種情況,重複腳本會引起不必要的HTTP 請求和無用的JavaScript運算,這降低了網站性能。

在Internet Explorer中會產生不必要的HTTP請求,而在Firefox卻不會。在Internet Explorer中,如果一個腳本被引用兩次而且它又不可緩存,它就會在頁面加載過程中產生兩次HTTP請求。即時腳本可以緩存,當用戶重載頁面時也會產 生額外的HTTP請求。

除增加額外的HTTP請求外,多次運算腳本也會浪費時間。在Internet Explorer和Firefox中不管腳本是否可緩存,它們都存在重複運算JavaScript的問題。

一個避免偶爾發生的兩次引用同一腳本的方法是在模板中使用腳本管理模塊引用腳本。在HTML頁面中使用

在PHP中可以通過創建名爲insertScript的方法來替代:

爲了防止多次重複引用腳本,這個方法中還應該使用其它機制來處理腳本,如檢查所屬目錄和爲腳本文件名中增加版本號以用於Expire文件頭等。

25、減少DOM訪問

使用JavaScript訪問DOM元素比較慢,因此爲了獲得更多的應該頁面,應該做到:

1、緩存已經訪問過的有關元素;

2、線下更新完節點之後再將它們添加到文檔樹中;

3、避免使用JavaScript來修改頁面佈局。

有關此方面的更多信息請查看Julien Lecomte在YUI專題中的文章《高性能Ajax程序》。

26、開發智能事件處理程序

有時候我們會感覺到頁面反應遲鈍,這是因爲DOM樹元素中附加了過多的事件句柄並且些事件句病被頻繁地觸發。這就是爲什麼說使用event delegation(事件代理)是一種好方法了。如果你在一個div中有10個按鈕,你只需要在div上附加一次事件句柄就可以了,而不用去爲每一個按 鈕增加一個句柄。事件冒泡時你可以捕捉到事件並判斷出是哪個事件發出的。

你同樣也不用爲了操作DOM樹而等待onload事件的發生。你需要做的就是等待樹結構中你要訪問的元素出現。你也不用等待所有圖像都加載完畢。

你可能會希望用DOMContentLoaded事件來代替事件應用程序中的onAvailable方法。

27、減小Cookie體積

HTTP coockie可以用於權限驗證和個性化身份等多種用途。coockie內的有關信息是通過HTTP文件頭來在web服務器和瀏覽器之間進行交流的。因此保持coockie儘可能的小以減少用戶的響應時間十分重要。

有關更多信息可以查看Tenni Theurer和Patty Chi的文章《When the Cookie Crumbles》。這們研究中主要包括:

1、去除不必要的coockie;

2、使coockie體積儘量小以減少對用戶響應的影響;

3、注意在適應級別的域名上設置coockie以便使子域名不受影響。

設置合理的過期時間,較早地Expire時間和不要過早去清除coockie,都會改善用戶的響應時間。

28、對於頁面內容使用無coockie域名

當瀏覽器在請求中同時請求一張靜態的圖片和發送coockie時,服務器對於這些coockie不會做任何地使用。因此他們只是因爲某些負面因素而創建的 網絡傳輸。所有你應該確定對於靜態內容的請求是無coockie的請求。創建一個子域名並用他來存放所有靜態內容。

如果你的域名是www.52maomao.info,你可以在static.52maomao.info上存在靜態內容。但是,如果你不是在 www.52maomao.info 上而是在頂級域名52maomao.info設置了coockie,那麼所有對於static.52maomao.info的請求都包含coockie。 在這種情 況下,你可以再重新購買一個新的域名來存在靜態內容,並且要保持這個域名是無coockie的。Yahoo!使用的是ymig.com,YouTube使 用的是ytimg.com,Amazon使用的是images-anazon.com等等。

使用無coockie域名存在靜態內容的另外一個好處就是一些代理(服務器)可能會拒絕對coockie的內容請求進行緩存。一個相關的建議就是, 如果你想確定應該使用52maomao.info還是www.52maomao.info 作爲你的一主頁,你要考慮到coockie帶來的影響。忽略掉www會使你除了把coockie設置到.example.org(是泛域名解析,代表 了所有子域名)外沒有其它選擇,因此出於性能方面的考慮最好是使用帶有www的子域名並且在它上面設置coockie。

29、優化圖像

設計人員完成對頁面的設計之後,不要急於將它們上傳到web服務器,這裏還需要做幾件事:

你可以檢查一下你的GIF圖片中圖像顏色的數量是否和調色板規格一致。 使用imagemagick中下面的命令行很容易檢查:identify-verbose image.gif。

如果你發現圖片中只用到了4種顏色,而在調色板的中顯示的256色的顏色槽,那麼這張圖片就還有壓縮的空間。

嘗試把GIF格式轉換成PNG格式,看看是否節省空間。大多數情況下是可以壓縮的。由於瀏覽器支持有限,設計者們往往不太樂意使用PNG格式的圖 片,不過這 都是過去的事情了。現在只有一個問題就是在真彩PNG格式中的alpha通道半透明問題,不過同樣的,GIF也不是真彩格式也不支持半透明。因此GIF能 做到的,PNG(PNG8)同樣也能做到(除了動畫)。下面這條簡單的命令可以安全地把GIF格式轉換爲PNG格式:
convert image.gif image.png
“我們要說的是:給PNG一個施展身手的機會吧!”

在所有的PNG圖片上運行pngcrush(或者其它PNG優化工具)。例如:

pngcrush image.png -rem alla -reduce -brute result.png

在所有的 JPEG圖片上運行jpegtran。這個工具可以對圖片中的出現的鋸齒等做無損操作,同時它還可以用於優化和清除圖片中的註釋以及其它無用信息(如 EXIF信息):
jpegtran -copy none -optimize -perfect src.jpg dest.jpg

30、優化CSS Spirite

在Spirite中水平排列你的圖片,垂直排列會稍稍增加文件大小;

Spirite 中把顏色較近的組合在一起可以降低顏色數,理想狀況是低於256色以便適用PNG8格式;

便於移動,不要在Spirite的圖像中間留有較大空隙。這雖然不大會增加文件大小但對於用戶代理來說它需要更少的內存來把圖片解壓爲像素地圖。100×100的圖片爲1萬像素,而 1000×1000就是100萬像素。

31、不要在HTML中縮放圖像

不要爲了在HTML中設置長寬而使用比實際需要大的圖片。如果你需要:

32、favicon.ico要小而且可緩存

favicon.ico是位於服務器根目錄下的一個圖片文件。它是必定存在的,因爲即使你不關心它是否有用,瀏覽器也會對它發出請求,因此最好不要 返回一 個404 Not Found的響應。由於是在同一臺服務器上,它每被請求一次coockie就會被髮送一次。這個圖片文件還會影響下載順序,例如在IE中當你在 onload中請求額外的文件時,favicon會在這些額外內容被加載前下載。

因此,爲了減少favicon.ico帶來的弊端,要做到:文件儘量地小,最好小於1K。

在適當的時候(也就是你不要打算再換 favicon.ico的時候,因爲更換新文件時不能對它進行重命名)爲它設置Expires文件頭。你可以很安全地把Expires文件頭設置爲未來的幾個月。你可以通過覈對當前favicon.ico的上次編輯時間來作出判斷。

Imagemagick可以幫你創建小巧的favicon。

33、保持單個內容小於25K

這條限制主要是因爲iPhone不能緩存大於25K的文件。注意這裏指的是解壓縮後的大小。由於單純gizp壓縮可能達不要求,因此精簡文件就顯得十分重要。

查看更多信息,請參閱Wayne Shea和Tenni Theurer的文件《Performance Research, Part 5: iPhone Cacheability – Making it Stick》。

34、打包組件成複合文本

把頁面內容打包成複合文本就如同帶有多附件的Email,它能夠使你在一個HTTP請求中取得多個組件(切記:HTTP請求是很奢侈的)。當你使用這條規則時,首先要確定用戶代理是否支持(iPhone就不支持)。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章