前端性能優化

面向內容的優化規則目前有 10 條。

1. 儘可能減小 HTTP 請求 (Make Fewer HTTP Requests) 
做爲第一條，可能也是最重要的一條。根據 Yahoo! 研究團隊的數據分析，有很大一部分用戶訪問會由於這一條而取得最大受益。有幾種常見的方法能切實減小 HTTP 請求：

•1) 合併文件，好比把多個 CSS 文件合成一個； 
•2) CSS Sprites 利用 CSS background 相關元素進行背景圖絕對定位；參見：CSS Sprites: Image Slicing's Kiss of Death 
•3) 圖像地圖 
•4) 內聯圖象 使用 data: URL scheme 在實際的頁面嵌入圖像數據. 
2. 減小 DNS 查找 (Reduce DNS Lookups)
    必須明確的一點，DNS 查找的開銷是很大的。另外，我卻是以爲這是 Yahoo! 全部站點的通病，Yahoo！主站點可能還不夠明顯，一些分站點，存在明顯的相似問題。對於國內站點來講，若是過多的使用了站外的 Widget ，也很容易引發過多的 DNS 查找問題。

3. 避免重定向 (Avoid Redirects)
     不是絕對的避免，儘可能減小。另外，應該注意一些沒必要要的重定向。好比對 Web 站點子目錄的後面添加個 / (Slash) ，就能有效避免一次重定向。http://www.dbanotes.net/arch 與 http://www.dbanotes.net/arch/兩者之間是有差別的。若是是 Apache 服務器，經過配置 Alias 或mod_rewrite 或是 DirectorySlash 可以消除這個問題。

4. 使得 Ajax 可緩存 (Make Ajax Cacheable)
     響應時間對 Ajax 來講相當重要，不然用戶體驗絕對好不到哪裏去。提升響應時間的有效手段就是 Cache 。其它的一些優化規則對這一條也是有效的。

5. 延遲載入組件 (Post-load Components)
6. 預載入組件 (Preload Components)
      上面兩條嚴格說來，都是屬於異步這個思想靈活運用的事兒。

7. 減小 DOM 元素數量 (Reduce the Number of DOM Elements)
8. 切分組件到多個域 (Split Components Across Domains)
    主要的目的是提升頁面組件並行下載能力。但不要跨太多域名，不然就和第二條有些衝突了。

9. 最小化 iframe 的數量 (Minimize the Number of iframes)
      熟悉 SEO 的朋友知道 iframe 是 SEO 的大忌。針對前端優化來講 iframe 有其好處，也有其弊端，一分爲二看問題吧。

10. 杜絕 http 404 錯誤 (No 404s)
               對頁面連接的充分測試加上對 Web 服務器 error 日誌的不斷跟蹤能有效減小 404 錯誤，亦能提高用戶體驗。值得一提的是，CSS 與 Java Script 引發的 404 錯誤由於定位稍稍"難"一點而每每容易被忽略。

Web 前端優化最佳實踐第二部分面向 Server 。

目前共計有 6 條實踐規則。【注，這最多算技術筆記，查看最原始內容，還請訪問：Exceptional Performance : Best Practices for Speeding Up Your Web Site 】

1. 使用 CDN (Use a Content Delivery Network)
國內 CDN 的普及還不夠。不過咱們有獨特的電信、網通之間的問題，若是針對這個做優化，基本上也算能收到 CDN 或相似的效果吧(僞裝如此)。【Tin 說國內 CDN 用的挺多，看看 CDN 廠商的市場就知道了，還沒走入尋常百姓家】

2. 添加 Expires 或 Cache-Control 信息頭 (Add an Expires or a Cache-Control Header)
各個瀏覽器都有針對的方案, Apache 例子【注意：下面的說明例子還不夠精細，具體的環境上還要加一些調整】:

ExpiresActive On
ExpiresByType image/gif "modification plus 1 weeks"Lighttpd 啓用 mod_expire 模塊 後：

$HTTP["url"] =~ "\.(jpg|gif|png)___FCKpd___1quot; {
     expire.url = ( "" => "access 1 years" )
}Nginx 例子參考:

location ~* \.(jpg|gif|png)$ {
  if (-f $request_filename) {
        expires      max;
    break; 
  }        
}

3. 壓縮內容 (Gzip Components)
對於絕大多數站點，這都是必要的一步，能有效減輕網絡流量壓力。或許有人擔憂對 CPU 壓縮對於 CPU 的影響，放心大膽的整吧，沒事兒。Nginx 例子：

gzip            on;
gzip_types      text/plain text/html text/css ext/javascript;另外參見：

IIS 如何啓用 Gzip 壓縮? 
4. 設置 Etags (Configure ETags)
對於 Etag，多是多數網站維護者都會忽略的地方。在這一系列優化規則出現以前，可能互聯網上絕大多數站點都對這個問題忽略了。固然，Etag 對多數站點性能的影響並非很大。除非是面向 RSS 的網站。【看到有朋友批評說寫的簡略，而且說 IE 不支持 ETag。明確說一下：IE 支持 ETag，卻是使用 IIS 要注意相關 Etag Bug。】

