舍棄@import","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"前面提到了一個最佳實踐：為了實現逐步渲染，CSS應該放在頂部。\n在iE中用@import與在底部用效果一樣，所以最好不要用它。\n\n"],[20,"13.避免使用濾鏡","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"iE專有的AlphaimageLoader濾鏡可以用來修復iE7之前的版本中半透明PNG圖片的問題。在圖片加載過程中，這個濾鏡會阻塞渲染，卡住瀏覽器，還會增加內存消耗而且是被應用到每個元素的，而不是每個圖片，所以會存在一大堆問題。\n\n\n"],[20,"14.把樣式表放在頂部","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"在Yahoo!研究性能的時候，我們發現把樣式表放到文檔的HEAD部分能讓頁面看起來加載地更快。這是因為把樣式表放在head里能讓頁面逐步渲染。\n\n"],[20,"15.去除重復腳本","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"頁面含有重復的腳本文件會影響性能，這可能和你想象的不一樣。在對美國前10大web站點的評審中，發現只有2個站點含有重復腳本。兩個主要原因增加了在單一頁面中出現重復腳本的幾率：團隊大小和腳本數量。在這種情況下，重復腳本會創建不必要的HTTP請求，執行無用的JavaScript代碼，而影響頁面性能。\n\n"],[20,"16.盡量減少DOM訪問","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"用JavaScript訪問DOM元素是很慢的，所以，為了讓頁面反應更迅速，應該：\n緩存已訪問過的元素的索引\n先“離線”更新節點，再把它們添到DOM樹上\n避免用JavaScript修復布局問題\n\n"],[20,"17.用智能的事件處理器","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"有時候感覺頁面反映不夠靈敏，是因為有太多頻繁執行的事件處理器被添加到了DOM樹的不同元素上，這就是推薦使用事件委托的原因。如果一個div里面有10個按鈕，應該只給div容器添加一個事件處理器，而不是給每個按鈕都添加一個。事件能夠冒泡，所以可以捕獲事件并得知哪個按鈕是事件源。\n\n"],[20,"18.把腳本放在底部","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"腳本會阻塞并行下載，HTTP/1.1官方文檔建議瀏覽器每個主機名下并行下載的組件數不要超過兩個，如果圖片來自多個主機名，并行下載的數量就可以超過兩個。如果腳本正在下載，瀏覽器就不開始任何其它下載任務，即使是在不同主機名下的。\n有時候，并不容易把腳本移動到底部。舉個例子，如果腳本是用document.write插入到頁面內容中的，就沒辦法再往下移了。還可能存在作用域問題，在多數情況下，這些問題都是可以解決的。\n\n"],[20,"","27:\"12\""],[20,"\n","32:3"],[20,"19.把JavaScript和CSS放到外面","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"很多性能原則都是關于如何管理外部組件的，然而，在這些顧慮出現之前你應該問一個更基礎的問題：應該把JavaScript和CSS放到外部文件中還是直接寫在頁面里？\n實際上，用外部文件可以讓頁面更快，因為JavaScript和CSS文件會被緩存在瀏覽器。HTML文檔中的行內JavaScript和CSS在每次請求該HTML文檔的時候都會重新下載。這樣做減少了所需的HTTP請求數，但增加了HTML文檔的大小。另一方面，如果JavaScript和CSS在外部文件中，并且已經被瀏覽器緩存起來了，那么我們就成功地把HTML文檔變小了，而且還沒有增加HTTP請求數。\n\n"],[20,"20.壓縮JavaScript和CSS","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"壓縮具體來說就是從代碼中去除不必要的字符以減少大小，從而提升加載速度。代碼最小化就是去掉所有注釋和不必要的空白字符（空格，換行和tab）。在JavaScript中這樣做能夠提高響應性能，因為要下載的文件變小了。兩個最常用的JavaScript代碼壓縮工具是JSMin和YUi Compressor，YUi compressor還可以壓縮CSS。\n"],[20,"\n","7:2"],[20,"\n"],[20,"21.優化圖片","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"嘗試把GiF格式轉換成PNG格式，看看是否節省空間。在所有的PNG圖片上運行pngcrush（或者其它PNG優化工具）\n"],[20,"","27:\"12\""],[20,"\n","32:3"],[20,"22.優化CSS Sprite","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"在Sprite圖片中橫向排列一般都比縱向排列的最終文件小\n組合Sprite圖片中的相似顏色可以保持低色數，最理想的是256色以下PNG8格式\n“對移動端友好”，不要在Sprite圖片中留下太大的空隙。雖然不會在很大程度上影響圖片文件的大小，但這樣做可以節省用戶代理把圖片解壓成像素映射時消耗的內存。100×100的圖片是1萬個像素，而1000×1000的圖片就是100萬個像素了。\n"],[20,"","27:\"12\""],[20,"\n","32:3"],[20,"23.不要用HTML縮放圖片","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"不要因為在HTML中可以設置寬高而使用本不需要的大圖。\n"],[20,"24.用小的可緩存的favicon.ico（P.S. 收藏夾圖標）","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"favicon.ico是放在服務器根目錄的圖片，它會帶來一堆麻煩，因為即便你不管它，瀏覽器也會自動請求它，所以最好不要給一個404 Not Found響應。而且只要在同一個服務器上，每次請求它時都會發送cookie，此外這個圖片還會干擾下載順序，例如在iE中，當你在onload中請求額外組件時，將會先下載favicon。\n所以為了緩解favicon.ico的缺點，應該確保：\n足夠小，最好在1K以下\n設置合適的有效期HTTP頭（以后如果想換的話就不能重命名了），把有效期設置為幾個月后一般比較安全，可以通過檢查當前favicon.ico的最后修改日期來確保變更能讓瀏覽器知道。\n"],[20,"","16:\"http%3A%2F%2Fwww.imagemagick.org%2F\""],[20,"\n"],[20,"","27:\"12\""],[20,"\n","32:3"],[20,"25.給Cookie減肥","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20," 使用cookie的原因有很多，比如授權和個性化。HTTP頭中cookie信息在web服務器和瀏覽器之間交換。重要的是保證cookie盡可能的小，以最小化對用戶響應時間的影響。","27:\"12\""],[20,"\n"],[20,"清除不必要的cookie","27:\"12\""],[20,"\n\n"],[20,"","27:\"12\""],[20,"\n","32:3"],[20,"26.把組件放在不含cookie的域下","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20," 當瀏覽器發送對靜態圖像的請求時，cookie也會一起發送，而服務器根本不需要這些cookie。所以它們只會造成沒有意義的網絡通信量，應該確保對靜態組件的請求不含cookie。","27:\"12\""],[20,"\n"],[20,"","27:\"12\""],[20,"\n\n"],[20,"27.保證所有組件都小于25K","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"\n這個限制是因為iPhone不能緩存大于25K的組件，注意這里指的是未壓縮的大小。這就是為什么縮減內容本身也很重要，因為單純的gzip可能不夠。\n\n"],[20,"28.把組件打包到一個復合文檔里","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"\n把各個組件打包成一個像有附件的電子郵件一樣的復合文檔里，可以用一個HTTP請求獲取多個組件（記住一點：HTTP請求是代價高昂的）。用這種方式的時候，要先檢查用戶代理是否支持（iPhone就不支持）。\n\n\n"],[20,"29.Gzip組件","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"前端工程師可以想辦法明顯地縮短通過網絡傳輸HTTP請求和響應的時間。毫無疑問，終端用戶的帶寬速度，網絡服務商，對等交換點的距離等等，都是開發團隊所無法控制的。但還有別的能夠影響響應時間的因素，壓縮可以通過減少HTTP響應的大小來縮短響應時間。\n從HTTP/1.1開始，web客戶端就有了支持壓縮的Accept-Encoding HTTP請求頭。\n如果web服務器看到這個請求頭，它就會用客戶端列出的一種方式來壓縮響應。web服務器通過Content-Encoding相應頭來通知客戶端。\n盡可能多地用gzip壓縮能夠給頁面減肥，這也是提升用戶體驗最簡單的方法。\n\n\n"],[20,"30.避免圖片src屬性為空","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"image with empty string"],[20,"src","8:1"],[20,"屬性是空字符串的圖片很常見，主要以兩種形式出現：\nstraight HTML\n"],[20,"","1:\"initial\""],[20,"\n","blockquote:true"],[20,"JavaScript\n"],[20,"var img = new image();","1:\"initial\""],[20,"\n","blockquote:true"],[20,"img.src = “”;","1:\"initial\""],[20,"\n","blockquote:true"],[20,"這兩種形式都會引起相同的問題：瀏覽器會向服務器發送另一個請求。\n"],[20,"　","27:\"12\""],[20,"\n"],[20,"31.配置ETags","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"實體標簽（ETags），是服務器和瀏覽器用來決定瀏覽器緩存中組件與源服務器中的組件是否匹配的一種機制（“實體”也就是組件：圖片，腳本，樣式表等等）。添加ETags可以提供一種實體驗證機制，比最后修改日期更加靈活。\n"],[20,"","8:1"],[20,"\n"],[20,"32.對Ajax用GET請求","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"Yahoo!郵箱團隊發現使用XMLHttpRequest時，瀏覽器的POST請求是通過一個兩步的過程來實現的：先發送HTTP頭，在發送數據。所以最好用GET請求，它只需要發送一個TCP報文（除非cookie特別多）。iE的URL長度大值是2K，所以如果要發送的數據超過2K就無法使用GET了。\nPOST請求的一個有趣的副作用是實際上沒有發送任何數據，就像GET請求一樣。所以它的語義只是用GET請求來請求數據，而不是用來發送需要存儲到服務器的數據。\n\n"],[20,"","27:\"12\""],[20,"\n"],[20,"33.盡早清空緩沖區","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"當用戶請求一個頁面時，服務器需要用大約200到500毫秒來組裝HTML頁面，在這期間，瀏覽器閑等著數據到達。PHP中有一個flush()函數，允許給瀏覽器發送一部分已經準備完畢的HTML響應，以便瀏覽器可以在后臺準備剩余部分的同時開始獲取組件，好處主要體現在很忙的后臺或者很“輕”的前端頁面上（P.S. 也就是說，響應時耗主要在后臺方面時最能體現優勢）。\n較理想的清空緩沖區的位置是HEAD后面，因為HTML的HEAD部分通常更容易生成，并且允許引入任何CSS和JavaScript文件，這樣就可以讓瀏覽器在后臺還在處理的時候就開始并行獲取組件。\n\n"],[20,"34.使用CDN（","0:\"%23d51228\"|27:\"12\""],[20,"內容分發網絡","0:\"%23d51228\"|27:\"12\"|8:1"],[20,"）","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"用戶與服務器的物理距離對響應時間也有影響。把內容部署在多個地理位置分散的服務器上能讓用戶更快地載入頁面。但具體要怎么做呢？\n實現內容在地理位置上分散的第一步是：不要嘗試去重新設計你的web應用程序來適應分布式結構。這取決于應用程序，改變結構可能包括一些讓人望而生畏的任務，比如同步會話狀態和跨服務器復制數據庫事務（翻譯可能不準確）。縮短用戶和內容之間距離的提議可能被推遲，或者根本不可能通過，就是因為這個難題。\n記住終端用戶80%到90%的響應時間都花在下載頁面組件上了：圖片，樣式，腳本，Flash等等，這是業績黃金法則。最好先分散靜態內容，而不是一開始就重新設計應用程序結構。這不僅能夠大大減少響應時間，還更容易表現出CDN的功勞。\n內容分發網絡（CDN）是一組分散在不同地理位置的web服務器，用來給用戶更高效地發送內容。典型地，選擇用來發送內容的服務器是基于網絡距離的衡量標準的。\n\n"],[20,"35.添上Expires或者Cache-Control HTTP頭","0:\"%23d51228\"|27:\"12\""],[20,"\n","32:3"],[20,"這條規則有兩個方面：\n對于靜態組件：通過設置一個遙遠的將來時間作為Expires來實現永不失效\n多余動態組件：用合適的Cache-ControlHTTP頭來讓瀏覽器進行條件性的請求\n網頁設計越來越豐富，這意味著頁面里有更多的腳本，圖片和Flash。站點的新訪客可能還是不得不提交幾個HTTP請求，但通過使用有效期能讓組件變得可緩存，這避免了在接下來的瀏覽過程中不必要的HTTP請求。有效期HTTP頭通常被用在圖片上，但它們應該用在所有組件上，包括腳本、樣式和Flash組件。\n瀏覽器（和代理）用緩存來減少HTTP請求的數目和大小，讓頁面能夠更快加載。web服務器通過有效期HTTP響應頭來告訴客戶端，頁面的各個組件應該被緩存多久。用一個遙遠的將來時間做有效期，告訴瀏覽器這個響應在2010年4月15日前不會改變。\n"]]'>

