[譯]雅虎13個簡單規則-加速您的網站的最佳實踐

時間 2019-11-30

標籤雅虎簡單規則加速您的網站最佳實踐欄目網站開發简体版

原文原文鏈接

加速您的網站的最佳實踐

原文地址：https://developer.yahoo.com/performance/rules.htmljavascript

卓越績效團隊已經肯定了一些快速製做網頁的最佳作法。該清單包括35個最佳實踐，分爲7個類別。php

最小化HTTP請求

tag：contentcss

80％的最終用戶響應時間花費在前端。大部分時間是在下載頁面中的全部組件時綁定的：圖像，樣式表，腳本，Flash等。減小組件數量會減小呈現頁面所需的HTTP請求數。這是更快頁面的關鍵。html

減小頁面中組件數量的一種方法是簡化頁面的設計。可是是否有一種方法來構建具備更豐富內容的頁面，同時還實現快速響應時間？下面是一些減小HTTP請求數的技術，同時仍然支持豐富的頁面設計。前端

合併的文件是由全部腳本組合成一個單一的腳本，而且相似地全部的CSS組合成單個樣式表來減小HTTP請求的數量的方法。當腳本和樣式表在頁面之間有所不一樣時，組合文件更具挑戰性，但將此部分做爲發佈流程能夠提升響應時間。java

CSS精靈是減小圖像的請求的數量的優選的方法。結合您的背景圖片爲一個圖像，而後使用CSSbackground-image和background-position屬性來顯示所需的圖像段。node

圖像映射合併多個圖像到一個單一的形象。總體大小大體相同，但減小HTTP請求的數量加快了頁面。僅當圖像在頁面中是連續的（例如導航欄）時，圖像映射才起做用。定義圖像映射的座標多是乏味的而且容易出錯。使用圖像地圖進行導航也不可訪問，所以不建議使用。web

內嵌圖像使用data:URL方案嵌入到實際頁面的圖像數據。這可能會增長HTML文檔的大小。將行內圖片合併到（緩存的）樣式表是一種減小HTTP請求並避免增長網頁大小的方法。全部主要瀏覽器都不支持內聯圖片。ajax

減小您網頁中的HTTP請求數是開始的地方。這是提升首次訪問者性能的最重要指南。正如Tenni陶依爾的博客文章中描述的瀏覽器緩存的使用-曝光！，您網站的每日訪問者的40-60％帶有一個空緩存。爲您的網頁快速訪問這些第一次訪客是更好的用戶體驗的關鍵。算法

頂部 | 討論這個規則

使用內容交付網絡

tag：server

用戶與Web服務器的距離對響應時間有影響。在多個地理位置分散的服務器上部署內容，能夠從用戶的角度更快地加載網頁。但你應該從哪裏開始？

做爲實現地理上分散的內容的第一步，不要嘗試從新設計您的Web應用程序以在分佈式體系結構中工做。根據應用程序，更改架構可能包括使人沮喪的任務，如跨服務器位置同步會話狀態和複製數據庫事務。嘗試減小用戶和您的內容之間的距離可能會延遲，或永遠不會經過此應用程序體系結構步驟。

請記住，對最終用戶的響應時間80-90％用於下載的全部組件在頁面：圖片，樣式，腳本，Flash等這是性能的黃金法則。而不是開始從新設計您的應用程序架構的艱鉅任務，最好先分散您的靜態內容。這不只實現了響應時間的更大減小，可是因爲內容交付網絡更容易。

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

一些大型互聯網公司擁有本身的CDN，但它的成本效益的使用CDN服務提供商，如Akamai Technologies公司，EdgeCast或3級。對於初創公司和私人網站，CDN服務的成本多是使人望而卻步的，可是隨着您的目標受衆變得愈來愈大並變得愈來愈全球化，CDN是實現快速響應時間所必需的。在雅虎（以上以及雅虎本身提到這兩個第三方感動靜態內容了他們的應用程序的網絡服務器到一個CDN性能CDN提升終端用戶響應由20％或更屢次）。切換到CDN是一個相對容易的代碼更改，將大大提升您的網站的速度。

頂部 | 討論這個規則

添加到期或高速緩存控制標題

tag：server

這個規則有兩個方面：

對於靜態部件：落實設置遙遠的未來「永不過時」的政策Expires頭
對於動態組件：使用適當的Cache-Control頭球幫助有條件的請求瀏覽器

網頁設計愈來愈豐富，這意味着頁面中有更多的腳本，樣式表，圖像和Flash。您的網頁的首次訪問者可能必須發出幾個HTTP請求，但經過使用Expires標頭，您可使這些組件可緩存。這樣可避免後續網頁瀏覽中出現沒必要要的HTTP請求。Expires頭最常使用圖片使用，但他們應該使用全部包括腳本，樣式表和Flash組件組成。

瀏覽器（和代理）使用緩存減小HTTP請求的數量和大小，使網頁加載更快。Web服務器使用HTTP響應中的Expires標頭來告訴客戶端組件能夠緩存多長時間。這是一個遠將來Expires標題，告訴瀏覽器，這個響應將不會過期，直到2010年4月15日。

      到期日：星期四，2010年4月15日20:00:00 GMT

