1、最小化HTTP請求

最終用戶響應時間的80％用于前端。大部分時間都在下載頁面中的所有組件：圖像，樣式表，腳本，Flash等。減少組件數(shù)量反過來減少了呈現(xiàn)頁面所需的HTTP請求數(shù)量。這是更快頁面的關鍵。

減少頁面中組件數(shù)量的一種方法是簡化頁面設計。但有沒有辦法構建內容更豐富的頁面，同時還能實現(xiàn)快速響應時間？以下是一些減少HTTP請求數(shù)量的技術，同時仍支持豐富的頁面設計。

組合文件是一種通過將所有腳本組合到單個腳本中來減少HTTP請求數(shù)量的方法，并且類似地將所有CSS組合到單個樣式表中。當腳本和樣式表在不同頁面之間變化時，組合文件更具挑戰(zhàn)性，但是使這部分發(fā)布過程可以縮短響應時間。

CSS Sprites是減少圖像請求數(shù)量的首選方法。將背景圖像合并為單個圖像，并使用CSSbackground-image和background-position屬性顯示所需的圖像片段。

圖像地圖將多個圖像組合成單個圖像。總體大小大致相同，但減少HTTP請求的數(shù)量會加快頁面的速度。圖像映射僅在圖像在頁面中是連續(xù)的時才起作用，例如導航欄。定義圖像映射的坐標可能是乏味且容易出錯的。使用圖像地圖進行導航也無法訪問，因此不建議使用。

內聯(lián)圖像使用data:URL方案將圖像數(shù)據(jù)嵌入實際頁面中。這可以增加HTML文檔的大小。將內嵌圖像組合到（緩存的）樣式表中是一種減少HTTP請求并避免增加頁面大小的方法。所有主流瀏覽器尚不支持內嵌圖像。

減少頁面中HTTP請求的數(shù)量是可以開始的地方。這是提高首次訪問者性能的最重要指南。https://blog.csdn.net/qq_42066250/article/details/90369131，您網(wǎng)站的每日訪問者中有40-60％使用空緩存。讓這些首次訪問者快速訪問頁面是獲得更好用戶體驗的關鍵。
*

2、使用內容分發(fā)網(wǎng)絡

用戶與Web服務器的距離會對響應時間產生影響。在多個地理位置分散的服務器上部署內容將使您的頁面從用戶的角度加載更快。但是你應該從哪里開始呢？

作為實現(xiàn)地理位置分散的內容的第一步，請勿嘗試重新設計Web應用程序以在分布式體系結構中工作。根據(jù)應用程序的不同，更改體系結構可能包括令人生畏的任務，例如同步會話狀態(tài)和跨服務器位置復制數(shù)據(jù)庫事務。嘗試減少用戶與您的內容之間的距離可能會延遲或永遠不會通過此應用程序架構步驟。

請記住，最終用戶響應時間的80-90％用于下載頁面中的所有組件：圖像，樣式表，腳本，Flash等。這是Performance Golden Rule。而不是從重新設計應用程序架構的艱巨任務開始，最好首先分散您的靜態(tài)內容。這不僅可以大大縮短響應時間，而且由于內容交付網(wǎng)絡，它更容易實現(xiàn)。

內容傳送網(wǎng)絡（CDN）是分布在多個位置的Web服務器的集合，以更有效地向用戶傳送內容。選擇用于向特定用戶傳送內容的服務器通常基于網(wǎng)絡接近度的度量。例如，選擇具有最少網(wǎng)絡跳數(shù)的服務器或具有最快響應時間的服務器。

一些大型互聯(lián)網(wǎng)公司擁有自己的CDN，但使用CDN服務提供商（如Akamai Technologies，EdgeCast或level3）具有成本效益。對于初創(chuàng)公司和私人網(wǎng)站來說，CDN服務的成本可能過高，但隨著您的目標受眾變得越來越大并變得更加全球化，CDN對于實現(xiàn)快速響應時間是必要的。在Yahoo！中，將靜態(tài)內容從其應用程序Web服務器移動到CDN（如上所述的第三方以及Yahoo自己的CDN）的屬性將最終用戶響應時間提高了20％或更多。切換到CDN是一個相對容易的代碼更改，將顯著提高您的網(wǎng)站的速度。

3、添加Expires或Cache-Control標頭

這條規(guī)則有兩個方面：

對于靜態(tài)組件：通過設置遠期未來Expires標頭實現(xiàn)“永不過期”策略
對于動態(tài)組件：使用適當?shù)腃ache-Control標頭來幫助瀏覽器處理條件請求

網(wǎng)頁設計越來越豐富，這意味著頁面中有更多的腳本，樣式表，圖像和Flash。頁面的首次訪問者可能必須發(fā)出多個HTTP請求，但通過使用Expires標頭，您可以使這些組件可緩存。這避免了后續(xù)頁面視圖上不必要的HTTP請求。Expires頭文件通常與圖像一起使用，但它們應該用于所有組件，包括腳本，樣式表和Flash組件。

瀏覽器（和代理）使用緩存來減少HTTP請求的數(shù)量和大小，從而加快網(wǎng)頁加載速度。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"

Keep in mind, if you use a far future Expires header you have to change the component’s filename whenever the component changes. At Yahoo! we often make this step part of the build process: a version number is embedded in the component’s filename, for example, yahoo_2.0.6.js.

