yslow的中文翻譯

為加快您的網站的最佳實踐

最大限度地減少HTTP請求

标簽：内容

80％的最終使用者響應時間花在前端。大部分時間是捆綁在下載下傳頁面中的所有元件：圖檔，樣式表，腳本，閃存等依次減少元件數量減少來渲染頁面的HTTP請求的數量。這是更快的頁面的關鍵。

頁面，以減少元件數量的方法之一是簡化頁面的設計。但有一個方法來建立與更豐富的内容的網頁，同時也實作了快速的反應時間？這裡是減少HTTP請求的數量，同時還支援豐富的網頁設計的一些技巧。

合并的檔案合并成一個單一的腳本的所有腳本，同樣所有的CSS結合到一個單一的樣式表的方式來減少HTTP請求數量 。合并檔案是更具挑戰性的腳本和樣式表頁與頁之間的不同，但是這部分釋放過程，提高響應時間。

CSS精靈的首選方法是減少圖像請求的數量 。您的背景圖像合并成一個單一的形象和使用的CSS背景圖檔和背景位置屬性，以顯示所需的圖像部分 。

圖像映射到一個單一的形象相結合的多張圖像。總體規模大緻相同，但HTTP請求的數量減少了頁面的速度 。圖檔地圖隻有工作如果圖像是連續在頁面，如導航欄。定義影像地圖的坐标可乏味而且容易出錯 。使用導航影像地圖是無法通路過，是以不推薦。

内嵌圖檔使用的資料： URL方案，在實際的頁面中嵌入的圖像資料 。這可以增加你的HTML文檔的大小 。内嵌圖檔到您的樣式表（緩存）相結合的方式來減少HTTP請求，并避免增加您的網頁的大小。内嵌圖像尚不支援所有主要浏覽器。

減少HTTP請求在您的網頁數量是開始的地方。這是首次通路者的性能改善的最重要的準則。作為在Tenni陶依爾的部落格文章中描述的浏覽器高速緩存的使用-暴露，每天遊客到您的網站的40-60％來自于一個空緩存。這些首次通路者的頁面快速更好的使用者體驗是關鍵。

首頁 | 讨論這個規則

使用内容傳送網絡

标簽：伺服器

使用者的接近您的Web伺服器響應時間的影響。部署在多個地理上分散的伺服器，您的内容會從使用者的角度來看，您的網頁加載更快。但是，你應該在哪裡開始呢？

作為第一步實施地理上分散的的内容，不要試圖重新設計的Web應用程式工作在一個分布式體系結構。根據不同的應用，改變結構可以包括跨伺服器的位置同步會話狀态和複制資料庫交易等艱巨任務。嘗試，以減少使用者和内容之間的距離可能會推遲，或從來沒有通過，此應用程式的架構步驟。

請記住，最終使用者響應時間的80-90％是花費在下載下傳頁面中的所有元件：圖檔，樣式表，腳本，閃光燈等，這是性能黃金法則。而不是重新設計您的應用程式體系結構的艱巨任務開始時，最好先驅散你的靜态内容。這不僅實作了一個更大的減少響應時間，但它的内容傳遞網絡更簡單的感謝。

内容傳遞網絡（CDN）是分布在多個地點的Web伺服器，更有效地向使用者提供内容的集合。選擇一個特定的使用者提供内容的伺服器通常是基于衡量一個網絡接近。例如，用最少的網絡啤酒花或伺服器以最快的響應時間伺服器選擇。

一些大型網際網路公司擁有自己的CDN，但是使用一個CDN服務提供商，如Akamai技術，EdgeCast，或Level3的，它的成本效益 。對于剛成立的公司和私人網站，一個CDN服務的成本可以讓人望而卻步，但您的目标閱聽人越來越多，越來越全球化，CDN是必要的，以實作快速的響應時間。在雅虎，移出其應用程式的Web伺服器上的靜态内容到一個CDN（包括第三方的上述以及雅虎自己的CDN），改善最終使用者的響應時間， 20％以上的屬性。切換到一個CDN是一個相對容易的代碼更改，這将大大提高您的網站的速度。

首頁 | 讨論這個規則

添加一個Expires或Cache - Control頭

标簽：伺服器

此規則有兩個方面：

• 對于靜态元件：實作“永不過期”不遠的将來通過設定政策Expires标頭
• 對于動态元件：使用适當的Cache - Control頭，幫助有條件的請求的浏覽器

網頁設計是越來越豐富，這意味着更多的腳本，樣式表，圖像和Flash在頁 ​​面 。是第一次到您的網頁的通路者可能有幾個HTTP請求，但是通過使用Expires頭你讓這些元件緩存的 。這就避免了不必要的HTTP請求，在随後的頁面浏覽量。過期頭是最常用的圖像，但他們應該使用的所有元件，包括腳本，樣式表和Flash元件 。

浏覽器（和代理）使用緩存來減少HTTP請求的數量和規模，使網頁加載速度更快。使用一個Web伺服器的HTTP響應的Expires頭資訊告訴用戶端元件可以被緩存多久。這是一個遙遠的未來Expires頭，告訴浏覽器，這種反應不會陳舊，直到2010年4月15日，。

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

如果你的伺服器是Apache，使用ExpiresDefault指令來設定相對目前日期到期日期。這個例子的ExpiresDefault指令集，過期日期10年來的請求時。

ExpiresDefault“通路加10年”      