若是您的服務器是Apache，請使用ExpiresDefault指令設置相對於當前日期的過時日期。ExpiresDefault指令的此示例將Expires日期設置爲從請求時起10年。

      ExpiresDefault「訪問加10年」

請記住，若是你使用遠期的Expires標頭，你必須在組件更改時更改組件的文件名。在Yahoo!，咱們常常將此步驟做爲構建過程的一部分：版本號嵌入在組件的文件名中，例如，yahoo_2.0.6.js。

使用遠的未來Expires標頭只會在用戶訪問過您的網站後影響網頁瀏覽量。當用戶首次訪問您的網站而且瀏覽器的緩存爲空時，它對HTTP請求的數量沒有影響。所以，此性能提高的影響取決於用戶使用加載緩存訪問您的網頁的頻率。（A「引緩存」已經包含了全部的頁面組件。）咱們測得該在雅虎，發現有底漆的緩存頁面瀏覽數爲75-85％。經過使用遠期的Expires標頭，您能夠增長瀏覽器緩存的組件數量，並在後續頁面視圖上重複使用，而無需經過用戶的Internet鏈接發送單個字節。

頂部 | 討論這個規則

Gzip組件

tag：server

經過網絡傳輸HTTP請求和響應所需的時間能夠經過前端工程師作出的決定大大減小。的確，終端用戶的帶寬速度，互聯網服務提供商，對等交換點的距離等都超出了開發團隊的控制範圍。但還有其餘影響響應時間的變量。壓縮經過減小HTTP響應的大小來減小響應時間。

從HTTP / 1.1開始，Web客戶機指示對HTTP請求中的Accept-Encoding頭的壓縮支持。

      Accept-Encoding：gzip，deflate

若是Web服務器在請求中看到此標頭，它可使用客戶端列出的方法之一來壓縮響應。Web服務器經過響應中的Content-Encoding頭來通知Web客戶端。

      Content-Encoding：gzip

Gzip是目前最流行和最有效的壓縮方法。它是由GNU項目開發和標準化的RFC 1952年。你可能看到的惟一其餘壓縮格式是deflate，但它的效率較低，不受歡迎。

Gzip一般將響應大小減少約70％。目前大約90％的互聯網流量經過聲稱支持gzip的瀏覽器。若是您使用Apache，該模塊配置的gzip取決於您的版本：Apache 1.3中使用mod_gzip的同時，阿帕奇2.x使用mod_deflate模塊。

瀏覽器和代理有一些已知的問題，可能致使瀏覽器指望的內容不匹配，以及關於壓縮內容接收的內容不匹配。幸運的是，這些邊緣狀況正在逐漸減小，由於舊版瀏覽器的使用降低了。Apache模塊經過自動添加適當的Vary響應頭來幫助。

服務器根據文件類型選擇gzip，可是它們決定壓縮的內容一般太受限制。大多數網站gzip它們的HTML文檔。還有一點值得gzip你的腳本和樣式表，但許多網站錯過了這個機會。事實上，壓縮任何文本響應，包括XML和JSON是值得的。圖像和PDF文件不該該gzipped，由於它們已經壓縮。嘗試gzip它們不只浪費CPU，但可能增長文件大小。

Gzip儘量多的文件類型是減小頁面權重和加快用戶體驗的簡單方法。

頂部 | 討論這個規則

將樣式表放在頂部

標籤：css

雖然研究在雅虎的表現！咱們發現移動樣式表文件HEAD使頁面看起來要加載速度更快。這是由於在HEAD中放置樣式表容許頁面逐步呈現。

關注性能的前端工程師須要一個頁面逐步加載; 也就是說，咱們但願瀏覽器儘快顯示它所擁有的任何內容。這對於具備大量內容的網頁和用戶在較慢的Internet鏈接上尤爲重要。給予用戶視覺反饋的重要性，如進度指標，獲得了很好的研究和記載。在咱們的例子中，HTML頁面是進度指示器！當瀏覽器逐漸加載頁面時，頁眉，導航欄，頂部的標誌等都用做對等待頁面的用戶的視覺反饋。這提升了總體用戶體驗。

將樣式表放在文檔底部附近的問題是，它禁止在許多瀏覽器（包括Internet Explorer）中進行漸進式渲染。這些瀏覽器阻止渲染，以免若是頁面的樣式發生變化，則不得不重繪頁面的元素。用戶卡住了查看空白白頁。

在HTML規範明確規定樣式將被包含在頁面的頭：「不象A，[連接]只能出如今文檔的HEAD部分，但它可能會出現任意次數。」沒有替代品，空白的白色屏幕或閃光的未定型內容，是值得的風險。最佳解決方案是遵循HTML規範並在文檔HEAD中加載樣式表。

頂部 | 討論這個規則

將腳本放在底部

標籤：javascript

腳本引發的問題是它們阻止並行下載。的HTTP / 1.1規範建議的瀏覽器下載不超過兩種組分在每主機平行。若是您從多個主機名中提供圖像，則能夠同時進行兩次以上的下載。然而，當腳本下載時，瀏覽器不會啓動任何其餘下載，即便在不一樣的主機名。

在某些狀況下，將腳本移動到底部並不容易。若是，例如，腳本使用document.write插入網頁內容的一部分，它不能在頁移動更低。還可能存在範圍問題。在許多狀況下，有辦法解決這些狀況。