使用遠期的Expires標頭僅在用戶訪問過您的網(wǎng)站后才會影響網(wǎng)頁瀏覽量。當用戶第一次訪問您的站點并且瀏覽器的緩存為空時，它對HTTP請求的數(shù)量沒有影響。因此，此性能改進的影響取決于用戶使用已準備好的緩存命中頁面的頻率。（“已準備好的緩存”已包含頁面中的所有組件。）我們在Yahoo!上測量了這一點。并發(fā)現(xiàn)帶有固定緩存的頁面查看次數(shù)為75-85％。通過使用遠期的Expires標頭，您可以增加瀏覽器緩存的組件數(shù)量，并在后續(xù)頁面視圖中重復使用，而無需通過用戶的Internet連接發(fā)送單個字節(jié)。

4、Gzip組件

通過前端工程師做出的決策，可以顯著減少在網(wǎng)絡上傳輸HTTP請求和響應所需的時間。確實，最終用戶的帶寬速度，互聯(lián)網(wǎng)服務提供商，與對等交換點的距離等都超出了開發(fā)團隊的控制范圍。但是還有其他變量會影響響應時間。壓縮通過減小HTTP響應的大小來減少響應時間。

從HTTP / 1.1開始，Web客戶端表示支持使用HTTP請求中的Accept-Encoding標頭進行壓縮。

Accept-Encoding：gzip，deflate

如果Web服務器在請求中看到此標頭，則它可以使用客戶端列出的方法之一壓縮響應。Web服務器通過響應中的Content-Encoding標頭向Web客戶端通知此情況。

Content-Encoding：gzip

Gzip是目前最流行，最有效的壓縮方法。它由GNU項目開發(fā)，由[RFC 1952]標準化。您可能會看到的唯一其他壓縮格式是deflate，但效果較差且不太受歡迎。

Gzipping通常將響應大小減少約70％。今天大約90％的互聯(lián)網(wǎng)流量通過聲稱支持gzip的瀏覽器傳播。如果你使用Apache，配置gzip的模塊取決于你的版本：Apache 1.3使用mod_gzip而Apache 2.x使用mod_deflate。

瀏覽器和代理存在已知問題，這些問題可能導致瀏覽器期望的內容與壓縮內容相關的內容不匹配。幸運的是，隨著舊瀏覽器的使用逐漸減少，這些邊緣情況正在減少。Apache模塊通過自動添加適當?shù)腣ary響應頭來幫助解決問題。

服務器根據(jù)文件類型選擇gzip的內容，但通常在他們決定壓縮的內容上有限。大多數(shù)網(wǎng)站都會壓縮他們的HTML文檔。gzip你的腳本和樣式表也是值得的，但很多網(wǎng)站都錯過了這個機會。實際上，壓縮包括XML和JSON在內的任何文本響應都是值得的。不應對圖像和PDF文件進行gzip壓縮，因為它們已經過壓縮。試圖對它們進行gzip不僅會浪費CPU，還可能會增加文件大小。

盡可能多地壓縮文件類型是減輕頁面重量和加速用戶體驗的簡便方法。

5、將樣式表放在頂部

在研究Yahoo!的性能時，我們發(fā)現(xiàn)將樣式表移動到文檔HEAD會使頁面看起來加載速度更快。這是因為將樣式表放在HEAD中允許頁面逐步呈現(xiàn)。

關注性能的前端工程師希望頁面逐步加載; 也就是說，我們希望瀏覽器盡快顯示它擁有的任何內容。這對于具有大量內容的頁面和對較慢Internet連接的用戶尤其重要。為用戶提供視覺反饋（例如進度指示器）的重要性已得到很好的研究和記錄。在我們的例子中，HTML頁面是進度指示器！當瀏覽器逐步加載頁面時，標題，導航欄，頂部的徽標等都作為等待頁面的用戶的視覺反饋。這改善了整體用戶體驗。

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

的HTML規(guī)范明確指出，樣式表是被包括在網(wǎng)頁的HEAD：“與A，[LINK]可以僅出現(xiàn)在一個文檔的HEAD部分，盡管它可能出現(xiàn)任意次數(shù)”。這些替代品，空白的白色屏幕或無風格內容的閃光都是值得冒險的。最佳解決方案是遵循HTML規(guī)范并在文檔HEAD中加載樣式表。

6、把腳本放在底部

腳本引起的問題是它們阻止了并行下載。的HTTP / 1.1規(guī)范建議的瀏覽器下載不超過兩種組分在每主機名平行。如果您從多個主機名提供圖像，則可以并行執(zhí)行兩次以上的下載。但是，在下載腳本時，即使在不同的主機名上，瀏覽器也不會啟動任何其他下載。

在某些情況下，將腳本移到底部并不容易。例如，如果腳本用于document.write插入頁面內容的一部分，則無法在頁面中向下移動。可能還存在范圍問題。在許多情況下，有辦法解決這些問題。

經常出現(xiàn)的另一種建議是使用延遲腳本。該DEFER屬性表明該腳本不包含document.write，并且是瀏覽器可以繼續(xù)呈現(xiàn)的線索。不幸的是，Firefox不支持該DEFER屬性。在Internet Explorer中，腳本可能會延遲，但不是所需的。如果可以延遲腳本，也可以將其移動到頁面底部。這將使您的網(wǎng)頁加載速度更快。

