最小化HTTP請求

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

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

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

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

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

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

開始減少頁面中的HTTP請求數(shù)。這是提高初次訪問者性能的最重要指南。正如Tenni Theurer的博客文章《瀏覽器緩存使用情況-公開！，有40-60％的每日訪問者訪問您的網(wǎng)站時(shí)會(huì)出現(xiàn)空的緩存。使這些初次訪問者快速瀏覽您的頁面對于改善用戶體驗(yàn)至關(guān)重要。

使用內(nèi)容交付網(wǎng)絡(luò)

用戶與您的Web服務(wù)器的接近程度會(huì)影響響應(yīng)時(shí)間。從用戶的角度來看，跨多個(gè)地理位置分散的服務(wù)器部署內(nèi)容將使您的頁面加載速度更快。但是你應(yīng)該從哪里開始呢？

作為實(shí)現(xiàn)地理上分散的內(nèi)容的第一步，請不要嘗試重新設(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ì)因此應(yīng)用程序體系結(jié)構(gòu)步驟而被延遲或永遠(yuǎn)不會(huì)過去。

請記住，最終用戶響應(yīng)時(shí)間的80-90％是花在下載頁面上的所有組件上的：圖像，樣式表，腳本，Flash等。這是Performance Golden Rule。與其從重新設(shè)計(jì)應(yīng)用程序體系結(jié)構(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ò)跳數(shù)最少的服務(wù)器或響應(yīng)時(shí)間最快的服務(wù)器。

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

添加過期或緩存控制標(biāo)頭

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

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

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

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

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

如果您的服務(wù)器是Apache，請使用ExpiresDefault指令設(shè)置相對于當(dāng)前日期的到期日期。此ExpiresDefault指令示例將Expires日期設(shè)置為自請求之日起10年。

過期默認(rèn)為“訪問權(quán)限加上10年”

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

僅在用戶已經(jīng)訪問您的網(wǎng)站之后，使用將來的Expires標(biāo)頭才會(huì)影響頁面瀏覽量。當(dāng)用戶首次訪問您的站點(diǎn)并且瀏覽器的緩存為空時(shí)，它對HTTP請求的數(shù)量沒有影響。因此，此性能改進(jìn)的影響取決于用戶使用預(yù)備緩存訪問您的頁面的頻率。（“主緩存”已包含頁面中的所有組件。）我們在Yahoo! 并發(fā)現(xiàn)帶有預(yù)填充緩存的頁面瀏覽量為75-85％。通過使用遠(yuǎn)期的Expires標(biāo)頭，可以增加瀏覽器緩存并在后續(xù)頁面視圖中重復(fù)使用的組件的數(shù)量，而無需通過用戶的Internet連接發(fā)送單個(gè)字節(jié)。

Gzip組件

通過前端工程師的決定，可以大大減少跨網(wǎng)絡(luò)傳輸HTTP請求和響應(yīng)所花費(fèi)的時(shí)間。的確，最終用戶的帶寬速度，Internet服務(wù)提供商，與對等交換點(diǎn)的距離等等，都是開發(fā)團(tuán)隊(duì)無法控制的。但是還有其他影響響應(yīng)時(shí)間的變量。壓縮通過減小HTTP響應(yīng)的大小來減少響應(yīng)時(shí)間。

從HTTP / 1.1開始，Web客戶端使用HTTP請求中的Accept-Encoding標(biāo)頭指示對壓縮的支持。

接受編碼：gzip，放氣

如果Web服務(wù)器在請求中看到此標(biāo)頭，則可以使用客戶端列出的方法之一壓縮響應(yīng)。Web服務(wù)器通過響應(yīng)中的Content-Encoding標(biāo)頭將其通知Web客戶端。

內(nèi)容編碼：gzip

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

壓縮通常會(huì)將響應(yīng)大小減少約70％。如今，大約90％的Internet流量通過聲稱支持gzip的瀏覽器傳輸。如果使用Apache，則配置gzip的模塊取決于您的版本：Apache 1.3使用mod_gzip，而Apache 2.x使用mod_deflate。

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

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

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

