網(wǎng)站頁面性能優(yōu)化的20條黃金守則
1、用<link>代替@import
前面的最佳實現(xiàn)中提到CSS應(yīng)該放置在頂端以利于有序加載呈現(xiàn)。
在IE中，頁面底部@import和使用
作用是一樣的，因此最好不要使用它。
2、避免使用濾鏡
IE獨有屬性AlphaImageLoader用于修正7.0以下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在于瀏覽器加載圖片時它會終止內(nèi)容的呈現(xiàn)并且凍結(jié)瀏覽器。在每一個元素（不僅僅是圖片）它都會運算一次，增加了內(nèi)存開支，因此它的問題是多方面的。
完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替，這種格式能在IE中很好地工作。如果你確實需要使用AlphaImageLoader，請使用下劃線_filter又使之對IE7以上版本的用戶無效。
3、把腳本置于頁面底部
腳本帶來的問題就是它阻止了頁面的平行下載。HTTP/1.1 規(guī)范建議，瀏覽器每個主機(jī)名的并行下載內(nèi)容不超過兩個。如果你的圖片放在多個主機(jī)名上，你可以在每個并行下載中同時下載2個以上的文件。但是當(dāng)下載腳本時，瀏覽器就不會同時下載其它文件了，即便是主機(jī)名不相同。
在某些情況下把腳本移到頁面底部可能不太容易。比如說，如果腳本中使用了document.write來插入頁面內(nèi)容，它就不能被往下移動了。這里可能還會有作用域的問題。很多情況下，都會遇到這方面的問題。
一個經(jīng)常用到的替代方法就是使用延遲腳本。DEFER屬性表明腳本中沒有包含document.write，它告訴瀏覽器繼續(xù)顯示。不幸的是，F(xiàn)irefox并不支持DEFER屬性。在Internet Explorer中，腳本可能會被延遲但效果也不會像我們所期望的那樣。如果腳本可以被延遲，那么它就可以移到頁面的底部。這會讓你的頁面加載的快一點。
4、剔除重復(fù)腳本
在同一個頁面中重復(fù)引用JavaScript文件會影響頁面的性能。你可能會認(rèn)為這種情況并不多見。對于美國前10大網(wǎng)站的調(diào)查顯示其中有兩家存在重復(fù)引用腳本的情況。有兩種主要因素導(dǎo)致一個腳本被重復(fù)引用的奇怪現(xiàn)象發(fā)生：團(tuán)隊規(guī)模和腳本數(shù)量。如果真的存在這種情況，重復(fù)腳本會引起不必要的HTTP請求和無用的JavaScript運算，這降低了網(wǎng)站性能。
在Internet Explorer中會產(chǎn)生不必要的HTTP請求，而在Firefox卻不會。在Internet Explorer中，如果一個腳本被引用兩次而且它又不可緩存，它就會在頁面加載過程中產(chǎn)生兩次HTTP請求。即時腳本可以緩存，當(dāng)用戶重載頁面時也會產(chǎn)生額外的HTTP請求。
除增加額外的HTTP請求外，多次運算腳本也會浪費時間。在Internet Explorer和Firefox中不管腳本是否可緩存，它們都存在重復(fù)運算JavaScript的問題。
一個避免偶爾發(fā)生的兩次引用同一腳本的方法是在模板中使用腳本管理模塊引用腳本。在HTML頁面中使用
標(biāo)簽引用腳本的最常見方法就是：
<script type="text/javascript" src="menu_1.0.17.js">
在PHP中可以通過創(chuàng)建名為insertScript的方法來替代：
為了防止多次重復(fù)引用腳本，這個方法中還應(yīng)該使用其它機(jī)制來處理腳本，如檢查所屬目錄和為腳本文件名中增加版本號以用于Expire文件頭等。
5、減少DOM訪問
使用JavaScript訪問DOM元素比較慢，因此為了獲得更多的應(yīng)該頁面，應(yīng)該做到：緩存已經(jīng)訪問過的有關(guān)元素 線下更新完節(jié)點之后再將它們添加到文檔樹中 避免使用JavaScript來修改頁面布局
有關(guān)此方面的更多信息請查看Julien Lecomte在YUI專題中的文章“高性能Ajax應(yīng)該程序”。
6、開發(fā)智能事件處理程序
有時候我們會感覺到頁面反應(yīng)遲鈍，這是因為DOM樹元素中附加了過多的事件句柄并且些事件句病被頻繁地觸發(fā)。這就是為什么說使用event delegation（事件代理）是一種好方法了。如果你在一個div中有10個按鈕，你只需要在div上附加一次事件句柄就可以了，而不用去為每一個按鈕增加一個句柄。事件冒泡時你可以捕捉到事件并判斷出是哪個事件發(fā)出的。
你同樣也不用為了操作DOM樹而等待onload事件的發(fā)生。你需要做的就是等待樹結(jié)構(gòu)中你要訪問的元素出現(xiàn)。你也不用等待所有圖像都加載完畢。
你可能會希望用DOMContentLoaded事件來代替onload，但是在所有瀏覽器都支持它之前你可使用YUI 事件應(yīng)用程序中的onAvailable方法。
7、減小Cookie體積
HTTP coockie可以用于權(quán)限驗證和個性化身份等多種用途。coockie內(nèi)的有關(guān)信息是通過HTTP文件頭來在web服務(wù)器和瀏覽器之間進(jìn)行交流的。因此保持coockie盡可能的小以減少用戶的響應(yīng)時間十分重要。 有關(guān)更多信息可以查看Tenni Theurer和Patty Chi的文章“When the Cookie Crumbles”。這們研究中主要包括：去除不必要的coockie 使coockie體積盡量小以減少對用戶響應(yīng)的影響 注意在適應(yīng)級別的域名上設(shè)置coockie以便使子域名不受影響 設(shè)置合理的過期時間。較早地Expire時間和不要過早去清除coockie，都會改善用戶的響應(yīng)時間。
8、對于頁面內(nèi)容使用無coockie域名
當(dāng)瀏覽器在請求中同時請求一張靜態(tài)的圖片和發(fā)送coockie時，服務(wù)器對于這些coockie不會做任何地使用。因此他們只是因為某些負(fù)面因素而創(chuàng)建的網(wǎng)絡(luò)傳輸。所有你應(yīng)該確定對于靜態(tài)內(nèi)容的請求是無coockie的請求。創(chuàng)建一個子域名并用他來存放所有靜態(tài)內(nèi)容。
如果你的域名是www.example.org，你可以在static.example.org上存在靜態(tài)內(nèi)容。但是，如果你不是在www.example.org上而是在頂級域名example.org設(shè)置了coockie，那么所有對于static.example.org的請求都包含coockie。在這種情況下，你可以再重新購買一個新的域名來存在靜態(tài)內(nèi)容，并且要保持這個域名是無coockie的。Yahoo!使用的是ymig.com，YouTube使用的是ytimg.com，Amazon使用的是images-anazon.com等等。
使用無coockie域名存在靜態(tài)內(nèi)容的另外一個好處就是一些代理（服務(wù)器）可能會拒絕對coockie的內(nèi)容請求進(jìn)行緩存。一個相關(guān)的建議就是，如果你想確定應(yīng)該使用example.org還是www.example.org作為你的一主頁，你要考慮到coockie帶來的影響。忽略掉www會使你除了把coockie設(shè)置到*.example.org（*是泛域名解析，代表了所有子域名譯者dudo注）外沒有其它選擇，因此出于性能方面的考慮最好是使用帶有www的子域名并且在它上面設(shè)置coockie。
9、優(yōu)化圖像
設(shè)計人員完成對頁面的設(shè)計之后，不要急于將它們上傳到web服務(wù)器，這里還需要做幾件事：你可以檢查一下你的GIF圖片中圖像顏色的數(shù)量是否和調(diào)色板規(guī)格一致。 使用imagemagick中下面的命令行很容易檢查： identify -verbose image.gif 如果你發(fā)現(xiàn)圖片中只用到了4種顏色，而在調(diào)色板的中顯示的256色的顏色槽，那么這張圖片就還有壓縮的空間。
嘗試把GIF格式轉(zhuǎn)換成PNG格式，看看是否節(jié)省空間。大多數(shù)情況下是可以壓縮的。由于瀏覽器支持有限，設(shè)計者們往往不太樂意使用PNG格式的圖片，不過這都是過去的事情了?，F(xiàn)在只有一個問題就是在真彩PNG格式中的alpha通道半透明問題，不過同樣的，GIF也不是真彩格式也不支持半透明。因此GIF能做到的，PNG（PNG8）同樣也能做到（除了動畫）。下面這條簡單的命令可以安全地把GIF格式轉(zhuǎn)換為PNG格式： convert image.gif image.png “我們要說的是：給PNG一個施展身手的機(jī)會吧！” 在所有的PNG圖片上運行pngcrush（或者其它PNG優(yōu)化工具）。例如： pngcrush image.png -rem alla -reduce -brute result.png 在所有的JPEG圖片上運行jpegtran。這個工具可以對圖片中的出現(xiàn)的鋸齒等做無損操作，同時它還可以用于優(yōu)化和清除圖片中的注釋以及其它無用信息（如EXIF信息）： jpegtran -copy none -optimize -perfect src.jpg dest.jpg
10、優(yōu)化CSS不要出現(xiàn)404錯誤
Spirite在Spirite中水平排列你的圖片，垂直排列會稍稍增加文件大小； Spirite中把顏色較近的組合在一起可以降低顏色數(shù)，理想狀況是低于256色以便適用PNG8格式； 便于移動，不要在Spirite的圖像中間留有較大空隙。這雖然不大會增加文件大小但對于用戶代理來說它需要更少的內(nèi)存來把圖片解壓為像素地圖。100x100的圖片為1萬像素，而1000x1000就是100萬像素。
HTTP請求時間消耗是很大的，因此使用HTTP請求來獲得一個沒有用處的響應(yīng)（例如404沒有找到頁面）是完全沒有必要的，它只會降低用戶體驗而不會有一點好處。
有些站點把404錯誤響應(yīng)頁面改為“你是不是要找***”，這雖然改進(jìn)了用戶體驗但是同樣也會浪費服務(wù)器資源（如數(shù)據(jù)庫等）。最糟糕的情況是指向外部JavaScript的鏈接出現(xiàn)問題并返回404代碼。首先，這種加載會破壞并行加載；其次瀏覽器會把試圖在返回的404響應(yīng)內(nèi)容中找到可能有用的部分當(dāng)作JavaScript代碼來執(zhí)行。
11、使用內(nèi)容分發(fā)網(wǎng)絡(luò)
用戶與你網(wǎng)站服務(wù)器的接近程度會影響響應(yīng)時間的長短。把你的網(wǎng)站內(nèi)容分散到多個、處于不同地域位置的服務(wù)器上可以加快下載速度。但是首先我們應(yīng)該做些什么呢？
按地域布置網(wǎng)站內(nèi)容的第一步并不是要嘗試重新架構(gòu)你的網(wǎng)站讓他們在分發(fā)服務(wù)器上正常運行。根據(jù)應(yīng)用的需求來改變網(wǎng)站結(jié)構(gòu)，這可能會包括一些比較復(fù)雜的任務(wù)，如在服務(wù)器間同步Session狀態(tài)和合并數(shù)據(jù)庫更新等。要想縮短用戶和內(nèi)容服務(wù)器的距離，這些架構(gòu)步驟可能是不可避免的。
要記住，在終端用戶的響應(yīng)時間中有80%到90%的響應(yīng)時間用于下載圖像、樣式表、腳本、Flash等頁面內(nèi)容。這就是網(wǎng)站性能黃金守則。和重新設(shè)計你的應(yīng)用程序架構(gòu)這樣比較困難的任務(wù)相比，首先來分布靜態(tài)內(nèi)容會更好一點。這不僅會縮短響應(yīng)時間，而且對于內(nèi)容分發(fā)網(wǎng)絡(luò)來說它更容易實現(xiàn)。
內(nèi)容分發(fā)網(wǎng)絡(luò)（Content Delivery Network，CDN）是由一系列分散到各個不同地理位置上的Web服務(wù)器組成的，它提高了網(wǎng)站內(nèi)容的傳輸速度。用于向用戶傳輸內(nèi)容的服務(wù)器主要是根據(jù)和用戶在網(wǎng)絡(luò)上的靠近程度來指定的。例如，擁有最少網(wǎng)絡(luò)跳數(shù)（network hops）和響應(yīng)速度最快的服務(wù)器會被選定。
一些大型的網(wǎng)絡(luò)公司擁有自己的CDN，但是使用像Akamai Technologies，Mirror Image Internet， 或者Limelight Networks這樣的CDN服務(wù)成本卻非常高。對于剛剛起步的企業(yè)和個人網(wǎng)站來說，可能沒有使用CDN的成本預(yù)算，但是隨著目標(biāo)用戶群的不斷擴(kuò)大和更加全球化，CDN就是實現(xiàn)快速響應(yīng)所必需的了。以Yahoo來說，他們轉(zhuǎn)移到CDN上的網(wǎng)站程序靜態(tài)內(nèi)容節(jié)省了終端用戶20%以上的響應(yīng)時間。使用CDN是一個只需要相對簡單地修改代碼實現(xiàn)顯著改善網(wǎng)站訪問速度的方法。
12、為文件頭指定Expires或Cache-Control
這條守則包括兩方面的內(nèi)容： 對于靜態(tài)內(nèi)容：設(shè)置文件頭過期時間Expires的值為“Never expire”（永不過期） 對于動態(tài)內(nèi)容：使用恰當(dāng)?shù)腃ache-Control文件頭來幫助瀏覽器進(jìn)行有條件的請求
網(wǎng)頁內(nèi)容設(shè)計現(xiàn)在越來越豐富，這就意味著頁面中要包含更多的腳本、樣式表、圖片和Flash。第一次訪問你頁面的用戶就意味著進(jìn)行多次的HTTP請求，但是通過使用Expires文件頭就可以使這樣內(nèi)容具有緩存性。它避免了接下來的頁面訪問中不必要的HTTP請求。Expires文件頭經(jīng)常用于圖像文件，但是應(yīng)該在所有的內(nèi)容都使用他，包括腳本、樣式表和Flash等。
瀏覽器（和代理）使用緩存來減少HTTP請求的大小和次數(shù)以加快頁面訪問速度。Web服務(wù)器在HTTP響應(yīng)中使用Expires文件頭來告訴客戶端內(nèi)容需要緩存多長時間。下面這個例子是一個較長時間的Expires文件頭，它告訴瀏覽器這個響應(yīng)直到2010年4月15日才過期。 Expires: Thu, 15 Apr 2010 20:00:00 GMT 如果你使用的是Apache服務(wù)器，可以使用ExpiresDefault來設(shè)定相對當(dāng)前日期的過期時間。下面這個例子是使用ExpiresDefault來設(shè)定請求時間后10年過期的文件頭：
ExpiresDefault "access plus 10 years"
要切記，如果使用了Expires文件頭，當(dāng)頁面內(nèi)容改變時就必須改變內(nèi)容的文件名。依Yahoo!來說我們經(jīng)常使用這樣的步驟：在內(nèi)容的文件名中加上版本號，如yahoo_2.0.6.js。
使用Expires文件頭只有會在用戶已經(jīng)訪問過你的網(wǎng)站后才會起作用。當(dāng)用戶首次訪問你的網(wǎng)站時這對減少HTTP請求次數(shù)來說是無效的，因為瀏覽器的緩存是空的。因此這種方法對于你網(wǎng)站性能的改進(jìn)情況要依據(jù)他們“預(yù)緩存”存在時對你頁面的點擊頻率（“預(yù)緩存”中已經(jīng)包含了頁面中的所有內(nèi)容）。Yahoo!建立了一套測量方法，我們發(fā)現(xiàn)所有的頁面瀏覽量中有75~85%都有“預(yù)緩存”。通過使用Expires文件頭，增加了緩存在瀏覽器中內(nèi)容的數(shù)量，并且可以在用戶接下來的請求中再次使用這些內(nèi)容，這甚至都不需要通過用戶發(fā)送一個字節(jié)的請求。
13、Gzip壓縮文件內(nèi)容
網(wǎng)絡(luò)傳輸中的HTTP請求和應(yīng)答時間可以通過前端機(jī)制得到顯著改善。的確，終端用戶的帶寬、互聯(lián)網(wǎng)提供者、與對等交換點的靠近程度等都不是網(wǎng)站開發(fā)者所能決定的。但是還有其他因素影響著響應(yīng)時間。通過減小HTTP響應(yīng)的大小可以節(jié)省HTTP響應(yīng)時間。
從HTTP/1.1開始，web客戶端都默認(rèn)支持HTTP請求中有Accept-Encoding文件頭的壓縮格式：Accept-Encoding: gzip, deflate
如果web服務(wù)器在請求的文件頭中檢測到上面的代碼，就會以客戶端列出的方式壓縮響應(yīng)內(nèi)容。Web服務(wù)器把壓縮方式通過響應(yīng)文件頭中的Content-Encoding來返回給瀏覽器。
Content-Encoding: gzip
Gzip是目前最流行也是最有效的壓縮方式。這是由GNU項目開發(fā)并通過RFC 1952來標(biāo)準(zhǔn)化的。另外僅有的一個壓縮格式是deflate，但是它的使用范圍有限效果也稍稍遜色。
Gzip大概可以減少70%的響應(yīng)規(guī)模。目前大約有90%通過瀏覽器傳輸?shù)幕ヂ?lián)網(wǎng)交換支持gzip格式。如果你使用的是Apache，gzip模塊配置和你的版本有關(guān)：Apache 1.3使用mod_zip，而Apache 2.x使用moflate。
瀏覽器和代理都會存在這樣的問題：瀏覽器期望收到的和實際接收到的內(nèi)容會存在不匹配的現(xiàn)象。幸好，這種特殊情況隨著舊式瀏覽器使用量的減少在減少。Apache模塊會通過自動添加適當(dāng)?shù)腣ary響應(yīng)文件頭來避免這種狀況的出現(xiàn)。
服務(wù)器根據(jù)文件類型來選擇需要進(jìn)行g(shù)zip壓縮的文件，但是這過于限制了可壓縮的文件。大多數(shù)web服務(wù)器會壓縮HTML文檔。對腳本和樣式表進(jìn)行壓縮同樣也是值得做的事情，但是很多web服務(wù)器都沒有這個功能。實際上，壓縮任何一個文本類型的響應(yīng)，包括XML和JSON，都值得的。圖像和PDF文件由于已經(jīng)壓縮過了所以不能再進(jìn)行g(shù)zip壓縮。如果試圖gizp壓縮這些文件的話不但會浪費CPU資源還會增加文件的大小。
Gzip壓縮所有可能的文件類型是減少文件體積增加用戶體驗的簡單方法。
14、配置ETag
Entity tags（ETags）（實體標(biāo)簽）是web服務(wù)器和瀏覽器用于判斷瀏覽器緩存中的內(nèi)容和服務(wù)器中的原始內(nèi)容是否匹配的一種機(jī)制（“實體”就是所說的“內(nèi)容”，包括圖片、腳本、樣式表等）。增加ETag為實體的驗證提供了一個比使用“l(fā)ast-modified date（上次編輯時間）”更加靈活的機(jī)制。Etag是一個識別內(nèi)容版本號的唯一字符串。唯一的格式限制就是它必須包含在雙引號內(nèi)。原始服務(wù)器通過含有ETag文件頭的響應(yīng)指定頁面內(nèi)容的ETag。
HTTP/1.1 200 OK Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT ETag: "10c24bc-4ab-457e1c1f" Content-Length: 12195
稍后，如果瀏覽器要驗證一個文件，它會使用If-None-Match文件頭來把ETag傳回給原始服務(wù)器。在這個例子中，如果ETag匹配，就會返回一個304狀態(tài)碼，這就節(jié)省了12195字節(jié)的響應(yīng)。 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的問題在于，它是根據(jù)可以辨別網(wǎng)站所在的服務(wù)器的具有唯一性的屬性來生成的。當(dāng)瀏覽器從一臺服務(wù)器上獲得頁面內(nèi)容后到另外一臺服務(wù)器上進(jìn)行驗證時ETag就會不匹配，這種情況對于使用服務(wù)器組和處理請求的網(wǎng)站來說是非常常見的。默認(rèn)情況下，Apache和IIS都會把數(shù)據(jù)嵌入ETag中，這會顯著減少多服務(wù)器間的文件驗證沖突。
Apache 1.3和2.x中的ETag格式為inode-size-timestamp。即使某個文件在不同的服務(wù)器上會處于相同的目錄下，文件大小、權(quán)限、時間戳等都完全相同，但是在不同服務(wù)器上他們的內(nèi)碼也是不同的。
IIS 5.0和IIS 6.0處理ETag的機(jī)制相似。IIS中的ETag格式為Filetimestamp:ChangeNumber。用ChangeNumber來跟蹤IIS配置的改變。網(wǎng)站所用的不同IIS服務(wù)器間ChangeNumber也不相同。 不同的服務(wù)器上的Apache和IIS即使對于完全相同的內(nèi)容產(chǎn)生的ETag在也不相同，用戶并不會接收到一個小而快的304響應(yīng)；相反他們會接收一個正常的200響應(yīng)并下載全部內(nèi)容。如果你的網(wǎng)站只放在一臺服務(wù)器上，就不會存在這個問題。但是如果你的網(wǎng)站是架設(shè)在多個服務(wù)器上，并且使用Apache和IIS產(chǎn)生默認(rèn)的ETag配置，你的用戶獲得頁面就會相對慢一點，服務(wù)器會傳輸更多的內(nèi)容，占用更多的帶寬，代理也不會有效地緩存你的網(wǎng)站內(nèi)容。即使你的內(nèi)容擁有Expires文件頭，無論用戶什么時候點擊“刷新”或者“重載”按鈕都會發(fā)送相應(yīng)的GET請求。
如果你沒有使用ETag提供的靈活的驗證模式，那么干脆把所有的ETag都去掉會更好。Last-Modified文件頭驗證是基于內(nèi)容的時間戳的。去掉ETag文件頭會減少響應(yīng)和下次請求中文件的大小。微軟的這篇支持文稿講述了如何去掉ETag。在Apache中，只需要在配置文件中簡單添加下面一行代碼就可以了：FileETag none
15、盡早刷新輸出緩沖
當(dāng)用戶請求一個頁面時，無論如何都會花費200到500毫秒用于后臺組織HTML文件。在這期間，瀏覽器會一直空閑等待數(shù)據(jù)返回。在PHP中，你可以使用flush()方法，它允許你把已經(jīng)編譯的好的部分HTML響應(yīng)文件先發(fā)送給瀏覽器，這時瀏覽器就會可以下載文件中的內(nèi)容（腳本等）而后臺同時處理剩余的HTML頁面。這樣做的效果會在后臺煩惱或者前臺較空閑時更加明顯。
輸出緩沖應(yīng)用最好的一個地方就是緊跟在之后，因為HTML的頭部分容易生成而且頭部往往包含CSS和JavaScript文件，這樣瀏覽器就可以在后臺編譯剩余HTML的同時并行下載它們。
為了證明使用這項技術(shù)的好處，Yahoo!搜索率先研究并完成了用戶測試。
16、使用GET來完成AJAX請求
Yahoo!Mail團(tuán)隊發(fā)現(xiàn)，當(dāng)使用XMLHttpRequest時，瀏覽器中的POST方法是一個“兩步走”的過程：首先發(fā)送文件頭，然后才發(fā)送數(shù)據(jù)。因此使用GET最為恰當(dāng)，因為它只需發(fā)送一個TCP包（除非你有很多cookie）。IE中URL的最大長度為2K，因此如果你要發(fā)送一個超過2K的數(shù)據(jù)時就不能使用GET了。
一個有趣的不同就是POST并不像GET那樣實際發(fā)送數(shù)據(jù)。根據(jù)HTTP規(guī)范，GET意味著“獲取”數(shù)據(jù)，因此當(dāng)你僅僅獲取數(shù)據(jù)時使用GET更加有意義（從語意上講也是如此），相反，發(fā)送并在服務(wù)端保存數(shù)據(jù)時使用POST。
17、把樣式表置于頂部
在研究Yahoo!的性能表現(xiàn)時，我們發(fā)現(xiàn)把樣式表放到文檔的內(nèi)部似乎會加快頁面的下載速度。這是因為把樣式表放到內(nèi)會使頁面有步驟的加載顯示。
注重性能的前端服務(wù)器往往希望頁面有秩序地加載。同時，我們也希望瀏覽器把已經(jīng)接收到內(nèi)容盡可能顯示出來。這對于擁有較多內(nèi)容的頁面和網(wǎng)速較慢的用戶來說特別重要。向用戶返回可視化的反饋，比如進(jìn)程指針，已經(jīng)有了較好的研究并形成了正式文檔。在我們的研究中HTML頁面就是進(jìn)程指針。當(dāng)瀏覽器有序地加載文件頭、導(dǎo)航欄、頂部的logo等對于等待頁面加載的用戶來說都可以作為可視化的反饋。這從整體上改善了用戶體驗。
把樣式表放在文檔底部的問題是在包括Internet Explorer在內(nèi)的很多瀏覽器中這會中止內(nèi)容的有序呈現(xiàn)。瀏覽器中止呈現(xiàn)是為了避免樣式改變引起的頁面元素重繪。用戶不得不面對一個空白頁面。
HTML規(guī)范清楚指出樣式表要放包含在頁面的區(qū)域內(nèi)：“和不同，只能出現(xiàn)在文檔的區(qū)域內(nèi)，盡管它可以多次使用它”。無論是引起白屏還是出現(xiàn)沒有樣式化的內(nèi)容都不值得去嘗試。最好的方案就是按照HTML規(guī)范在文檔內(nèi)加載你的樣式表。
18、避免使用CSS表達(dá)式（Expression）
CSS表達(dá)式是動態(tài)設(shè)置CSS屬性的強(qiáng)大（但危險）方法。Internet Explorer從第5個版本開始支持CSS表達(dá)式。下面的例子中，使用CSS表達(dá)式可以實現(xiàn)隔一個小時切換一次背景顏色：background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" ); 如上所示，expression中使用了JavaScript表達(dá)式。CSS屬性根據(jù)JavaScript表達(dá)式的計算結(jié)果來設(shè)置。expression方法在其它瀏覽器中不起作用，因此在跨瀏覽器的設(shè)計中單獨針對Internet Explorer設(shè)置時會比較有用。
表達(dá)式的問題就在于它的計算頻率要比我們想象的多。不僅僅是在頁面顯示和縮放時，就是在頁面滾動、乃至移動鼠標(biāo)時都會要重新計算一次。給CSS表達(dá)式增加一個計數(shù)器可以跟蹤表達(dá)式的計算頻率。在頁面中隨便移動鼠標(biāo)都可以輕松達(dá)到10000次以上的計算量。
一個減少CSS表達(dá)式計算次數(shù)的方法就是使用一次性的表達(dá)式，它在第一次運行時將結(jié)果賦給指定的樣式屬性，并用這個屬性來代替CSS表達(dá)式。如果樣式屬性必須在頁面周期內(nèi)動態(tài)地改變，使用事件句柄來代替CSS表達(dá)式是一個可行辦法。如果必須使用CSS表達(dá)式，一定要記住它們要計算成千上萬次并且可能會對你頁面的性能產(chǎn)生影響。
19、使用外部JavaScript和CSS
很多性能規(guī)則都是關(guān)于如何處理外部文件的。但是，在你采取這些措施前你可能會問到一個更基本的問題：JavaScript和CSS是應(yīng)該放在外部文件中呢還是把它們放在頁面本身之內(nèi)呢？
在實際應(yīng)用中使用外部文件可以提高頁面速度，因為JavaScript和CSS文件都能在瀏覽器中產(chǎn)生緩存。內(nèi)置在HTML文檔中的JavaScript和CSS則會在每次請求中隨HTML文檔重新下載。這雖然減少了HTTP請求的次數(shù)，卻增加了HTML文檔的大小。從另一方面來說，如果外部文件中的JavaScript和CSS被瀏覽器緩存，在沒有增加HTTP請求次數(shù)的同時可以減少HTML文檔的大小。
關(guān)鍵問題是，外部JavaScript和CSS文件緩存的頻率和請求HTML文檔的次數(shù)有關(guān)。雖然有一定的難度，但是仍然有一些指標(biāo)可以一測量它。如果一個會話中用戶會瀏覽你網(wǎng)站中的多個頁面，并且這些頁面中會重復(fù)使用相同的腳本和樣式表，緩存外部文件就會帶來更大的益處。
許多網(wǎng)站沒有功能建立這些指標(biāo)。對于這些網(wǎng)站來說，最好的堅決方法就是把JavaScript和CSS作為外部文件引用。比較適合使用內(nèi)置代碼的例外就是網(wǎng)站的主頁，如Yahoo!主頁和My Yahoo!。主頁在一次會話中擁有較少（可能只有一次）的瀏覽量，你可以發(fā)現(xiàn)內(nèi)置JavaScript和CSS對于終端用戶來說會加快響應(yīng)時 間。
對于擁有較大瀏覽量的首頁來說，有一種技術(shù)可以平衡內(nèi)置代碼帶來的HTTP請求減少與通過使用外部文件進(jìn)行緩存帶來的好處。其中一個就是在首頁中內(nèi)置JavaScript和CSS，但是在頁面下載完成后動態(tài)下載外部文件，在子頁面中使用到這些文件時，它們已經(jīng)緩存到瀏覽器了。
20、削減JavaScript和CSS
精簡是指從去除代碼不必要的字符減少文件大小從而節(jié)省下載時間。消減代碼時，所有的注釋、不需要的空白字符（空格、換行、tab縮進(jìn)）等都要去掉。在JavaScript中，由于需要下載的文件體積變小了從而節(jié)省了響應(yīng)時間。精簡JavaScript中目前用到的最廣泛的兩個工具是JSMin和YUI Compressor。YUI Compressor還可用于精簡CSS。
混淆是另外一種可用于源代碼優(yōu)化的方法。這種方法要比精簡復(fù)雜一些并且在混淆的過程更易產(chǎn)生問題。在對美國前10大網(wǎng)站的調(diào)查中發(fā)現(xiàn)，精簡也可以縮小原來代碼體積的21%，而混淆可以達(dá)到25%。盡管混淆法可以更好地縮減代碼，但是對于JavaScript來說精簡的風(fēng)險更小。
除消減外部的腳本和樣式表文件外，