雅虎網頁性能優化的35條黃金守則

時間 2019-11-18

標籤雅虎網頁性能優化黃金守則欄目 HTML 简体版

原文原文鏈接

　　參考Best Practices for Speeding Up Your Web Sitejavascript

　　Exceptional Performance 團隊總結了一系列優化網站性能的方法，分紅了7個大類35條，包括內容、服務器、cookie、CSS、 JavaScript、圖片、移動應用等七部分。php

1.減小http請求

　　標籤: 內容css

　　80%的終端響應時間花在了前端下載網頁的各項內容，包括圖片，樣式表，腳本，Flash等。減小頁面的中的元素能夠減小http請求，從而提升網頁速度。html

減小頁面元素的方法就是簡化頁面的設計。可是有沒有一種方法既能保持頁面既的豐富性，又能達到加快響應時間的目的呢？這裏有幾條減小HTTP請求次數同時又可能保持頁面內容豐富的技術。前端

　　合併文件是減小大量HTTP請求的途徑之一，例如合併大量的腳本文件爲一個腳本，簡單地把全部的CSS文件都放入一個樣式表中。當腳本或者樣式表在不一樣頁面中使用時須要作不一樣的修改，這可能會相對麻煩點，但即使如此也要把這個方法做爲改善頁面性能的重要一步。java

　　CSS Sprites是減小圖像請求的有效方法，將你的背景圖片合併成一張圖片，使用CSS background-image和 background-position屬性能夠顯示想要的顯示圖片模塊。node

　　Image maps 圖像映射是把多張圖片整合到一張圖片中。雖然文件的整體大小不會改變，可是能夠減小HTTP請求次數加快網頁的響應速度。圖片映射只有在圖片的全部組成部分在頁面中是緊挨在一塊兒的時候才能使用，如導航欄。肯定圖片的座標和可能會比較繁瑣且容易出錯，同時使用圖片地圖導航也不具備可讀性，所以不推薦這種方法。web

　　Inline images 內聯圖像是使用data:URL scheme 的方法把圖像數據加載頁面中。這可能會增長html頁面的大小。把內聯圖像放到樣式表（可緩存）中能夠減小HTTP請求同時又避免增長頁面文件的大小。可是內聯圖像如今尚未獲得主流瀏覽器的支持。ajax

　　減小頁面的HTTP請求次數是你首先要作的一步。這是改進首次訪問用戶等待時間的最重要的方法。HTTP請求在無緩存狀況下佔去了40%到60%的響應時間。讓那些初次訪問你網站的人獲得更加快速的體驗吧！數據庫

2. 使用CDN（Content Delivery Network）

tag: 服務器

　　用戶與你的web服務器的距離對響應時間有很大影響。將你服務器的內容部署在多個，地理上分散的服務器可使你的用戶更快地加載網頁內容。可是從哪開始呢？

第一步，地理上分散的內容，不要試圖爲了在分佈式架構上工做而從新設計你的web應用。對於有些應用，改變體系結構可能包括艱鉅的任務，例如在同步會話狀態和在服務器地點複製數據庫事務。嘗試減小用戶和內容之間的距離能夠經過被這一步應用架構推遲或從不實施。

　　80%-90%的終端響應時間花在了下載網頁的各項內容，如圖片，樣式表，腳本，Flash等。這是 Performance Golden Rule.與其從新設計你的應用架構，不如首先分散你的靜態內容。這個不只能夠達到更好的減小響應時間的目的，還很簡單，由於內容分發網絡CDN。

　　內容分發網絡（CDN）是分佈在多個位置，以更有效地提供內容給用戶的網絡服務器的集合。選擇服務器用於傳送內容給特定用戶，一般基於用戶與網絡的接近度。例如，用最少的網絡跳數或以最快的響應時間的服務器的服務器被選中。

　　一些大型互聯網公司擁有本身的CDN，但使用CDN服務提供商更划算，如Akamai Technologies公司EdgeCast或3級。對於初創公司和私人網站，一個CDN服務的成本可能會望而卻步，但隨着你的目標受衆變大，變得更加全球化，一個CDN要實現快速的響應時間。在雅虎，提升最終用戶的響應20％或更屢次（以上以及雅虎本身的CDN提到二者的第三方）感動靜態內容了他們的應用程序的Web服務器到CDN屬性。切換到CDN是一個比較簡單的代碼更改，這將極大地提升你的網站的速度。