摘要：在網站建設的過程中，web前端性能的優化占著舉足輕重的地位，那么前端進行優化需要從哪些方面入手呢？雅虎前端性能團隊總結了34條優化“軍規”，不過現在已經是35條了，所以可以說是雅虎前端優化的35條軍規。在這里我進行了一下總結，大家可以閱讀一下，可以提高網頁的加載速度，同時也提高了用戶的瀏覽體驗。

1.盡量減少HTTP請求數

在網頁加載的過程中，80%的終端用戶響應時間都花在了前端上，其中大部分時間都在下載頁面上的各種組件：圖片，樣式表，腳本，Flash等等。減少組件數必然能夠減少頁面提交的HTTP請求數。這是讓頁面更快的關鍵。

合并文件是通過把所有腳本放在一個文件中的方式來減少請求數，當然，也可以合并所有的CSS。

CSS Sprites是減少圖片請求數量的選方式。把背景圖片都整合到一張圖片中，然后用CSS的background-image和background-position屬性來定位要顯示的部分。

圖像映射可以把多張圖片合并成單張圖片，總大小是一樣的，但減少了請求數并加速了頁面加載。

行內圖片（base64編碼）用data:URL模式來把圖片嵌入頁面。

減少頁面的HTTP請求數是前端優化的起點，這是提升站點首次訪問速度的重要指導原則。