記住，如果您使用的是遙遠的未來，你必須改變元件的檔案名元件的變化時Expires頭。雅虎，我們常常使這個生成過程中的步驟的一部分：一個版本号是嵌入式元件的檔案名，例如yahoo_2.0.6.js。

不遠的将來使用過期頭的影響隻有在使用者已經通路了您的網站頁面浏覽量。這對HTTP請求的數量沒有影響，當使用者首次通路您的網站和浏覽器的緩存是空的。是以這種性能改善的影響取決于多久使用者點選您的網頁與催芽緩存 。（一個“底漆緩存”已包含在頁面中的所有元件。）測量雅虎，發現與催芽緩存的頁面浏覽量的數量是75-85 ％。通過使用一個遙遠的未來Expires頭，你不發送了使用者的網際網路連接配接的單位元組的浏覽器，并在随後的頁面浏覽量再使用緩存的元件數量增加。

首頁 | 讨論這個規則

Gzip已元件

标簽：伺服器

通過網絡傳輸HTTP請求和響應所花費的時間可大大減少前端工程師所作出的決定。這是真正的最終使用者的帶寬速度，網際網路服務提供商，接近對等交換點等超出開發團隊的控制。但也有其他變數影響響應時間的。通過減少HTTP響應的大小，壓縮減少了響應時間。

Web用戶端與HTTP/1.1的開始，表示支援在HTTP請求的Accept - Encoding頭壓縮。

的Accept - Encoding：GZIP，DEFLATE      

如果Web伺服器認為在要求這個頭，可能壓縮響應使用由客戶列出的方法之一。Web伺服器通知該Web用戶端，通過在響應的Content - Encoding頭。

内容編碼：gzip      

gzip是在這個時候最流行 ​​和最有效的壓縮方法。它是由GNU項目，并通過标準化RFC 1952。你可能會看到其他壓縮格式是緊縮，但它的效果較差，不太受歡迎。

gzip壓縮一般可降低約70％的響應大小 。今天的網際網路流量的約90％穿過聲稱支援gzip的浏覽器。如果您使用Apache，子產品配置GZIP取決于你的版本：Apache 1.3中使用，而Apache 2.x 的使用 mod_deflate mod_gzip。

有與已知問題，可能會導緻在浏覽器期望收到關于壓縮的内容不比對的浏覽器和代理。幸運的是，這些邊緣情況正在減少，使用舊版本的浏覽器脫落。Apache子產品幫助加入适當的變化的響應頭自動。

伺服器選擇什麼樣的gzip根據檔案類型，但通常太有限，在他們決定壓縮。大多數網站的gzip他們的HTML檔案。這也是值得GZIP你的腳本和樣式表，但許多網站錯過這個機會。事實上，這是值得的壓縮任何文本響應，包括XML和JSON。圖檔和PDF檔案不應該用gzip壓縮的，因為它們已經被壓縮。試圖GZIP他們不僅浪費CPU，但可能會增加檔案大小。

gzip壓縮盡可能多的檔案類型，是一種簡單的方法，減少頁面的重量和加快使用者體驗。

首頁 | 讨論這個規則

在上面的樣式表“

标簽：CSS

雖然研究在雅虎的表現，我們發現，将樣式表文檔的HEAD使得網頁加載更快 。這是因為将在HEAD的樣式表可以讓頁面呈現逐漸。

前端工程師，關心性能要逐漸加載頁面，也就是說，我們希望浏覽器顯示的任何内容，盡快 。了很多内容的網頁和使用者在網際網路連接配接速度較慢，這一點尤為重要。重要性，為使用者提供視覺回報，如進度名額，得到了很好的研究和記錄。在我們的例子中的HTML頁面是進度訓示器！當浏覽器加載頁面逐漸頭，導航欄，在頂部的标志，等所有使用者等待頁面的視覺回報服務。這提高了整體的使用者體驗 。

與樣式表放在文檔底部附近的問題是，它禁止在許多浏覽器進行渲染，包括Internet Explorer。這些浏覽器塊渲染，以避免重繪頁面元素，如果其款式變化。使用者停留觀看一個空白頁。

HTML規範中明确指出，樣式表是包含在頁面的HEAD：“不像，可能隻出現在文檔的HEAD部分，雖然它可能會出現任意多次。” 既不替代品，空白螢幕或無樣式内容的閃光燈，是值得冒這個險 。最佳的解決方案，是按照HTML規範，并加載在檔案頭你的樣式表 。

首頁 | 讨論這個規則

放在底部的腳本

标簽：JavaScript的

由腳本引起的問題是，他們阻止并行下載下傳。HTTP/1.1規範 建議浏覽器下載下傳不超過兩部分組成，在每個主機名并行 。如果您的圖檔，從多個主機服務，你可以得到并行發生在兩個以上的下載下傳 。然而，當一個腳本下載下傳，浏覽器不會啟動任何其他下載下傳，甚至在不同的主機名。

在某些情況下它是不容易移動腳本的底部。如果，例如，該腳本使用的document.write來插入頁面的内容的一部分，它不能被移到較低頁面 。還可能有範圍問題。在許多情況下，有辦法來解決這些情況。

常出現的另一種建議是使用延遲腳本 。defer屬性表示腳本不包含的document.write，是一個線索，他們可以繼續渲染的浏覽器 。不幸的是，Firefox不支援defer屬性。在Internet Explorer中，腳本可能會推遲，但不及所需。如果腳本可以被推遲，它也可以被移動到頁面底部。這将使您的網頁加載速度更快。