　　就近緩存==>智能路由==>負載均衡==>WSA全站動態加速

3.爲文件頭設定Expires或Cache-Control

tag:server

　　這條守則包括兩方面的內容：
　　對於靜態內容：設置文件頭過時時間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文件頭，增長了緩存在瀏覽器中內容的數量，而且能夠在用戶接下來的請求中再次使用這些內容，這甚至都不須要經過用戶發送一個字節的請求。

4.Gzip壓縮文件內容

tag: server

　　網絡傳輸中的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壓縮全部可能的文件類型是減小文件體積增長用戶體驗的簡單方法。

5.把樣式表置於頂部

tag: css

　　在研究Yahoo!的性能表現時，咱們發現把樣式表放到文檔的<head />內部彷佛會加快頁面的下載速度。這是由於把樣式表放到<head />內會使頁面有步驟的加載顯示。
      注重性能的前端服務器每每但願頁面有秩序地加載。同時，咱們也但願瀏覽器把已經接收到內容儘量顯示出來。這對於擁有較多內容的頁面和網速較慢的用戶來講特別重要。向用戶返回可視化的反饋，好比進程指針，已經有了較好的研究並造成了正式文檔。在咱們的研究中 HTML頁面就是進程指針。當瀏覽器有序地加載文件頭、導航欄、頂部的logo等對於等待頁面加載的用戶來講均可以做爲可視化的反饋。這從總體上改善了用戶體驗。
      把樣式表放在文檔底部的問題是在包括Internet Explorer在內的不少瀏覽器中這會停止內容的有序呈現。瀏覽器停止呈現是爲了不樣式改變引發的頁面元素重繪。用戶不得不面對一個空白頁面。
      HTML規範清楚指出樣式表要放包含在頁面的<head />區域內：「和<a />不一樣，<link />只能出如今文檔的<head />區域內，儘管它能夠屢次使用它」。不管是引發白屏仍是出現沒有樣式化的內容都不值得去嘗試。最好的方案就是按照HTML規範在文檔<head />內加載你的樣式表。

6.腳本文件置於頁面底部

　　腳本帶來的問題就是它阻止了頁面的平行下載。HTTP/1.1 規範建議，瀏覽器每一個主機名的並行下載內容不超過兩個。若是你的圖片放在多個主機名上，你能夠在每一個並行下載中同時下載2個以上的文件。可是當下載腳本時，瀏覽器就不會同時下載其它文件了，即使是主機名不相同。
在某些狀況下把腳本移到頁面底部可能不太容易。好比說，若是腳本中使用了document.write來插入頁面內容，它就不能被往下移動了。這裏可能還會有做用域的問題。不少狀況下，都會遇到這方面的問題。
一個常常用到的替代方法就是使用延遲腳本。DEFER屬性代表腳本中沒有包含document.write，它告訴瀏覽器繼續顯示。不幸的是，Firefox並不支持DEFER屬性。在Internet Explorer中，腳本可能會被延遲但效果也不會像咱們所指望的那樣。若是腳本能夠被延遲，那麼它就能夠移到頁面的底部。這會讓你的頁面加載的快一點。

7.避免使用CSS Expressions

tag: css

　　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表達式，必定要記住它們要計算成千上萬次而且可能會對你頁面的性能產生影響。

8.使用外部的JavaScript and CSS

tag: 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，可是在頁面下載完成後動態下載外部文件，在子頁面中使用到這些文件時，它們已經緩存到瀏覽器了。

9.減小DNS查找次數

tag: content　　