7、避免使用CSS表達式

CSS表達式是一種動態(tài)設置CSS屬性的強大（且危險）方法。從版本5開始，它們在Internet Explorer中受支持，但從IE8開始不推薦使用。例如，可以使用CSS表達式將背景顏色設置為每小時交替：

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

如此處所示，該expression方法接受JavaScript表達式。CSS屬性設置為評估JavaScript表達式的結果。expression其他瀏覽器會忽略該方法，因此在Internet Explorer中設置屬性以在跨瀏覽器創(chuàng)建一致體驗時非常有用。

表達式的問題在于它們的評估頻率高于大多數(shù)人的預期。它們不僅在頁面呈現(xiàn)和調整大小時進行評估，而且在頁面滾動時甚至在用戶將鼠標移到頁面上時進行評估。在CSS表達式中添加計數(shù)器可以讓我們跟蹤CSS表達式的計算時間和頻率。在頁面上移動鼠標可以輕松生成10,000多個評估。

減少CSS表達式求值次數(shù)的一種方法是使用一次性表達式，其中第一次計算表達式時，它將style屬性設置為顯式值，這將替換CSS表達式。如果必須在頁面的整個生命周期中動態(tài)設置樣式屬性，則使用事件處理程序而不是CSS表達式是另一種方法。如果必須使用CSS表達式，請記住它們可能會被評估數(shù)千次，并可能影響頁面的性能。

8、使JavaScript和CSS外部

其中許多性能規(guī)則都涉及外部組件的管理方式。但是，在出現(xiàn)這些考慮因素之前，您應該提出一個更基本的問題：JavaScript和CSS是否應該包含在外部文件中，還是內嵌在頁面中？

在現(xiàn)實世界中使用外部文件通常會產生更快的頁面，因為瀏覽器會緩存JavaScript和CSS文件。每次請求HTML文檔時，都會下載HTML文檔中內聯(lián)的JavaScript和CSS。這減少了所需的HTTP請求數(shù)，但增加了HTML文檔的大小。另一方面，如果JavaScript和CSS位于瀏覽器緩存的外部文件中，則HTML文檔的大小會減少，而不會增加HTTP請求的數(shù)量。

因此，關鍵因素是外部JavaScript和CSS組件相對于請求的HTML文檔數(shù)量的緩存頻率。這個因素雖然難以量化，但可以使用各種指標進行衡量。如果您站點上的用戶每個會話有多個頁面查看，并且您的許多頁面重復使用相同的腳本和樣式表，則緩存的外部文件可能會帶來更大的潛在好處。

許多網(wǎng)站都處于這些指標的中間。對于這些站點，最佳解決方案通常是將JavaScript和CSS部署為外部文件。內聯(lián)的唯一例外是主頁，例如Yahoo！的首頁和My Yahoo! 。每個會話具有很少（可能只有一個）頁面視圖的主頁可能會發(fā)現(xiàn)內聯(lián)JavaScript和CSS會導致更快的最終用戶響應時間。

對于通常是許多頁面視圖中的第一個的首頁，有一些技術可以利用內聯(lián)提供的HTTP請求的減少，以及通過使用外部文件實現(xiàn)的緩存優(yōu)勢。其中一種技術是在首頁中內聯(lián)JavaScript和CSS，但在頁面加載完成后動態(tài)下載外部文件。后續(xù)頁面將引用應該已存在于瀏覽器緩存中的外部文件。

9、減少DNS查找

域名系統(tǒng)（DNS）將主機名映射到IP地址，就像電話簿將人們的姓名映射到他們的電話號碼一樣。當您在瀏覽器中鍵入www.yahoo.com時，瀏覽器聯(lián)系的DNS解析器將返回該服務器的IP地址。DNS有成本。DNS通常需要20-120毫秒才能查找給定主機名的IP地址。在DNS查找完成之前，瀏覽器無法從此主機名下載任何內容。

緩存DNS查找以獲得更好的性能。此緩存可以在由用戶的ISP或局域網(wǎng)維護的特殊緩存服務器上進行，但是在單個用戶的計算機上也存在緩存。DNS信息保留在操作系統(tǒng)的DNS緩存中（Microsoft Windows上的“DNS客戶端服務”）。大多數(shù)瀏覽器都有自己的緩存，與操作系統(tǒng)的緩存分開。只要瀏覽器將DNS記錄保存在自己的緩存中，它就不會因操作系統(tǒng)請求記錄而煩惱。

默認情況下，Internet Explorer會將DNS查找緩存30分鐘，具體 DnsCacheTimeout取決于注冊表設置。Firefox將DNS查詢緩存1分鐘，由network.dnsCacheExpiration配置設置控制。（Fasterfox將此更改為1小時。）

當客戶端的DNS緩存為空（對于瀏覽器和操作系統(tǒng)）時，DNS查找的數(shù)量等于網(wǎng)頁中唯一主機名的數(shù)量。這包括頁面的URL，圖像，腳本文件，樣式表，Flash對象等中使用的主機名。減少唯一主機名的數(shù)量可減少DNS查找的數(shù)量。

