最新博客站點(diǎn)：歡迎來訪

1. 最小化HTTP請(qǐng)求次數(shù)

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

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

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

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

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

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

　　減少頁面中HTTP請(qǐng)求的數(shù)量是可以開始的地方。這是提高首次訪問者性能的最重要指南。正如Tenni Theurer的博客文章瀏覽器緩存使用 - 暴露！，您網(wǎng)站的每日訪問者中有40-60％使用空緩存。讓這些首次訪問者快速訪問頁面是獲得更好用戶體驗(yàn)的關(guān)鍵。

2. 使用內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）

? ? ? ?用戶與Web服務(wù)器的距離會(huì)對(duì)響應(yīng)時(shí)間產(chǎn)生影響。在多個(gè)地理位置分散的服務(wù)器上部署內(nèi)容將使您的頁面從用戶的角度加載更快。但是你應(yīng)該從哪里開始呢？

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

　　請(qǐng)記住，最終用戶響應(yīng)時(shí)間的80-90％用于下載頁面中的所有組件：圖像，樣式表，腳本，Flash等。這是性能黃金規(guī)則。而不是從重新設(shè)計(jì)應(yīng)用程序架構(gòu)的艱巨任務(wù)開始，最好先分散靜態(tài)內(nèi)容。這不僅可以縮短響應(yīng)時(shí)間，而且由于內(nèi)容交付網(wǎng)絡(luò)，它更容易實(shí)現(xiàn)。

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

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

3. 添加Expires或Cache-Control標(biāo)頭

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

• 對(duì)于靜態(tài)組件：通過設(shè)置遠(yuǎn)期未來Expires標(biāo)頭實(shí)現(xiàn)“永不過期”策略
• 對(duì)于動(dòng)態(tài)組件：使用適當(dāng)?shù)腃ache-Control標(biāo)頭來幫助瀏覽器處理?xiàng)l件請(qǐng)求

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

瀏覽器（和代理）使用緩存來減少HTTP請(qǐng)求的數(shù)量和大小，從而加快網(wǎng)頁加載速度。Web服務(wù)器使用HTTP響應(yīng)中的Expires頭來告訴客戶端可以緩存組件多長(zhǎng)時(shí)間。這是一個(gè)遙遠(yuǎn)的未來Expires標(biāo)題，告訴瀏覽器這個(gè)響應(yīng)在2010年4月15日之前不會(huì)過時(shí)。

Expires: Thu, 15 Apr 2010 20:00:00 GMT

? ? ? ?如果您的服務(wù)器是Apache，請(qǐng)使用ExpiresDefault指令設(shè)置相對(duì)于當(dāng)前日期的到期日期。ExpiresDefault指令的這個(gè)示例將Expires日期設(shè)置為距請(qǐng)求時(shí)間10年。

ExpiresDefault "access plus 10 years"

? ? ? ?請(qǐng)記住，如果您使用遠(yuǎn)期的Expires標(biāo)頭，則必須在組件更改時(shí)更改組件的文件名。在Yahoo!?我們經(jīng)常將此步驟作為構(gòu)建過程的一部分：版本號(hào)嵌入在組件的文件名中，例如，yahoo_2.0.6.js。

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

? ? ? ?4. 使用Gzip組件

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

從HTTP / 1.1開始，Web客戶端表示支持使用HTTP請(qǐng)求中的Accept-Encoding標(biāo)頭進(jìn)行壓縮。

Accept-Encoding：gzip，deflate

? ? ? ?如果Web服務(wù)器在請(qǐng)求中看到此標(biāo)頭，它可能會(huì)使用客戶端列出的方法之一壓縮響應(yīng)。Web服務(wù)器通過響應(yīng)中的Content-Encoding標(biāo)頭向Web客戶端通知此情況。

Content-Encoding：gzip

? ? ? ?Gzip是目前最流行，最有效的壓縮方法。它由GNU項(xiàng)目開發(fā)，并由RFC 1952標(biāo)準(zhǔn)化。您可能會(huì)看到的唯一其他壓縮格式是deflate，但效果較差且不太受歡迎。

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

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