　　域名系統（DNS）提供了域名和IP的對應關係，就像電話本中人名和他們的電話號碼的關係同樣。當你在瀏覽器地址欄中輸入www.dudo.org 時，DNS解析服務器就會返回這個域名對應的IP地址。DNS解析的過程一樣也是須要時間的。通常狀況下返回給定域名對應的IP地址會花費20到120毫秒的時間。並且在這個過程當中瀏覽器什麼都不會作直到DNS查找完畢。

       緩存DNS查找能夠改善頁面性能。這種緩存須要一個特定的緩存服務器，這種服務器通常屬於用戶的ISP提供商或者本地局域網控制，可是它一樣會在用戶使用的計算機上產生緩存。DNS信息會保留在操做系統的DNS緩存中（微軟Windows系統中DNS Client Service）。大多數瀏覽器有獨立於操做系統之外的本身的緩存。因爲瀏覽器有本身的緩存記錄，所以在一次請求中它不會受到操做系統的影響。

      Internet Explorer默認狀況下對DNS查找記錄的緩存時間爲30分鐘，它在註冊表中的鍵值爲DnsCacheTimeout。Firefox對DNS的查找記錄緩存時間爲1分鐘，它在配置文件中的選項爲network.dnsCacheExpiration（Fasterfox把這個選項改成了1小時）。

      當客戶端中的DNS緩存都爲空時（瀏覽器和操做系統都爲空），DNS查找的次數和頁面中主機名的數量相同。這其中包括頁面中URL、圖片、腳本文件、樣式表、Flash對象等包含的主機名。減小主機名的數量能夠減小DNS查找次數。

      減小主機名的數量還能夠減小頁面中並行下載的數量。減小DNS查找次數能夠節省響應時間，可是減小並行下載卻會增長響應時間。個人指導原則是把這些頁面中的內容分割成至少兩部分但不超過四部分。這種結果就是在減小DNS查找次數和保持較高程度並行下載二者之間的權衡了。

10.削減JavaScript and CSS

tag: javascript, css

　　精簡是指從去除代碼沒必要要的字符減小文件大小從而節省下載時間。消減代碼時，全部的註釋、不須要的空白字符（空格、換行、tab縮進）等都要去掉。在 JavaScript中，因爲須要下載的文件體積變小了從而節省了響應時間。精簡JavaScript中目前用到的最普遍的兩個工具是JSMin 和YUI Compressor 。YUI Compressor還可用於精簡CSS。
混淆是另一種可用於源代碼優化的方法。這種方法要比精簡複雜一些而且在混淆的過程更易產生問題。在對美國前10大網站的調查中發現，精簡也能夠縮小原來代碼體積的21%，而混淆能夠達到25%。儘管混淆法能夠更好地縮減代碼，可是對於JavaScript來講精簡的風險更小。
除消減外部的腳本和樣式表文件外，<script>和<style>代碼塊也能夠而且應該進行消減。即便你用Gzip壓縮過腳本和樣式表，精簡這些文件仍然能夠節省5%以上的空間。因爲JavaScript和CSS的功能和體積的增長，消減代碼將會得到益處。

11.避免跳轉

tag: content

　　跳轉是使用301和302代碼實現的。下面是一個響應代碼爲301的HTTP頭：
      HTTP/1.1 301 Moved Permanently
      Location: http://example.com/newuri
      Content-Type: text/html
      瀏覽器會把用戶指向到Location中指定的URL。頭文件中的全部信息在一次跳轉中都是必需的，內容部分能夠爲空。無論他們的名稱，301和302響應都不會被緩存除非增長一個額外的頭選項，如Expires或者Cache-Control來指定它緩存。<meat />元素的刷新標籤和JavaScript也能夠實現URL的跳轉，可是若是你必需要跳轉的時候，最好的方法就是使用標準的3XXHTTP狀態代碼，這主要是爲了確保「後退」按鈕能夠正確地使用。

      可是要記住跳轉會下降用戶體驗。在用戶和HTML文檔中間增長一個跳轉，會拖延頁面中全部元素的顯示，由於在HTML文件被加載前任何文件（圖像、 Flash等）都不會被下載。

      有一種常常被網頁開發者忽略卻每每十分浪費響應時間的跳轉現象。這種現象發生在當URL本該有斜槓（/）卻被忽略掉時。例如，當咱們要訪問http: //astrology.yahoo.com/astrology 時，實際上返回的是一個包含301代碼的跳轉，它指向的是http://astrology.yahoo.com/astrology/ （注意末尾的斜槓）。在Apache服務器中可使用Alias 或者 mod_rewrite或者the DirectorySlash來避免。

      鏈接新網站和舊網站是跳轉功能常常被用到的另外一種狀況。這種狀況下每每要鏈接網站的不一樣內容而後根據用戶的不一樣類型（如瀏覽器類型、用戶帳號所屬類型）來進行跳轉。使用跳轉來實現兩個網站的切換十分簡單，須要的代碼量也很少。儘管使用這種方法對於開發者來講能夠下降複雜程度，可是它一樣下降用戶體驗。一個可替代方法就是若是二者在同一臺服務器上時使用Alias和mod_rewrite和實現。若是是由於域名的不一樣而採用跳轉，那麼能夠經過使用Alias 或者mod_rewirte創建CNAME（保存一個域名和另一個域名之間關係的DNS記錄）來替代。