首頁 | 讨論這個規則

避免CSS表達式

标簽：CSS

CSS表達式是一個強大的和危險的方式動态設定CSS屬性 。他們支援在Internet Explorer版本5開始，但已過時與IE8開始。作為一個例子，可以設定背景顔色交替每隔一小時，使用CSS表達式 ：

背景顔色：表達式（（新的Date（））getHours（）％2“＃B8D4FF”：？“＃F08A00”）;      

如下所示，表達方法接受一個JavaScript表達式。CSS屬性設定為JavaScript表達式評估結果。其他浏覽器中的表達方法被忽略，是以它是用于設定屬性在Internet Explorer的需要，以建立一個跨浏覽器一緻的體驗 。

與表達式的問題是，他們比大多數人預期的更頻繁的評估。他們不僅評估時，頁面呈現和調整，而且當頁面滾動，甚至當使用者移動滑鼠在頁面。添加計數器的CSS表達式，使我們能夠保持跟蹤何時以及如何往往是CSS表達式求值。滑鼠移動頁面，可以友善地生成超過10,000評估。

減少你的CSS表達式求值的次數的方法之一是使用一次性的表情，表達是評估它的第一次設定樣式屬性的一個明确的價值，它取代了CSS表達式。如果樣式屬性必須設定動态頁面的整個生命，使用事件處理程式，而不是CSS表達式是一種替代方法。如果必須使用CSS表達式，記住，他們可能會評估幾千倍，并可能影響你的頁面的性能。

首頁 | 讨論這個規則

使JavaScript和CSS外部

标簽：JAVASCRIPT，CSS

許多這些性能規則處理如何管理外部元件。然而，這些因素出現之前，你應該問一個更基本的問題：JavaScript和CSS包含外部檔案中，或在網頁本身的内聯？

在現實世界中使用外部檔案通常會産生更快的網頁，因為JavaScript和CSS檔案浏覽器緩存。JavaScript和CSS，HTML文檔中的内聯得到下載下傳的每一個HTML文檔要求的時間。這減少了所需要的HTTP請求的數量，但增加了HTML文檔的大小。另一方面，如果在浏覽器緩存的外部檔案，JavaScript和CSS，HTML文檔的大小是不增加HTTP請求的數量減少。

的關鍵因素，那麼，是與外部JavaScript和CSS元件被緩存請求的HTML檔案的數量相對的頻率。這個因素，雖然難以量化，可衡量使用各種名額。如果您網站上的使用者，每個會話的多個頁面浏覽量和許多您的網頁上重複使用相同的腳本和樣式表，有一個更大的緩存外部檔案的潛在利益。

許多網站在這些名額中下降。對于這些網站，最好的解決辦法通常是JavaScript和CSS作為外部檔案來部署。唯一的例外，最好是内聯網頁，如雅虎的頭版和我的 Yahoo! 。很少（也許隻有一個）頁檢視每節的首頁可能會發現，内聯JavaScript和CSS成果更快的終端使用者響應時間。

通常許多頁面浏覽量第一的頭版，有技術，利用減少HTTP請求，内聯提供的，以及通過使用外部檔案的緩存實作利益。這樣的技術之一是内聯的JavaScript和CSS在頭版，但頁面加載完成後動态下載下傳外部檔案。随後的頁面引用外部檔案，應該已經在浏覽器的緩存。

首頁 | 讨論這個規則

減少DNS查找

标簽：内容

域名系統（DNS）映射主機名到IP位址，就像他們的電話号碼的通訊錄，地圖人的名字。當您鍵入www.yahoo.com到您的浏覽器，浏覽器聯系一個DNS解析傳回該伺服器的IP位址。DNS有代價的。它通常需要20-120毫秒的DNS來查找一個給定的主機名的IP位址。浏覽器不能從此主機下載下傳的東西，直到DNS查找完成。

DNS查找更好的性能，緩存。此緩存可以發生在一個特殊的緩存伺服器，由使用者的ISP或區域網路維護，但也有個人使用者的計算機上發生的緩存。DNS資訊仍保留在作業系統的DNS緩存（在Microsoft Windows的“DNS用戶端服務”）。大多數浏覽器都有自己的高速緩存，獨立于作業系統的緩存。隻要浏覽器保持在它自己的緩存DNS記錄，它并不理會記錄的要求作業系統。

Internet Explorer的緩存DNS查找，預設情況下，30分鐘由 指定 DnsCacheTimeout的系統資料庫設定。Firefox的緩存DNS查找為1分鐘，由控制network.dnsCacheExpiration配置設定。（Fasterfox變化至1小時。）

當用戶端的DNS緩存是空的（浏覽器和作業系統），DNS查找的數量是獨特的主機名的網頁數量相等。這包括在頁面的URL中使用的主機名，圖像，腳本檔案，樣式表，Flash對象等，減少了獨特的主機名的數量減少DNS查找。

降低獨特的主機名的數量有可能減少，需要在頁面的平行下載下傳量。避免DNS查找的響應時間，但減少同時下載下傳可能會增加響應時間。我的方針是分割成至少兩個，這些元件，但不超過4個的主機名。在一個很好的妥協之間減少DNS查找，并允許一個高度并行下載下傳結果。

首頁 | 讨論這個規則

縮小的JavaScript和CSS

标簽：JAVASCRIPT，CSS