將樣式表放在頂部

雖然研究在雅虎的表現(xiàn)！我們發(fā)現(xiàn)，移動(dòng)樣式表文件HEAD使頁面看起來是加載速度更快。這是因?yàn)閷邮奖矸旁贖EAD中可以使頁面逐步呈現(xiàn)。

關(guān)心性能的前端工程師希望頁面逐漸加載。也就是說，我們希望瀏覽器盡快顯示其具有的所有內(nèi)容。這對于內(nèi)容豐富的頁面以及Internet連接速度較慢的用戶而言尤其重要。為用戶提供視覺反饋（例如進(jìn)度指示器）的重要性已經(jīng)得到了充分的研究和記錄。在我們的例子中，HTML頁面是進(jìn)度指示器！當(dāng)瀏覽器逐步加載頁面時(shí)，標(biāo)題，導(dǎo)航欄，頂部的徽標(biāo)等均作為等待頁面的用戶的視覺反饋。這樣可以改善整體用戶體驗(yàn)。

將樣式表放在文檔底部附近的問題是，它禁止在許多瀏覽器（包括Internet Explorer）中進(jìn)行漸進(jìn)式渲染。這些瀏覽器會(huì)阻止渲染，以避免樣式改變時(shí)不得不重繪頁面元素。用戶被困在查看空白白頁。

的HTML規(guī)范明確指出，樣式表是被包括在網(wǎng)頁的HEAD：“與A，[LINK]可以僅出現(xiàn)在一個(gè)文檔的HEAD部分，盡管它可能出現(xiàn)任意次數(shù)”。空白的黑屏或未樣式化的內(nèi)容閃爍均不值得冒險(xiǎn)。最佳解決方案是遵循HTML規(guī)范并將樣式表加載到文檔HEAD中。

將腳本放在最下面

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

在某些情況下，將腳本移到底部并不容易。例如，如果腳本用于document.write插入頁面內(nèi)容的一部分，則不能將其在頁面中移至較低位置。可能還會(huì)存在范圍界定問題。在許多情況下，有一些方法可以解決這些情況。

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

避免CSS表達(dá)式

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

背景顏色：expression（（new Date（））。getHours（）％2？“＃B8D4FF”：“＃F08A00”）;

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

表達(dá)式的問題在于對它們的評估比大多數(shù)人期望的要頻繁。不僅會(huì)在呈現(xiàn)頁面和調(diào)整頁面大小時(shí)對它們進(jìn)行評估，還會(huì)在滾動(dòng)頁面甚至用戶將鼠標(biāo)移到頁面上時(shí)進(jìn)行評估。在CSS表達(dá)式中添加一個(gè)計(jì)數(shù)器，使我們能夠跟蹤何時(shí)以及何時(shí)評估CSS表達(dá)式。在頁面上移動(dòng)鼠標(biāo)可以輕松生成10,000多個(gè)評估。

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

將JavaScript和CSS設(shè)為外部

這些性能規(guī)則中有許多涉及如何管理外部組件。但是，在考慮這些因素之前，您應(yīng)該提出一個(gè)更基本的問題：JavaScript和CSS是否應(yīng)包含在外部文件中，還是應(yīng)包含在頁面本身中？

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

因此，關(guān)鍵因素是相對于請求的HTML文檔數(shù)量而言，緩存外部JavaScript和CSS組件的頻率。盡管難以量化，但可以使用各種度量標(biāo)準(zhǔn)來衡量此因素。如果您站點(diǎn)上的用戶每個(gè)會(huì)話具有多個(gè)頁面視圖，并且您的許多頁面都重復(fù)使用相同的腳本和樣式表，則緩存的外部文件會(huì)帶來更大的潛在利益。

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

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

減少DNS查找

域名系統(tǒng)（DNS）會(huì)將主機(jī)名映射到IP地址，就像電話簿將人們的姓名映射到他們的電話號(hào)碼一樣。在瀏覽器中輸入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)。