12.剔除重複腳本

tag: javascript

　　在同一個頁面中重複引用JavaScript文件會影響頁面的性能。你可能會認爲這種狀況並很少見。對於美國前10大網站的調查顯示其中有兩家存在重複引用腳本的狀況。有兩種主要因素致使一個腳本被重複引用的奇怪現象發生：團隊規模和腳本數量。若是真的存在這種狀況，重複腳本會引發沒必要要的HTTP請求和無用的JavaScript運算，這下降了網站性能。
      在Internet Explorer中會產生沒必要要的HTTP請求，而在Firefox卻不會。在Internet Explorer中，若是一個腳本被引用兩次並且它又不可緩存，它就會在頁面加載過程當中產生兩次HTTP請求。即時腳本能夠緩存，當用戶重載頁面時也會產生額外的HTTP請求。
      除增長額外的HTTP請求外，屢次運算腳本也會浪費時間。在Internet Explorer和Firefox中無論腳本是否可緩存，它們都存在重複運算JavaScript的問題。
      一個避免偶爾發生的兩次引用同一腳本的方法是在模板中使用腳本管理模塊引用腳本。在HTML頁面中使用<script />標籤引用腳本的最多見方法就是：
      <script type="text/javascript" src="menu_1.0.17.js"></script>
　　在PHP中能夠經過建立名爲 insertScript的方法來替代：
      <?php insertScript("menu.js") ?>
　　爲了防止屢次重複引用腳本，這個方法中還應該使用其它機制來處理腳本，如檢查所屬目錄和爲腳本文件名中增長版本號以用於Expire 文件頭等。

13.配置 ETags

tag: server

　　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: us.yimg.com
      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

14.Make Ajax Cacheable

tag: content

　　Ajax常常被說起的一個好處就是因爲其從後臺服務器傳輸信息的異步性而爲用戶帶來的反饋的即時性。可是，使用Ajax並不能保證用戶不會在等待異步的 JavaScript和XML響應上花費時間。在不少應用中，用戶是否須要等待響應取決於Ajax如何來使用。例如，在一個基於Web的Email客戶端中，用戶必須等待Ajax返回符合他們條件的郵件查詢結果。記住一點，「異步」並不異味着「即時」，這很重要。

      爲了提升性能，優化Ajax響應是很重要的。提升Ajxa性能的措施中最重要的方法就是使響應具備可緩存性，具體的討論能夠查看Add an Expires or a Cache-Control Header 。其它的幾條規則也一樣適用於Ajax：
    Gizp壓縮文件
    減小DNS查找次數
    精簡JavaScript
    避免跳轉
    配置ETags

     讓咱們來看一個例子：一個Web2.0的Email客戶端會使用Ajax來自動完成對用戶地址薄的下載。若是用戶在上次使用過Email web應用程序後沒有對地址薄做任何的修改，並且Ajax響應經過Expire或者Cacke-Control頭來實現緩存，那麼就能夠直接從上一次的緩存中讀取地址薄了。必須告知瀏覽器是使用緩存中的地址薄仍是發送一個新的請求。這能夠經過爲讀取地址薄的Ajax URL增長一個含有上次編輯時間的時間戳來實現，例如，&t=11900241612等。若是地址薄在上次下載後沒有被編輯過，時間戳就不變，則從瀏覽器的緩存中加載從而減小了一次HTTP請求過程。若是用戶修改過地址薄，時間戳就會用來肯定新的URL和緩存響應並不匹配，瀏覽器就會重要請求更新地址薄。
        即便你的Ajxa響應是動態生成的，哪怕它只適用於一個用戶，那麼它也應該被緩存起來。這樣作可使你的Web2.0應用程序更加快捷。