微小的，是從代碼中删除不必要的字元，以減小其大小，進而改善加載時間的實踐。縮小的代碼時，所有的意見都将被删除，以及不需要的空白字元（空格，換行符和制表 ）。在JavaScript的情況下，這樣可以提高響應時間的性能，因為下載下傳的檔案的大小降低。minifying JavaScript代碼的兩個流行的工具是 JSMin 和YUI壓縮機 。YUI壓縮也可以縮小的CSS。

模糊處理是一種替代的，可以應用到源代碼的優化。它的微小和複雜得多，因而更容易産生混淆步驟本身的錯誤。在美國十大網站的調查中，微小的達到21％，體積減少混淆與25％。雖然模糊了更高的體積減少，minifying的JavaScript是風險較小。

此外，minifying外部腳本和樣式，<SCRIPT>内聯和<STYLE>塊可以，也應該縮小的。即使你的gzip你的腳本和樣式，minifying他們仍然會減少5％或以上的規模 。使用JavaScript和CSS的增加的大小，是以将儲蓄取得minifying你的代碼。

首頁 | 讨論這個規則

避免重定向

标簽：内容

重定向使用301和302狀态碼來完成。這裡的301響應的HTTP頭的一個例子：

HTTP/1.1 301永久移動
      地點：http://example.com/newuri
      内容類型：文本/ HTML      

浏覽器會自動将使用者在位置字段中指定的URL 。所有必要的資訊重定向是在頭。響應主體通常是空的。盡管他們的名字，既不是301也不是一個302響應緩存是在實踐中中，除非附加頭，如過期或者緩存控制，表明它應。META重新整理标記和JavaScript的其他方式将使用者定向到不同的URL，但如果你必須做一個重定向，首選的方法是使用标準3xx的HTTP狀态代碼，主要是為了確定“後退”按鈕正常工作。

主要的是要記住，重定向減慢使用者體驗。插入一個重定向和使用者之間，因為沒有什麼可以在頁面呈現，并沒有元件可以開始下載下傳，直到HTML文檔已經抵達的頁面的HTML文檔延誤一切。

一個最浪費的重定向經常發生和Web開發人員一般都沒有意識到這一點 。它發生時應該有一個從URL中缺少一個斜線（/） 。例如，http://astrology.yahoo.com/astrology 301響應結果重定向到http://astrology.yahoo.com/astrology/（通知添加結尾的斜線）。這是固定在Apache中使用别名或mod_rewrite的，或DirectorySlash指令，如果你使用Apache處理程式 。

舊網站連接配接到一個新的，是另一個共同使用重定向 。其他人包括一個網站的不同部分連接配接，并指導使用者基于一定條件下（浏覽器類型，類型的使用者帳戶，等）。使用重定向來連接配接兩個網站很簡單，需要一點額外的編碼。雖然在這些情況下使用重定向減少了開發的複雜性，降低了使用者體驗。使用這種重定向的替代品，包括使用别名和 mod_rewrite的，如果在同一台伺服器上托管的兩個代碼路徑。如果一個域名的變化是使用重定向的原因，另一種方法是建立一個CNAME（DNS記錄建立一個别名，從一個域名指向到另一個）與組合 别名或 mod_rewrite的。

首頁 | 讨論這個規則

删除重複的腳本

标簽：JavaScript的

它傷害的表現，包括在一個頁面兩次同一個JavaScript檔案。這是不是像你想象的不尋常。美國十大網站的審查表明，他們兩個包含重複的腳本。兩個主要因素增加，在一個單一的網頁複制一個腳本的賠率：團隊的規模和數量的腳本。當它發生，重複，造成不必要的HTTP請求和浪費JavaScript執行腳本損害性能。

在Internet Explorer中發生不必要的HTTP請求，但不能在Firefox。在Internet Explorer中，如果外部腳本被包含兩次，是不可緩存的，它會生成在頁面加載的兩個HTTP請求。即使腳本是可緩存的，額外的HTTP請求時有發生，當使用者重新加載頁面。

除了産生浪費的HTTP請求，浪費時間評估腳本多次。這種備援的JavaScript執行發生在Firefox和Internet Explorer，不管是否腳本緩存。

的方式，以避免意外相同的腳本，包括兩次之一是落實在你的模闆系統腳本管理子產品。包括腳本的典型方法是使用在你的HTML頁面的腳本标簽。

<script type="text/javascript" src="menu_1.0.17.js"> </ SCRIPT>      

在PHP中的另一種選擇是建立調用的函數insertScript。

<？PHP insertScript（“menu.js”）？>      

此外，以防止被插入多次相同的腳本，這個功能可以處理腳本，如依賴性檢查和增加版本号的腳本檔案名支援不遠的将來到期頭，其他的問題。

首頁 | 讨論這個規則

配置ETag的

标簽：伺服器

實體标記（ETag的）是一種機制，Web伺服器和浏覽器使用，以确定是否在浏覽器的緩存元件與原伺服器上的一個 。（“實體”是添加ETag的人提供了一個驗證明體的最後修改日期較靈活的機制，另一個字的“分量”：圖像，腳本，樣式表等 ）。一個ETag是一個字元串，它唯一辨別一個元件的具體版本 。唯一的格式限制，被引用的字元串 。源伺服器使用的ETag響應頭指定元件的ETag的。

HTTP/1.1 200 OK
      最後修改時間：星期二，2006年12月12日3時03分59秒格林尼治标準​​時間
      ETag的：“10c24bc 4AB - 457e1c1f”
      内容長度：12195      

