YUI前端優化以內容篇

Excetional Performance團隊總結出了一系列能夠提升網站速度的方法。能夠分爲7大類34條。包括內容、服務器、cookie、CSS、JavaScript、圖片、移動應用等七部分。
1、內容篇儘可能減小HTTP請求減小DNS查找避免跳轉緩存Ajxa推遲加載提早加載減小DOM元素數量用域名劃分頁面內容減少iframe的大小避免404錯誤

一、儘可能減小HTTP請求次數
      終端用戶響應的時間中，有80%用於下載各項內容。這部分時間包括下載頁面中的圖像、樣式表、腳本、Flash等。經過減小頁面中的元素能夠減小HTTP請求的次數。這是提升網頁速度的關鍵步驟。
      減小頁面組件的方法其實就是簡化頁面設計。那麼有沒有一種方法既能保持頁面內容的豐富性又能達到加快響應時間的目的呢？這裏有幾條減小HTTP請求次數同時又可能保持頁面內容豐富的技術。

合併文件是經過把全部的腳本放到一個文件中來減小HTTP請求的方法，如能夠簡單地把全部的CSS文件都放入一個樣式表中。當腳本或者樣式表在不一樣頁面中使用時須要作不一樣的修改，這可能會相對麻煩點，但即使如此也要把這個方法做爲改善頁面性能的重要一步。

CSS Sprites是減小圖像請求的有效方法。把全部的背景圖像都放到一個圖片文件中，而後經過CSS的background-image和background-position屬性來顯示圖片的不一樣部分；

圖片地圖是 把多張圖片整合到一張圖片中。雖然文件的整體大小不會改變，可是能夠減小HTTP請求次數。圖片地圖只有在圖片的全部組成部分在頁面中是緊挨在一塊兒的時候 才能使用，如導航欄。肯定圖片的座標和可能會比較繁瑣且容易出錯，同時使用圖片地圖導航也不具備可讀性，所以不推薦這種方法；

內聯圖像是使用data:URL scheme的方法把圖像數據加載頁面中。這可能會增長頁面的大小。把內聯圖像放到樣式表（可緩存）中能夠減小HTTP請求同時又避免增長頁面文件的大小。可是內聯圖像如今尚未獲得主流瀏覽器的支持。

     減小頁面的HTTP請求次數是你首先要作的一步。這是改進首次訪問用戶等待時間的最重要的方法。如同Tenni Theurer的他的博客Browser Cahe Usage - Exposed!中所說，HTTP請求在無緩存狀況下佔去了40%到60%的響應時間。讓那些初次訪問你網站的人得到更加快速的體驗吧！

二、減小DNS查找次數
        域名系統（DNS）提供了域名和IP的對應關係，就像電話本中人名和他們的電話號碼的關係同樣。當你在瀏覽器地址欄中輸入www.kuqin.com 時，DNS解析服務器就會返回這個域名對應的IP地址。DNS解析的過程一樣也是須要時間的。通常狀況下返回給定域名對應的IP地址會花費20到120毫秒的時間。並且在這個過程當中瀏覽器什麼都不會作直到DNS查找完畢。

       緩存DNS查找能夠改善頁面性能。這種緩存須要一個特定的緩存服務器，這種服務器通常屬於用戶的ISP提供商或者本地局域網控制，可是它一樣會在用戶使用 的計算機上產生緩存。DNS信息會保留在操做系統的DNS緩存中（微軟Windows系統中DNS Client Service）。大多數瀏覽器有獨立於操做系統之外的本身的緩存。因爲瀏覽器有本身的緩存記錄，所以在一次請求中它不會受到操做系統的影響。

      Internet Explorer默認狀況下對DNS查找記錄的緩存時間爲30分鐘，它在註冊表中的鍵值爲DnsCacheTimeout。Firefox對DNS的查找 記錄緩存時間爲1分鐘，它在配置文件中的選項爲network.dnsCacheExpiration（Fasterfox把這個選項改成了1小時）。

      當客戶端中的DNS緩存都爲空時（瀏覽器和操做系統都爲空），DNS查找的次數和頁面中主機名的數量相同。這其中包括頁面中URL、圖片、腳本文件、樣式表、Flash對象等包含的主機名。減小主機名的數量能夠減小DNS查找次數。

      減小主機名的數量還能夠減小頁面中並行下載的數量。減小DNS查找次數能夠節省響應時間，可是減小並行下載卻會增長響應時間。個人指導原則是把這些頁面中 的內容分割成至少兩部分但不超過四部分。這種結果就是在減小DNS查找次數和保持較高程度並行下載二者之間的權衡了。