補充：個人意思是"不少網站在不注意的狀況下都是打開 Etag 的，而沒有網站關心如何用，消耗資源而不知。並非說 Etag 很差，合理利用 Etag ，絕對能取得很好的收益.

5. 儘早刷新 Buffer (Flush the Buffer Early)
對這一條，琢磨了半天，貌似仍是異步的思路。能更好的提高用戶體驗?

6. 對 AJAX 請求使用 GET 方法 (Use GET for AJAX Requests)
XMLHttpRequest POST 要兩步，而 GET 只須要一步。但要注意的是在 IE 上 GET 最大能處理的 URL 長度是 2K。

Web 前端優化最佳實踐第三部分面向 Cookie 。目前只有 2 條實踐規則。

1. 縮小 Cookie (Reduce Cookie Size)
Cookie 是個頗有趣的話題。根據 RFC 2109 的描述，每一個客戶端最多保持 300 個 Cookie，針對每一個域名最多 20 個 Cookie (實際上多數瀏覽器如今都比這個多，好比 Firefox 是 50 個) ，每一個 Cookie 最多 4K，注意這裏的 4K 根據不一樣的瀏覽器可能不是嚴格的 4096 。別扯遠了，對於 Cookie 最重要的就是，儘可能控制 Cookie 的大小，不要塞入一些無用的信息。

2. 針對 Web 組件使用域名無關性的 Cookie (Use Cookie-free Domains for Components)
這個話題在此前針對 Web 圖片服務器的討論中曾經說起。這裏說的 Web 組件(Component)，多指靜態文件，好比圖片 CSS 等，Yahoo! 的靜態文件都在 yimg.com 上，客戶端請求靜態文件的時候，減小了 Cookie 的反覆傳輸對主域名 (yahoo.com) 的影響。

從這篇 When the Cookie Crumbles 能看出，MySpace 和 eBay 的 Cookie 都不小的，想必是對用戶行爲比較關心。eBay 前不久構造了 Personalization Platform ，就是從 Cookie 的限制中跳出來。

 

Web 前端優化最佳實踐第四部分面向 CSS。

目前共計有 6 條實踐規則。另請參見 Mozilla 開發者中心的文章：Writing Efficient CSS

1. 把 CSS 放到代碼頁上端 (Put Stylesheets at the Top)
官方的解釋我以爲多少有點語焉不詳。這一條其實和用戶訪問指望有關。CSS 放到最頂部，瀏覽器可以有針對性的對 HTML 頁面從頂到下進行解析和渲染。沒有人喜歡等待，而瀏覽器已經考慮到了這一點。

2. 避免 CSS 表達式 (Avoid CSS Expressions)
我的認爲經過 CSS 表達式能作到的事情，經過其它手段也一樣能作到並且風險更小一些。

3. 從頁面中剝離 JavaScript 與 CSS (Make JavaScript and CSS External)
剝離後，可以有針對性的對其進行單獨的處理策略，好比壓縮或者緩存策略。

4. 精簡 JavaScript 與 CSS (Minify JavaScript and CSS)
若是沒有 JavaScript 與 CSS 可能更好。但，這是不可能的，SO，儘可能小點吧。語法能簡寫的簡寫。

5. 使用 <link> 而不是@importChoose <link> over @import
在 IE 中 @import 指令等同於把 link 標記寫在 HTML 的底部。而這與第一條相違背。

6. 避免使用Filter (Avoid Filters)

網頁製做poluoluo文章簡介：Web 前端性能優化是個大話題，是個值得運維人員持續跟蹤的話題，是被不少網站無情忽視的技術。

Web 前端優化最佳實踐之 JavaScript 篇

這部分有 6 條規則，和 CSS 篇 重複的有幾條。前端優化最佳實踐，最重要的仍是"實踐"，要理解這東西容易得很，關鍵是要去"實踐"，去"執行"，去"反饋"，去獲取受益。

1. 腳本放到 HTML 代碼頁底部 (Put Scripts at the Bottom)
當一個腳本在下載的時候，瀏覽器幹不了其它的事兒(串行了)。因此，把它扔到最後面去處理。對於一些功能性的腳本，可能實現起來有些兩難。不過對於國內網站來講，有不少使用 Google Analytics 服務進行網站數據分析的。這這一點來講，絕對可行的建議，放到頁面最底下。

2. Make JavaScript and CSS External
參見 CSS 篇的描述

3. 精簡 JavaScript 與 CSS (Minify JavaScript and CSS)
參見 CSS 篇的描述

4. 移除重複腳本 (Remove Duplicate Scripts)
對於一些歷史遺留站點或是論壇類的網站來講，這卻是比較常見的。接手維護人先後變化過多，每一個人都有本身的一套。這就會帶來一些潛在的麻煩。