2.減少DNS查找

域名系統建立了主機名和iP地址間的映射，就像電話簿上人名和號碼的映射一樣。當你在瀏覽器輸入www.yahoo.com的時候，瀏覽器就會聯系DNS解析器返回服務器的iP地址。DNS是有成本的，它需要20到120毫秒去查找給定主機名的iP地址。在DNS查找完成之前，瀏覽器無法從主機名下載任何東西。

DNS查找被緩存起來更高效，由用戶的iSP（網絡服務提供商）或者本地網絡存在一個特殊的緩存服務器上，但還可以緩存在個人用戶的計算機上。DNS信息被保存在操作系統的DNS cache(微軟Windows上的”DNS客戶端服務”)里。大多數瀏覽器有獨立于操作系統的自己的cache。只要瀏覽器在自己的cache里還保留著這條記錄，它就不會向操作系統查詢DNS。

3.避免重定向

重定向用301和302狀態碼，下面是一個有301狀態碼的HTTP頭：

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

瀏覽器會自動跳轉到Location域指明的URL。重定向需要的所有信息都在HTTP頭部，而響應體一般是空的。其實額外的HTTP頭，比如Expires和Cache-Control也表示重定向。除此之外還有別的跳轉方式：refresh元標簽和JavaScript，但如果你必須得做重定向，最好用標準的3xxHTTP狀態碼，主要是為了讓返回按鈕能正常使用。