三、避免跳轉
跳轉是使用301和302代碼實現的。下面是一個響應代碼爲301的HTTP頭：
      HTTP/1.1 301 Moved Permanently
      Location: http://example.com/newuri
      Content-Type: text/html
      瀏覽器會把用戶指向到Location中指定的URL。頭文件中的全部信息在一次跳轉中都是必需的，內容部分能夠爲空。無論他們的名稱，301和302響 應都不會被緩存除非增長一個額外的頭選項，如Expires或者Cache-Control來指定它緩存。<meat />元素的刷新標籤和JavaScript也能夠實現URL的跳轉，可是若是你必需要跳轉的時候，最好的方法就是使用標準的3XXHTTP狀態代 碼，這主要是爲了確保「後退」按鈕能夠正確地使用。

      可是要記住跳轉會下降用戶體驗。在用戶和HTML文檔中間增長一個跳轉，會拖延頁面中全部元素的顯示，由於在HTML文件被加載前任何文件（圖像、Flash等）都不會被下載。

      有一種常常被網頁開發者忽略卻每每十分浪費響應時間的跳轉現象。這種現象發生在當URL本該有斜槓（/）卻被忽略掉時。例如，當咱們要訪問http: //astrology.yahoo.com/astrology 時，實際上返回的是一個包含301代碼的跳轉，它指向的是http://astrology.yahoo.com/astrology/ （注意末尾的斜槓）。在Apache服務器中可使用Alias 或者 mod_rewrite或者the DirectorySlash來避免。

      鏈接新網站和舊網站是跳轉功能常常被用到的另外一種狀況。這種狀況下每每要鏈接網站的不一樣內容而後根據用戶的不一樣類型（如瀏覽器類型、用戶帳號所屬類型）來 進行跳轉。使用跳轉來實現兩個網站的切換十分簡單，須要的代碼量也很少。儘管使用這種方法對於開發者來講能夠下降複雜程度，可是它一樣下降用戶體驗。一個 可替代方法就是若是二者在同一臺服務器上時使用Alias和mod_rewrite和實現。若是是由於域名的不一樣而採用跳轉，那麼能夠經過使用Alias 或者mod_rewirte創建CNAME（保存一個域名和另一個域名之間關係的DNS記錄）來替代。

四、可緩存的AJAX
      Ajax常常被說起的一個好處就是因爲其從後臺服務器傳輸信息的異步性而爲用戶帶來的反饋的即時性。可是，使用Ajax並不能保證用戶不會在等待異步的 JavaScript和XML響應上花費時間。在不少應用中，用戶是否須要等待響應取決於Ajax如何來使用。例如，在一個基於Web的Email客戶端 中，用戶必須等待Ajax返回符合他們條件的郵件查詢結果。記住一點，「異步」並不異味着「即時」，這很重要。

      爲了提升性能，優化Ajax響應是很重要的。提升Ajxa性能的措施中最重要的方法就是使響應具備可緩存性，具體的討論能夠查看Add an Expires or a Cache-Control Header。其它的幾條規則也一樣適用於Ajax：
    Gizp壓縮文件
    減小DNS查找次數
    精簡JavaScript
    避免跳轉
    配置ETags

     讓咱們來看一個例子：一個Web2.0的Email客戶端會使用Ajax來自動完成對用戶地址薄的下載。若是用戶在上次使用過Email web應用程序後沒有對地址薄做任何的修改，並且Ajax響應經過Expire或者Cacke-Control頭來實現緩存，那麼就能夠直接從上一次的緩 存中讀取地址薄了。必須告知瀏覽器是使用緩存中的地址薄仍是發送一個新的請求。這能夠經過爲讀取地址薄的Ajax URL增長一個含有上次編輯時間的時間戳來實現，例如，&t=11900241612等。若是地址薄在上次下載後沒有被編輯過，時間戳就不變，則 從瀏覽器的緩存中加載從而減小了一次HTTP請求過程。若是用戶修改過地址薄，時間戳就會用來肯定新的URL和緩存響應並不匹配，瀏覽器就會重要請求更新 地址薄。
        即便你的Ajxa響應是動態生成的，哪怕它只適用於一個用戶，那麼它也應該被緩存起來。這樣作可使你的Web2.0應用程序更加快捷。

五、推遲加載內容
        你能夠仔細看一下你的網頁，問問本身「哪些內容是頁面呈現時所必需首先加載的？哪些內容和結構能夠稍後再加載？
        把整個過程按照onload事件分隔成兩部分，JavaScript是一個理想的選擇。例如，若是你有用於實現拖放和動畫的JavaScript，那麼它 就以等待稍後加載，由於頁面上的拖放元素是在初始化呈現以後才發生的。其它的例如隱藏部分的內容（用戶操做以後才顯現的內容）和處於摺疊部分的圖像也能夠 推遲加載
        工具能夠節省你的工做量：YUI Image Loader能夠幫你推遲加載摺疊部分的圖片，YUI Get utility是包含JS和 CSS的便捷方法。好比你能夠打開Firebug的Net選項卡看一下Yahoo的首頁。
        當性能目標和其它網站開發實踐一致時就會相得益彰。這種狀況下，經過程序提升網站性能的方法告訴咱們，在支持JavaScript的狀況下，能夠先去除用 戶體驗，不過這要保證你的網站在沒有JavaScript也能夠正常運行。在肯定頁面運行正常後，再加載腳原本實現如拖放和動畫等更加花哨的效果。

