16?在Ajax請求中使用GET方法?(Use?GET?for?AJAX?Requests)<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

tag:server

Yahoo!?Mail團隊發現進行XMLHttpRequest的時候，POST方法在瀏覽器中分兩步執行：先發送頭部，然后發送數據。所以最好使用只發送一個TCP包（除非你有很多的cookie）的GET方法。IE中URL的最大長度是2000，所以如果你發送超過2000的數據就不能使用GET方法。

一個有趣的現象是，POST方法并不像GET那樣實際發送數據（而Get則名副其實）。基于HTTP規范，GET方法意味著取回數據，所以當你只是請求數據時使用GET方法更為有意義（從語義上來說），而在發送需要儲存在服務器端的數據時則相反使用POST。

17?后加載組件?(Post-load?Components)

tag:content

你可以仔細端詳下你的頁面然后自問：“什么是在頁面初始化時必須的？”那么其余的內容和組件可以放在后面。

JavaScript是理想的用來分割onload事件之前和之后的選擇。例如你有執行拖放、下拉和動畫的JavaScript代碼和菜單，它們可以稍后加載，因為用戶在初始呈現之后才會在頁面上拖動元素。其他的可以被后加載的地方包括隱藏的內容（當用戶做某項操作才會展現的內容）和被折疊的圖片。

可以幫助你的工具有：?YUI?Image?Loader能幫助你延緩加載折疊的圖片，而且YUI?Get?utility能夠很簡單的包裝運行中的JS和CSS。比如，打開Firebug的網絡選項卡去查看Yahoo!?HomePage。

當性能指標和其它網站開發的好的實踐一致時是不錯的。漸進增強的觀念告訴我們當支持JavaScript時，會提高用戶體驗，但你必須確保在沒有JavaScript時頁面也能工作。所以當你確保頁面工作正常時，你會通過延后加載的那些更花哨的腳本比如拖放和動畫，來增強你的頁面。

18?預先加載組件?(Preload?Components)

tag:content

預加載看起來和后加載原則是個矛盾，但它其實是為了另外一個目的。預加載組件讓你可以利用瀏覽器的空閑時間來加載之后需要的組件（比如圖片，樣式表和腳本）。這樣當用戶瀏覽下一個頁面的時候，大部分組件都已經在緩存里了而頁面會加載的更快。

有幾種預加載的類型：

·?無條件預加載-當原本內容加載完成時，立刻開始獲取一些額外的組件。比如到google.com看下一個sprite圖片怎樣被在onload事件后請求的。在google.com的首頁里并沒有用到sprite圖片，但被用在接下來的結果頁面里。

·?有條件的預加載-根據用戶的行為來猜測用戶什么時候到達下個頁面然后據此預加載。在search.yahoo.com上，你可以看到額外的組件在你在輸入框中輸入時是怎樣被加載的。

·?有預期的加載-當登錄重新設計的網站時進行加載。你通常會在重新設計網站后聽到：“新網站很酷，但它比以前的要慢”。這個問題的部分原因是用戶訪問舊網站時有所有的緩存，而對于新的來說，緩存是空的。你可以通過在登錄重新設計的網站前預加載一些組件來緩解這方面的影響。你的舊網站可以用瀏覽器空閑的時間來請求新網站中用到的腳本和圖片。

19?減小DOM元素的數量?(Reduce?the?Number?of?DOM?Elements)

tag:content

復雜的頁面意味著更多的字節需要被下載而且也意味著在JavaScript中遍歷DOM更慢。比如你在頁面中添加一個事件，讓它在500或者5000個DOM元素中循環，它們的效率是不同的。

更多的DOM元素表明有些標簽需要被改良而并不一定需要移除實際內容。你是否為了布局而使用繁瑣的網一樣的表格？你是否只是為了彌補一些布局的問題而使用了更多的div標簽？也許還有更好和更符合語義的標簽可以使用。

YUI?CSS?utilities可以很好的幫助進行布局:grid.css?可以幫助你進行所有的布局，front.css?和?reset.css?可以幫助你去除瀏覽器默認的格式。這是你開始重新審視你的標簽的機會，比如只在語義符合時使用div標簽，而不是用它來另起一行。

DOM元素的數量很好檢測，只要在Firebug的控制臺里輸入：
document.getElementsByTagName('*').length

那么多少DOM元素算多呢？查看下類似的使用較好的標簽的頁面。比如Yahoo!?Home?Page是一個很豐富的頁面但只有700以下的DOM元素（HTML標簽）。

20?分域部署部件：Split?Components?Across?Domains

tag：內容

將部件分割能使你獲得最大的并行下載效率。但你同時需要注意不使用多于2~4個域名，以避免DNS查詢導致的問題。例如，你可以將HTML內容和動態的組建放于www.example.org域名下，將靜態組件分別放于static1.example.org和static2.example.org之下。