牢記重定向會拖慢用戶體驗，在用戶和HTML文檔之間插入重定向會延遲頁面上的所有東西，頁面無法渲染，組件也無法開始下載，直到HTML文檔被送達瀏覽器。

有一種常見的極其浪費資源的重定向，而且web開發人員一般都意識不到這一點，就是URL尾部缺少一個斜線的時候。例如，跳轉到http://astrology.yahoo.com/astrology會返回一個重定向到http://astrology.yahoo.com/astrology/的301響應（注意添在尾部的斜線）。在Apache中可以用Alias，mod_rewrite或者DirectorySlash指令來取消不必要的重定向。

重定向最常見的用途是把舊站點連接到新的站點，還可以連接同一站點的不同部分，針對用戶的不同情況（瀏覽器類型，用戶帳號類型等等）做一些處理。用重定向來連接兩個網站是最簡單的，只需要少量的額外代碼。雖然在這些時候使用重定向減少了開發人員的開發復雜度，但降低了用戶體驗。一種替代方案是用Alias和mod_rewrite，前提是兩個代碼路徑都在相同的服務器上。如果是因為域名變化而使用了重定向，就可以創建一條CNAME（創建一個指向另一個域名的DNS記錄作為別名）結合Alias或者mod_rewrite指令。

4.讓Ajax可緩存