後來，如果浏覽器來驗證元件，它使用如果沒有比對頭傳遞的ETag到源伺服器。如果ETag的比賽中，傳回一個304狀态代碼是這個例子中，響應減少12195位元組 。

GET / I / yahoo.gif HTTP/1.1
      主持人：us.yimg.com
      如果- Modified - Since的：星期二，2006年12月12日3時03分59秒格林尼治标準​​時間
      如果無比對：“10c24bc 4AB - 457e1c1f”
      HTTP/1.1 304未修改      

與ETag的問題是，他們通常使用的屬性，使它們獨特的站點到一個特定的伺服器托管。ETag的不比對，當浏覽器從一台伺服器上擷取原始元件，并稍後嘗試不同的伺服器上驗證該元件，這種情況是很常見的網站上，使用一個伺服器叢集來處理請求。預設情況下，Apache和IIS嵌入的ETag的有效性測試多個伺服器的網站上獲得成功的幾率，大大降低了資料。

适用于Apache 1.3和2.x的ETag格式是inode的大小時間戳。雖然一個給定的檔案可能跨多個伺服器駐留在相同的目錄，并有相同的檔案大小，權限，時間戳等，它的inode是從一個伺服器到不同的未來。

IIS 5.0和6.0有ETag的一個類似的問題。IIS上的ETag的格式是：ChangeNumber Filetimestamp 。一個ChangeNumber是一個計數器用來跟蹤到IIS的配置更改 。這是不可能的ChangeNumber，是一個網站背後的所有IIS伺服器 相同。

最終的結果是完全相同的元件Apache和IIS生成ETag的，将不比對從一個伺服器到另一個 。如果ETag的不比對，使用者不接受小，速度快，ETag的被設計為304響應，相反，他們會得到一個正常的200響應元件的所有資料 。如果你隻有一台伺服器上托管你的網站，這不是一個問題。但如果你有多個伺服器托管您的網站，你使用Apache或IIS預設的ETag配置，你的使用者是越來越慢的頁面，您的伺服器具有更高的負載，你消耗更大的帶寬，和代理 AREN“ 噸緩存你的内容有效 。即使你的元件有一個遙遠的未來Expires标頭，仍是一個有條件的GET請求，每當使用者點選重新整理或重新整理。

如果你不采取ETag的提供靈活的驗證模型的優勢，它的更好，隻是完全删除的ETag。基于元件的時間戳的Last - Modified頭驗證。和删除的ETag減少的反應和後續的請求的HTTP頭的大小 。此Microsoft支援文章 ​​介紹了如何删除ETag的 。在Apache中，這樣做是通過簡單的Apache配置檔案中添加以下行 ：

FileETag無      

首頁 | 讨論這個規則

制作的Ajax可緩存

标簽：内容

引用Ajax的好處之一是，它提供瞬時回報給使用者，因為它要求從後端Web伺服器的資訊異步。但是，使用Ajax是沒有保證使用者不會再做這些異步JavaScript和XML響應等待傳回他的拇指。在許多應用中，無論使用者是一直在等待取決于Ajax是如何使用。例如，在一個基于Web的電子郵件用戶端的使用者将保持等待一個Ajax請求，找到符合他們的搜尋條件的所有電子郵件的結果。重要的是要記住，“異步”并不意味着“瞬間”。

為了提高性能，重要的是要優化Ajax響應。提高Ajax性能是最重要的方式作出反應緩存的，因為在讨論添加一個Expires或Cache - Control頭。其他的一些規則也适用于對Ajax ：

• Gzip已元件
• 減少DNS查找
• 縮小的JavaScript
• 避免重定向
• 配置ETag的

讓我們來看看一個例子。Web 2.0的電子郵件用戶端可能會使用Ajax自動完成下載下傳使用者的位址簿 。如果使用者沒有修改自己的位址簿中，因為她最後一次使用電子郵件的Web應用程式，以前的位址簿中的反應可以從緩存中讀取，如果說Ajax響應緩存的未來Expires或Cache - Control頭。必須告知浏覽器，當請求一個新的使用與以前緩存的位址簿中的反應。這可以通過一個時間戳添加到位址簿中的Ajax URL說明最後一次使用者修改了她的位址簿，例如，T = 1190241612。如果通訊簿中沒有被修改，自上次下載下傳的時間戳将同一位址簿将消除額外的HTTP往返，從浏覽器的緩存讀取 。如果使用者已經修改了她的位址簿，時間戳，確定新的URL不比對緩存的響應，浏覽器将請求更新位址簿條目。

即使你的Ajax響應動态建立的，并且可能隻适用于單個使用者，他們仍然可以被緩存。這樣做将會使您的Web 2.0應用的速度。

首頁 | 讨論這個規則

提前重新整理緩沖區

标簽：伺服器

當使用者請求一個頁面，它可以在任何地方從200至500ms縫合在一起的HTML頁面的後端伺服器。在這段時間内，浏覽器處于閑置狀态，等待資料到達 。在PHP中的flush（）函數。它允許你發送部分準備的HTML浏覽器，這樣浏覽器就可以開始抓取元件，而你的後端是忙于其他的 HTML頁面。這樣做的好處主要是在繁忙的後端或輕前端。

因為頭的HTML通常比較容易産生，它允許您包括任何CSS和JavaScript檔案的浏覽器開始并行抓取，而後端仍在處理後的頭一個好地方，要考慮沖洗。