另外一個建議是常常出現的是使用延遲腳本。該DEFER屬性表示腳本不包含文件撰寫，是一個線索的瀏覽器，他們能夠繼續渲染。不幸的是，Firefox不支持的DEFER屬性。在Internet Explorer中，腳本可能會延遲，但不會如指望的那麼多。若是腳本能夠延遲，它也能夠移動到頁面的底部。這將使您的網頁加載更快。

頂部 | 討論這個規則

避免使用CSS表達式

標籤：css

CSS表達式是一種強大的（和危險的）動態設置CSS屬性的方法。他們在Internet Explorer中開始支持5.0版本，但被廢棄的開始與IE8。做爲示例，背景顏色能夠設置爲使用CSS表達式每小時交替：

      background-color：expression（（new Date（））。getHours（）％2？「＃B8D4FF」：「＃F08A00」）;

如圖所示，該expression方法接受一個JavaScript表達式。CSS屬性設置爲評估JavaScript表達式的結果。該expression方法經過其餘瀏覽器忽略，因此它是在Internet Explorer中須要建立跨瀏覽器提供一致的體驗設置屬性頗有用。

表達式的問題是它們的評價比大多數人指望的更頻繁。它不只在頁面呈現和調整大小時進行評估，並且還在頁面滾動時，甚至在用戶將鼠標移動到頁面上時進行評估。向CSS表達式添加計數器容許咱們跟蹤CSS表達式的計算時間和頻率。在頁面上移動鼠標能夠輕鬆生成超過10,000個評估。

減小評估CSS表達式的次數的一種方法是使用一次性表達式，其中第一次評估表達式時，它將style屬性設置爲顯式值，該值替換CSS表達式。若是樣式屬性必須在頁面的整個生命週期中動態設置，那麼使用事件處理程序而不是CSS表達式是一種替代方法。若是必須使用CSS表達式，請記住它們可能被評估數千次，並可能影響頁面的性能。

頂部 | 討論這個規則

使JavaScript和CSS外部

標籤：javascript，css

許多這些性能規則處理如何管理外部組件。然而，在這些考慮出現以前，你應該問一個更基本的問題：JavaScript和CSS應包含在外部文件中，仍是內聯在頁面自己？

在現實世界中使用外部文件一般會產生更快的頁面，由於JavaScript和CSS文件由瀏覽器緩存。HTML文檔中內聯的JavaScript和CSS在每次請求HTML文檔時都會下載。這會減小所需的HTTP請求數，但會增長HTML文檔的大小。另外一方面，若是JavaScript和CSS在由瀏覽器緩存的外部文件中，則減小HTML文檔的大小而不增長HTTP請求的數量。

所以，關鍵因素是外部JavaScript和CSS組件相對於請求的HTML文檔的數量緩存的頻率。這個因素雖然難以量化，但可使用各類指標來衡量。若是您的網站上的用戶每一個會話有多個網頁瀏覽量，並且您的許多網頁重複使用相同的腳本和樣式表，則緩存的外部文件的潛在好處更大。

許多網站落在這些指標的中間。對於這些網站，最佳解決方案一般是將JavaScript和CSS部署爲外部文件。其中，內聯最好惟一的例外是主頁，如雅虎頭版和個人雅虎。每一個會話具備少許（也許只有一個）頁面查看的主頁可能會發現，內聯JavaScript和CSS結果會致使更快的最終用戶響應時間。

對於一般是許多頁面視圖中的第一頁的前端頁面，存在利用內聯提供的HTTP請求減小的技術，以及經過使用外部文件實現的緩存益處。一種這樣的技術是在前端頁面中嵌入JavaScript和CSS，但在頁面加載完成後動態下載外部文件。後續頁面將引用應該已在瀏覽器緩存中的外部文件。

頂部 | 討論這個規則

減小DNS查找

tag：content

域名系統（DNS）將主機名映射到IP地址，就像電話簿將人們的名字映射到他們的電話號碼。當您在瀏覽器中鍵入www.yahoo.com時，瀏覽器聯繫的DNS解析器返回該服務器的IP地址。DNS有成本。DNS一般須要20-120毫秒來查找給定主機名的IP地址。在DNS查找完成以前，瀏覽器沒法今後主機名下載任何內容。

DNS查找緩存以得到更好的性能。這種高速緩存能夠發生在由用戶的ISP或局域網維護的特殊高速緩存服務器上，可是也存在發生在各個用戶的計算機上的高速緩存。DNS信息保留在操做系統的DNS緩存中（Microsoft Windows上的「DNS客戶端服務」）。大多數瀏覽器都有本身的緩存，與操做系統的緩存分開。只要瀏覽器在其本身的高速緩存中保留DNS記錄，它就不會使操做系統對記錄的請求困擾。

InternetExplorer緩存DNS查找在默認狀況下30分鐘後，由指定的 DnsCacheTimeout註冊表設置。Firefox的緩存DNS查找1分鐘，由控制的network.dnsCacheExpiration配置設置。（Fasterfox將此更改成1小時。）

當客戶端的DNS緩存爲空（對於瀏覽器和操做系統），DNS查找的數量等於網頁中惟一主機名的數量。這包括頁面的URL，圖像，腳本文件，樣式表，Flash對象等中使用的主機名。減小惟一主機名的數量減小了DNS查找的數量。