? ? ? ?服務(wù)器根據(jù)文件類型選擇gzip的內(nèi)容，但通常在他們決定壓縮的內(nèi)容方面受到限制。大多數(shù)網(wǎng)站都會(huì)gzip他們的HTML文檔。gzip你的腳本和樣式表也是值得的，但很多網(wǎng)站都錯(cuò)過了這個(gè)機(jī)會(huì)。實(shí)際上，壓縮包括XML和JSON在內(nèi)的任何文本響應(yīng)都是值得的。不應(yīng)對(duì)圖像和PDF文件進(jìn)行g(shù)zip壓縮，因?yàn)樗鼈円呀?jīng)過壓縮。試圖對(duì)它們進(jìn)行g(shù)zip不僅浪費(fèi)CPU，而且可能會(huì)增加文件大小。

? ? ? ?盡可能多地壓縮文件類型是減輕頁面重量和加速用戶體驗(yàn)的簡(jiǎn)便方法。

? ? ? ?5. 將CSS樣式表放在頂部

? ? ? ?在研究Yahoo!的性能時(shí)，我們發(fā)現(xiàn)將樣式表移動(dòng)到文檔HEAD會(huì)使頁面看起來加載速度更快。這是因?yàn)閷邮奖矸旁贖EAD中允許頁面逐步呈現(xiàn)。

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

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

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

? ? ? ?6. 將JavaScript腳本放在底部

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

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

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

? ? ? ?7. 避免使用CSS中的expressions

? ? ? ?CSS表達(dá)式是一種動(dòng)態(tài)設(shè)置CSS屬性的強(qiáng)大（且危險(xiǎn)）方法。從版本5開始，它們?cè)贗nternet Explorer中受支持，但從IE8開始不推薦使用。例如，可以使用CSS表達(dá)式將背景顏色設(shè)置為每小時(shí)交替：??

background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

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

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

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

? ? ? ?8. 將JavaScript和CSS獨(dú)立成外部文件

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

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

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

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

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

? ? ? ?9. 減少DNS查詢

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

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

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

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

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

? ? ? ?10. 壓縮JavaScript和CSS(包括內(nèi)聯(lián)<script>和<style>)

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

　　混淆是可以應(yīng)用于源代碼的替代優(yōu)化。它比壓縮更復(fù)雜，因此更容易因混淆步驟本身而產(chǎn)生錯(cuò)誤。在對(duì)美國(guó)十大頂級(jí)網(wǎng)站的調(diào)查中，壓縮規(guī)模縮小了21％，而混淆縮小了25％。盡管混淆具有更高的大小縮減，但壓縮JavaScript的風(fēng)險(xiǎn)較小。

　　除了壓縮外部腳本和樣式之外，內(nèi)聯(lián)<script>和<style>塊也可以并且也應(yīng)該壓縮。即使你gzip你的腳本和樣式，壓縮它們?nèi)匀粫?huì)減小5％或更多的大小。隨著JavaScript和CSS的使用和大小的增加，壓縮代碼所節(jié)省的成本也會(huì)增加。

? ? ? ?11. 避免重定向

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

HTTP/1.1 301 Moved Permanently Location: http://example.com/newuri Content-Type: text/html

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

　　要記住的主要事情是重定向會(huì)降低用戶體驗(yàn)。在用戶和HTML文檔之間插入重定向會(huì)延遲頁面中的所有內(nèi)容，因?yàn)轫撁嬷械娜魏蝺?nèi)容都無法呈現(xiàn)，并且在HTML文檔到達(dá)之前不會(huì)開始下載任何組件。

　　最浪費(fèi)的重定向之一經(jīng)常發(fā)生，Web開發(fā)人員通常不了解它。當(dāng)URL中缺少尾部斜杠（/）時(shí)會(huì)發(fā)生這種情況。例如，轉(zhuǎn)到http://astrology.yahoo.com/astrology會(huì)產(chǎn)生301響應(yīng)，其中包含重定向到http://astrology.yahoo.com/astrology/（注意添加的尾部斜杠）。如果您使用的是Apache處理程序，則可以使用Alias 或?mod_rewrite 或?DirectorySlash指令在Apache中修復(fù)此問題。

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

? ? ? ?12. 刪除重復(fù)的腳本

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

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

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

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

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

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

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