減少唯一主機名的數(shù)量有可能減少頁面中發(fā)生的并行下載量。避免DNS查找會縮短響應時間，但減少并行下載可能會縮短響應時間。我的準則是將這些組件分成至少兩個但不超過四個主機名。這導致在減少DNS查找和允許高度并行下載之間的良好折衷。

10、縮小JavaScript和CSS

縮小是從代碼中刪除不必要的字符以減小其大小從而縮短加載時間的做法。縮小代碼時，將刪除所有注釋，以及不需要的空格字符（空格，換行符和制表符）。在JavaScript的情況下，這改善了響應時間性能，因為下載文件的大小減小了。用于縮小JavaScript代碼的兩個流行工具是JSMin和YUI Compressor。YUI壓縮器也可以縮小CSS。

混淆是可以應用于源代碼的替代優(yōu)化。它比縮小更復雜，因此更容易因混淆步驟本身而產生錯誤。在對美國十大頂級網(wǎng)站的調查中，縮小規(guī)模縮小了21％，而混淆則縮小了25％。雖然混淆具有更高的大小減少，但縮小JavaScript的風險較小。

除了縮小外部腳本和樣式之外，內聯(lián)<script>和<\style>塊也可以并且也應該縮小。即使你gzip你的腳本和樣式，縮小它們仍然會減小5％或更多的大小。隨著JavaScript和CSS的使用和大小的增加，通過縮小代碼所節(jié)省的成本也會增加。

11、避免重定向

使用301和302狀態(tài)代碼完成重定向。以下是301響應中HTTP標頭的示例：

HTTP / 1.1 301 Moved PermanentlyLocation：http：//example.com/newuriContent-Type：text / html

瀏覽器自動將用戶帶到該Location字段中指定的URL 。重定向所需的所有信息都在標題中。響應的主體通常是空的。盡管它們的名稱，但實際上沒有緩存301或302響應，除非額外的標題，例如Expires或Cache-Control表示它應該是。元刷新標記和JavaScript是將用戶定向到不同URL的其他方法，但如果必須進行重定向，首選技術是使用標準3xx HTTP狀態(tài)代碼，主要是為了確保后退按鈕正常工作。

要記住的主要事情是重定向會降低用戶體驗。在用戶和HTML文檔之間插入重定向會延遲頁面中的所有內容，因為頁面中的任何內容都無法呈現(xiàn)，并且在HTML文檔到達之前不會開始下載任何組件。

浪費最多的重定向之一經常發(fā)生，Web開發(fā)人員通常不會意識到這一點。它發(fā)生在URL中缺少尾部斜杠（/）時，否則應該有一個斜杠。例如，轉到http://astrology.yahoo.com/astrology會產生301響應，其中包含重定向到http://astrology.yahoo.com/astrology/（注意添加的尾部斜杠）。如果您使用的是Apache處理程序，則可以使用Aliasor mod_rewrite或DirectorySlash指令在Apache中修復此問題。

將舊網(wǎng)站連接到新網(wǎng)站是重定向的另一種常見用途。其他包括連接網(wǎng)站的不同部分并根據(jù)特定條件（瀏覽器類型，用戶帳戶類型等）指導用戶。使用重定向連接兩個網(wǎng)站很簡單，只需要很少的額外編碼。雖然在這些情況下使用重定向會降低開發(fā)人員的復雜性，但會降低用戶體驗。使用重定向的替代方法包括使用Alias以及mod_rewrite兩個代碼路徑是否托管在同一服務器上。如果域名更改是使用重定向的原因，則另一種方法是創(chuàng)建CNAME（創(chuàng)建從一個域名指向另一個域名的別名的DNS記錄）與Alias或組合mod_rewrite。

12、刪除重復的腳本

在一個頁面中包含兩次相同的JavaScript文件會損害性能。這并不像你想象的那么不尋常。對美國十大頂級網(wǎng)站的評論顯示，其中兩個網(wǎng)站包含重復的腳本。兩個主要因素會增加腳本在單個網(wǎng)頁中重復的幾率：團隊規(guī)模和腳本數(shù)量。當它發(fā)生時，重復的腳本會通過創(chuàng)建不必要的HTTP請求和浪費的JavaScript執(zhí)行來損害性能。

不必要的HTTP請求在Internet Explorer中發(fā)生，但在Firefox中不發(fā)生。在Internet Explorer中，如果外部腳本包含兩次且不可緩存，則在頁面加載期間會生成兩個HTTP請求。即使腳本是可緩存的，當用戶重新加載頁面時也會發(fā)生額外的HTTP請求。

除了生成浪費的HTTP請求之外，還浪費了多次評估腳本的時間。無論腳本是否可緩存，這種冗余的JavaScript執(zhí)行都會在Firefox和Internet Explorer中執(zhí)行。

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

<script type =“text / javascript”src =“menu_1.0.17.js”> </ script>

PHP中的另一種選擇是創(chuàng)建一個名為的函數(shù)insertScript。

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

除了防止多次插入相同的腳本之外，此函數(shù)還可以處理腳本的其他問題，例如依賴性檢查和向腳本文件名添加版本號以支持遠期的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狀態(tài)代碼，從而將響應減少12195字節(jié)。

GET /i/yahoo.gif HTTP / 1.1Host：us.yimg.comIf-Modified-Since：Tue, 12 Dec 2006 03:03:59 GMTIf-None-Match：“10c24bc-4ab-457e1c1f”HTTP / 1.1 304 Not Modified