5. 減小 DOM 訪問 (Minimize DOM Access)
有三條指導建議:

•緩存已經訪問過的元素 (Cache references to accessed elements) 
•"離線"更新節點, 再將它們添加到樹中 (Update nodes "offline" and then add them to the tree) 
•避免使用 JavaScript 輸出頁面佈局--應該是 CSS 的事兒 (Avoid fixing layout with JavaScript) 
6. Develop Smart Event Handlers
除了英文解釋外，這裏也提醒一下注意關於 Java Script 內存泄漏的問題。

另外推薦一篇《如何優化 JavaScript 腳本的性能》，關於 Ajax 優化指導原則，能夠參見 提升 Ajax 應用程序性能，避開 Web 服務漏洞。

後記1) ：整理得差很少以後，發現網絡上已經有一篇 《Yahoo!網站性能最佳體驗的34條黃金守則》，是翻譯稿。看來我作了一部分重複勞動。

後記 2)：CSS / JavaScript 都有優化規則。但彷佛缺乏了對 Flash 的優化實踐。

 

Web 前端優化最佳實踐第六部分面向 圖片(Image)

這部分目前有 4 條規則。在最近的 Velocity 2008 技術大會上，Yahoo! 的 Stoyan Stefanov 作的 Image Optimization: How Many of These 7 Mistakes Are You Making 也很是有參考價值。結合一塊兒說一下。

1. 優化圖片 (Optimize Images)
使用 GIF 、JPG 仍是 PNG 格式的圖片? 儘量的使用 PNG 格式的圖片，更多的功能，更小的尺寸(與 GIF 相比)。

對於 PNG 圖片，考慮用 Pngcrush 或相似的工具進行優化。常見的工具以下表:

•pngcrush http://pmt.sourceforge.net/pngcrush/ 
•pngrewrite http://www.pobox.com/~jason1/pngrewrite/ 
•OptiPNG http://www.cs.toronto.edu/~cosmin/pngtech/optipng/ (refer: 教程) 
•PNGOut http://advsys.net/ken/utils.htm 
另請參見: Five Tips For the Effective Use of PNG Images

對 JPEG 圖片的優化工具：

•jpegtran (http://jpegclub.org/) 
必須要強調的是，圖片設計的同窗啊，請考慮設計面向 Web 的圖片，不要動不動就設計超過可接受尺寸以外你們夥，這應該是一種習慣，而不是什麼高超的技能，只須要記住就成了。

2. 使用 CSS Sprites 技巧對圖片優化 (Optimize CSS Sprites)
以前提到過，簡單的說就是"利用 CSS background 相關元素進行背景圖絕對定位"，把屢次 HTTP 調用變爲一次調用，更多參考：CSS Sprites: Image Slicing's Kiss of Death

補充一下：對於這個技巧我曾經見到有人濫用的。把多個背景圖片揉成一個，減小　HTTP 調用，這是一個很好的思路。但必定要記住這個大圖片不能太"重"，我看到過 100 多K 的背景圖。一個圖片就把整個網站拖得很慢。比較好的例子能夠參考雅虎關係的這個圖.

更新：使用 CSS Sprites 的一個潛在的反作用是客戶端將消耗更多內存(參考)。

3. 不要在 HTML 中使用縮放圖片 (Don't Scale Images in HTML)
更多的時候，多是由於偷懶而沒有製做合適大小的圖片，若是是批量處理圖片的話，可能一條 ImageMagic 命令（convert ）就能搞定 。必須說起的是，看到太多的對圖片拉伸很難看的頁面，救救這些頁面!

4. 用更小的而且可緩存的 favicon.ico (Make favicon.ico Small and Cacheable)
更小，可緩存，這兩條可能都不是問題。問題是，太多站點根本沒有 favicon.ico 。有的時候，判斷獨立域名的 Blog 是否專業，基本看一下是否有 favicon.ico 就差很少了。

--EOF--

補充：視覺設計者應該儘可能考慮控制圖片大小，推薦在 200K 如下。這不是胡說的，參考頁面。

 

Web 前端優化最佳實踐最後一部分是針對移動應用的，其實只是針對 iPhone 的，目前只有兩條規則。

1. 單個數據對象小於 25K (Keep Components under 25K)
這個彷佛只是針對 iPhone 研究的。建議保持單個 Web 數據對象在 25 K 如下。爲何是 25K? Apple 官方信息指出可緩存到內存中的 Web 對象最大支持到 10M，但通過測試，發現也就是 25K 左右。

iPhone 在市場上的優異表現，讓 Web 人員不得不考慮如何針對其進行優化。相信這部份內容也在不斷變化中。

2. Pack Components into a Multipart Document把Web 頁面組件打包成一個多部分組成的文檔。其目的是減小 HTTP 請求。