　　除了防止多次插入相同的腳本之外，此函數(shù)還可以處理腳本的其他問題，例如依賴性檢查和向腳本文件名添加版本號(hào)以支持遠(yuǎn)期的Expires頭。

? ? ? ?13. 配置實(shí)體標(biāo)記ETag

　　實(shí)體標(biāo)記（ETag）是Web服務(wù)器和瀏覽器用于確定瀏覽器緩存中的組件是否與源服務(wù)器上的組件匹配的機(jī)制。（“實(shí)體”是另一個(gè)詞“組件”：圖像，腳本，樣式表等）。添加ETag以提供驗(yàn)證比上次修改日期更靈活的實(shí)體的機(jī)制。ETag是唯一標(biāo)識(shí)組件的特定版本的字符串。唯一的格式約束是引用字符串。源服務(wù)器使用ETag響應(yīng)頭指定組件的ETag?。

HTTP/1.1 200 OKLast-Modified: Tue, 12 Dec 2006 03:03:59 GMTETag: "10c24bc-4ab-457e1c1f"Content-Length: 12195

　　之后，如果瀏覽器必須驗(yàn)證組件，它將使用If-None-Match標(biāo)頭將ETag傳遞回原始服務(wù)器。如果ETag匹配，則返回304狀態(tài)代碼，從而將響應(yīng)減少12195字節(jié)。

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的問題在于它們通常使用屬性構(gòu)建，這些屬性使它們對(duì)托管站點(diǎn)的特定服務(wù)器是唯一的。當(dāng)瀏覽器從一個(gè)服務(wù)器獲取原始組件并稍后嘗試在不同服務(wù)器上驗(yàn)證該組件時(shí)，ETag將不匹配，這種情況在使用服務(wù)器集群處理請(qǐng)求的網(wǎng)站上非常常見。默認(rèn)情況下，Apache和IIS都在ETag中嵌入數(shù)據(jù)，這大大降低了在具有多個(gè)服務(wù)器的網(wǎng)站上成功進(jìn)行有效性測(cè)試的幾率。

　　Apache 1.3和2.x的ETag格式是inode-size-timestamp。雖然給定文件可以跨多個(gè)服務(wù)器駐留在同一目錄中，并且具有相同的文件大小，權(quán)限，時(shí)間戳等，但它的inode在服務(wù)器與下一個(gè)服務(wù)器之間是不同的。

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

　　最終結(jié)果是Apache和IIS生成的ETag對(duì)于完全相同的組件從一臺(tái)服務(wù)器到另一臺(tái)服務(wù)器不匹配。如果ETag不匹配，則用戶不會(huì)收到ETag設(shè)計(jì)的小的，快速的304響應(yīng);?相反，他們將獲得正常的200響應(yīng)以及組件的所有數(shù)據(jù)。如果您只在一臺(tái)服務(wù)器上托管您的網(wǎng)站，這不是問題。但是，如果您有多個(gè)服務(wù)器托管您的網(wǎng)站，并且您正在使用具有默認(rèn)ETag配置的Apache或IIS，則您的用戶正在變慢頁面，您的服務(wù)器負(fù)載更高，您正在消耗更大的帶寬，并且代理服務(wù)器沒有有效地緩存您的內(nèi)容。即使您的組件具有遠(yuǎn)期Expires標(biāo)頭，每當(dāng)用戶點(diǎn)擊重新加載或刷新時(shí)，仍會(huì)發(fā)出條件GET請(qǐng)求。

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

FileETag none

? ? ? ?14. 使Ajax可以緩存

　　Ajax的一個(gè)優(yōu)點(diǎn)是它為用戶提供即時(shí)反饋，因?yàn)樗鼜暮蠖薟eb服務(wù)器異步請(qǐng)求信息。但是，使用Ajax并不能保證用戶不會(huì)在等待那些異步JavaScript和XML響應(yīng)返回時(shí)大拇指。在許多應(yīng)用程序中，用戶是否保持等待取決于Ajax的使用方式。例如，在基于Web的電子郵件客戶端中，用戶將一直等待Ajax請(qǐng)求的結(jié)果，以查找符合其搜索條件的所有電子郵件。重要的是要記住“異步”并不意味著“瞬時(shí)”。

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

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

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