Ajax的一個好處是可以給用戶提供即時反饋，因為它能夠從后臺服務器異步請求信息。然而，用了Ajax就無法保證用戶在等待異步JavaScript和XML響應返回期間不會非常無聊。在很多應用程序中，用戶能夠一直等待取決于如何使用Ajax。例如，在基于web的電子郵件客戶端中，用戶為了尋找符合他們搜索標準的郵件消息，將會保持對Ajax請求返回結果的關注。重要的是，要記得“異步”并不意味著“即時”。

要提高性能，優化這些Ajax響應至關重要。最重要的提高Ajax性能的方法就是讓響應變得可緩存，就像在添上Expires或者Cache-Control HTTP頭中討論的一樣。

即使Ajax響應是動態創建的，而且可能只適用于單用戶，它們也可以被緩存，而這樣會讓你的Web 2.0應用更快。

5.延遲加載組件

JavaScript是分隔onload事件之前和之后的一個理想選擇。例如，如果有JavaScript代碼和支持拖放以及動畫的庫，這些都可以先等會兒，因為拖放元素是在頁面最初渲染之后的。其它可以延遲加載的部分包括隱藏內容（在某個交互動作之后才出現的內容）和折疊的圖片。

6.預加載組件

預加載可能看起來和延遲加載是相反的，但它其實有不同的目標。通過預加載組件可以充分利用瀏覽器空閑的時間來請求將來會用到的組件（圖片，樣式和腳本）。用戶訪問下一頁的時候，大部分組件都已經在緩存里了，所以在用戶看來頁面會加載得更快。

7.減少DOM元素的數量

一個復雜的頁面意味著要下載更多的字節，而且用JavaScript訪問DOM也會更慢。舉個例子，想要添加一個事件處理器的時候，循環遍歷頁面上的500個DOM元素和5000個DOM元素是有區別的。

8.跨域分離組件

分離組件可以大化并行下載，但要確保只用不超過2-4個域，因為存在DNS查找的代價。例如，可以把HTML和動態內容部署在www.example.org，而把靜態組件分離到static1.example.org和static2.example.org。

9.盡量少用iframe

用iframe可以把一個HTML文檔插入到父文檔里，重要的是明白iframe是如何工作的并高效地使用它。

10.杜絕404