減小惟一主機名的數量有可能減小頁面中發生的並行下載量。避免DNS查找減小響應時間，但減小並行下載可能會增長響應時間。個人準則是將這些組件跨至少兩個但不超過四個主機名。這致使在減小DNS查找和容許高度並行下載之間的良好折衷。

頂部 | 討論這個規則

縮小JavaScript和CSS

標籤：javascript，css

縮小是從代碼中刪除沒必要要的字符以減少其大小從而提升加載時間的實踐。當代碼縮小時，刪除全部註釋，以及沒必要要的空格字符（空格，換行符和製表符）。在JavaScript的狀況下，這提升了響應時間性能，由於減小了下載的文件的大小。縮小JavaScript代碼的兩個流行的工具是JSMin和YUI壓縮機。YUI壓縮程序也能夠縮小CSS。

混淆是能夠應用於源代碼的替代優化。它比縮寫更復雜，所以更可能因爲混淆步驟自己而產生錯誤。在對十個美國頂級網站的調查中，縮減達到了21％的大小減小，而25％的混淆。雖然模糊化具備更高的大小減小，但縮小JavaScript風險較小。

除了與縮小外部腳本和樣式，內聯<script>和<style>塊能夠，也應該精縮。即便你gzip你的腳本和樣式，縮小他們仍然會減小5％或更多的尺寸。隨着JavaScript和CSS的使用和大小的增長，縮小代碼所節省的成本也將增長。

頂部 | 討論這個規則

避免重定向

tag：content

重定向使用301和302狀態碼完成。如下是301響應中HTTP標頭的示例：

      HTTP / 1.1 301永久移動
      位置：http://example.com/newuri
      Content-Type：text / html

瀏覽器會自動將用戶在指定的URL Location字段中。重定向所需的全部信息都在標題中。響應的主體一般爲空。儘管他們的名字，既不是301，也不是302的響應在實踐中，除非緩存附加頭，好比Expires和Cache-Control，代表它應該是。元刷新標記和JavaScript是將用戶定向到其餘網址的其餘方法，但若是您必須執行重定向，首選的技術是使用標準的3xx HTTP狀態代碼，主要是確保後退按鈕正常工做。

要記住的主要事情是重定向會減慢用戶體驗。在用戶和HTML文檔之間插入重定向會延遲頁面中的全部內容，由於沒法呈現頁面中的任何內容，而且在HTML文檔到達以前，不會開始下載任何組件。

最浪費的重定向之一頻繁發生，Web開發人員一般不知道它。它發生在一個URL中缺乏一個尾部斜槓（/）的狀況，不然應該有一個。例如，要http://astrology.yahoo.com/astrology~~V包含重定向到一個301響應結果http://astrology.yahoo.com/astrology/~~V（注意加斜槓）。這是經過使用固定的Apache Alias或mod_rewrite，或DirectorySlash指令，若是你使用Apache處理程序。

將舊網站鏈接到新網站是另外一個經常使用的重定向。其餘包括鏈接網站的不一樣部分並基於特定條件（瀏覽器的類型，用戶賬戶的類型等）指導用戶。使用重定向鏈接兩個網站很簡單，只須要少許額外的編碼。雖然在這些狀況下使用重定向會下降開發人員的複雜性，但會下降用戶體驗。這種使用重定向方案包括使用Alias與mod_rewrite若是兩個代碼路徑在同一臺服務器上託管。若是一個域名的變化是使用重定向的緣由，另外一種是建立一個CNAME與組合（即建立從一個域名指向另外一個別名DNS記錄）Alias或mod_rewrite。

頂部 | 討論這個規則

刪除重複腳本

標籤：javascript

它損害性能，在一個頁面中包含相同的JavaScript文件兩次。這並不像你想象的那麼不尋常。對十大美國網站的審查顯示，其中兩個包含重複的腳本。兩個主要因素增長了在單個網頁中複製腳本的概率：團隊規模和腳本數。當它發生時，重複的腳本經過建立沒必要要的HTTP請求和浪費JavaScript執行來損害性能。

沒必要要的HTTP請求在Internet Explorer中發生，但在Firefox中不發生。在Internet Explorer中，若是外部腳本包含兩次而且不可緩存，則在加載頁面期間會生成兩個HTTP請求。即便腳本是可緩存的，當用戶從新加載頁面時也會發生額外的HTTP請求。

除了生成浪費的HTTP請求以外，還浪費了屢次評估腳本的時間。這種冗餘的JavaScript執行發生在Firefox和Internet Explorer中，不管腳本是否可緩存。

避免意外包括相同腳本兩次的一種方法是在模板系統中實現腳本管理模塊。包含腳本的典型方法是在HTML頁面中使用SCRIPT標記。

      <script type =「text / javascript」src =「menu_1.0.17.js」> </ script>

在PHP另外一種方法是建立一個調用的函數insertScript。

      <？php insertScript（「menu.js」）？>

除了防止相同的腳本被插入屢次，此函數能夠處理腳本的其餘問題，例如依賴關係檢查和添加版本號到腳本文件名以支持遠期未來的Expires頭。

頂部 | 討論這個規則

配置ETag

tag：server

