Web 前端最佳化最佳實務

標籤：des   style   blog   http   io   os   使用   java   ar   

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

1. 盡量減少HTTP請求 (Make FewerHTTPRequests)

作為第一條，可能也是最重要的一條。根據 Yahoo! 研究團隊的資料分析，有很大一部分使用者訪問會因為這一條而取得最大受益。有幾種常見的方法能切實減少HTTP請求：

• 1) 合并檔案，比如把多個CSS檔案合成一個；

• 2) CSSSprites 利用CSSbackground 相關元素進行背景圖絕對定位；參見：CSS Sprites: Image Slicing’s Kiss of Death

• 3) 映像地圖

• 4) 內聯圖象 使用 data: URL scheme 在實際的頁面內嵌影像資料.

2. 減少DNS尋找 (ReduceDNSLookups)

必須明確的一點，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 ofDOMElements)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)$” { 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 forAJAXRequests)

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運算式 (AvoidCSSExpressions)

個人認為通過CSS運算式能做到的事情，通過其它手段也同樣能做到而且風險更小一些。

3. 從頁面中剝離 JavaScript 與CSS(Make JavaScript andCSSExternal)

剝離後，能夠有針對性的對其進行單獨的處理策略，比如壓縮或者緩衝策略。

4. 精簡 JavaScript 與CSS(Minify JavaScript andCSS)

如果沒有 JavaScript 與CSS可能更好。但，這是不可能的，SO，盡量小點吧。文法能簡寫的簡寫。

5. 使用 <link> 而不是@importChoose <link> over @import

在IE中 @import 指令等同於把 link 標記寫在HTML的底部。而這與第一條相違背。

6. 避免使用Filter (Avoid Filters)

 

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

1. 指令碼放到HTML字碼頁底部 (Put Scripts at the Bottom)

當一個指令碼在下載的時候，瀏覽器幹不了其它的事兒(串列了)。所以，把它扔到最後面去處理。對於一些功能性的指令碼，可能實現起來有些兩難。不過對於 國內網站來說，有很多使用 Google Analytics 服務進行網站資料分析的。這這一點來說，絕對可行的建議，放到頁面最底下。

2. Make JavaScript andCSSExternal

參見 CSS 篇的描述

3. 精簡 JavaScript 與CSS(Minify JavaScript andCSS)

參見 CSS 篇的描述

4. 移除重複指令碼 (Remove Duplicate Scripts)

對於一些曆史遺留網站或是論壇類的網站來說，這倒是比較常見的。接手維護人前後變化過多，每個人都有自己的一套。這就會帶來一些潛在的麻煩。

5. 減少DOM訪問 (MinimizeDOMAccess)

有三條指導建議:

• 緩衝已經訪問過的元素 (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 記憶體流失的問題。

 

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

對JPEG圖片的最佳化工具：

• jpegtran (http://jpegclub.org/)

必需要強調的是，圖片設計的同學啊，請考慮設計面向 Web 的圖片，不要動不動就設計超過可接受尺寸之外大傢伙，這應該是一種習慣，而不是什麼高超的技能，只需要記住就成了。

2. 使用CSSSprites 技巧對圖片最佳化 (OptimizeCSSSprites)

之前提到過，簡單的說就是”利用CSSbackground 相關元素進行背景圖絕對位置”，把多次HTTP調用變為一次調用，更多參考：CSS Sprites: Image Slicing’s Kiss of Death

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

3. 不要在HTML中使用縮放圖片 (Don’t Scale Images inHTML)

更多的時候，可能是因為偷懶而沒有製作合適大小的圖片，如果是批量處理圖片的話，可能一條 ImageMagic 命令（convert ）就能搞定 。必須提及的是，看到太多的對圖片展開很難看的頁面，救救這些頁面!

4. 用更小的並且可快取的 favicon.ico (Make favicon.ico Small and Cacheable)

更小，可緩衝，這兩條可能都不是問題。問題是，太多網站根本沒有 favicon.ico 。有的時候，判斷獨立網域名稱的 Blog 是否專業，基本看一下是否有 favicon.ico 就差不多了。

 

Web 前端最佳化最佳實務最後一部分是針對行動裝置 App的，其實只是針對 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請求。

Web 前端最佳化最佳實務