默認(rèn)情況下，Internet Explorer會(huì)緩存30分鐘的DNS查找，這是由DnsCacheTimeout注冊表設(shè)置指定的 。Firefox在network.dnsCacheExpiration配置設(shè)置的控制下緩存DNS查找1分鐘。（Fasterfox將其更改為1小時(shí)。）

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

減少唯一主機(jī)名的數(shù)量有可能減少頁面中并行下載的數(shù)量。避免DNS查找會(huì)減少響應(yīng)時(shí)間，但是減少并行下載可能會(huì)增加響應(yīng)時(shí)間。我的指導(dǎo)原則是將這些組件劃分為至少兩個(gè)但不超過四個(gè)主機(jī)名。這導(dǎo)致在減少DNS查找與允許高度并行下載之間達(dá)成良好的折衷。

縮小JavaScript和CSS

最小化是從代碼中刪除不必要的字符以減小其大小，從而縮短加載時(shí)間的實(shí)踐。當(dāng)代碼最小化時(shí)，所有注釋以及不需要的空格字符（空格，換行符和制表符）都將被刪除。在使用JavaScript的情況下，由于減小了下載文件的大小，因此可以提高響應(yīng)時(shí)間性能。最小化JavaScript代碼的兩種流行工具是JSMin和YUI Compressor。YUI壓縮器還可以縮小CSS。

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

除了最小化外部腳本和樣式，內(nèi)聯(lián)script和style塊也可以并且也應(yīng)該被最小化。即使您對腳本和樣式進(jìn)行g(shù)zip壓縮，將它們縮小也會(huì)使大小減小5％或更多。隨著JavaScript和CSS的使用和大小的增加，通過減少代碼量而節(jié)省的費(fèi)用也將隨之增加。

避免重定向

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

HTTP / 1.1 301永久移動(dòng)位置：http：//example.com/newuri內(nèi)容類型：text / html

瀏覽器會(huì)自動(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)闊o法呈現(xiàn)頁面中的任何內(nèi)容，并且只有在HTML文檔到達(dá)之前，才能開始下載任何組件。

最浪費(fèi)的重定向之一經(jīng)常發(fā)生，并且Web開發(fā)人員通常不了解它。當(dāng)URL末尾應(yīng)包含一個(gè)斜杠（/）時(shí)，就會(huì)發(fā)生此錯(cuò)誤。例如，轉(zhuǎn)到http://astrology.yahoo.com/astrology會(huì)導(dǎo)致301響應(yīng)，其中包含對http://astrology.yahoo.com/astrology/的重定向（請注意添加了斜杠）。如果使用Apache處理程序，則可以使用Alias或mod_rewrite或該DirectorySlash指令在Apache中進(jìn)行修復(fù)。

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

刪除重復(fù)的腳本

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

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

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

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

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

PHP中的一種替代方法是創(chuàng)建一個(gè)名為的函數(shù)insertScript。

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

除了防止多次插入同一腳本外，此功能還可以處理腳本的其他問題，例如依賴性檢查以及向腳本文件名添加版本號(hào)以支持將來的Expires標(biāo)頭。

配置ETag

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

HTTP / 1.1 200 OK上次修改時(shí)間：2006年12月12日，星期二，格林尼治標(biāo)準(zhǔn)時(shí)間ETag：“ 10c24bc-4ab-457e1c1f”內(nèi)容長度：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主持人：us.yimg.com如果修改時(shí)間：自星期二，2006年12月12日格林尼治標(biāo)準(zhǔn)時(shí)間如果不匹配：“ 10c24bc-4ab-457e1c1f”HTTP / 1.1 304未修改