實體標籤（ETag）是Web服務器和瀏覽器用來肯定瀏覽器緩存中的組件是否與源服務器上的組件匹配的機制。（「實體」是另外一個詞「組件」：圖像，腳本，樣式表等）添加ETag以提供用於驗證比上次修改日期更靈活的實體的機制。ETag是惟一標識組件的特定版本的字符串。惟一的格式約束是字符串引用。源服務器指定使用組件的ETag的ETag響應頭。

      HTTP / 1.1 200 OK
      最後修改：二，2006年12月12日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
      主機：us.yimg.com
      If-Modified-Since：Tue，12 Dec 2006 03:03:59 GMT
      If-None-Match：「10c24bc-4ab-457e1c1f」
      HTTP / 1.1 304未修改

ETag的問題是它們一般使用屬性來構造，這些屬性使得它們對於託管站點的特定服務器是惟一的。當瀏覽器從一個服務器獲取原始組件，而後嘗試在不一樣的服務器上驗證該組件時，ETag不匹配，這種狀況在使用服務器集羣處理請求的網站上太常見。默認狀況下，Apache和IIS都在ETag中嵌入數據，這大大下降了在具備多個服務器的網站上有效性測試成功的概率。

爲Apache 1.3和2.x的eTag格式inode-size-timestamp。儘管給定文件能夠駐留在跨多個服務器的相同目錄中，而且具備相同的文件大小，許可，時間戳等，但其inode對於每一個服務器是不一樣的。

IIS 5.0和6.0對ETag有相似的問題。在IIS上的ETag的格式Filetimestamp:ChangeNumber。一個ChangeNumber是用於跟蹤配置更改IIS計數器。這是不太可能的ChangeNumber是後面整個網站全部的IIS服務器相同。

最終結果是由Apache和IIS生成的ETag對於徹底相同的組件將不匹配從一個服務器到另外一個。若是ETag不匹配，則用戶不接收ETag設計的小的，快速的304響應; 相反，他們將得到正常的200響應以及組件的全部數據。若是您只在一個服務器上託管您的網站，這不是問題。可是若是你有多個服務器託管你的網站，而且你使用默認的ETag配置的Apache或IIS，你的用戶愈來愈慢的頁面，你的服務器有更高的負載，你消耗更大的帶寬，有效地緩存您的內容。即便你的組件有一個遙遠的將來Expires頭部，有條件的GET請求依然取得每當用戶點擊刷新或刷新。

若是你沒有利用ETag提供的靈活的驗證模型，最好只是刪除ETag。該Last-Modified首標驗證基於對組件的時間戳。刪除ETag會減小響應和後續請求中HTTP頭的大小。此Microsoft支持文章介紹瞭如何刪除的ETag。在Apache中，這是經過簡單地添加如下行到您的Apache配置文件：

      FileETag無

頂部 | 討論這個規則

使Ajax可緩存

tag：content

Ajax的一個引用的優勢是它向用戶提供即時反饋，由於它從後端Web服務器異步請求信息。可是，使用Ajax並不能保證用戶不會讓他的拇指等待這些異步JavaScript和XML響應返回。在許多應用程序中，用戶是否保持等待取決於如何使用Ajax。例如，在基於Web的電子郵件客戶端中，用戶將持續等待Ajax請求的結果，以查找與其搜索條件匹配的全部電子郵件。重要的是要記住「異步」並不意味着「瞬時」。

爲了提升性能，優化這些Ajax響應很重要。以提升Ajax的性能最重要的方式是使響應緩存，在討論添加一個Expires或Cache-Control頭。一些其餘規則也適用於Ajax：

讓咱們看一個例子。Web 2.0電子郵件客戶端可能使用Ajax下載用戶的通信錄以進行自動完成。若是用戶自她上次使用電子郵件網絡應用程序以來沒有修改她的地址簿，則能夠從高速緩存讀取先前的地址簿響應，若是該Ajax響應能夠利用將來的Expires或Cache-Control頭部可高速緩存。必須通知瀏覽器什麼時候使用先前緩存的通信簿響應，而不是請求新的響應。這能夠經過添加一個時間戳到地址簿的Ajax的URL指示最後一次用戶修改了她的地址簿，例如完成，&t=1190241612。若是地址簿自從上次下載以來沒有被修改，則時間戳將是相同的，而且地址簿將從瀏覽器的高速緩存讀取，消除額外的HTTP往返。若是用戶修改了她的地址簿，則時間戳確保新的URL與緩存的響應不匹配，而且瀏覽器將請求更新的地址簿條目。

即便您的Ajax響應是動態建立的，而且可能只適用於單個用戶，仍然能夠緩存它們。這樣作將使您的Web 2.0應用程序更快。

頂部 | 討論這個規則

儘早沖洗緩衝區

tag：server

當用戶請求頁面時，後端服務器可能須要200到500毫秒的時間來將HTML頁面拼接在一塊兒。在此期間，瀏覽器在等待數據到達時處於空閒狀態。在PHP中有函數刷新（）。它容許您將部分準備好的HTML響應發送到瀏覽器，以便瀏覽器能夠開始提取組件，然後端正忙於其他的HTML頁面。好處主要在繁忙的後端或光前端。

一個好的地方考慮刷新是正確的HEAD後，由於頭的HTML一般更容易生產，它容許您包括任何CSS和JavaScript文件的瀏覽器開始並行抓取，然後端仍在處理。