15.儘早刷新輸出緩衝區Flush the Buffer Early

tag: server

當用戶請求一個頁面時，不管如何都會花費200到500毫秒用於後臺組織HTML文件。在這期間，瀏覽器會一直空閒等待數據返回。在PHP中，你可使用 flush()方法，它容許你把已經編譯的好的部分HTML響應文件先發送給瀏覽器，這時瀏覽器就會能夠下載文件中的內容（腳本等）然後臺同時處理剩餘的 HTML頁面。這樣作的效果會在後臺煩惱或者前臺較空閒時更加明顯。
      輸出緩衝應用最好的一個地方就是緊跟在<head />以後，由於HTML的頭部分容易生成並且頭部每每包含CSS和JavaScript文件，這樣瀏覽器就能夠在後臺編譯剩餘HTML的同時並行下載它們。例子：

      ... 
    </head>
    <?php flush(); ?>
    <body>
      ... 

爲了證實使用這項技術的好處，Yahoo!搜索率先研究並完成了用戶測試。

16.使用GET來完成AJAX請求

tag: server

　　Yahoo!Mail 團隊發現，當使用 XMLHttpRequest時，瀏覽器中的POST方法是一個「兩步走」的過程：首先發送文件頭，而後才發送數據。所以使用GET最爲恰當，由於它只需發送一個TCP包（除非你有不少cookie）。IE中URL的最大長度爲2K，所以若是你要發送一個超過2K的數據時就不能使用GET了。
一個有趣的不一樣就是POST並不像GET那樣實際發送數據。根據HTTP規範，GET 意味着「獲取」數據，所以當你僅僅獲取數據時使用GET更加有意義（從語意上講也是如此），相反，發送並在服務端保存數據時使用POST。

　　除此以外，JavaScript和CSS也是咱們頁面中常常用到的內容，對它們的優化也提升網站性能的重要方面：
CSS：

JavaScript

17.推遲加載內容

tag: content

　　你能夠仔細看一下你的網頁，問問本身「哪些內容是頁面呈現時所必需首先加載的？哪些內容和結構能夠稍後再加載？
        把整個過程按照onload事件分隔成兩部分，JavaScript是一個理想的選擇。例如，若是你有用於實現拖放和動畫的JavaScript，那麼它就以等待稍後加載，由於頁面上的拖放元素是在初始化呈現以後才發生的。其它的例如隱藏部分的內容（用戶操做以後才顯現的內容）和處於摺疊部分的圖像也能夠推遲加載
        工具能夠節省你的工做量：YUI Image Loader 可以幫你推遲加載摺疊部分的圖片，YUI Get utility是包含JS和 CSS的便捷方法。好比你能夠打開Firebug的Net選項卡看一下Yahoo的首頁。
        當性能目標和其它網站開發實踐一致時就會相得益彰。這種狀況下，經過程序提升網站性能的方法告訴咱們，在支持JavaScript的狀況下，能夠先去除用戶體驗，不過這要保證你的網站在沒有JavaScript也能夠正常運行。在肯定頁面運行正常後，再加載腳原本實現如拖放和動畫等更加花哨的效果。

18.預加載

tag: content

預加載和後加載看起來彷佛偏偏相反，但實際上預加載是爲了實現另一種目標。預加載是在瀏覽器空閒時請求未來可能會用到的頁面內容（如圖像、樣式表和腳本）。使用這種方法，當用戶要訪問下一個頁面時，頁面中的內容大部分已經加載到緩存中了，所以能夠大大改善訪問速度。