ETag的問題在于它們通常使用使它們對托管站點(diǎn)的特定服務(wù)器而言唯一的屬性構(gòu)造。當(dāng)瀏覽器從一臺(tái)服務(wù)器獲取原始組件，然后嘗試在另一臺(tái)服務(wù)器上驗(yàn)證該組件時(shí)，ETag將不匹配，這種情況在使用服務(wù)器集群處理請求的網(wǎng)站上非常普遍。默認(rèn)情況下，Apache和IIS都將數(shù)據(jù)嵌入ETag中，從而大大降低了在具有多臺(tái)服務(wù)器的網(wǎng)站上成功進(jìn)行有效性測試的幾率。

Apache 1.3和2.x的ETag格式為inode-size-timestamp。盡管一個(gè)給定的文件可能位于多個(gè)服務(wù)器的同一目錄中，并且具有相同的文件大小，權(quán)限，時(shí)間戳等，但它的索引節(jié)點(diǎn)在一個(gè)服務(wù)器和另一個(gè)服務(wù)器之間是不同的。

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

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

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

FileETag無

使Ajax可緩存

Ajax引用的好處之一是，它向用戶提供了即時(shí)反饋，因?yàn)樗鼜暮蠖薟eb服務(wù)器異步請求信息。但是，使用Ajax并不能保證用戶不會(huì)在等待那些異步JavaScript和XML響應(yīng)返回時(shí)揮手致意。在許多應(yīng)用程序中，用戶是否一直等待取決于Ajax的使用方式。例如，在基于Web的電子郵件客戶端中，用戶將一直等待Ajax請求的結(jié)果以查找與其搜索條件匹配的所有電子郵件。重要的是要記住，“異步”并不意味著“瞬時(shí)”。

為了提高性能，優(yōu)化這些Ajax響應(yīng)很重要。改善Ajax性能的最重要方法是使響應(yīng)可緩存，如Add Expires或Cache-Control Header中所述。其他一些規(guī)則也適用于Ajax：
Gzip組件
減少DNS查找
縮小JavaScript
避免重定向
配置ETag

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

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

盡早沖洗緩沖液

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

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

例：

... <！-CSS，JS-> </ head> <？php flush（）; ？> <身體>... <！-內(nèi)容->

雅虎！搜索率先進(jìn)行研究并進(jìn)行實(shí)際用戶測試，以證明使用此技術(shù)的好處。

使用GET處理AJAX請求

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

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

加載后組件

您可以仔細(xì)查看您的頁面，然后問自己：“最初呈現(xiàn)頁面絕對需要什么？”。其余的內(nèi)容和組件可以等待。

JavaScript是onload事件之前和之后進(jìn)行拆分的理想選擇。例如，如果您有執(zhí)行拖放操作的JavaScript代碼和庫以及動(dòng)畫，則它們可以等待，因?yàn)轫撁嫔系耐蟿?dòng)元素是在初始渲染之后進(jìn)行的。尋找后加載候選的其他地方包括隱藏內(nèi)容（用戶操作后出現(xiàn)的內(nèi)容）和首屏以下的圖像。

可以幫助您完成工作的工具：YUI Image Loader允許您將圖像延遲到首屏以下，并且YUI Get實(shí)用程序是一種動(dòng)態(tài)添加JS和CSS的簡便方法。舉個(gè)例子，看看Yahoo! Firebug的“ Net Panel”已打開的主頁。

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

預(yù)載組件

預(yù)加載可能看起來與后加載相反，但實(shí)際上有一個(gè)不同的目標(biāo)。通過預(yù)加載組件，您可以利用瀏覽器空閑的時(shí)間來請求將來需要的組件（例如圖像，樣式和腳本）。這樣，當(dāng)用戶訪問下一頁時(shí)，您可能已經(jīng)在緩存中包含了大多數(shù)組件，因此頁面的加載將為用戶帶來更快的速度。

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