HTTP請求代價高昂，完全沒有必要用一個HTTP請求去獲取一個無用的響應（比如404 Not Found），只會拖慢用戶體驗而沒有任何好處。

11.避免使用CSS表達式

用CSS表達式動態設置CSS屬性，是一種強大又危險的方式。從iE5開始支持，但從iE8起就不推薦使用了。

12.選擇<link>舍棄@import

前面提到了一個最佳實踐：為了實現逐步渲染，CSS應該放在頂部。

在iE中用@import與在底部用<link>效果一樣，所以最好不要用它。

13.避免使用濾鏡

iE專有的AlphaimageLoader濾鏡可以用來修復iE7之前的版本中半透明PNG圖片的問題。在圖片加載過程中，這個濾鏡會阻塞渲染，卡住瀏覽器，還會增加內存消耗而且是被應用到每個元素的，而不是每個圖片，所以會存在一大堆問題。

14.把樣式表放在頂部

在Yahoo!研究性能的時候，我們發現把樣式表放到文檔的HEAD部分能讓頁面看起來加載地更快。這是因為把樣式表放在head里能讓頁面逐步渲染。

15.去除重復腳本

頁面含有重復的腳本文件會影響性能，這可能和你想象的不一樣。在對美國前10大web站點的評審中，發現只有2個站點含有重復腳本。兩個主要原因增加了在單一頁面中出現重復腳本的幾率：團隊大小和腳本數量。在這種情況下，重復腳本會創建不必要的HTTP請求，執行無用的JavaScript代碼，而影響頁面性能。

16.盡量減少DOM訪問

用JavaScript訪問DOM元素是很慢的，所以，為了讓頁面反應更迅速，應該：

緩存已訪問過的元素的索引

先“離線”更新節點，再把它們添到DOM樹上

避免用JavaScript修復布局問題

17.用智能的事件處理器

有時候感覺頁面反映不夠靈敏，是因為有太多頻繁執行的事件處理器被添加到了DOM樹的不同元素上，這就是推薦使用事件委托的原因。如果一個div里面有10個按鈕，應該只給div容器添加一個事件處理器，而不是給每個按鈕都添加一個。事件能夠冒泡，所以可以捕獲事件并得知哪個按鈕是事件源。

18.把腳本放在底部

腳本會阻塞并行下載，HTTP/1.1官方文檔建議瀏覽器每個主機名下并行下載的組件數不要超過兩個，如果圖片來自多個主機名，并行下載的數量就可以超過兩個。如果腳本正在下載，瀏覽器就不開始任何其它下載任務，即使是在不同主機名下的。

有時候，并不容易把腳本移動到底部。舉個例子，如果腳本是用document.write插入到頁面內容中的，就沒辦法再往下移了。還可能存在作用域問題，在多數情況下，這些問題都是可以解決的。

19.把JavaScript和CSS放到外面

很多性能原則都是關于如何管理外部組件的，然而，在這些顧慮出現之前你應該問一個更基礎的問題：應該把JavaScript和CSS放到外部文件中還是直接寫在頁面里？

實際上，用外部文件可以讓頁面更快，因為JavaScript和CSS文件會被緩存在瀏覽器。HTML文檔中的行內JavaScript和CSS在每次請求該HTML文檔的時候都會重新下載。這樣做減少了所需的HTTP請求數，但增加了HTML文檔的大小。另一方面，如果JavaScript和CSS在外部文件中，并且已經被瀏覽器緩存起來了，那么我們就成功地把HTML文檔變小了，而且還沒有增加HTTP請求數。

20.壓縮JavaScript和CSS

壓縮具體來說就是從代碼中去除不必要的字符以減少大小，從而提升加載速度。代碼最小化就是去掉所有注釋和不必要的空白字符（空格，換行和tab）。在JavaScript中這樣做能夠提高響應性能，因為要下載的文件變小了。兩個最常用的JavaScript代碼壓縮工具是JSMin和YUi Compressor，YUi compressor還可以壓縮CSS。