例：

      ... <！ -  css，js  - >
    </ head>
    <？php flush（）; ？>
    <body>
      ... <！ -  content  - >

雅虎搜索獨創的研究和實用戶測試，以證實使用這種技術的好處。

最佳

對AJAX請求使用GET

tag：server

在雅虎郵件研究小組發現，當使用XMLHttpRequest，POST在瀏覽器中實現爲兩個步驟：首先發送標題，而後發送數據。因此最好使用GET，它只須要一個TCP數據包發送（除非你有不少cookie）。IE中的最大URL長度爲2K，所以若是您發送超過2K的數據，您可能沒法使用GET。

一個有趣的一面影響是POST沒有實際發佈任何數據的行爲像GET。基於對HTTP規範，GET是爲獲取信息，所以它是有道理的（語義）使用GET當你只請求數據，而不是將數據發送到存儲服務器端。

最佳

後負載組件

tag：content

你能夠仔細看看你的頁面，問本身：「爲了最初呈現頁面絕對須要什麼？其他的內容和組件能夠等待。

JavaScript是在onload事件以前和以後拆分的理想選擇。例如，若是你有JavaScript代碼和庫拖放和動畫，那些能夠等待，由於拖動頁面上的元素是在初始渲染以後。尋找候選人後載加載的其餘地方包括隱藏內容（在用戶操做後顯示的內容）和非摺疊圖片。

工具來幫助你出你的努力：YUI圖像裝載機可讓你延緩倍如下圖片和YUI獲取工具是一種簡單的方法，包括JS和動態CSS。對於在野外的例子來看看雅虎主頁與Firebug的網絡面板打開。

當性能目標與其餘Web開發最佳作法一致時，這是很好的。在這種狀況下，漸進加強的想法告訴咱們，JavaScript支持時，能夠改善用戶體驗，但你必須確保頁面工做，即便沒有JavaScript。所以，在確保頁面正常工做後，您可使用一些後載腳原本加強它，這些腳本會爲您提供更多的響鈴和哨聲，例如拖放和動畫。

最佳

預加載組件

tag：content

預加載可能看起來像後加載的相反，但它實際上有不一樣的目標。經過預加載組件，您能夠利用瀏覽器空閒的時間，並請求未來須要的組件（如圖像，樣式和腳本）。這樣，當用戶訪問下一頁時，您可使大多數組件已經在緩存中，而且您的頁面將爲用戶加載更快。

實際上有幾種類型的預加載：

無條件預緊-儘快的onload火災，你繼續前進，獲取一些額外的組件。查看google.com上有關如何請求sprite圖片的示例。此sprite圖片在google.com首頁上不須要，但在連續搜索結果頁上須要。
有條件的預緊力-基於用戶動做你作一個猜想，用戶接下來爲首並據此預加載。在search.yahoo.com你能夠看到你在輸入框中輸入開始後，一些額外的組件是如何提出要求。
預計推出從新設計的前預提早-預緊力。它常常發生在從新設計以後，你聽到：「新網站很酷，但它比之前慢」。部分問題多是用戶正在使用完整緩存訪問您的舊站點，但新的站點老是空的緩存體驗。您能夠經過在啓動從新設計以前預加載一些組件來減輕這種反作用。您的舊站點可使用瀏覽器空閒的時間，並請求新站點將使用的圖像和腳本

最佳

減小DOM元素的數量

tag：content

複雜的頁面意味着更多的字節下載，它也意味着更慢的DOM訪問在JavaScript。若是您要在頁面上循環500或5000個DOM元素，以便添加事件處理程序（例如），這會有所不一樣。

大量的DOM元素多是一個症狀，有一些應該經過頁面的標記改進而沒必要移除內容。您是否使用嵌套表進行佈局？你更拋出<div>僅s解決佈局問題？也許有更好的和更語義的正確方法來作你的標記。

與佈局有很大的幫助是YUI的CSS實用工具：grids.css能夠幫助你的總體佈局，fonts.css和reset.css能夠幫助你剝去瀏覽器的默認格式。這是從新開始，想一想你的標記，好比用一個機會，<div>惟一的，當它是有意義的語義，而不是由於它呈現一個新行。

DOM元素的數量很容易測試，只需鍵入Firebug的控制檯：
document.getElementsByTagName('*').length

和多少DOM元素太多？檢查其餘具備良好標記的相似網頁。例如，雅虎主頁是一個很是繁忙的頁面，而且仍然在700元素（HTML標籤）。

最佳

跨域分割組件

tag：content

拆分組件容許您最大化並行下載。請確保您使用的域名不超過2到4個，由於DNS查找會受到懲罰。例如，您能夠承載你的HTML和動態內容www.example.org 和之間的分裂靜電元件static1.example.org和static2.example.org

欲瞭解更多信息，檢查「最大化的拼車車道並行下載」的Tenni陶依爾和帕蒂志。

最佳

最小化iframe的數量

tag：content

Iframes容許在父文檔中插入HTML文檔。瞭解iframe如何工做以便有效使用很是重要。

<iframe> 專業：

有助於緩慢的第三方內容（如徽章和廣告）
安全沙箱
並行下載腳本

<iframe> 缺點：