無條件預(yù)加載-一旦onload觸發(fā)，您就繼續(xù)獲取一些額外的組件。在google.com上查看有關(guān)如何在加載時(shí)請求子畫面圖片的示例。不需要在google.com主頁上使用此圖片圖片，但在連續(xù)的搜索結(jié)果頁面上則需要使用此圖片圖片。
有條件的預(yù)加載-根據(jù)用戶操作，您可以進(jìn)行有根據(jù)的猜測，預(yù)測用戶下一步將到達(dá)何處，并進(jìn)行相應(yīng)的預(yù)加載。在search.yahoo.com上，您可以看到在開始在輸入框中輸入內(nèi)容后如何請求一些額外的組件。
預(yù)期的預(yù)加載-啟動(dòng)重新設(shè)計(jì)之前的預(yù)加載。經(jīng)過重新設(shè)計(jì)后，您通常會(huì)聽到這樣的消息：“新站點(diǎn)很酷，但是比以前慢。” 問題的一部分可能是用戶訪問了具有完整緩存的舊站點(diǎn)，但是新站點(diǎn)始終是空的緩存體驗(yàn)。您可以在啟動(dòng)重新設(shè)計(jì)之前預(yù)先加載一些組件來減輕這種副作用。您的舊站點(diǎn)可以使用瀏覽器空閑時(shí)的時(shí)間，并請求新站點(diǎn)將使用的圖像和腳本

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

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

大量的DOM元素可能是一種征兆，即頁面的標(biāo)記有一些需要改進(jìn)的地方，而不必刪除內(nèi)容。您是否使用嵌套表進(jìn)行布局？您是否

只為了解決布局問題而投入更多資源？也許有一種更好，更語義正確的方式來進(jìn)行標(biāo)記。

與布局有很大的幫助是YUI CSS公用事業(yè)：grids.css可以幫助你的整體布局，fonts.css和reset.css可以幫你除掉那些瀏覽器的默認(rèn)格式。這是一個(gè)重新開始并思考您的標(biāo)記的機(jī)會(huì)，例如，

僅在語義上有意義時(shí)才使用s，而不是因?yàn)樗尸F(xiàn)了新的一行。

DOM元素的數(shù)量易于測試，只需在Firebug的控制臺(tái)中輸入：
document.getElementsByTagName(’*’).length

多少個(gè)DOM元素太多？檢查其他具有良好標(biāo)記的相似頁面。例如Yahoo! 主頁是一個(gè)非常繁忙的頁面，仍然少于700個(gè)元素（HTML標(biāo)記）。

跨域拆分組件

拆分組件使您可以最大程度地并行下載。確保您使用的域名不超過2-4個(gè)，因?yàn)镈NS查詢會(huì)受到影響。例如，您可以承載你的HTML和動(dòng)態(tài)內(nèi)容上www.example.org 與分裂之間的靜電元件static1.example.org和static2.example.org

有關(guān)更多信息，請查看Tenni Theurer和Patty Chi撰寫的“ 最大程度地在拼車通道中并行下載 ”。

減少iframe的數(shù)量

iframe可將HTML文檔插入父文檔中。了解iframe的工作方式非常重要，這樣才能有效地使用它們。

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

幫助處理緩慢的第三方內(nèi)容，例如徽章和廣告
安全沙箱
并行下載腳本
<iframe> 缺點(diǎn)：

即使空白也很昂貴
阻止頁面加載
非語義

沒有404

HTTP請求非常昂貴，因此完全不需要發(fā)出HTTP請求并獲得無用的響應(yīng)（即404 Not Found），這會(huì)減慢用戶體驗(yàn)，而沒有任何好處。

一些站點(diǎn)具有有用的404“您是不是X嗎？”，這對用戶體驗(yàn)很有用，但也浪費(fèi)了服務(wù)器資源（如數(shù)據(jù)庫等）。特別糟糕的是，當(dāng)指向外部JavaScript的鏈接錯(cuò)誤并且結(jié)果為404時(shí)。首先，此下載將阻止并行下載。接下來，瀏覽器可能會(huì)嘗試將404響應(yīng)主體解析為JavaScript代碼，試圖在其中找到可用的內(nèi)容。

減少Cookie大小

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

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