21.優化圖片

嘗試把GiF格式轉換成PNG格式，看看是否節省空間。在所有的PNG圖片上運行pngcrush（或者其它PNG優化工具）

22.優化CSS Sprite

在Sprite圖片中橫向排列一般都比縱向排列的最終文件小

組合Sprite圖片中的相似顏色可以保持低色數，最理想的是256色以下PNG8格式

“對移動端友好”，不要在Sprite圖片中留下太大的空隙。雖然不會在很大程度上影響圖片文件的大小，但這樣做可以節省用戶代理把圖片解壓成像素映射時消耗的內存。100×100的圖片是1萬個像素，而1000×1000的圖片就是100萬個像素了。

23.不要用HTML縮放圖片

不要因為在HTML中可以設置寬高而使用本不需要的大圖。

24.用小的可緩存的favicon.ico（P.S. 收藏夾圖標）

favicon.ico是放在服務器根目錄的圖片，它會帶來一堆麻煩，因為即便你不管它，瀏覽器也會自動請求它，所以最好不要給一個404 Not Found響應。而且只要在同一個服務器上，每次請求它時都會發送cookie，此外這個圖片還會干擾下載順序，例如在iE中，當你在onload中請求額外組件時，將會先下載favicon。

所以為了緩解favicon.ico的缺點，應該確保：

足夠小，最好在1K以下

設置合適的有效期HTTP頭（以后如果想換的話就不能重命名了），把有效期設置為幾個月后一般比較安全，可以通過檢查當前favicon.ico的最后修改日期來確保變更能讓瀏覽器知道。

25.給Cookie減肥

使用cookie的原因有很多，比如授權和個性化。HTTP頭中cookie信息在web服務器和瀏覽器之間交換。重要的是保證cookie盡可能的小，以最小化對用戶響應時間的影響。

清除不必要的cookie

26.把組件放在不含cookie的域下

當瀏覽器發送對靜態圖像的請求時，cookie也會一起發送，而服務器根本不需要這些cookie。所以它們只會造成沒有意義的網絡通信量，應該確保對靜態組件的請求不含cookie。

27.保證所有組件都小于25K

這個限制是因為iPhone不能緩存大于25K的組件，注意這里指的是未壓縮的大小。這就是為什么縮減內容本身也很重要，因為單純的gzip可能不夠。

28.把組件打包到一個復合文檔里

把各個組件打包成一個像有附件的電子郵件一樣的復合文檔里，可以用一個HTTP請求獲取多個組件（記住一點：HTTP請求是代價高昂的）。用這種方式的時候，要先檢查用戶代理是否支持（iPhone就不支持）。

29.Gzip組件

前端工程師可以想辦法明顯地縮短通過網絡傳輸HTTP請求和響應的時間。毫無疑問，終端用戶的帶寬速度，網絡服務商，對等交換點的距離等等，都是開發團隊所無法控制的。但還有別的能夠影響響應時間的因素，壓縮可以通過減少HTTP響應的大小來縮短響應時間。

從HTTP/1.1開始，web客戶端就有了支持壓縮的Accept-Encoding HTTP請求頭。

如果web服務器看到這個請求頭，它就會用客戶端列出的一種方式來壓縮響應。web服務器通過Content-Encoding相應頭來通知客戶端。

盡可能多地用gzip壓縮能夠給頁面減肥，這也是提升用戶體驗最簡單的方法。

30.避免圖片src屬性為空

image with empty stringsrc屬性是空字符串的圖片很常見，主要以兩種形式出現：

straight HTML

<img src=””>

JavaScript

var img = new image();

img.src = “”;

這兩種形式都會引起相同的問題：瀏覽器會向服務器發送另一個請求。

31.配置ETags

實體標簽（ETags），是服務器和瀏覽器用來決定瀏覽器緩存中組件與源服務器中的組件是否匹配的一種機制（“實體”也就是組件：圖片，腳本，樣式表等等）。添加ETags可以提供一種實體驗證機制，比最后修改日期更加靈活。