六、預加載
        預加載和後加載看起來彷佛偏偏相反，但實際上預加載是爲了實現另一種目標。預加載是在瀏覽器空閒時請求未來可能會用到的頁面內容（如圖像、樣式表和腳 本）。使用這種方法，當用戶要訪問下一個頁面時，頁面中的內容大部分已經加載到緩存中了，所以能夠大大改善訪問速度。

下面提供了幾種預加載方法：
無條件加載：觸發onload事件時，直接加載額外的頁面內容。以Google.com爲例，你能夠看一下它的spirit image圖像是怎樣在onload中加載的。這個spirit image圖像在google.com主頁中是不須要的，可是卻能夠在搜索結果頁面中用到它。
有條件加載：根據用戶的操做來有根據地判斷用戶下面可能去往的頁面並相應的預加載頁面內容。在search.yahoo.com中你能夠看到如何在你輸入內容時加載額外的頁面內容。
有預期的加載：載 入從新設計過的頁面時使用預加載。這種狀況常常出如今頁面通過從新設計後用戶抱怨「新的頁面看起來很酷，可是卻比之前慢」。問題可能出在用戶對於你的舊站 點創建了完整的緩存，而對於新站點卻沒有任何緩存內容。所以你能夠在訪問新站以前就加載一部內容來避免這種結果的出現。在你的舊站中利用瀏覽器的空餘時間 加載新站中用到的圖像的和腳原本提升訪問速度。

七、減小DOM元素數量
        一個複雜的頁面意味着須要下載更多數據，同時也意味着JavaScript遍歷DOM的效率越慢。好比當你增長一個事件句柄時在500和5000個DOM元素中循環效果確定是不同的。
       大量的DOM元素的存在乎味着頁面中有能夠不用移除內容只須要替換元素標籤就能夠精簡的部分。你在頁面佈局中使用表格了嗎？你有沒有僅僅爲了佈局而引入更多的<div>元素呢？也許會存在一個適合或者在語意是更貼切的標籤能夠供你使用。
        YUI CSS utilities能夠給你的佈局帶來巨大幫助：grids.css能夠幫你實現總體佈局，font.css和reset.css能夠幫助你移除瀏覽器默 認格式。它提供了一個從新審視你頁面中標籤的機會，好比只有在語意上有意義時才使用<div>，而不是由於它具備換行效果才使用它。
      DOM元素數量很容易計算出來，只須要在Firebug的控制檯內輸入：
document.getElementsByTagName('*').length
        那麼多少個DOM元素算是多呢？這能夠對照有很好標記使用的相似頁面。好比Yahoo!主頁是一個內容很是多的頁面，可是它只使用了700個元素（HTML標籤）。

八、根據域名劃分頁面內容
      把頁面內容劃分紅若干部分可使你最大限度地實現平行下載。因爲DNS查找帶來的影響你首先要確保你使用的域名數量在2個到4個之間。例如，你能夠把用到 的HTML內容和動態內容放在www.example.org上，而把頁面各類組件（圖片、腳本、CSS)分別存放在 statics1.example.org和statics.example.org上。
你可在Tenni Theurer和Patty Chi合寫的文章Maximizing Parallel Downloads in the Carpool Lane找到更多相關信息。

九、使iframe的數量最小
      ifrmae元素能夠在父文檔中插入一個新的HTML文檔。瞭解iframe的工做理而後才能更加有效地使用它，這一點很重要。
<iframe>優勢：

解決加載緩慢的第三方內容如圖標和廣告等的加載問題Security sandbox並行加載腳本

<iframe>的缺點：

即時內容爲空，加載也須要時間會阻止頁面加載沒有語意

十、不要出現404錯誤
      HTTP請求時間消耗是很大的，所以使用HTTP請求來得到一個沒有用處的響應（例如404沒有找到頁面）是徹底沒有必要的，它只會下降用戶體驗而不會有一點好處。
      有些站點把404錯誤響應頁面改成「你是否是要找***」，這雖然改進了用戶體驗可是一樣也會浪費服務器資源（如數據庫等）。最糟糕的狀況是指向外部 JavaScript的連接出現問題並返回404代碼。首先，這種加載會破壞並行加載；其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分當 做JavaScript代碼來執行。