消除不必要的Cookie
保持盡可能小的Cookie大小，以最大程度地減少對用戶響應(yīng)時(shí)間的影響
請注意在適當(dāng)?shù)挠蚣?jí)別上設(shè)置Cookie，以免影響其他子域
適當(dāng)設(shè)置到期日期。較早的失效日期或沒有失效日期會(huì)更快地刪除Cookie，從而縮短了用戶響應(yīng)時(shí)間

對組件使用無Cookie域

當(dāng)瀏覽器發(fā)出靜態(tài)圖像請求并與請求一起發(fā)送cookie時(shí)，服務(wù)器對這些cookie沒有任何用處。因此，它們只會(huì)無緣無故地創(chuàng)建網(wǎng)絡(luò)流量。您應(yīng)確保使用無Cookie的請求來請求靜態(tài)組件。創(chuàng)建一個(gè)子域并在其中托管所有靜態(tài)組件。

如果您的域是www.example.org，則可以在上托管靜態(tài)組件static.example.org。但是，如果您已經(jīng)在頂級(jí)域example.org（而不是）上設(shè)置了cookie www.example.org，則所有的請求都 static.example.org將包含這些cookie。在這種情況下，您可以購買一個(gè)全新的域，在其中托管靜態(tài)組件，并使該域保持無Cookie狀態(tài)。雅虎！使用yimg.com，YouTube使用ytimg.com，Amazon使用images-amazon.com等等。

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

最小化DOM訪問

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

緩存對已訪問元素的引用
更新節(jié)點(diǎn)“離線”，然后將其添加到樹中
避免使用JavaScript修復(fù)布局
有關(guān)更多信息，請查看 Julien Lecomte 的YUI劇院的 “高性能Ajax應(yīng)用程序”。

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

有時(shí)，頁面會(huì)因?yàn)轫憫?yīng)事件處理程序的響應(yīng)性降低而出現(xiàn)問題，這是因?yàn)楦郊拥紻OM樹的不同元素上的事件處理程序過多，因而導(dǎo)致執(zhí)行頻率太高。這就是為什么使用事件委托是一種好方法。如果a中有10個(gè)按鈕div，則僅將一個(gè)事件處理程序附加到div包裝器，而不是每個(gè)按鈕一個(gè)處理程序。事件冒泡了，因此您可以捕獲事件并弄清楚它來自哪個(gè)按鈕。

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

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

在@import上選擇

以前的最佳實(shí)踐之一指出，CSS應(yīng)該位于頂部，以便進(jìn)行漸進(jìn)式渲染。

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

避免使用過濾器

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

最好的方法是AlphaImageLoader完全避免使用PNG8并降低其性能，這在IE中很好。如果絕對需要AlphaImageLoader，請使用下劃線_filter，以免對IE7 +用戶造成不利影響。

優(yōu)化圖像

設(shè)計(jì)人員完成了為您的網(wǎng)頁創(chuàng)建圖像后，仍然可以嘗試一些操作，然后再將這些圖像通過FTP傳輸?shù)絎eb服務(wù)器。

您可以檢查GIF，并查看它們是否使用的調(diào)色板尺寸與圖像中的顏色數(shù)量相對應(yīng)。使用imagemagick可以很容易地進(jìn)行檢查。
identify -verbose image.gif
當(dāng)您在調(diào)色板中看到使用4種顏色和256種顏色“插槽”的圖像時(shí)，還有改進(jìn)的余地。
嘗試將GIF轉(zhuǎn)換為PNG，看看是否有節(jié)省。經(jīng)常有。由于瀏覽器支持有限，開發(fā)人員常常不愿使用PNG，但這已成為過去。唯一的實(shí)際問題是真彩色PNG中的alpha透明性，但是同樣，GIF也不是真彩色，也不支持可變透明度。因此，GIF可以做的任何事情，調(diào)色板PNG（PNG8）也可以做（動(dòng)畫除外）。這個(gè)簡單的imagemagick命令產(chǎn)生了完全安全使用的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

優(yōu)化CSS精靈