32.對Ajax用GET請求

Yahoo!郵箱團隊發現使用XMLHttpRequest時，瀏覽器的POST請求是通過一個兩步的過程來實現的：先發送HTTP頭，在發送數據。所以最好用GET請求，它只需要發送一個TCP報文（除非cookie特別多）。iE的URL長度大值是2K，所以如果要發送的數據超過2K就無法使用GET了。

POST請求的一個有趣的副作用是實際上沒有發送任何數據，就像GET請求一樣。所以它的語義只是用GET請求來請求數據，而不是用來發送需要存儲到服務器的數據。

33.盡早清空緩沖區

當用戶請求一個頁面時，服務器需要用大約200到500毫秒來組裝HTML頁面，在這期間，瀏覽器閑等著數據到達。PHP中有一個flush()函數，允許給瀏覽器發送一部分已經準備完畢的HTML響應，以便瀏覽器可以在后臺準備剩余部分的同時開始獲取組件，好處主要體現在很忙的后臺或者很“輕”的前端頁面上（P.S. 也就是說，響應時耗主要在后臺方面時最能體現優勢）。

較理想的清空緩沖區的位置是HEAD后面，因為HTML的HEAD部分通常更容易生成，并且允許引入任何CSS和JavaScript文件，這樣就可以讓瀏覽器在后臺還在處理的時候就開始并行獲取組件。

34.使用CDN（內容分發網絡）

用戶與服務器的物理距離對響應時間也有影響。把內容部署在多個地理位置分散的服務器上能讓用戶更快地載入頁面。但具體要怎么做呢？

實現內容在地理位置上分散的第一步是：不要嘗試去重新設計你的web應用程序來適應分布式結構。這取決于應用程序，改變結構可能包括一些讓人望而生畏的任務，比如同步會話狀態和跨服務器復制數據庫事務（翻譯可能不準確）。縮短用戶和內容之間距離的提議可能被推遲，或者根本不可能通過，就是因為這個難題。

記住終端用戶80%到90%的響應時間都花在下載頁面組件上了：圖片，樣式，腳本，Flash等等，這是業績黃金法則。最好先分散靜態內容，而不是一開始就重新設計應用程序結構。這不僅能夠大大減少響應時間，還更容易表現出CDN的功勞。

內容分發網絡（CDN）是一組分散在不同地理位置的web服務器，用來給用戶更高效地發送內容。典型地，選擇用來發送內容的服務器是基于網絡距離的衡量標準的。

35.添上Expires或者Cache-Control HTTP頭

這條規則有兩個方面：

對于靜態組件：通過設置一個遙遠的將來時間作為Expires來實現永不失效

多余動態組件：用合適的Cache-ControlHTTP頭來讓瀏覽器進行條件性的請求

網頁設計越來越豐富，這意味著頁面里有更多的腳本，圖片和Flash。站點的新訪客可能還是不得不提交幾個HTTP請求，但通過使用有效期能讓組件變得可緩存，這避免了在接下來的瀏覽過程中不必要的HTTP請求。有效期HTTP頭通常被用在圖片上，但它們應該用在所有組件上，包括腳本、樣式和Flash組件。

瀏覽器（和代理）用緩存來減少HTTP請求的數目和大小，讓頁面能夠更快加載。web服務器通過有效期HTTP響應頭來告訴客戶端，頁面的各個組件應該被緩存多久。用一個遙遠的將來時間做有效期，告訴瀏覽器這個響應在2010年4月15日前不會改變。

當前標題：前端性能優化---雅虎前端性能團隊總結的35條黃金定律
網站URL：http://m.newbst.com/news20/310920.html

成都網站建設公司_創新互聯，為您提供網站導航、ChatGPT、商城網站、做網站、網站改版、微信公眾號

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