ETag的問題在于它們通常使用使其對托管站點的特定服務器唯一的屬性構建。當瀏覽器從一個服務器獲取原始組件并稍后嘗試在另一個服務器上驗證該組件時，ETag將不匹配，這種情況在使用服務器集群處理請求的網(wǎng)站上非常常見。默認情況下，Apache和IIS都在ETag中嵌入數(shù)據(jù)，這大大降低了在具有多個服務器的網(wǎng)站上成功進行有效性測試的幾率。

Apache 1.3和2.x的ETag格式是inode-size-timestamp。雖然給定文件可以跨多個服務器駐留在同一目錄中，并且具有相同的文件大小，權限，時間戳等，但它的inode從一個服務器到下一個服務器是不同的。

IIS 5.0和6.0與ETag有類似的問題。IIS上ETag的格式是Filetimestamp:ChangeNumber。A ChangeNumber是用于跟蹤IIS配置更改的計數(shù)器。ChangeNumber網(wǎng)站后面的所有IIS服務器都不太可能相同。

最終結果是Apache和IIS生成的ETag對于完全相同的組件，從一臺服務器到另一臺服務器不匹配。如果ETag不匹配，則用戶不會收到ETags設計的小的，快速的304響應; 相反，它們將獲得正常的200響應以及組件的所有數(shù)據(jù)。如果您只在一臺服務器上托管您的網(wǎng)站，這不是問題。但是如果您有多個服務器托管您的網(wǎng)站，并且您正在使用具有默認ETag配置的Apache或IIS，那么您的用戶的頁面速度會變慢，您的服務器負載會更高，您占用的帶寬會更多，代理服務器也不會有效地緩存您的內容。即使您的組件具有遠期Expires標頭，每當用戶點擊重新加載或刷新時，仍會發(fā)出條件GET請求。

如果您沒有利用ETag提供的靈活驗證模型，最好只刪除ETag。該Last-Modified頭驗證基于對組件的時間戳。刪除ETag會減少響應和后續(xù)請求中HTTP標頭的大小。此Microsoft支持文章介紹了如何刪除ETag。在Apache中，只需將以下行添加到Apache配置文件即可：

FileETag none

14、使Ajax可以緩存

Ajax的一個優(yōu)點是它向用戶提供即時反饋，因為它從后端Web服務器異步請求信息。但是，使用Ajax并不能保證用戶不會在等待那些異步JavaScript和XML響應返回時大拇指。在許多應用程序中，用戶是否保持等待取決于Ajax的使用方式。例如，在基于Web的電子郵件客戶端中，用戶將一直等待Ajax請求的結果，以查找符合其搜索條件的所有電子郵件。重要的是要記住“異步”并不意味著“瞬時”。

為了提高性能，優(yōu)化這些Ajax響應非常重要。提高Ajax性能的最重要方法是使響應可緩存，如添加過期或緩存控制標頭中所述。其他一些規(guī)則也適用于Ajax：

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

我們來看一個例子。Web 2.0電子郵件客戶端可能使用Ajax下載用戶的通訊簿以進行自動完成。如果用戶自上次使用電子郵件Web應用程序以來未修改過她的地址簿，則可以從緩存中讀取先前的地址簿響應，如果該Ajax響應可以使用將來的Expires或Cache-Control標頭進行緩存。必須通知瀏覽器何時使用先前緩存的地址簿響應而不是請求新的地址簿響應。這可以通過向地址簿Ajax URL添加時間戳來完成，該時間戳指示用戶上次修改其地址簿的時間，例如，&t=1190241612。如果自上次下載后地址簿未被修改，則時間戳將相同，并且將從瀏覽器的緩存中讀取地址簿，從而消除額外的HTTP往返。如果用戶修改了地址簿，則時間戳確保新URL與緩存的響應不匹配，并且瀏覽器將請求更新的地址簿條目。

即使您的Ajax響應是動態(tài)創(chuàng)建的，并且可能僅適用于單個用戶，它們仍然可以緩存。這樣做可以使您的Web 2.0應用程序更快。

15、提前刷新緩沖區(qū)

當用戶請求頁面時，后端服務器可能需要200到500毫秒的時間來縫合HTML頁面。在此期間，瀏覽器在等待數(shù)據(jù)到達時處于空閑狀態(tài)。在PHP中，函數(shù)flush()。它允許您將部分準備好的HTML響應發(fā)送到瀏覽器，以便瀏覽器可以在后端忙于處理HTML頁面的其余部分時開始獲取組件。這種好處主要體現(xiàn)在繁忙的后端或輕前端。
一個考慮刷新的好地方是頭部之后，因為頭部的HTML通常更容易生成，而且它允許您包含任何CSS和JavaScript文件，以便瀏覽器在后臺仍在處理時開始并行獲取。

Example:... <!-- css, js --></head><?php flush(); ?><body>... <!-- content -->

雅虎搜索開創(chuàng)了研究和真實用戶測試的先機，以證明使用這種技術的好處。

16、對AJAX請求使用GET

Yahoo !郵件團隊發(fā)現(xiàn)，當使用XMLHttpRequest時，POST在瀏覽器中實現(xiàn)為一個兩步過程:首先發(fā)送頭部，然后發(fā)送數(shù)據(jù)。所以最好使用GET，它只需要發(fā)送一個TCP包(除非您有很多cookie)。IE的最大URL長度是2K，所以如果你發(fā)送超過2K的數(shù)據(jù)，你可能無法使用GET。