下面提供了幾種預加載方法：
無條件加載：觸發onload事件時，直接加載額外的頁面內容。以Google.com爲例，你能夠看一下它的spirit image圖像是怎樣在onload中加載的。這個spirit image圖像在google.com主頁中是不須要的，可是卻能夠在搜索結果頁面中用到它。
有條件加載：根據用戶的操做來有根據地判斷用戶下面可能去往的頁面並相應的預加載頁面內容。在search.yahoo.com中你能夠看到如何在你輸入內容時加載額外的頁面內容。
有預期的加載：載入從新設計過的頁面時使用預加載。這種狀況常常出如今頁面通過從新設計後用戶抱怨「新的頁面看起來很酷，可是卻比之前慢」。問題可能出在用戶對於你的舊站點創建了完整的緩存，而對於新站點卻沒有任何緩存內容。所以你能夠在訪問新站之前就加載一部內容來避免這種結果的出現。在你的舊站中利用瀏覽器的空餘時間加載新站中用到的圖像的和腳原本提升訪問速度。

19.減小 DOM 元素的數量

tag: content

　　一個複雜的頁面意味着須要下載更多數據，同時也意味着JavaScript遍歷DOM的效率越慢。好比當你增長一個事件句柄時在500和5000個DOM 元素中循環效果確定是不同的。
       大量的DOM元素的存在乎味着頁面中有能夠不用移除內容只須要替換元素標籤就能夠精簡的部分。你在頁面佈局中使用表格了嗎？你有沒有僅僅爲了佈局而引入更多的<div>元素呢？也許會存在一個適合或者在語意是更貼切的標籤能夠供你使用。
        YUI CSS utilities能夠給你的佈局帶來巨大幫助：grids.css能夠幫你實現總體佈局，font.css和reset.css能夠幫助你移除瀏覽器默認格式。它提供了一個從新審視你頁面中標籤的機會，好比只有在語意上有意義時才使用<div>，而不是由於它具備換行效果才使用它。
      DOM元素數量很容易計算出來，只須要在Firebug的控制檯內輸入：
document.getElementsByTagName('*').length
        那麼多少個DOM元素算是多呢？這能夠對照有很好標記使用的相似頁面。好比Yahoo!主頁是一個內容很是多的頁面，可是它只使用了700個元素（HTML標籤）。

20.根據域名劃分頁面內容

tag: content

　　把頁面內容劃分紅若干部分可使你最大限度地實現平行下載。因爲DNS查找帶來的影響你首先要確保你使用的域名數量在2個到4個之間。例如，你能夠把用到的HTML內容和動態內容放在www.example.org上，而把頁面各類組件（圖片、腳本、CSS)分別存放在 statics1.example.org和statics.example.org上。
你可在Tenni Theurer和Patty Chi合寫的文章Maximizing Parallel Downloads in the Carpool Lane 找到更多相關信息。

21.使 iframes數量最少

tag: content

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

<iframe> 優勢：

解決加載緩慢的第三方內容如圖標和廣告等的加載問題
Security sandbox
並行加載腳本

即時內容爲空，加載也須要時間
會阻止頁面加載
沒有語意

22.No 404s錯誤

tag: content

　　 HTTP請求時間消耗是很大的，所以使用HTTP請求來得到一個沒有用處的響應（例如404沒有找到頁面）是徹底沒有必要的，它只會下降用戶體驗而不會有一點好處。
有些站點把404錯誤響應頁面改成「你是否是要找***」，這雖然改進了用戶體驗可是一樣也會浪費服務器資源（如數據庫等）。最糟糕的狀況是指向外部 JavaScript的連接出現問題並返回404代碼。首先，這種加載會破壞並行加載；其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分當做JavaScript代碼來執行。

除了在網站在內容上的改進外，在網站服務器端上也有須要注意和改進的地方，它們包括：

23.Reduce Cookie Size

tag: cookie

　　HTTP coockie能夠用於權限驗證和個性化身份等多種用途。coockie內的有關信息是經過HTTP文件頭來在web服務器和瀏覽器之間進行交流的。所以保持coockie儘量的小以減小用戶的響應時間十分重要。
有關更多信息能夠查看Tenni Theurer和Patty Chi的文章「When the Cookie Crumbles」。這們研究中主要包括：