例如：

... ... <！ - CSS，JS - >
    </ HEAD>
    <PHP的flush（）;？>
    <BODY>
      ... ... <！ - 内容 - >
      

雅虎搜尋率先研究和實際使用者測試，證明使用這種技術的好處 。

頂部

AJAX請求使用GET

标簽：伺服器

在雅虎 郵件研究小組發現， 使用 XMLHttpRequest時，POST是在浏覽器中實作一個兩步的過程：發送标題，然後發送資料 。是以，最好使用GET，隻需要一個TCP資料包發送（除非你有很多的餅幹）。在IE的最大URL長度是2K，是以，如果你發送超過2K的資料，你可能不能夠使用 GET。

一個有趣的影響是該職位沒有釋出任何資料行為像GET。基于的HTTP規範，GET檢索資訊的含義，是以它才有意義（語義）使用GET時，你隻請求資料，而不是發送到伺服器端存儲的 資料。

頂部

後負荷

标簽：内容

您可以在您的網頁定睛一看，問自己：“什麼是絕對必要的，以渲染頁面最初？”。可以等待其餘的内容群組成部分。

JavaScript是一種分裂的onload事件之前和之後的理想人選。例如，如果你有JavaScript代碼和庫拖放和動畫，那些可以等​​待，因為拖動頁面上的元素後初步呈現。其他地方尋找後加載的候選人包括隐藏的内容（使用者操作後出現的内容，）和倍以下的圖像。

工具，以幫助你在你的努力：YUI圖像裝載機允許您延遲低于倍和圖像銳獲得實用程式是一個簡單的方法，包括JS和CSS飛。在野外的一個例子來看看雅虎 首頁 Firebug的淨面闆打開。

這是很好的績效目标時，内聯與其他Web開發最佳實踐。在這種情況下，漸進增強的想法告訴我們的JavaScript支援時，可以改善使用者體驗，但你必須確定頁的作品，即使沒有JavaScript。是以當你確定頁面正常工作，可以加強與一些後加載的腳本，給你更多的鐘聲和口哨聲，如拖放和動畫。

頂部

預壓元件

标簽：内容

預壓後負荷相反可能看起來像，但它實際上有不同的目标。通過預加載元件，你可以利用浏覽器是空閑的時間，并要求元件（如圖像，樣式和腳本），您将需要在未來的優勢。這種方式，當使用者通路下一頁，你可能有大部分元件已經在緩存中，您的網頁将加載使用者快得多。

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

• 無條件預緊-盡快的onload火災，你繼續前進，擷取一些額外的元件。檢查google.com sprite圖像是如何要求的onload的一個例子。這個sprite圖像是沒有必要對google.com網頁，但它是需要連續搜尋結果頁上。
• 有條件的預緊-基于對使用者操作進行猜測使用者相應的上司和預緊 。search.yahoo.com你可以看到如何要求一些額外的元件後，開始在輸入框中輸入。
• 預計推出重新設計前提前預壓-預緊。它經常發生的經過重新設計，你聽到：“新網站是涼爽的，但它比以前慢 “。問題的部分原因可能是使用者一個完整的高速緩存通路您的舊網站，但新的始終是一個空緩存的經驗 。堆載預壓的一些元件之前，你甚至推出了重新設計，您可以減輕這種副作用 。您的舊網站可以使用浏覽器是空閑的時間和要求圖像和腳本将被用于新網站

頂部

減少DOM元素數量

标簽：内容

一個複雜的頁面意味着更多的位元組下載下傳，這也意味着慢DOM的JavaScript通路。它的确與衆不同，如果循環當你想添加一個事件處理程式，例如通過500或5000個頁面的DOM元素。

一個DOM元素的高數量可以是一個症狀，有什麼東西，應與改善，而不必删除内容頁的标記。你使用嵌套表布局的目的呢 ？你在投擲<DIV>唯一的解決布局問題？也許有一個更好，更語義正确的方式做标記 。

與布局的一個很大的幫助了YUI的CSS實用工具：grids.css可以幫助你的總體布局，fonts.css和reset.css可以幫助你去掉浏覽器的預設格式。這是一個機會重新開始，想想你的标記，例如使用<DIV> s的，隻有當它是有意義的語義，而不是因為它呈現一個新 行。

DOM元素數量很容易測試，在Firebug的控制台隻需鍵入：document.getElementsByTagName ('*').長度

多少DOM元素太多呢？檢查其他類似的網頁，有良好的标記。例如在雅虎 首頁是一個非常繁忙的頁面，并仍在700個元素（HTML 标簽）。

頂部

分割成域元件

标簽：内容

分割元件，可以最大限度地提高并行下載下傳。確定您使用的是由于DNS查找罰款不超過2-4域。例如，您可以承載你的HTML和動态内容的 www.example.org和分裂之間的靜态元件 static1.example.org 和 static2.example.org

有關詳細資訊，選中“在共乘車道最大化的同時下載下傳“Tenni陶依爾和侯佩岑 志。

頂部

iframe的數量最小化

标簽：内容

IFRAMES允許在父文檔中插入一個HTML文檔。重要的是要了解如何工作，使他們能夠有效地使用iframe的。

<IFRAME>優點：

• 緩慢的第三方如徽章和廣告的内容有幫助
• 安全沙箱
• 并行的下載下傳腳本

<IFRAME>的利弊：