一個有趣的副作用是，在沒有實際發(fā)布任何數(shù)據(jù)的情況下，POST的行為類似GET。根據(jù)HTTP規(guī)范，GET用于檢索信息，因此在只請求數(shù)據(jù)而不是發(fā)送要存儲在服務器端的數(shù)據(jù)時使用GET(語義上)是有意義的。

17、后加載組件

你可以仔細看看你的頁面，問問你自己:“最初呈現(xiàn)頁面絕對需要什么?”其余的內容和組件可以等待。

JavaScript是在onload事件之前和之后拆分的理想候選者。例如，如果您有執(zhí)行拖放和動畫的JavaScript代碼和庫，那么可以等待，因為在初始渲染之后拖動頁面上的元素。其他尋找后期加載候選者的地方包括隱藏內容（用戶操作后顯示的內容）和首屏下方的圖像。

幫助您完成工作的工具:YUI image loader 允許您延遲折疊下方的圖像，YUI Get實用程序是一種動態(tài)包含JS和CSS的簡單方法。舉個野外的例子，看看雅虎吧!打開Firebug的Net面板的主頁。

當性能目標與其他web開發(fā)最佳實踐內聯(lián)時，這是很好的。在這種情況下，漸進式增強的思想告訴我們，JavaScript在受到支持時可以改善用戶體驗，但必須確保即使沒有JavaScript頁面也能正常工作。因此，在確保頁面正常工作之后，可以使用一些加載后的腳本來增強它，這些腳本可以提供更多的功能，比如拖放和動畫。

18、預加載組件

預加載可能看起來與后加載相反，但它實際上有不同的目標。通過預加載組件，您可以利用瀏覽器空閑的時間并請求將來需要的組件（如圖像，樣式和腳本）。這樣，當用戶訪問下一頁時，您可以將大部分組件放在緩存中，并且您的頁面將為用戶加載更快。

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

• 無條件預加載 -
  只要onload觸發(fā)，你就可以繼續(xù)獲取一些額外的組件。請訪問google.com，了解如何請求加載精靈圖像。google.com主頁上不需要此精靈圖片，但在連續(xù)搜索結果頁面上需要此精靈圖片。
• 條件預加載 -
  基于用戶操作，您可以進行有根據(jù)的猜測，即用戶前進的位置并相應地預加載。在search.yahoo.com上，您可以看到在輸入框中開始輸入后如何請求一些額外的組件。
• 預期的預加載 -
  在重新設計之前提前預加載。經常在重新設計之后聽到：“新網(wǎng)站很酷，但比以前慢”。部分問題可能是用戶使用完整緩存訪問舊網(wǎng)站，但新網(wǎng)站始終是空緩存體驗。您可以通過在啟動重新設計之前預加載某些組件來緩解此副作用。您的舊站點可以使用瀏覽器空閑的時間并請求新站點將使用的圖像和腳本

18、減少DOM元素的數(shù)量

復雜頁面意味著要下載更多字節(jié)，這也意味著JavaScript中的DOM訪問速度更慢。如果您想要添加事件處理程序，例如，在頁面上循環(huán)500或5000個DOM元素，則會有所不同。

大量的DOM元素可能是一個癥狀，即應該通過頁面標記來改進，而不必刪除內容。您是否使用嵌套表進行布局？你是否

只是為了解決布局問題而投入更多？也許有一種更好，更語義正確的標記方式。

YUI CSS實用程序 提供了很好的布局幫助：grids.css可以幫助您完成整體布局，fonts.css和reset.css可以幫助您去除瀏覽器的默認格式。這是一個重新開始并考慮你的標記的機會，例如

只有在語義上有意義時才使用s，而不是因為它呈現(xiàn)一個新行。

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

有多少DOM元素太多了？檢查具有良好標記的其他類似頁面。例如雅虎！主頁是一個非常繁忙的頁面，仍然不到700個元素（HTML標記）。

19、跨域拆分組件

拆分組件允許您最大化并行下載。由于DNS查詢懲罰，請確保您使用的域名不超過2-4個。例如，您可以托管HTML和動態(tài)內容，www.example.org 并在static1.example.org和之間拆分靜態(tài)組件static2.example.org

有關更多信息，請查看Tenni Theurer和Patty Chi的“ 在Carpool Lane中最大化并行下載 ”。

20、最小化iframe的數(shù)量

iframe允許將HTML文檔插入父文檔中。了解iframe如何運作以便有效使用非常重要。

優(yōu)點：

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

缺點：

• 即使空白，也非常消耗
• 塊頁面裝載
• 非語義

21、沒有404

HTTP請求很昂貴，因此發(fā)出HTTP請求并獲得無用的響應（即404 Not Found）是完全沒必要的，并且會在沒有任何好處的情況下減慢用戶體驗。

有些網(wǎng)站有幫助404“你的意思是X？”，這對用戶體驗很有好處，但也浪費了服務器資源（比如數(shù)據(jù)庫等）。特別糟糕的是當外部JavaScript的鏈接錯誤并且結果是404時。首先，此下載將阻止并行下載。接下來，瀏覽器可能會嘗試解析404響應主體，就像它是JavaScript代碼一樣，試圖找到可用的東西。