將圖片中的圖片水平排列而不是垂直排列通常會(huì)減小文件大小。
在子畫面中組合相似的顏色可以幫助您保持較低的顏色計(jì)數(shù)，理想情況下應(yīng)少于256種顏色，以適合PNG8。
“對移動(dòng)設(shè)備友好”，并且在sprite中的圖像之間不要留有很大的空隙。這不會(huì)對文件大小產(chǎn)生太大影響，但需要較少的內(nèi)存供用戶代理將圖像解壓縮為像素圖。100x100圖片為1萬像素，其中1000x1000為100萬像素

不要縮放HTML中的圖像

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

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

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

使favicon.ico小型且可緩存

favicon.ico是保留在服務(wù)器根目錄中的映像。這是一個(gè)必不可少的邪惡，因?yàn)榧词鼓魂P(guān)心它，瀏覽器仍然會(huì)請求它，因此最好不要使用來響應(yīng)404 Not Found。另外，由于它在同一臺(tái)服務(wù)器上，因此每次請求時(shí)都會(huì)發(fā)送cookie。該映像還會(huì)干擾下載順序，例如，在IE中，當(dāng)您在onload中請求其他組件時(shí)，將在這些其他組件之前下載圖標(biāo)。

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

它很小，最好在1K以下。
根據(jù)需要設(shè)置Expires標(biāo)頭（因?yàn)槿绻麤Q定更改它，則無法重命名）。您可能可以在未來幾個(gè)月安全地設(shè)置Expires標(biāo)頭。您可以檢查當(dāng)前favicon.ico的最后修改日期，以做出明智的決定。
Imagemagick可以幫助您創(chuàng)建小型網(wǎng)站圖標(biāo)

組件保持在25K以下

此限制與以下事實(shí)有關(guān)：iPhone不會(huì)緩存大于25K的組件。請注意，這是未壓縮的大小。在這里，縮小非常重要，因?yàn)閮H使用gzip可能不夠。

有關(guān)更多信息，請查看Wayne Shea和Tenni Theurer撰寫的“ 性能研究，第5部分：iPhone緩存能力-堅(jiān)持下去 ”。
將組件打包成多部分文檔
日：移動(dòng)

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

避免空圖片源

具有空字符串src屬性的圖像出現(xiàn)的次數(shù)超過預(yù)期。它以兩種形式出現(xiàn)：

直接HTML

<img src =“”>

的JavaScript

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

兩種形式都會(huì)產(chǎn)生相同的效果：瀏覽器再次向您的服務(wù)器發(fā)出請求。

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

為什么這種行為不好？

通過發(fā)送大量意外流量來破壞服務(wù)器，尤其是對于每天獲得數(shù)百萬次頁面查看的頁面。
浪費(fèi)的服務(wù)器計(jì)算周期生成了永遠(yuǎn)不會(huì)被查看的頁面。
可能損壞用戶數(shù)據(jù)。如果您正在通過Cookie或其他方式跟蹤請求中的狀態(tài)，則可能會(huì)破壞數(shù)據(jù)。即使圖像請求未返回圖像，瀏覽器也會(huì)讀取并接受所有標(biāo)頭，包括所有cookie。當(dāng)其余的響應(yīng)被丟棄時(shí)，損壞可能已經(jīng)造成。

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

HTML5在標(biāo)記的src屬性的描述中添加了內(nèi)容，以指示瀏覽器不要在4.8.2節(jié)中提出其他請求：

src屬性必須存在，并且必須包含有效的URL，該URL引用既非分頁也沒有腳本化的非交互式，可選動(dòng)畫的圖像資源。如果元素的基本URI與文檔的地址相同，則src屬性的值不能為空字符串。
希望將來瀏覽器不會(huì)出現(xiàn)此問題。不幸的是，對于<script src =“”>和<link href =“”>沒有此類子句。也許還有時(shí)間進(jìn)行調(diào)整，以確保瀏覽器不會(huì)意外實(shí)現(xiàn)此行為。

總結(jié)

以上是生活随笔為你收集整理的##加速网站的最佳做法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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