　　即使您的Ajax響應(yīng)是動(dòng)態(tài)創(chuàng)建的，并且可能僅適用于單個(gè)用戶，它們?nèi)匀豢梢跃彺妗＿@樣做可以使您的Web 2.0應(yīng)用程序更快。

? ? ? ?15. 盡早清除緩沖區(qū)

　　當(dāng)用戶請(qǐng)求頁面時(shí)，后端服務(wù)器可能需要200到500毫秒才能將HTML頁面拼接在一起。在此期間，瀏覽器在等待數(shù)據(jù)到達(dá)時(shí)處于空閑狀態(tài)。在PHP中，您有函數(shù)flush（）。它允許您將部分準(zhǔn)備好的HTML響應(yīng)發(fā)送到瀏覽器，以便瀏覽器可以在后端忙于HTML頁面的其余部分時(shí)開始獲取組件。這種好處主要出現(xiàn)在繁忙的后端或輕量級(jí)前端。

　　考慮刷新的好地方就在HEAD之后，因?yàn)轭^部的HTML通常更容易生成，并且它允許您包含任何CSS和JavaScript文件，以便瀏覽器在后端處理時(shí)并行地開始獲取。

例：

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

　　雅虎?搜索開創(chuàng)性研究和真實(shí)用戶測(cè)試，以證明使用此技術(shù)的好處。

? ? ? ?16. 使用GET進(jìn)行Ajax請(qǐng)求

　　在雅虎?郵件團(tuán)隊(duì)發(fā)現(xiàn)，在使用時(shí)XMLHttpRequest，POST在瀏覽器中實(shí)現(xiàn)為兩步過程：首先發(fā)送標(biāo)頭，然后發(fā)送數(shù)據(jù)。因此最好使用GET，它只需要一個(gè)TCP數(shù)據(jù)包發(fā)送（除非你有很多cookie）。IE中的最大URL長(zhǎng)度為2K，因此如果發(fā)送的數(shù)據(jù)超過2K，則可能無法使用GET。

　　一個(gè)有趣的副作用是沒有實(shí)際發(fā)布任何數(shù)據(jù)的POST就像GET一樣。根據(jù)HTTP規(guī)范，GET用于檢索信息，因此當(dāng)您僅請(qǐng)求數(shù)據(jù)時(shí)，使用GET是有意義的（語義上），而不是將數(shù)據(jù)發(fā)送到服務(wù)器端存儲(chǔ)。

? ? ? ?17. 延遲加載組件

　　您可以仔細(xì)查看您的頁面并問自己：“頁面最初渲染必要的是什么？”。其余的內(nèi)容和組件可以等待。

　　JavaScript是在onload事件之前和之后拆分的理想候選者。例如，如果您有執(zhí)行拖放和動(dòng)畫的JavaScript代碼和庫，則可以等待，因?yàn)樵诔跏间秩局笸蟿?dòng)頁面上的元素。其他尋找后期加載候選者的地方包括隱藏內(nèi)容（用戶操作后顯示的內(nèi)容）和首屏下方的圖像。

　　幫助您完成工作的工具：YUI Image Loader允許您將圖像延遲到折疊下方，YUI Get實(shí)用程序是一種簡(jiǎn)單的方法，可以動(dòng)態(tài)地包含JS和CSS。在野外的例子看看雅虎！打開Firebug網(wǎng)絡(luò)面板的主頁。

　　當(dāng)性能目標(biāo)與其他Web開發(fā)最佳實(shí)踐一致時(shí)，這是很好的。在這種情況下，漸進(jìn)增強(qiáng)的想法告訴我們，JavaScript在受支持時(shí)可以改善用戶體驗(yàn)，但您必須確保即使沒有JavaScript也能正常工作。因此，在確保頁面正常工作之后，您可以使用一些后期加載的腳本來增強(qiáng)它，這些腳本可以為您提供更多的花俏功能，例如拖放和動(dòng)畫。

? ? ? ?18. 預(yù)加載組件

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

　　實(shí)際上有幾種類型的預(yù)加載：

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

? ? ? ?19. 減少DOM元素的數(shù)量

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

　　大量的DOM元素可能是一種通癥，即應(yīng)該通過頁面標(biāo)記來改進(jìn)，而不必刪除內(nèi)容。您是否使用嵌套表進(jìn)行布局？您是否只是為了解決布局問題而投入更多<div>？也許有一種更好，語義更正確的標(biāo)記方式。