成本高，即便空白
阻止頁面onload
非語義

最佳

沒有404s

tag：content

HTTP請求是昂貴的，因此使得HTTP請求和得到無用的響應（即404未找到）是徹底沒必要要的，將減慢用戶體驗，沒有任何好處。

一些網站有幫助404s「你的意思是X？」，這是偉大的用戶體驗，但也浪費服務器資源（如數據庫等）。特別糟糕的是當外部JavaScript的連接是錯誤的，結果是404.首先，這個下載將阻止並行下載。接下來，瀏覽器可能會嘗試解析404響應正文，如同它是JavaScript代碼，試圖找到可用的東西。

最佳

減小Cookie大小

標籤：cookie

HTTP cookie用於各類緣由，例如身份驗證和個性化。有關Cookie的信息在Web服務器和瀏覽器之間的HTTP標頭中進行交換。保持Cookie的大小盡量低，以儘量減小對用戶響應時間的影響很是重要。

欲瞭解更多信息，請查看「當曲奇崩潰」由Tenni陶依爾和帕蒂志。這項研究的收穫：

消除沒必要要的Cookie
保持Cookie大小盡量低，以最小化對用戶響應時間的影響
請注意將Cookie設置爲適當的域級別，以便其餘子域不受影響
適當設置過時日期。較早的Expires日期或無早期刪除Cookie，從而提升用戶響應時間

最佳

對組件使用無Cookie的域

標籤：cookie

當瀏覽器請求靜態圖像並與請求一塊兒發送Cookie時，服務器對這些Cookie沒有任何用途。因此他們只建立網絡流量沒有好的理由。你應該確保靜態組件被請求無cookie的請求。建立一個子域並託管全部靜態組件。

若是您的域名是www.example.org，您能夠承載你的靜態組件上static.example.org。可是，若是你已經在頂級域名設置cookie example.org，而不是www.example.org，那麼全部的請求，static.example.org將包括這些cookie。在這種狀況下，您能夠購買一個全新的域，在那裏託管您的靜態組件，並保持此域無Cookie。雅虎使用yimg.com，YouTube使用ytimg.com，亞馬遜使用images-amazon.com等。

在無Cookie的域上託管靜態組件的另外一個好處是，一些代理可能拒絕緩存使用Cookie請求的組件。在一個相關的說明，若是你想知道是否應該使用example.org或www.example.org爲您的主頁，請考慮cookie影響。省略WWW離開你別無選擇，只能寫餅乾*.example.org，因此對於性能方面的緣由，最好使用www子域名和寫入Cookie傳送給子域。

最佳

最小化DOM訪問

標籤：javascript

使用JavaScript訪問DOM元素的速度很慢，爲了得到更靈敏的頁面，您應該：

緩存對訪問的元素的引用
更新節點「脫機」，而後將其添加到樹
避免使用JavaScript固定佈局

欲瞭解更多信息，請檢查YUI劇院的「高性能Ajax應用程序」由朱利安·勒孔特。

最佳

開發智能事件處理程序

標籤：javascript

有時，頁面感受不太靈敏，由於太多的事件處理程序附加到DOM樹的不一樣元素，而後執行太頻繁。這就是爲何使用事件表明團是一個不錯的辦法。若是你有一個內部的10個按鈕div，鏈接只有一個事件處理程序到div包裝，而不是一個處理程序爲每一個按鈕。事件冒泡，因此你能夠抓住事件，弄清楚它源自哪一個按鈕。

你也不須要等待onload事件，以便開始使用DOM樹作一些事情。一般你須要的是你想要訪問的元素在樹中可用。您沒必要等待全部圖像下載。 DOMContentLoaded是你能夠考慮使用替代的onload事件，但直到它在全部瀏覽器可用，您可使用YUI事件工具，它有一個onAvailable方法。

欲瞭解更多信息，請檢查YUI劇院的「高性能Ajax應用程序」由朱利安·勒孔特。

最佳

選擇<link> over @import

標籤：css

先前的最佳實踐之一指出CSS應該在頂部，以便容許漸進渲染。

在IE瀏覽器@import的行爲同樣用<link>在頁面的底部，因此最好不要使用它。

最佳

避免過濾器

標籤：css

IE的專有AlphaImageLoader過濾器的目的是解決一個問題，在IE版本<7.半透明真彩色的PNG用此過濾器的問題是，它的塊渲染和當圖像正在下載凍結瀏覽器。它也增長了內存消耗，並應用於每一個元素，而不是每一個圖像，因此問題倍增。

最好的辦法是避免AlphaImageLoader徹底並使用優雅有辱人格的PNG8代替，這是在IE的罰款。若是你確實須要AlphaImageLoader，使用下劃線黑客_filter以不懲罰你的IE7 +用戶。

最佳

優化圖像

tag：images

設計師完成爲您的網頁建立圖像後，在將這些圖像FTP到您的Web服務器以前，仍然能夠嘗試一些操做。