查看Tenni?Theurer和Patty?Chi的"Maximizing?Parallel?Downloads?in?the?Carpool?Lane"獲取更多關于并行下載的信息。

21?減少Iframe的數量?Minimize?the?Number?of?iframes

tag：內容

Iframes?能夠使HTML文檔被插入進父級文檔中。首先需要明確iframe的工作方式，才能有效的利用這一形式。

<iframe>的優點：

·?對于第三方內容，比如廣告，能夠在不影響父級設計的情況下快捷插入。

·?提供安全沙箱，不影響父級。

·?能夠并行下載腳本。

<iframe>的缺點：

·?即使是空的也會有消耗。

·?會鎖住頁面的onload事件。

·?不支持語義表達。

22?避免404錯誤?No?404s

tag：內容?

一個獲得沒用的404響應的HTTP請求對于寶貴的HTTP請求資源來說是完全不必要的，而且這樣還會減慢用戶的體驗。

有的網站提供了有幫助的404錯誤信息，比如"你是否在尋找……？"，這樣雖然能提高用戶體驗，但同樣浪費了服務端資源（比如數據庫）。尤其不妙的是在請求一個外部的Javascript腳本文件失敗時獲得的一個404錯誤，因為這樣不但會堵塞并行的下載，而且瀏覽器會嘗試分析404響應的內容，來辨識它是否是有用的Javascript代碼。

23?減少Cookie的大小?Reduce?Cookie?Size

tag：cookie

有多種理由讓我們應用HTTP?cookie，比如身份驗證，或者個性化設置。Cookie中的信息在服務端和瀏覽器間被放在HTTP頭中交換。盡量減少cookie的體積對減少用戶獲得響應的時間十分重要。

查看Tenni?Theurer和Patty?Chi的"When?the?Cookie?Crumbles"獲取更多信息。

·?去除不必要的cookie。

·?盡量減少cookie的大小。

·?留心將cookie設置在適當的域名下，避免影響到其他網站。

·?設置適當的過期時間。一個較早的過期時間或者不設置過期時間會更快的刪除cookie，從而減少用戶的響應時間。

24?為部件使用沒有cookie的域名?Use?Cookie-free?Domains?for?Components

tag：cookie

當瀏覽其請求一個靜態圖片并一同發送cookie時，服務器并不需要這些cookie。這樣只是毫無益處的創建了多余的網絡流量。應當保證靜態的部件在請求時沒有攜帶cookie，所以需要把你的靜態部件放在另一個子域名下。

如果你的域名是www.example.org，你可以將你的靜態部件放在static.example.org中。如果你把cookie設置在頂級域名example.org上而不是www.example.org，那么所有發送至static.example.org的請求會包括那些cookie。在這種情況下，你可以買一個全新的沒有cookie的域名來放置你的靜態部件。Yahoo！使用了yimg.com，YouTube試用了ytimg.com，Amazon使用的是p_w_picpaths-amazon.com。

將靜態部件放于沒有cookie的域名下的另一個好處是一些代理服務器會拒絕緩存有cookie的部件。于此相關的一點是，如果你懷疑你應該為你的首頁使用example.org還是www.example.org，考慮cookie的贏下。省略www會讓你不得不把cookie寫到*.example.org下，所以考慮性能，最好使用www.子域名，然后把cookie寫到這個子域名下。?

25?減少DOM的讀取?Minimize?DOM?Access

tag：javascript

利用Javascript讀取DOM元素很慢，所以為了獲得響應更快的頁面，你應該：

·?緩存被讀取的元素的引用。

·?脫機更新節點然后把它們加回到樹結構中。

·?避免利用Javascript定位布局。

查看Julien?Lecomte的"High?Performance?Ajax?Applications"獲得更多信息。

26?開發靈巧的事件處理程序?Develop?Smart?Event?Handlers

tag：javascript

如果有太多的事件處理邏輯部署在DOM樹的不同元素上，它們的頻繁執行會拖慢頁面的響應速度。而使用事件委托是一個好的解決方法。如果在一個Div中有10個按鈕，與其在每個按鈕上都放一個事件處理程序，步入只在Div上放一個事件處理程序。事件會冒泡上溯，這樣你就會捕獲這一事件，并找出是哪個按鈕發起的它。

同樣，你并不需要等待onload事件來啟動一些操作DOM樹的程序。你只需要保證你需要操作的元素可用就可以了。你不需要等待所有的圖片下載完畢，你應當使用DOMContentLoaded事件來替代onload事件，當然，目前并不是所有瀏覽器都支持這一事件，你可以使用YUI?Event組件，其中包含了一個onAvailable函數。

查看Julien?Lecomte的"High?Performance?Ajax?Applications"獲取更多信息。

27?選擇<link>而不是@import?Choose?<link>?over?@import

tag：css

前面提到把CSS應當放在最頂端來提供預顯。在IE中，放在頁面底部的@import和<link>效果是一樣的，所以最好不要用它。