• 不惜血本，即使空白
• 阻止頁面的onload
• 非語義

頂部

沒有404

标簽：内容

HTTP請求是昂貴的，是以一個HTTP請求，并得到一個無用的反應（即404未找​​到）是完全不必要的的，并會減慢使用者體驗沒有任何好處。

有些網站有用404“您的意思是X？”，這是偉大的使用者體驗，但也浪費了伺服器資源（如資料庫等）。特别糟糕的是當一個外部JavaScript的連結是錯誤的，結果是404。首先，此下載下傳将塊并行下載下傳。接下來，浏覽器可能會嘗試解析404響應體，就好像它是JavaScript代碼，試圖找到它可用的東西。

頂部

減少cookie大小

标簽：CO​​OKIE

用于各種原因，如身份驗證和個性化的HTTP cookies。有關Cookie的資訊交換，在Web伺服器和浏覽器之間的的HTTP标頭。重要的是要保持盡可能低的餅幹的大小，以盡量減少對使用者的響應時間的影響。

欲了解更多資訊， 檢查“繁忙 “Tenni陶依爾和侯佩岑志 。這項研究的帶回家：

• 消除不必要的Cookie
• 保持盡可能低的cookie的大小，以盡量減少對使用者的響應時間的影響
• 要注意在适當的域級别設定的，是以不影響其他子域的Cookie
• 設定一個過期日期适當。較早的到期日期或沒有删除的cookie越早，提高使用者的響應時間

頂部

元件使用無Cookie的域

标簽：CO​​OKIE

當浏覽器發出一個靜态圖像的請求并發送請求的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，亞馬遜使用圖像，amazon.com等。

無cookie的域上承載的靜态元件的另一個好處是，有些代理伺服器可能會拒絕緩存與cookies請求的元件。與此相關的，如果你想知道，您是否應該使用為您的首頁example.org或www.example.org，考慮cookie的影響 。省略WWW離開你别無選擇，但寫的cookie *. example.org，是以性能方面的原因，最好使用www的子域和寫子域的 cookies。

頂部

最小化DOM通路

标簽：JavaScript的

使用JavaScript通路DOM元素是緩慢的，是以為了有更多的響應頁面，你應該：

• 緩存引用通路的元素
• 更新節點“離線”，然後将它們添加到樹
• 避免固定使用JavaScript的布局

欲了解更多資訊，檢查銳劇院 的“高性能Ajax應用程式 “，由Julien Lecomte。

頂部

開發智能事件處理程式

标簽：JavaScript的

網頁有時感覺不到，因為太多的事件處理程式附加到DOM樹的不同元素，然後執行往往反應。這就是為什麼使用事件代表團是一個很好的辦法。如果你有10個按鈕格内，隻有一個事件處理程式附加到div包裝，每個按鈕的處理程式，而不是一個。事件冒泡，讓您能夠捕捉的事件，并找出它起源于哪個按鈕。

你也不必等待onload事件，以開始做DOM樹的東西 。通常你需要的是你要通路的元素在樹。您不必等待下載下傳所有圖像。 DOMContentLoaded是你可能考慮的onload事件，而不是使用事件，但直到它在所有的浏覽器，你可以使用YUI事件工具，其中有一個onAvailable方法。

欲了解更多資訊，檢查銳劇院 的“高性能Ajax應用程式 “，由Julien Lecomte。

頂部

選擇對的@ import的<link>

标簽：CSS

以前最好的做法一個國家的CSS應在頂部，以便逐漸呈現。

在IE浏覽器的@ import的行為使用的是相同的 <link>在頁面的底部，是以最好不要使用它 。

頂部

避免過濾器

标簽：CSS

IE專有的AlphaImageLoader篩選器的目的是修複與真彩色的PNG半透明版本的IE <7問題 。此過濾器的問題是，它塊的渲染和當機浏覽器，而正在下載下傳的圖像。這也增加了記憶體消耗是每個元素的應用，而不是每幅圖像，這樣的問題是成倍增加 。

最好的辦法是完全避免AlphaImageLoader和使用優雅有辱人格的PNG8，而不是，這是在IE的罰款 ​​。如果你絕對需要AlphaImageLoader的，使用下劃線劈 _Filter不懲罰你的IE7 + 使用者。

頂部

優化圖像

标簽：圖像

經過設計師與創造您的網頁圖像，仍然有一些事情你可以先試後到Web伺服器FTP這些圖像。

• 您可以檢視GIF和看看他們使用的是調色闆的大小對應于圖像中的顔色數量 。使用ImageMagick的，很容易地 檢查确定詳細 image.gif，當你看到的圖像，使用4種顔色，256色調色闆中的“槽”，有 改進的餘地。
• 嘗試轉換的GIF，PNG和檢視是否有節省。往往不是存在。開發人員經常會毫不猶豫地使用PNG格式，由于在浏覽器中的有限支援，但現在這是過去的事情了。唯一的真正問題是真彩色的PNG的Alpha透明度，但話又說回來，gifs是不是真彩色，不支援可變的透明度。調色闆PNG（PNG8），是以任何一個GIF可以做，可以做太多（動畫除外） 。這個簡單的ImageMagick指令的結果，在完全安全使用PNG 圖像：轉換 image.gif image.png“我們說的是：給ping一個 機會！“
• 運作pngcrush所有的PNG（或任何其他PNG優化工具）。例： pngcrush image.png REM ALLA減少野蠻result.png
• 運作在所有的JPEG檔案jpegtran。此工具如旋轉無損JPEG操作，也可用于優化和删除您的圖檔的意見和其他無用的資訊（如EXIF資訊） 。jpegtran複制沒有優化完美src.jpg dest.jpg