22、減少Cookie大小

HTTP cookie的使用有多種原因，例如身份驗證和個性化。有關cookie的信息在Web服務器和瀏覽器之間的HTTP標頭中進行交換。保持cookie的大小盡可能低是非常重要的，以盡量減少對用戶響應時間的影響。

欲了解更多信息，請查看 Tenni Theurer和Patty Chi撰寫的“當Cookie崩潰時”。這項研究的主要內容：

• 消除不必要的cookie
• 保持cookie大小盡可能低，以盡量減少對用戶響應時間的影響
• 請注意在適當?shù)挠蚣墑e設置cookie，以免其他子域受到影響
• 適當?shù)卦O置過期日期。較早的Expires日期或者沒有更早刪除cookie，從而改善了用戶響應時間

23、對組件使用無Cookie域

當瀏覽器發(fā)出靜態(tài)圖像請求并將cookie與請求一起發(fā)送時，服務器對這些cookie沒有任何用處。因此，他們只會毫無理由地創(chuàng)建網(wǎng)絡流量。您應該確保使用無cookie請求請求靜態(tài)組件。創(chuàng)建一個子域并在那里托管所有靜態(tài)組件。

如果您的域名是www.example.org，您可以托管您的靜態(tài)組件static.example.org。但是，如果您已經在頂級域上設置了cookie example.org而不是www.example.org，則所有請求都 static.example.org將包含這些cookie。在這種情況下，您可以購買一個全新的域，在那里托管您的靜態(tài)組件，并保持此域無cookie。雅虎 用途yimg.com，YouTube使用ytimg.com，亞馬遜使用images-amazon.com等。

在無cookie域上托管靜態(tài)組件的另一個好處是，某些代理可能拒絕緩存使用cookie請求的組件。在相關說明中，如果您想知道是否應該使用example.org或www.example.org作為主頁，請考慮cookie的影響。省略www會讓您別無選擇，只能寫入cookie *.example.org，因此出于性能原因，最好使用www子域并將cookie寫入該子域。

24、最小化DOM訪問

使用JavaScript訪問DOM元素的速度很慢，因此為了獲得響應更快的頁面，您應該：

緩存對訪問元素的引用
更新節(jié)點“離線”，然后將它們添加到樹中
避免使用JavaScript修復布局
有關更多信息，請查看 Julien Lecomte 的YUI影院的 “高性能Ajax應用程序”。

25、開發(fā)智能事件處理程序

有時頁面感覺響應性較差，因為過多的事件處理程序附加到DOM樹的不同元素，然后執(zhí)行得太頻繁。這就是為什么使用事件委托是一個很好的方法。如果a中有10個按鈕div，則只將一個事件處理程序附加到div包裝器，而不是每個按鈕一個處理程序。事件冒出來，這樣你就可以捕捉事件并找出它來自哪個按鈕。

您也不需要等待onload事件才能開始使用DOM樹。通常，您只需要在樹中訪問要訪問的元素。您不必等待下載所有圖像。 DOMContentLoaded是您可能考慮使用的事件而不是onload，但在所有瀏覽器中都可用之前，您可以使用具有方法的YUI事件實用程序onAvailable。

有關更多信息，請查看 Julien Lecomte 的YUI影院的 “高性能Ajax應用程序”。

26、在@import上選擇<link>

之前的最佳實踐之一聲明CSS應位于頂部以便允許漸進式渲染。

在IE中，@import行為與在頁面底部使用的行為相同，因此最好不要使用它。

27、避免過濾器

IE專有的AlphaImageLoader過濾器旨在解決IE版本<7中的半透明真彩色PNG的問題。該過濾器的問題在于它在下載圖像時阻止渲染并凍結瀏覽器。它還會增加內存消耗并按每個元素應用，而不是按圖像應用，因此問題會成倍增加。

最好的方法是AlphaImageLoader完全避免使用優(yōu)雅降級的PNG8，這在IE中很好。如果你絕對需要AlphaImageLoader，使用下劃線黑客_filter不會懲罰你的IE7 +用戶。

28、優(yōu)化圖像

設計人員完成為您的網(wǎng)頁創(chuàng)建圖像后，在將這些圖像FTP到Web服務器之前，仍然可以嘗試一些操作。

• 您可以檢查GIF并查看它們是否使用與圖像中顏色數(shù)對應的調色板大小。使用imagemagick很容易檢查 identify
  -verbose image.gif 當你在調色板中看到使用4種顏色和256色“槽”的圖像時，還有改進的余地。
• 嘗試將GIF轉換為PNG并查看是否存在保存。通常，有。由于瀏覽器的支持有限，開發(fā)人員經常對使用PNG猶豫不決，但現(xiàn)在已成為過去。唯一真正的問題是真彩色PNG中的alpha透明度，但同樣，GIF不是真彩色，也不支持變量透明度。所以GIF可以做的任何事情，調色板PNG（PNG8）也可以做（除了動畫）。這個簡單的imagemagick命令導致完全安全的PNG：
  convert image.gif image.png “我們所說的只是：給PiNG一個機會！”
• 在所有PNG上 運行pngcrush（或任何其他PNG優(yōu)化工具）。例： pngcrush image.png -rem alla
  -reduce -brute result.png