　　YUI CSS實(shí)用程序?提供了很好的布局幫助：grids.css可以幫助您完成整體布局，fonts.css和reset.css可以幫助您去除瀏覽器的默認(rèn)格式。這是一個(gè)重新開始并考慮標(biāo)記的機(jī)會(huì)，例如，<div>只有在語義上有意義時(shí)才使用s，而不是因?yàn)樗尸F(xiàn)新行。

　　DOM元素的數(shù)量很容易測(cè)試，只需鍵入Firebug的控制臺(tái)：

document.getElementsByTagName('*').length

　　那到底有多少DOM元素才算少？檢查具有良好標(biāo)記的其他類似頁面。例如雅虎！主頁是一個(gè)非常繁忙的頁面，仍然不到700個(gè)元素（HTML標(biāo)記）。

? ? ? ?20. 跨域拆分組件

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

　　有關(guān)更多信息，請(qǐng)查看Tenni Theurer和Patty Chi的“?在Carpool Lane中最大化并行下載?”。

? ? ? ?21. 最小化iframe數(shù)量

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

　　<iframe>?優(yōu)點(diǎn)：

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

　　<iframe>?缺點(diǎn)：

• 即使空白也要花錢
• 阻止頁面onload
• 非語義

? ? ? ?22. 不用404s

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

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

? ? ? ?23. 減小Cookie大小

　　HTTP cookie的使用有多種原因，例如身份驗(yàn)證和個(gè)性化。有關(guān)cookie的信息在Web服務(wù)器和瀏覽器之間的HTTP標(biāo)頭中進(jìn)行交換。保持cookie的大小盡可能低是非常重要的，以盡量減少對(duì)用戶響應(yīng)時(shí)間的影響。

　　欲了解更多信息，請(qǐng)查看?Tenni Theurer和Patty Chi撰寫的“當(dāng)Cookie崩潰時(shí)”。這項(xiàng)研究的主要內(nèi)容：

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

? ? ? ?24. 對(duì)組建使用cookie-free的域名

　　當(dāng)瀏覽器發(fā)出靜態(tài)圖像請(qǐng)求并將cookie與請(qǐng)求一起發(fā)送時(shí)，服務(wù)器對(duì)這些cookie沒有任何用處。所以他們只是沒有充分理由創(chuàng)建網(wǎng)絡(luò)流量。您應(yīng)該確保使用無cookie請(qǐng)求請(qǐng)求靜態(tài)組件。創(chuàng)建一個(gè)子域并在那里托管所有靜態(tài)組件。

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

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

? ? ? ?25. 最小化DOM的訪問次數(shù)

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

• 緩存對(duì)訪問元素的引用
• 更新節(jié)點(diǎn)“離線”，然后將它們添加到樹中
• 避免使用JavaScript修復(fù)布局

　　有關(guān)更多信息，請(qǐng)查看?Julien Lecomte?的YUI影院的?“高性能Ajax應(yīng)用程序”。

? ? ? ?26. 開發(fā)巧妙的事件處理程序

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

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

　　有關(guān)更多信息，請(qǐng)查看?Julien Lecomte?的YUI影院的?“高性能Ajax應(yīng)用程序”。

? ? ? ?27. 優(yōu)先選擇使用<link>而非@import

　　之前的最佳實(shí)踐之一聲明CSS應(yīng)位于頂部以允許漸進(jìn)式渲染。

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

? ? ? ?28. 避免使用filters

　　IE專有的AlphaImageLoader過濾器旨在解決IE版本<7中的半透明真彩色PNG的問題。該過濾器的問題在于它在下載圖像時(shí)阻止渲染并凍結(jié)瀏覽器。它還會(huì)增加內(nèi)存消耗，并且每個(gè)元素應(yīng)用，而不是每個(gè)圖像，因此問題成倍增加。

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

? ? ? ?29. 優(yōu)化圖片

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

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

? ? ? ?30.優(yōu)化CSS Sprites　

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

? ? ? ?31. 不要在HTML中縮放圖像

　　不要使用比您需要的更大的圖像，因?yàn)槟梢栽贖TML中設(shè)置寬度和高度。如果您需要，

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

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