頂部

優化CSS精靈

标簽：圖像

• 安排在水準垂直通常在較小的檔案大小的結果，而不是的精靈的圖像。
• 結合相似的顔色在精靈幫助您保持色彩數低，下256色的理想，以适應在一個PNG8。
• “可移動的友好”，不留一個sprite圖像之間的較大差距。這不會影響檔案的大小，盡可能多的，但需要較少的記憶體，為使用者代了解壓縮到一個像素圖的圖像。100x100的圖像是10萬像素，1000X1000 100萬像素的

頂部

不要規模HTML圖像

标簽：圖像

不要使用比你需要的僅僅是因為你可以在HTML中的寬度和高度設定一個較大的圖像。如果您需要<img WIDTH="100" height="100" src="mycat.jpg" alt="My Cat" /> 那麼你的形象（mycat.jpg）應，而不是向下500x500px圖像的縮放 100x100px。

頂部

favicon.ico小和可高速緩存

标簽：圖像

favicon.ico是一個停留在您的伺服器的根的形象。這是一個必要的邪惡，因為即使你不關心它的浏覽器将仍然要求，是以最好不要回應一個404未找到。此外，由于在同一伺服器上的，Cookie是發送的每一個要求的時間。此圖檔下載下傳序列的幹擾，例如在IE浏覽器額外的元件，當您請求的onload的favicon會被下載下傳之前，這些額外的元件 。

是以，為了減輕favicon.ico確定弊端：

• 它的小，最好在1K。
• 設定Expires頭與你感覺很舒服（因為你不能重命名它，如果你決定改變它）。你或許可以安全地設定Expires頭在未來的幾個月。您可以檢視您目前favicon.ico的最後修改日期做出明智的決定。

ImageMagick的可以幫助你建立小的網站 圖示

頂部

保持下25K元件

标簽：手機

這種限制是有關的事實，iPhone将不緩存超過25K的元件 。請注意，這是未壓縮的大小 。這是微小的，是因為GZIP單獨可能不足以。

欲了解更多資訊，檢查“性能的研究，第5部分：iPhone可緩存-它棒“韋恩乳木果和Tenni陶依爾 。

頂部

包成一個Multipart檔案元件

标簽：手機

包裝成一個多文檔的元件，如帶有附件的電子郵件，它可以幫助你擷取一個HTTP請求（記住：HTTP請求昂貴）幾部分組成。當你使用這種方法，首先檢查是否使用者代理支援它（iPhone不）。

避免空洞的圖檔的src

标簽：伺服器

與空字元串的圖檔的 src屬性發生超過預期 。它有兩種形式出現：

1. 直接的HTML

   <img src="">

2. JavaScript的

   VAR IMG =新的Image（）; 

   img.src =“”;

這兩種形式引起相同的效果：浏覽器發出另一個請求到您的伺服器。

• Internet Explorer的要求在該頁面所在的目錄。
• Safari和Chrome實際頁面本身的請求 。
• 火狐 3和早期版本的Safari和Chrome相同的行為，但3.5版本解決了這一問題[錯誤 444931]不再發送請求。
• 歌劇沒有做任何事情時遇到一個空的形象SRC 。

為什麼這是不好的行為呢？

1. 跛子您的伺服器發送的大量突發流量，尤其是得到以百萬計的頁面浏覽量每天的網頁。
2. 廢物伺服器計算周期産生一個永遠不會被浏覽的網頁。
3. 可能會破壞使用者資料。如果你是跟蹤請求的狀态，可以通過cookie或以另一種方式，你有破壞資料的可能性。即使圖像請求不傳回一個圖像，所有的标題都閱讀并接受浏覽器，包括所有的cookies。雖然響應的其餘部分扔掉，損害可能已經完成。

這種行為的根源是，在浏覽器中進行解析URI的方式。這種行為是定義在RFC 3986 - 統一資源辨別符。當遇到一個空字元串作為URI，它被認為是一個相對的URI，是根據5.2節定義的算法解決。這個具體的例子，一個空字元串，列在第5.4節。火狐，Safari和Chrome都解決一個空字元串按照規範正确，而Internet Explorer是解決不正确的，顯然是在RFC 2396規範的早期版本， - 統一資源辨別符（這是由RFC 3986過時） 。是以從技術上來說，浏覽器是做他們應該做的事情來解決相對URI。問題是，在這種情況下，空字元串顯然是無意的。

HTML5的增加

标記的src屬性的說明，訓示浏覽器不作出第4.8.2節中的額外 要求：

src屬性必須存在，并且必須包含一個有效的URL引用一個非互動式的，可以選擇動畫，圖像資源，既不是分頁，也不照本宣科。如果元素的基URI是文檔的位址相同，則src屬性的值必須不能是空字元串。

希望，浏覽器不會有這個問題在未來。不幸的是，該條款沒有<script src="">和<link href="" target="_blank" rel="external nofollow" >。也許還有時間做出調整，以確定浏覽器不小心執行此行為。

此規則的設計靈感來自雅虎的JavaScript大師尼古拉斯C. Zakas。欲了解更多資訊，檢查出他的文章“空圖像的src可以摧毀你的網站 “。

頂部