28?不使用過濾器?Avoid?Filters

tag：css

IE專有的AlphaImageLoader過濾器是為了解決半透明真色PNG圖片在IE7之前的版本中顯示的問題。這個過濾器會在圖片下載時堵塞住展示。而且它會消耗內存并影響每個元素而不僅僅是每張圖片，所以這個過濾器的問題很多。

所以最好在IE中完全不使用AlphaImageLoader過濾器，而使用漸淡的PNG8圖片。如果你明確需要AlphaImageLoader，請使用hack?_filter，從而不影響到你的IE7+的用戶。?

29?優化圖片?Optimize?Images

tag：p_w_picpaths

當設計師制作好網站的圖片后，還有些事情應該是你在把這些圖片上傳到服務器之前做的。

·?你可以檢查GIF圖片中的調色板是否和圖片中的色彩數一致。使用p_w_picpathmagick來幫助你方便的檢查：
identify?-verbose?p_w_picpath.gif如果你看到一個4色的圖片卻有一個256色的調色板，那么還有很大的空間來做性能優化。

·?試試把GIF轉換成PNG是否會節省空間，這是常有的事情。由于瀏覽器支持的限制，開發者往往懷疑是否該使用PNG，但這是過去的事情了。唯一的問題是真色的PNG圖片的半透明問題，但同樣，GIF不是真色的而且也不支持豐富的透明效果。所以GIF可以做的，PNG或者PNG8同樣可以做到（除了動畫）。一條簡單的p_w_picpathmagick語句就可以提供可用的PNG：
convert?p_w_picpath.gif?p_w_picpath.png
“我們強調的是，給PNG一個機會！”

·?使用pngcrush或者任何的PNG優化工具，例如：
pngcrush?p_w_picpath.png?-rem?alla?-reduce?-brute?result.png

·?使用jpegtran處理JPEG圖片。這個工具會無損操作JPEG圖片，比如旋轉，而且可以用來優化圖片，比如去除圖片中的注釋和其他無用的信息（比如EXIF信息）。
jpegtran?-copy?none?-optimize?-perfect?src.jpg?dest.jpg

30?優化CSS精靈?Optimize?CSS?Sprites

tag：p_w_picpaths

·?橫向布局Sprite中的圖片往往比縱向布局會減少文件大小。

·?在一個Sprite中組合相近的顏色會降低顏色的數量，從而達到適合PNG8的低于256色的標準。

·?“對移動設備友好”，不在Sprite里留下大的空隙。這并不十分影響文件的大小，但會減少客戶端代理將圖片解壓為像素映射的內存消耗，100*100的圖片是一萬像素，而1000*1000則是一百萬像素。

31?不要在HTML中縮放圖片?Don't?Scale?Images?in?HTML

tag：p_w_picpaths

不要使用大小超過需要的圖片，即使你能夠在HTML中設置它的屬性。如果你需要

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

那么就使用恰好100*100px的圖片，而不是使用縮放后的500*500的圖片。

32?使用小的可緩存的Favicon.ico?Make?favicon.ico?Small?and?Cacheable

tag：p_w_picpaths

favicon.icon是放在服務器根目錄的一個圖片，它是個麻煩卻不得不處理，因為即使你不關心，瀏覽器依然會請求這張圖片，所以最好不要提供一個404的錯誤。而且由于它是在同一服務器下的，Cookie也會隨著每次請求一并發送。這張圖片同樣干擾下載隊列，比如在IE中，當你在onload事件中請求額外的組件時，favicon會在這些額外組件之前下載。

所以為了減少favicon.ico的不利影響，我們應當：

·?使用小圖片，小于1k為佳。

·?設置你認為合適的過期時間（因為你如果更新了圖片，你并不能修改它的名字）。你可以設置過期為未來的幾個月。你可以借鑒下你當前的favicon.ico的最后更新時間來作為設置依據。

Imagemagick能夠幫助你創建小圖片。

33?保證組件大小小于25K?Keep?Components?under?25K

tag：mobile

這一限制是因為iPone不會緩存大于25K的組件，注意這里指的是未壓縮前的大小。這就是為什么縮小大小很重要，因為單單gzip并不足夠。

查看Wayne?Shea和Tenni?Theurer的"Performance?Research,?Part?5:?iPhone?Cacheability?-?Making?it?Stick"獲取更多信息。

34?把組件打包進多部分文檔中?Pack?Components?into?a?Multipart?Document

tag：mobile

把組件打包進多部分文檔類似一封包含有附件的郵件，它能讓你通過一個HTTP請求獲取多個組件（記住HTTP請求是很昂貴的）。當你使用這一技術，請先檢查客戶端是否支持它(iPone不支持)。

轉載于:https://blog.51cto.com/yangzorder/691665

總結

以上是生活随笔為你收集整理的提高网站访问速度的34条军规(2)的全部內容，希望文章能夠幫你解決所遇到的問題。

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