您能夠檢查GIF，看看它們是否使用與圖像中顏色數量相對應的調色板大小。使用ImageMagick的它很容易檢查使用
identify -verbose image.gif
當你看到使用4種顏色，並在調色板中的256色「槽」的圖像，還有改進的餘地。
嘗試將GIF轉換爲PNG，並查看是否有保存。一般，有。開發人員常常猶豫使用PNG，由於瀏覽器支持有限，但如今已通過去了。惟一真正的問題是真正的顏色PNG的alpha透明度，但而後，GIFs不是真正的顏色，也不支持變量的透明度。所以，GIF能夠作的任何事情，調色板PNG（PNG8）也能夠作（動畫除外）。這個簡單的命令ImageMagick的結果徹底安全使用的PNG圖片：
convert image.gif image.png
「全部咱們要說的是：給PING一個機會」
運行pngcrush（或任何其餘PNG優化工具）在全部的PNG圖片。例：
pngcrush image.png -rem alla -reduce -brute result.png
在全部JPEG上運行jpegtran。此工具執行無損JPEG操做（如旋轉），也可用於優化和刪除您的圖像中的註釋和其餘無用的信息（如EXIF信息）。
jpegtran -copy none -optimize -perfect src.jpg dest.jpg

最佳

優化CSS Sprites

tag：images

在水平方向上而不是垂直方向上將圖像排列在子畫面中一般致使較小的文件大小。
在sprite中組合類似的顏色有助於保持色彩計數低，理想狀況下在256色下，以適應PNG8。
「適合移動設備」，而且不要在sprite中留下很大的圖像間隙。這不會影響文件大小，但須要更少的內存，用戶代理將圖像解壓縮爲像素映射。100x100圖像爲10,000像素，其中1000x1000是100萬像素

最佳

不要縮放HTML中的圖像

tag：images

不要使用比你須要的更大的圖像，由於你能夠在HTML中設置寬度和高度。若是你須要
<img width="100" height="100" src="mycat.jpg" alt="My Cat" />
那麼你的圖像（mycat.jpg）應100x100px而不是縮小500x500px形象。

最佳

使favicon.ico小和可緩存

tag：images

favicon.ico是駐留在服務器根目錄中的圖像。這是一個必要的邪惡，由於即便你不關心它的瀏覽器仍然會提出要求，因此最好不要與迴應404 Not Found。此外，因爲它在同一個服務器上，Cookie會在每次請求時發送。這個圖像也干擾下載順序，例如在IE中，當您在onload中請求額外的組件時，favicon將在這些額外的組件以前下載。

因此爲了減小favicon.ico確保的缺點：

它很小，最好低於1K。
設置過時標題與您以爲溫馨（由於你不能重命名，若是你決定更改它）。您能夠在將來幾個月內安全地設置Expires標頭。您能夠檢查您當前favicon.ico的最後修改日期，以作出明智的決定。

ImageMagick的能夠幫助你建立favicon的小

最佳

保持組件低於25K

tag：mobile

這個限制與iPhone不會緩存大於25K的組件有關。注意，這是未壓縮的大小。這是縮小重要的地方，由於gzip單獨可能不夠。

欲瞭解更多信息，請查看「性能的研究，第5部分：iPhone緩存能力-使之成爲堅持」由韋恩·謝伊和Tenni陶依爾。

最佳

將組件打包到多部分文檔中

tag：mobile

將組件包裝到多部分文檔中就像是一個帶有附件的電子郵件，它能夠幫助您使用一個HTTP請求獲取多個組件（請記住：HTTP請求很昂貴）。當您使用此技術時，首先檢查用戶代理是否支持它（iPhone不支持）。

避免空圖像src

tag：server

空字符串圖像SRC屬性出現超過一會的指望。它以兩種形式出現：

直的HTML

<img src =「」>
JavaScript

var img = new Image（）;
img.src =「」;

這兩種形式都產生相同的效果：瀏覽器向您的服務器發出另外一個請求。

Internet Explorer中使得在該頁面所在的目錄的請求。
Safari和Chrome作出實際的頁面自己的請求。
火狐 3和早期版本的行爲相同，Safari和Chrome，但3.5版本解決了這個問題[錯誤444931]再也不發送請求。
歌劇遇到一個空的圖片src時，不會作任何事情。

爲何這種行爲很差？

經過發送大量意外流量來削弱您的服務器，特別是對於天天得到數百萬次網頁瀏覽量的網頁。
廢棄服務器計算週期生成永遠不會被查看的頁面。
可能損壞用戶數據。若是您要經過Cookie或以其餘方式跟蹤請求中的狀態，您可能會銷燬數據。即便圖像請求沒有返回圖像，全部的頭部都被瀏覽器讀取和接受，包括全部的cookie。而其他的響應被拋棄，損害可能已經完成。

這種行爲的根本緣由是在瀏覽器中執行URI解析的方式。此行爲在RFC 3986 - 統一資源標識符中定義。當遇到一個空字符串做爲URI時，它被認爲是一個相對URI，並根據第5.2節中定義的算法進行解析。此特定示例，一個空字符串，在5.4節中列出。Firefox，Safari和Chrome都按照規範正確地解析了一個空字符串，而Internet Explorer正在不正確地解析它，這顯然符合規範的早期版本RFC 2396 - 統一資源標識符（這已被RFC 3986廢棄）。所以，技術上，瀏覽器正在作他們應該作的，以解決相對URI。問題是，在這種狀況下，空字符串顯然是無心的。

HTML5增長了的描述標籤的src屬性指示瀏覽器不做出第4.8.2額外要求：