去除沒必要要的coockie
使coockie體積儘可能小以減小對用戶響應的影響
注意在適應級別的域名上設置coockie以便使子域名不受影響
設置合理的過時時間。較早地Expire時間和不要過早去清除coockie，都會改善用戶的響應時間。

24.對於頁面內容使用無cookie域名

tag: cookie

　　當瀏覽器在請求中同時請求一張靜態的圖片和發送coockie時，服務器對於這些coockie不會作任何地使用。所以他們只是由於某些負面因素而建立的網絡傳輸。全部你應該肯定對於靜態內容的請求是無coockie的請求。建立一個子域名並用他來存放全部靜態內容。
若是你的域名是www.example.org，你能夠在static.example.org上存在靜態內容。可是，若是你不是在 www.example.org上而是在頂級域名example.org設置了coockie，那麼全部對於static.example.org的請求都包含coockie。在這種狀況下，你能夠再從新購買一個新的域名來存在靜態內容，而且要保持這個域名是無coockie的。Yahoo!使用的是 ymig.com，YouTube使用的是ytimg.com，Amazon使用的是images-anazon.com等等。
使用無coockie域名存在靜態內容的另一個好處就是一些代理（服務器）可能會拒絕對coockie的內容請求進行緩存。一個相關的建議就是，若是你想肯定應該使用example.org仍是www.example.org做爲你的一主頁，你要考慮到coockie帶來的影響。忽略掉www會使你除了把coockie設置到*.example.org（*是泛域名解析，表明了全部子域名譯者dudo注）外沒有其它選擇，所以出於性能方面的考慮最好是使用帶有www的子域名而且在它上面設置coockie。

25.減小 DOM 訪問

tag: javascript

使用JavaScript訪問DOM元素比較慢，所以爲了得到更多的應該頁面，應該作到：

緩存已經訪問過的有關元素
線下更新完節點以後再將它們添加到文檔樹中
避免使用JavaScript來修改頁面佈局

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

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

tag: javascript

　　有時候咱們會感受到頁面反應遲鈍，這是由於DOM樹元素中附加了過多的事件句柄而且些事件句病被頻繁地觸發。這就是爲何說使用event delegation（事件代理）是一種好方法了。若是你在一個div中有10個按鈕，你只須要在div上附加一次事件句柄就能夠了，而不用去爲每個按鈕增長一個句柄。事件冒泡時你能夠捕捉到事件並判斷出是哪一個事件發出的。
      你一樣也不用爲了操做DOM樹而等待onload事件的發生。你須要作的就是等待樹結構中你要訪問的元素出現。你也不用等待全部圖像都加載完畢。
      你可能會但願用DOMContentLoaded事件來代替onload，可是在全部瀏覽器都支持它以前你可以使用YUI 事件應用程序中的onAvailable 方法。
      有關此方面的更多信息請查看Julien Lecomte在YUI專題中的文章「高性能Ajax應該程序」。

圖片和Coockie也是咱們網站中幾乎不可缺乏組成部分，此外隨着移動設備的流行，對於移動應用的優化也十分重要。這主要包括：
Coockie:

圖片：

移動應用：

27.用 <link> 代替 @import

tag: css

　　前面的最佳實現中提到CSS應該放置在頂端以利於有序加載呈現。
在IE中，頁面底部@import和使用<link>做用是同樣的，所以最好不要使用它。

28.避免使用濾鏡

tag: css

　　IE獨有屬性AlphaImageLoader用於修正7.0如下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在於瀏覽器加載圖片時它會終止內容的呈現而且凍結瀏覽器。在每個元素（不只僅是圖片）它都會運算一次，增長了內存開支，所以它的問題是多方面的。
徹底避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中很好地工做。若是你確實須要使用 AlphaImageLoader，請使用下劃線_filter又使之對IE7以上版本的用戶無效。

29.優化圖像

tag: images

設計人員完成對頁面的設計以後，不要急於將它們上傳到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.Optimize CSS Sprites

tag: images