? ? ? ?32. 減小favicon.ico的體積并緩存

　　favicon.ico是一個(gè)保留在服務(wù)器根目錄中的映像。這是一個(gè)必要的邪惡，因?yàn)榧词鼓悴魂P(guān)心它，瀏覽器仍然會(huì)請(qǐng)求它，所以最好不要回復(fù)404 Not Found。此外，由于它位于同一臺(tái)服務(wù)器上，因此每次請(qǐng)求時(shí)都會(huì)發(fā)送cookie。此圖像也會(huì)干擾下載順序，例如在IE中，當(dāng)您在onload中請(qǐng)求額外組件時(shí)，將在這些額外組件之前下載favicon。

　　因此，為了減輕擁有favicon.ico的缺點(diǎn)，請(qǐng)確保：

• 它很小，最好不到1K。
• 使用您感覺舒適的設(shè)置Expires標(biāo)頭（因?yàn)槿绻鷽Q定更改它，則無法重命名）。您可以在將來幾個(gè)月安全地設(shè)置Expires標(biāo)頭。您可以查看當(dāng)前favicon.ico的上次修改日期，以做出明智的決定。

Imagemagick可以幫助您創(chuàng)建小的favicons

? ? ? ?33. 保持組件小于25K

　　此限制與iPhone不會(huì)緩存大于25K的組件這一事實(shí)有關(guān)。請(qǐng)注意，這是未壓縮的大小。這是縮小很重要的地方，因?yàn)閱为?dú)使用gzip可能還不夠。

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

? ? ? ?34. 將組件拆分到多個(gè)文檔中

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

? ? ? ?35. 避免設(shè)置空?qǐng)D像的src

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

直接的HTML
<img src =“”>

JavaScript的
var img = new Image（）;?
img.src =“”;

　　兩種形式都會(huì)產(chǎn)生相同的效果：瀏覽器向您的服務(wù)器發(fā)出另一個(gè)請(qǐng)求

• Internet Explorer向頁面所在的目錄發(fā)出請(qǐng)求。
• Safari和Chrome會(huì)向?qū)嶋H頁面提出請(qǐng)求。
• Firefox?3及更早版本的行為與Safari和Chrome相同，但3.5版解決了此問題[錯(cuò)誤444931]，不再發(fā)送請(qǐng)求。
• 遇到空?qǐng)D像時(shí)，Opera不執(zhí)行任何操作。

　　為什么這種行為不好？

通過發(fā)送大量意外流量來削弱您的服務(wù)器，特別是對(duì)于每天獲得數(shù)百萬頁面瀏覽量的頁面。

廢棄服務(wù)器計(jì)算周期生成永遠(yuǎn)不會(huì)被查看的頁面。

可能會(huì)損壞用戶數(shù)據(jù)。如果您通過cookie或其他方式跟蹤請(qǐng)求中的狀態(tài)，則可能會(huì)破壞數(shù)據(jù)。即使圖像請(qǐng)求未返回圖像，瀏覽器也會(huì)讀取并接受所有標(biāo)頭，包括所有cookie。雖然其余的響應(yīng)被丟棄，但可能已經(jīng)造成了損害。

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

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

src屬性必須存在，并且必須包含引用非交互式（可選動(dòng)畫）圖像資源的有效URL，該資源既不是分頁也不是腳本。如果元素的基URI與文檔的地址相同，則src屬性的值不能是空字符串。

　　希望瀏覽器將來不會(huì)出現(xiàn)這個(gè)問題。不幸的是，<script src =“”>和<link href =“”>沒有這樣的子句。也許還有時(shí)間進(jìn)行調(diào)整以確保瀏覽器不會(huì)意外地實(shí)現(xiàn)此行為。

　　這條規(guī)則的靈感來自雅虎的JavaScript大師Nicolas C. Zakas。有關(guān)更多信息，請(qǐng)查看他的文章“?Empty image src can destroy your site?”。

?

英文鏈接：

Best Practices for Speeding Up Your Web Site

轉(zhuǎn)載于:https://www.cnblogs.com/princess-knight/p/9314138.html

總結(jié)

以上是生活随笔為你收集整理的优化网站性能的35条规则的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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