优化网站性能的35条规则
最新博客站點：歡迎來訪
1. 最小化HTTP請求次數
? ? ? ?最終用戶響應時間的80％用于前端。大部分時間都在下載頁面中的所有組件：圖像，樣式表，腳本，Flash等。減少組件數量反過來減少了呈現頁面所需的HTTP請求數量。這是更快頁面的關鍵。
減少頁面中組件數量的一種方法是簡化頁面設計。但有沒有辦法構建內容更豐富的頁面，同時還能實現快速響應時間？以下是一些減少HTTP請求數量的技術，同時仍支持豐富的頁面設計。
組合文件是一種通過將所有腳本組合到單個腳本中來減少HTTP請求數量的方法，并且類似地將所有CSS組合到單個樣式表中。當腳本和樣式表在不同頁面之間變化時，組合文件更具挑戰性，但使這部分發布過程可以縮短響應時間。
CSS Sprites是減少圖像請求數量的首選方法。將背景圖像合并為單個圖像，并使用CSSbackground-image和background-position屬性顯示所需的圖像片段。
圖像地圖將多個圖像組合成單個圖像。整體大小大致相同，但減少HTTP請求的數量會加快頁面的速度。圖像映射僅在圖像在頁面中是連續的時才起作用，例如導航欄。定義圖像映射的坐標可能是乏味且容易出錯的。使用圖像地圖進行導航也無法訪問，因此不建議使用。
內聯圖像使用data:URL方案將圖像數據嵌入實際頁面中。這可以增加HTML文檔的大小。將內嵌圖像組合到（緩存的）樣式表中是一種減少HTTP請求并避免增加頁面大小的方法。并非所有主流瀏覽器都支持內嵌圖像。
減少頁面中HTTP請求的數量是可以開始的地方。這是提高首次訪問者性能的最重要指南。正如Tenni Theurer的博客文章瀏覽器緩存使用 - 暴露！，您網站的每日訪問者中有40-60％使用空緩存。讓這些首次訪問者快速訪問頁面是獲得更好用戶體驗的關鍵。
2. 使用內容分發網絡（CDN）
? ? ? ?用戶與Web服務器的距離會對響應時間產生影響。在多個地理位置分散的服務器上部署內容將使您的頁面從用戶的角度加載更快。但是你應該從哪里開始呢？
作為實現地理位置分散的內容的第一步，請勿嘗試重新設計Web應用程序以在分布式體系結構中工作。根據應用程序的不同，更改體系結構可能包括令人生畏的任務，例如同步會話狀態和跨服務器位置復制數據庫事務。嘗試縮短用戶與您的內容之間的距離可能會延遲或永遠不會通過此應用程序架構步驟。
請記住，最終用戶響應時間的80-90％用于下載頁面中的所有組件：圖像，樣式表，腳本，Flash等。這是性能黃金規則。而不是從重新設計應用程序架構的艱巨任務開始，最好先分散靜態內容。這不僅可以縮短響應時間，而且由于內容交付網絡，它更容易實現。
內容傳送網絡（CDN）是分布在多個位置的Web服務器的集合，以更有效地向用戶傳送內容。選擇用于向特定用戶傳送內容的服務器通常基于網絡鄰近度的度量。例如，選擇具有最少網絡跳躍的服務器或具有最快響應時間的服務器。
一些大型互聯網公司擁有自己的CDN，但使用CDN服務提供商（如Akamai Technologies，EdgeCast或level3）具有成本效益。對于初創公司和私人網站來說，CDN服務的成本可能過高，但隨著您的目標受眾變得越來越大并變得更加全球化，CDN對于實現快速響應時間是必要的。在Yahoo！中，將靜態內容從其應用程序Web服務器移動到CDN（如上所述的第三方以及Yahoo自己的CDN）的屬性將最終用戶響應時間提高了20％或更多。切換到CDN是一個相對容易的代碼更改，將顯著提高您的網站的速度。
3. 添加Expires或Cache-Control標頭
這條規則有兩個方面：
- 對于靜態組件：通過設置遠期未來Expires標頭實現“永不過期”策略
- 對于動態組件：使用適當的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指令的這個示例將Expires日期設置為距請求時間10年。
ExpiresDefault "access plus 10 years"? ? ? ?請記住，如果您使用遠期的Expires標頭，則必須在組件更改時更改組件的文件名。在Yahoo!?我們經常將此步驟作為構建過程的一部分：版本號嵌入在組件的文件名中，例如，yahoo_2.0.6.js。
使用遠期Expires標頭僅在用戶訪問過您的網站后才會影響網頁瀏覽量。當用戶第一次訪問您的站點并且瀏覽器的緩存為空時，它對HTTP請求的數量沒有影響。因此，此性能改進的影響取決于用戶使用已準備好的緩存命中您的頁面的頻率。（“已準備好的緩存”已包含頁面中的所有組件。）我們在Yahoo!上測量了這一點。并發現帶有固定緩存的頁面查看次數為75-85％。通過使用遠期的Expires標頭，您可以增加瀏覽器緩存的組件數量，并在后續頁面視圖中重復使用，而無需通過用戶的Internet連接發送單個字節。
? ? ? ?4. 使用Gzip組件
? ? ? ?通過前端工程師做出的決策，可以顯著減少在網絡上傳輸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，但效果較差且不太受歡迎。
? ? ? ?Gzipping通常將響應大小減少約70％。今天大約90％的互聯網流量通過聲稱支持gzip的瀏覽器傳播。如果你使用Apache，配置gzip的模塊取決于你的版本：Apache 1.3使用mod_gzip而Apache 2.x使用mod_deflate。
? ? ? ?瀏覽器和代理存在已知問題，這些問題可能導致瀏覽器期望的內容與壓縮內容相關的內容不匹配。幸運的是，隨著舊瀏覽器的使用逐漸減少，這些邊緣情況正在逐漸減少。Apache模塊通過自動添加適當的Vary響應頭來提供幫助。
? ? ? ?服務器根據文件類型選擇gzip的內容，但通常在他們決定壓縮的內容方面受到限制。大多數網站都會gzip他們的HTML文檔。gzip你的腳本和樣式表也是值得的，但很多網站都錯過了這個機會。實際上，壓縮包括XML和JSON在內的任何文本響應都是值得的。不應對圖像和PDF文件進行gzip壓縮，因為它們已經過壓縮。試圖對它們進行gzip不僅浪費CPU，而且可能會增加文件大小。
? ? ? ?盡可能多地壓縮文件類型是減輕頁面重量和加速用戶體驗的簡便方法。
? ? ? ?5. 將CSS樣式表放在頂部
? ? ? ?在研究Yahoo!的性能時，我們發現將樣式表移動到文檔HEAD會使頁面看起來加載速度更快。這是因為將樣式表放在HEAD中允許頁面逐步呈現。
? ? ? ?關注性能的前端工程師希望頁面逐步加載;?也就是說，我們希望瀏覽器盡快顯示它擁有的任何內容。這對于具有大量內容的頁面和對較慢Internet連接的用戶尤其重要。為用戶提供視覺反饋（例如進度指示器）的重要性已得到很好的研究和記錄。在我們的例子中，HTML頁面是進度指示器！當瀏覽器逐步加載頁面時，標題，導航欄，頂部的徽標等都作為等待頁面的用戶的視覺反饋。這改善了整體用戶體驗。
? ? ? ?將樣式表放在文檔底部附近的問題是它禁止在許多瀏覽器（包括Internet Explorer）中逐行渲染。這些瀏覽器會阻止渲染，以避免在樣式發生變化時重繪頁面元素。用戶查看空白頁面時卡住了。
? ? ? ?HTML規范明確指出，樣式表是被包括在網頁的HEAD：“與A，[LINK]可以僅出現在一個文檔的HEAD部分，盡管它可能出現任意次數”。這些替代品，空白的白色屏幕或無風格內容的閃光都是值得冒險的。最佳解決方案是遵循HTML規范并在文檔HEAD中加載樣式表。
? ? ? ?6. 將JavaScript腳本放在底部
? ? ? ?腳本引起的問題是它們阻止了并行下載。HTTP / 1.1規范建議的瀏覽器下載不超過兩種組分在每主機名平行。如果您從多個主機名提供圖像，則可以并行執行兩次以上的下載。但是，在下載腳本時，即使在不同的主機名上，瀏覽器也不會啟動任何其他下載。
? ? ? ?在某些情況下，將腳本移到底部并不容易。例如，如果腳本用于document.write插入頁面內容的一部分，則無法在頁面中向下移動。可能還存在范圍問題。在許多情況下，有辦法解決這些問題。
? ? ? ?經常出現的另一種建議是使用延遲腳本。該DEFER屬性表明該腳本不包含document.write，并且是瀏覽器可以繼續呈現的線索。不幸的是，Firefox不支持該DEFER屬性。在Internet Explorer中，腳本可能會延遲，但不是所需的。如果可以延遲腳本，也可以將其移動到頁面底部。這將使您的網頁加載速度更快。
? ? ? ?7. 避免使用CSS中的expressions
? ? ? ?CSS表達式是一種動態設置CSS屬性的強大（且危險）方法。從版本5開始，它們在Internet Explorer中受支持，但從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表達式，請記住它們可能會被評估數千次，并可能影響頁面的性能。
? ? ? ?8. 將JavaScript和CSS獨立成外部文件
? ? ? ?其中許多性能規則都涉及外部組件的管理方式。但是，在出現這些考慮因素之前，您應該提出一個更基本的問題：JavaScript和CSS是否應該包含在外部文件中，還是內嵌在頁面中？
? ? ? ?在現實世界中使用外部文件通常會產生更快的頁面，因為瀏覽器會緩存JavaScript和CSS文件。每次請求HTML文檔時，都會下載HTML文檔中內聯的JavaScript和CSS。這減少了所需的HTTP請求數，但增加了HTML文檔的大小。另一方面，如果JavaScript和CSS位于瀏覽器緩存的外部文件中，則HTML文檔的大小會減少，而不會增加HTTP請求的數量。
? ? ? ?因此，關鍵因素是外部JavaScript和CSS組件相對于請求的HTML文檔數量的緩存頻率。這個因素雖然難以量化，但可以使用各種指標進行衡量。如果您站點上的用戶每個會話有多個頁面查看，并且您的許多頁面重復使用相同的腳本和樣式表，則緩存的外部文件可能會帶來更大的潛在好處。
? ? ? ?許多網站都處于這些指標的中間。對于這些站點，最佳解決方案通常是將JavaScript和CSS部署為外部文件。內聯的唯一例外是主頁，例如Yahoo！的首頁和My Yahoo!?。每個會話具有很少（可能只有一個）頁面視圖的主頁可能會發現內聯JavaScript和CSS會導致更快的最終用戶響應時間。
? ? ? ?對于通常是許多頁面視圖中的第一個的首頁，有一些技術可以利用內聯提供的HTTP請求的減少，以及通過使用外部文件實現的緩存優勢。其中一種技術是在首頁中內聯JavaScript和CSS，但在頁面加載完成后動態下載外部文件。后續頁面將引用應該已存在于瀏覽器緩存中的外部文件。
? ? ? ?9. 減少DNS查詢
域名系統（DNS）將主機名映射到IP地址，就像電話簿將人們的姓名映射到他們的電話號碼一樣。當您在瀏覽器中鍵入www.yahoo.com時，瀏覽器聯系的DNS解析器將返回該服務器的IP地址。DNS有成本。DNS通常需要20-120毫秒才能查找給定主機名的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查找會縮短響應時間，但減少并行下載可能會縮短響應時間。我的準則是將這些組件分成至少兩個但不超過四個主機名。這導致在減少DNS查找和允許高度并行下載之間的良好折衷。
? ? ? ?10. 壓縮JavaScript和CSS(包括內聯<script>和<style>)
壓縮是從代碼中刪除不必要的字符以減小其大小從而改善加載時間的做法。壓縮代碼時，將刪除所有注釋，以及不需要的空格字符（空格，換行符和制表符）。在JavaScript的情況下，這改善了響應時間性能，因為下載文件的大小減小了。用于壓縮JavaScript代碼的兩種流行工具是JSMin和YUI Compressor。YUI壓縮器也可以壓縮CSS。
混淆是可以應用于源代碼的替代優化。它比壓縮更復雜，因此更容易因混淆步驟本身而產生錯誤。在對美國十大頂級網站的調查中，壓縮規模縮小了21％，而混淆縮小了25％。盡管混淆具有更高的大小縮減，但壓縮JavaScript的風險較小。
除了壓縮外部腳本和樣式之外，內聯<script>和<style>塊也可以并且也應該壓縮。即使你gzip你的腳本和樣式，壓縮它們仍然會減小5％或更多的大小。隨著JavaScript和CSS的使用和大小的增加，壓縮代碼所節省的成本也會增加。
? ? ? ?11. 避免重定向
使用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表示它應該是）。元刷新標記和JavaScript是將用戶定向到不同URL的其他方法，但如果必須進行重定向，則首選技術是使用標準3xx HTTP狀態代碼，主要是為了確保后退按鈕正常工作。
要記住的主要事情是重定向會降低用戶體驗。在用戶和HTML文檔之間插入重定向會延遲頁面中的所有內容，因為頁面中的任何內容都無法呈現，并且在HTML文檔到達之前不會開始下載任何組件。
最浪費的重定向之一經常發生，Web開發人員通常不了解它。當URL中缺少尾部斜杠（/）時會發生這種情況。例如，轉到http://astrology.yahoo.com/astrology會產生301響應，其中包含重定向到http://astrology.yahoo.com/astrology/（注意添加的尾部斜杠）。如果您使用的是Apache處理程序，則可以使用Alias 或?mod_rewrite 或?DirectorySlash指令在Apache中修復此問題。
將舊網站連接到新網站是重定向的另一種常見用途。其他包括連接網站的不同部分并基于特定條件（瀏覽器類型，用戶帳戶類型等）指導用戶。使用重定向連接兩個網站很簡單，只需要很少的額外編碼。雖然在這些情況下使用重定向會降低開發人員的復雜性，但會降低用戶體驗。使用重定向的替代方法包括使用Alias以及mod_rewrite兩個代碼路徑是否托管在同一服務器上。如果域名更改是使用重定向的原因，則另一種方法是創建CNAME（創建從一個域名指向另一個域名的別名的DNS記錄）與Alias或組合mod_rewrite。
? ? ? ?12. 刪除重復的腳本
在一個頁面中兩次包含相同的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頭。
? ? ? ?13. 配置實體標記ETag
實體標記（ETag）是Web服務器和瀏覽器用于確定瀏覽器緩存中的組件是否與源服務器上的組件匹配的機制。（“實體”是另一個詞“組件”：圖像，腳本，樣式表等）。添加ETag以提供驗證比上次修改日期更靈活的實體的機制。ETag是唯一標識組件的特定版本的字符串。唯一的格式約束是引用字符串。源服務器使用ETag響應頭指定組件的ETag?。
HTTP/1.1 200 OKLast-Modified: Tue, 12 Dec 2006 03:03:59 GMTETag: "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 ModifiedETag的問題在于它們通常使用屬性構建，這些屬性使它們對托管站點的特定服務器是唯一的。當瀏覽器從一個服務器獲取原始組件并稍后嘗試在不同服務器上驗證該組件時，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配置更改的計數器。后面整個網站的所有IIS服務器ChangeNumber是相同這是不太可能的。
最終結果是Apache和IIS生成的ETag對于完全相同的組件從一臺服務器到另一臺服務器不匹配。如果ETag不匹配，則用戶不會收到ETag設計的小的，快速的304響應;?相反，他們將獲得正常的200響應以及組件的所有數據。如果您只在一臺服務器上托管您的網站，這不是問題。但是，如果您有多個服務器托管您的網站，并且您正在使用具有默認ETag配置的Apache或IIS，則您的用戶正在變慢頁面，您的服務器負載更高，您正在消耗更大的帶寬，并且代理服務器沒有有效地緩存您的內容。即使您的組件具有遠期Expires標頭，每當用戶點擊重新加載或刷新時，仍會發出條件GET請求。
如果您沒有利用ETag提供的靈活驗證模型，最好只刪除ETag。該Last-Modified頭驗證基于對組件的時間戳。刪除ETag會減少響應和后續請求中HTTP標頭的大小。此Microsoft支持文章介紹了如何刪除ETag。在Apache中，只需將以下行添加到Apache配置文件即可：
FileETag none? ? ? ?14. 使Ajax可以緩存
Ajax的一個優點是它為用戶提供即時反饋，因為它從后端Web服務器異步請求信息。但是，使用Ajax并不能保證用戶不會在等待那些異步JavaScript和XML響應返回時大拇指。在許多應用程序中，用戶是否保持等待取決于Ajax的使用方式。例如，在基于Web的電子郵件客戶端中，用戶將一直等待Ajax請求的結果，以查找符合其搜索條件的所有電子郵件。重要的是要記住“異步”并不意味著“瞬時”。
為了提高性能，優化這些Ajax響應非常重要。提高Ajax性能的最重要方法是使響應可緩存，如添加Expires或Cache-controll標頭中所述。其他一些規則也適用于Ajax：
- Gzip組件
- 減少DNS查找
- 壓縮JavaScript
- 避免重定向
- 配置ETag
我們來看一個例子。Web 2.0電子郵件客戶端可能使用Ajax下載用戶的通訊簿以進行自動完成。如果用戶自上次使用電子郵件Web應用程序以來未修改過她的地址簿，則可以從緩存中讀取先前的地址簿響應，如果該Ajax響應可以使用將來的Expires或Cache-Control標頭進行緩存。必須通知瀏覽器何時使用先前緩存的地址簿響應而不是請求新的地址簿響應。這可以通過向地址簿Ajax URL添加時間戳來完成，該時間戳指示用戶上次修改其地址簿的時間，例如，&t=1190241612。如果自上次下載后地址簿尚未被修改，則時間戳將相同，并且將從瀏覽器的緩存中讀取地址簿，從而消除額外的HTTP往返。如果用戶修改了地址簿，則時間戳確保新URL與緩存的響應不匹配，瀏覽器將請求更新的地址簿條目。
即使您的Ajax響應是動態創建的，并且可能僅適用于單個用戶，它們仍然可以緩存。這樣做可以使您的Web 2.0應用程序更快。
? ? ? ?15. 盡早清除緩沖區
當用戶請求頁面時，后端服務器可能需要200到500毫秒才能將HTML頁面拼接在一起。在此期間，瀏覽器在等待數據到達時處于空閑狀態。在PHP中，您有函數flush（）。它允許您將部分準備好的HTML響應發送到瀏覽器，以便瀏覽器可以在后端忙于HTML頁面的其余部分時開始獲取組件。這種好處主要出現在繁忙的后端或輕量級前端。
考慮刷新的好地方就在HEAD之后，因為頭部的HTML通常更容易生成，并且它允許您包含任何CSS和JavaScript文件，以便瀏覽器在后端處理時并行地開始獲取。
例：
... <!-- css, js --> </head> <?php flush(); ?> <body> ... <!-- content -->雅虎?搜索開創性研究和真實用戶測試，以證明使用此技術的好處。
? ? ? ?16. 使用GET進行Ajax請求
在雅虎?郵件團隊發現，在使用時XMLHttpRequest，POST在瀏覽器中實現為兩步過程：首先發送標頭，然后發送數據。因此最好使用GET，它只需要一個TCP數據包發送（除非你有很多cookie）。IE中的最大URL長度為2K，因此如果發送的數據超過2K，則可能無法使用GET。
一個有趣的副作用是沒有實際發布任何數據的POST就像GET一樣。根據HTTP規范，GET用于檢索信息，因此當您僅請求數據時，使用GET是有意義的（語義上），而不是將數據發送到服務器端存儲。
? ? ? ?17. 延遲加載組件
您可以仔細查看您的頁面并問自己：“頁面最初渲染必要的是什么？”。其余的內容和組件可以等待。
JavaScript是在onload事件之前和之后拆分的理想候選者。例如，如果您有執行拖放和動畫的JavaScript代碼和庫，則可以等待，因為在初始渲染之后拖動頁面上的元素。其他尋找后期加載候選者的地方包括隱藏內容（用戶操作后顯示的內容）和首屏下方的圖像。
幫助您完成工作的工具：YUI Image Loader允許您將圖像延遲到折疊下方，YUI Get實用程序是一種簡單的方法，可以動態地包含JS和CSS。在野外的例子看看雅虎！打開Firebug網絡面板的主頁。
當性能目標與其他Web開發最佳實踐一致時，這是很好的。在這種情況下，漸進增強的想法告訴我們，JavaScript在受支持時可以改善用戶體驗，但您必須確保即使沒有JavaScript也能正常工作。因此，在確保頁面正常工作之后，您可以使用一些后期加載的腳本來增強它，這些腳本可以為您提供更多的花俏功能，例如拖放和動畫。
? ? ? ?18. 預加載組件
預加載可能看起來與延遲加載相反，但它實際上有不同的目標。通過預加載組件，您可以利用瀏覽器空閑的時間并請求將來需要的組件（如圖像，樣式和腳本）。這樣，當用戶訪問下一頁時，您可以將大部分組件放在緩存中，并且您的頁面將為用戶加載更快。
實際上有幾種類型的預加載：
- 無條件預加載 - 一旦onload觸發，你就可以繼續獲取一些額外的組件。請訪問google.com，了解如何請求加載精靈圖片。google.com主頁上不需要此精靈圖片，但在連續搜索結果頁面上需要此精靈圖片。
- 條件預加載 - 基于用戶操作，您可以進行有根據的猜測，即用戶前進的位置并相應地預加載。在search.yahoo.com上，您可以看到在開始輸入輸入框后如何請求一些額外的組件。
- 預期的預加載 - 在啟動重新設計之前提前預加載。經常在重新設計之后聽到：“新網站很酷，但比以前慢”。部分問題可能是用戶使用完整緩存訪問舊網站，但新網站始終是空緩存體驗。您可以通過在啟動重新設計之前預加載某些組件來緩解此副作用。您的舊站點可以使用瀏覽器空閑的時間并請求新站點將使用的圖像和腳本
? ? ? ?19. 減少DOM元素的數量
復雜頁面意味著要下載更多字節，這也意味著JavaScript中的DOM訪問速度更慢。例如，當您想要添加事件處理程序時，如果在頁面上循環遍歷500或5000個DOM元素，則會有所不同。
大量的DOM元素可能是一種通癥，即應該通過頁面標記來改進，而不必刪除內容。您是否使用嵌套表進行布局？您是否只是為了解決布局問題而投入更多<div>？也許有一種更好，語義更正確的標記方式。
YUI CSS實用程序?提供了很好的布局幫助：grids.css可以幫助您完成整體布局，fonts.css和reset.css可以幫助您去除瀏覽器的默認格式。這是一個重新開始并考慮標記的機會，例如，<div>只有在語義上有意義時才使用s，而不是因為它呈現新行。
DOM元素的數量很容易測試，只需鍵入Firebug的控制臺：
那到底有多少DOM元素才算少？檢查具有良好標記的其他類似頁面。例如雅虎！主頁是一個非常繁忙的頁面，仍然不到700個元素（HTML標記）。
? ? ? ?20. 跨域拆分組件
拆分組件允許您最大化并行下載。由于DNS查詢懲罰，請確保您使用的域名不超過2-4個。例如，您可以托管HTML和動態內容，www.example.org?并在static1.example.org和之間拆分靜態組件static2.example.org
有關更多信息，請查看Tenni Theurer和Patty Chi的“?在Carpool Lane中最大化并行下載?”。
? ? ? ?21. 最小化iframe數量
iframe允許將HTML文檔插入父文檔中。了解iframe如何運作以便有效使用非常重要。
<iframe>?優點：
- 幫助緩慢的第三方內容，如徽章和廣告
- 安全沙箱
- 并行下載腳本
<iframe>?缺點：
- 即使空白也要花錢
- 阻止頁面onload
- 非語義
? ? ? ?22. 不用404s
HTTP請求很昂貴，因此發出HTTP請求并獲得無用的響應（即404 Not Found）是完全沒必要的，并且會在沒有任何好處的情況下減慢用戶體驗。
有些網站有幫助404“你的意思是X？”，這對用戶體驗很有好處，但也浪費了服務器資源（比如數據庫等）。特別糟糕的是當外部JavaScript的鏈接錯誤并且結果是404時。首先，此下載將阻止并行下載。接下來，瀏覽器可能會嘗試解析404響應主體，就像它是JavaScript代碼一樣，試圖找到可用的東西。
? ? ? ?23. 減小Cookie大小
HTTP cookie的使用有多種原因，例如身份驗證和個性化。有關cookie的信息在Web服務器和瀏覽器之間的HTTP標頭中進行交換。保持cookie的大小盡可能低是非常重要的，以盡量減少對用戶響應時間的影響。
欲了解更多信息，請查看?Tenni Theurer和Patty Chi撰寫的“當Cookie崩潰時”。這項研究的主要內容：
- 消除不必要的cookie
- 保持cookie大小盡可能低，以盡量減少對用戶響應時間的影響
- 請注意在適當的域級別設置cookie，以免其他子域受到影響
- 適當地設置過期日期。較早的Expires日期或者沒有更早刪除cookie，從而改善了用戶響應時間
? ? ? ?24. 對組建使用cookie-free的域名
當瀏覽器發出靜態圖像請求并將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會讓您別無選擇，只能寫入cookie?*.example.org，因此出于性能原因，最好使用www子域并將cookie寫入該子域。
? ? ? ?25. 最小化DOM的訪問次數
使用JavaScript訪問DOM元素的速度很慢，因此為了獲得響應更快的頁面，您應該：
- 緩存對訪問元素的引用
- 更新節點“離線”，然后將它們添加到樹中
- 避免使用JavaScript修復布局
有關更多信息，請查看?Julien Lecomte?的YUI影院的?“高性能Ajax應用程序”。
? ? ? ?26. 開發巧妙的事件處理程序
有時頁面感覺響應性較差，因為過多的事件處理程序附加到DOM樹的不同元素，然后執行得太頻繁。這就是為什么使用事件委托是一個很好的方法。如果a中有10個按鈕div，則只將一個事件處理程序附加到div包裝器，而不是每個按鈕一個處理程序。事件冒出來，這樣你就可以捕捉事件并找出它來自哪個按鈕。
您也不需要等待onload事件以便開始使用DOM樹執行某些操作。通常，您只需要在樹中訪問要訪問的元素。您不必等待下載所有圖像。DOMContentLoaded是您可能考慮使用的事件而不是onload，但在所有瀏覽器中都可用之前，您可以使用具有方法的YUI事件實用程序onAvailable。
有關更多信息，請查看?Julien Lecomte?的YUI影院的?“高性能Ajax應用程序”。
? ? ? ?27. 優先選擇使用<link>而非@import
之前的最佳實踐之一聲明CSS應位于頂部以允許漸進式渲染。
在IE中，@import行為與<link>在頁面底部使用相同，因此最好不要使用它。
? ? ? ?28. 避免使用filters
IE專有的AlphaImageLoader過濾器旨在解決IE版本<7中的半透明真彩色PNG的問題。該過濾器的問題在于它在下載圖像時阻止渲染并凍結瀏覽器。它還會增加內存消耗，并且每個元素應用，而不是每個圖像，因此問題成倍增加。
最好的方法是AlphaImageLoader完全避免使用優雅降級的PNG8，這在IE中很好。如果你絕對需要AlphaImageLoader，使用下劃線黑客_filter不會懲罰你的IE7 +用戶。
? ? ? ?29. 優化圖片
設計師完成為您的網頁創建圖像后，在將這些圖像FTP到Web服務器之前，仍然可以嘗試一些操作。
- 您可以檢查GIF并查看它們是否使用與圖像中顏色數對應的調色板大小。使用imagemagick很容易檢查?
- identify -verbose image.gif?
- 當你在調色板中看到使用4種顏色和256色“槽”的圖像時，還有改進的余地。
- 嘗試將GIF轉換為PNG并查看是否存在保存。通常，有。由于瀏覽器的支持有限，開發人員經常對使用PNG猶豫不決，但現在已成為過去。唯一真正的問題是真彩色PNG中的alpha透明度，但是GIF也不是真彩色，也不支持變量透明度。所以GIF可以做任何事情，調色板PNG（PNG8）也可以做（動畫除外）。這個簡單的imagemagick命令導致完全安全的PNG：
- convert image.gif image.png
- “我們所說的只是：給PiNG一個機會！”
- 在所有PNG上?運行pngcrush（或任何其他PNG優化工具）。例：?
- pngcrush image.png -rem alla -reduce -brute result.png
- 在所有JPEG上運行jpegtran。此工具執行無損JPEG操作（如旋轉），還可用于優化和刪除圖像中的注釋和其他無用信息（如EXIF信息）。
- jpegtran -copy none -optimize -perfect src.jpg dest.jpg
? ? ? ?30.優化CSS Sprites
- 將圖像水平排列在精靈中而不是垂直排列通常會導致文件較小。
- 在精靈中組合相似的顏色可以幫助您保持較低的顏色數，理想情況下在256色以下，以適應PNG8。
- “適合移動設備”并且不要在精靈中留下大的間隙。這不會影響文件大小，但需要較少的內存，以便用戶代理將圖像解壓縮為像素圖。100x100圖像是1萬像素，其中1000x1000是100萬像素
? ? ? ?31. 不要在HTML中縮放圖像
不要使用比您需要的更大的圖像，因為您可以在HTML中設置寬度和高度。如果您需要，
<img width="100" height="100" src="mycat.jpg" alt="My Cat" />那么您的圖像（mycat.jpg）應該是100x100px而不是縮小的500x500px圖像。
? ? ? ?32. 減小favicon.ico的體積并緩存
favicon.ico是一個保留在服務器根目錄中的映像。這是一個必要的邪惡，因為即使你不關心它，瀏覽器仍然會請求它，所以最好不要回復404 Not Found。此外，由于它位于同一臺服務器上，因此每次請求時都會發送cookie。此圖像也會干擾下載順序，例如在IE中，當您在onload中請求額外組件時，將在這些額外組件之前下載favicon。
因此，為了減輕擁有favicon.ico的缺點，請確保：
- 它很小，最好不到1K。
- 使用您感覺舒適的設置Expires標頭（因為如果您決定更改它，則無法重命名）。您可以在將來幾個月安全地設置Expires標頭。您可以查看當前favicon.ico的上次修改日期，以做出明智的決定。
Imagemagick可以幫助您創建小的favicons
? ? ? ?33. 保持組件小于25K
此限制與iPhone不會緩存大于25K的組件這一事實有關。請注意，這是未壓縮的大小。這是縮小很重要的地方，因為單獨使用gzip可能還不夠。
欲了解更多信息，請查看Wayne Shea和Tenni Theurer的“?性能研究，第5部分：iPhone可緩存性 - 讓它堅持下去?”。
? ? ? ?34. 將組件拆分到多個文檔中
將組件打包到多部分文檔就像帶有附件的電子郵件，它可以幫助您通過一個HTTP請求獲取多個組件（請記住：HTTP請求很昂貴）。使用此技術時，首先檢查用戶代理是否支持它（iPhone不支持）。
? ? ? ?35. 避免設置空圖像的src
帶有空字符串src屬性的圖像會出現多個預期。它以兩種形式出現：
<img src =“”>
var img = new Image（）;?
img.src =“”;
兩種形式都會產生相同的效果：瀏覽器向您的服務器發出另一個請求
- Internet Explorer向頁面所在的目錄發出請求。
- Safari和Chrome會向實際頁面提出請求。
- Firefox?3及更早版本的行為與Safari和Chrome相同，但3.5版解決了此問題[錯誤444931]，不再發送請求。
- 遇到空圖像時，Opera不執行任何操作。
為什么這種行為不好？
此行為的根本原因是在瀏覽器中執行URI解析的方式。此行為在RFC 3986 - 統一資源標識符中定義。當遇到空字符串作為URI時，它被視為相對URI，并根據5.2節中定義的算法進行解析。這個具體的例子是一個空字符串，在5.4節中列出。Firefox，Safari和Chrome都按照規范正確解析空字符串，而Internet Explorer正在解析它，顯然符合規范的早期版本RFC 2396 - 統一資源標識符（這已被RFC 3986廢棄） 。從技術上講，瀏覽器正在做他們應該做的事情來解析相對URI。問題是在這種情況下，
HTML5添加了標記的src屬性的描述，以指示瀏覽器不要在4.8.2節中提出額外的請求：
src屬性必須存在，并且必須包含引用非交互式（可選動畫）圖像資源的有效URL，該資源既不是分頁也不是腳本。如果元素的基URI與文檔的地址相同，則src屬性的值不能是空字符串。希望瀏覽器將來不會出現這個問題。不幸的是，<script src =“”>和<link href =“”>沒有這樣的子句。也許還有時間進行調整以確保瀏覽器不會意外地實現此行為。
這條規則的靈感來自雅虎的JavaScript大師Nicolas C. Zakas。有關更多信息，請查看他的文章“?Empty image src can destroy your site?”。
?
英文鏈接：
Best Practices for Speeding Up Your Web Site
轉載于:https://www.cnblogs.com/princess-knight/p/9314138.html
總結
以上是生活随笔為你收集整理的优化网站性能的35条规则的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： [已解决]window下Can't co
- 下一篇： 如何实现蓝牙空中升级BLE OTA