• 在所有JPEG上運行jpegtran。此工具執(zhí)行無損JPEG操作（如旋轉），還可用于優(yōu)化和刪除圖像中的注釋和其他無用信息（如EXIF信息）。
  jpegtran -copy none -optimize -perfect src.jpg dest.jpg

29、優(yōu)化CSS Sprites

• 將圖像水平排列在精靈中而不是垂直排列通常會導致文件較小。
• 在精靈中組合相似的顏色可以幫助您保持較低的顏色數(shù)，理想情況下在256色以下，以適應PNG8。
• “適合移動設備”并且不要在精靈中留下大的間隙。這不會影響文件大小，但需要較少的內存以便用戶代理將圖像解壓縮為像素圖。100x100圖像是1萬像素，其中1000x1000是100萬像素

30、不要在HTML中縮放圖像

不要使用比您需要的更大的圖像，因為您可以在HTML中設置寬度和高度。如果您需要，

<img width="100" height="100" src="mycat.jpg" alt="My Cat" />

那么您的圖像（mycat.jpg）應該是100x100px而不是縮小的500x500px圖像。

31、使favicon.ico小巧且可緩存

favicon.ico是一個保留在服務器根目錄中的映像。這是一個必要的邪惡，因為即使你不關心它，瀏覽器仍然會請求它，所以最好不要回復404 Not Found。此外，由于它位于同一臺服務器上，因此每次請求時都會發(fā)送cookie。此圖像也會干擾下載順序，例如在IE中，當您在onload中請求額外組件時，將在這些額外組件之前下載favicon。

因此，為了減輕擁有favicon.ico的弊端，請確保：

它很小，最好不到1K。
使用您感覺舒適的設置Expires標頭（因為如果您決定更改它，則無法重命名）。您可以在將來幾個月安全地設置Expires標頭。您可以查看當前favicon.ico的上次修改日期，以做出明智的決定。
Imagemagick可以幫助您創(chuàng)建小的favicon

32、保持組件低于25K

此限制與iPhone不會緩存大于25K的組件這一事實有關。請注意，這是未壓縮的大小。這是縮小很重要的地方，因為單獨使用gzip可能還不夠。

欲了解更多信息，請查看Wayne Shea和Tenni Theurer的“ 性能研究，第5部分：iPhone可緩存性 - 讓它堅持下去 ”。

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

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

34、避免空圖像src

帶有空字符串src屬性的圖像會出現(xiàn)多個預期。它以兩種形式出現(xiàn)：

直接的HTML
<img src =“”>
JavaScript的
var img = new Image（）;
\img.src =“”;
兩種形式都會產生相同的效果：瀏覽器向您的服務器發(fā)出另一個請求

Internet Explorer向頁面所在的目錄發(fā)出請求。
Safari和Chrome會向實際頁面提出請求。
Firefox 3及更早版本的行為與Safari和Chrome相同，但3.5版解決了此問題[bug 444931]并且不再發(fā)送請求。
當遇到空圖像src時，Opera不執(zhí)行任何操作。

為什么這種行為不好？

通過發(fā)送大量意外流量來削弱您的服務器，特別是對于每天獲得數(shù)百萬頁面瀏覽量的頁面。
廢棄服務器計算周期生成永遠不會被查看的頁面。
可能會損壞用戶數(shù)據(jù)。如果您通過cookie或其他方式跟蹤請求中的狀態(tài)，則可能會破壞數(shù)據(jù)。即使圖像請求沒有返回圖像，瀏覽器也會讀取并接受所有標頭，包括所有cookie。雖然其余的響應被丟棄，但損害可能已經完成。

此行為的根本原因是在瀏覽器中執(zhí)行URI解析的方式。此行為在RFC 3986 - 統(tǒng)一資源標識符中定義。當遇到空字符串作為URI時，它被視為相對URI，并根據(jù)5.2節(jié)中定義的算法進行解析。這個具體的例子是一個空字符串，在5.4節(jié)中列出。Firefox，Safari和Chrome都按照規(guī)范正確解析空字符串，而Internet Explorer正在解析它，顯然符合規(guī)范的早期版本RFC 2396 - 統(tǒng)一資源標識符（這已被RFC 3986淘汰） 。從技術上講，瀏覽器正在做他們應該做的事情來解析相對URI。問題是在這種情況下，

HTML5添加了標記的src屬性的描述，以指示瀏覽器不要在4.8.2節(jié)中提出額外的請求：

src屬性必須存在，并且必須包含引用非交互式（可選動畫）圖像資源的有效URL，該資源既不是分頁也不是腳本。如果元素的基URI與文檔的地址相同，則src屬性的值不能是空字符串。
希望瀏覽器將來不會出現(xiàn)這個問題。不幸的是，<script src =“”>和<link href =“”>沒有這樣的子句。也許還有時間進行調整以確保瀏覽器不會意外地實現(xiàn)此行為。
這條規(guī)則的靈感來自雅虎的JavaScript大師Nicolas C. Zakas。有關更多信息，請查看他的文章“ 空圖像src可以破壞您的網(wǎng)站 ”。

本文章翻譯與: https://developer.yahoo.com/performance/rules.html?guccounter=1#expires

總結

以上是生活随笔為你收集整理的雅虎40个优化策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。