在Spirite中水平排列你的圖片，垂直排列會稍稍增長文件大小；
Spirite中把顏色較近的組合在一塊兒能夠下降顏色數，理想情況是低於256色以便適用PNG8格式；
便於移動，不要在Spirite的圖像中間留有較大空隙。這雖然不大會增長文件大小但對於用戶代理來講它須要更少的內存來把圖片解壓爲像素地圖。100x100的圖片爲1萬像素，而1000x1000就是100萬像素。

31.不要再HTML中縮放圖像

tag: images

　　不要爲了在HTML中設置長寬而使用比實際須要大的圖片。若是你須要：
<img width="100" height="100" src="mycat.jpg" alt="My Cat" />
那麼你的圖片（mycat.jpg）就應該是100x100像素而不是把一個500x500像素的圖片縮小使用。

32.favicon.ico 要小並且能夠緩存

tag: images

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

文件儘可能地小，最好小於1K
在適當的時候（也就是你不要打算再換favicon.ico的時候，由於更換新文件時不能對它進行重命名）爲它設置Expires文件頭。你能夠很安全地把 Expires文件頭設置爲將來的幾個月。你能夠經過覈對當前favicon.ico的上次編輯時間來做出判斷。

Imagemagick 能夠幫你建立小巧的favicon。

33.保證單個內容小於 25K

tag: mobile

　這條限制主要是由於iPhone不能緩存大於25K的文件。注意這裏指的是解壓縮後的大小。因爲單純gizp壓縮可能達不要求，所以精簡文件就顯得十分重要。
查看更多信息，請參閱Wayne Shea和Tenni Theurer的文件「Performance Research, Part 5: iPhone Cacheability - Making it Stick」。

34.打包組件成符合文本

tag: mobile

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

35.Avoid Empty Image src

tag: server

Image with empty string src attribute occurs more than one will expect. It appears in two form:

straight HTML

<img src="">
JavaScript

var img = new Image();
img.src = "";

Both forms cause the same effect: browser makes another request to your server.

Internet Explorer makes a request to the directory in which the page is located.
Safari and Chrome make a request to the actual page itself.
Firefox 3 and earlier versions behave the same as Safari and Chrome, but version 3.5 addressed this issue[bug 444931] and no longer sends a request.
Opera does not do anything when an empty image src is encountered.

Why is this behavior bad?

Cripple your servers by sending a large amount of unexpected traffic, especially for pages that get millions of page views per day.
Waste server computing cycles generating a page that will never be viewed.
Possibly corrupt user data. If you are tracking state in the request, either by cookies or in another way, you have the possibility of destroying data. Even though the image request does not return an image, all of the headers are read and accepted by the browser, including all cookies. While the rest of the response is thrown away, the damage may already be done.

The root cause of this behavior is the way that URI resolution is performed in browsers. This behavior is defined in RFC 3986 - Uniform Resource Identifiers. When an empty string is encountered as a URI, it is considered a relative URI and is resolved according to the algorithm defined in section 5.2. This specific example, an empty string, is listed in section 5.4. Firefox, Safari, and Chrome are all resolving an empty string correctly per the specification, while Internet Explorer is resolving it incorrectly, apparently in line with an earlier version of the specification, RFC 2396 - Uniform Resource Identifiers (this was obsoleted by RFC 3986). So technically, the browsers are doing what they are supposed to do to resolve relative URIs. The problem is that in this context, the empty string is clearly unintentional.

HTML5 adds to the description of the tag's src attribute to instruct browsers not to make an additional request in section 4.8.2:

The src attribute must be present, and must contain a valid URL referencing a non-interactive, optionally animated, image resource that is neither paged nor scripted. If the base URI of the element is the same as the document's address, then the src attribute's value must not be the empty string.

Hopefully, browsers will not have this problem in the future. Unfortunately, there is no such clause for <script src=""> and <link href="">. Maybe there is still time to make that adjustment to ensure browsers don't accidentally implement this behavior.

This rule was inspired by Yahoo!'s JavaScript guru Nicolas C. Zakas. For more information check out his article "Empty image src can destroy your site".

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。