[TOC]
當我們持續把web的能力發揮到極致的時候，讓網頁在最小開銷或等待時間下可用依然是同樣重要的問題。下面的章節說明如何優化網頁使用戶滿意。
### 優化CSS 和 Javascript傳輸
在生產環境傳輸CSS和Javascript，必須采用很多優化措施：
* 遵循?[Yahoo 性能指南](http://developer.yahoo.com/performance/)
* 使用?[smush.it](http://smush.it/)?對圖片進行無損壓縮優化。 還有，用?[YSlow](http://developer.yahoo.com/yslow/)?可以把你所有的圖片自動壓縮（【譯者注】YSlow不僅僅提供性能優化工具，還詳細說明了性能優化的34條規則，例如不要用CSS表達式、不要用空白的src或href、使用CDN、緩存AJAX響應、不要用過濾器、減少DOM元素數量等等）。
* 不要在HTML中寫內聯腳本?`<script>`?塊。 它們會阻塞頁面渲染操作，對頁面加載時間帶來破壞性的影響。
* 適當地設置緩存標題。
* 針對靜態資源，考慮單獨配置一個無cookie的子域。
* CSS 必須放在文檔的?`<head>`?部分, Javascript 必須正好放在?`</body>`?標簽的前面。
* CSS 和 JavaScript 都必須以最小化方式加載。大部分人會使用?[YUI 壓縮器](http://developer.yahoo.com/yui/compressor/)?做這件事。
* CSS 和 JavaScript 都必須?[以gzip形式傳輸](http://code.google.com/speed/page-speed/docs/payload.html#GzipCompression)。
* CSS 必須串接在一起。顯然，只有具備相同媒體類型（例如屏幕或打印）的文件才能合在一起。這里的總體目標是在加載頁面的時候減少因為依賴關系而產生的HTTP連接數。
* JavaScript 必須串接在一起。雖然用一個AJAX腳本依賴性管理器（類似于 YUI 3 Loader）可能會比較理想，但實施起來還是挺復雜的。 在這里我還是想推薦單次下載站點用到的所有腳本。（當然了，適當的緩存也是必需的，這樣可以讓文件在合理的時間內盡可能保持在本地）。
* 串接和最小化通常發生在自動build的過程中，這時候要把代碼打包用于發布或生產。有很多人用一些工具做這件事，例如?[Ant](http://ant.apache.org/)?或?[Maven](http://maven.apache.org/)?。
### 優化 JavaScript 執行
在頁面加載的時候，通常會有很多腳本等待執行，但你可以設定優先級。下面的順序就是基于用戶反饋設定的優先級：
1. 改變頁面視覺習性的腳本絕對要首先執行。這包括任何的字體調整、盒子布局、或IE6 pngfix。
2. 頁面內容初始化
3. 頁面標題、頂部導航和頁腳的初始化
4. 綁定事件處理器
5. 網頁流量分析、Doubleclick，以及其他第三方腳本
### 借力 CSS 精靈
CSS 精靈（Sprites） 基本上就是把一批圖片資源合并成單個圖片文件。然后每個部分用 CSS`background-position`?來展現。典型的 CSS 看起來是這樣的
~~~
a.expandbox { display:block; width: 75px; height: 15px; text-indent: -999px; overflow:hidden;
background: url(../img/sprite.png) no-repeat -50px -5px; }
~~~
接力 sprites 實現 :hover 懸停效果是很普遍的。這種情況下你會看到類似于這樣的定義：
~~~
a.expandbox:hover { background-position: -50px -20px; }
~~~
使用 sprites 可以減少頁面大小，也減少了HTTP連接數，這會加速頁面加載。?[在 css-tricks.com 上有更多總體性的技術和概述](http://css-tricks.com/css-sprites/)。盡可能地利用CSS 精靈總體來說是一項最佳實踐。
除了主要的sprite之外，很多開發者還會使用一個垂直方向的sprite。這個垂直方向的sprite的寬度（以及高度）會**小于或等于100px**，包含了通常一個挨著一個的圖標，諸如列表元素的著重號或對應功能的鏈接和按鈕。Yahoo 就用到了一些，[例如這個](http://l.yimg.com/a/i/ww/sp/pa-icons3.gif)。
有個注意事項就是別把sprite弄得太大，不管是高還是寬超過1000px都會導致用掉大量內存。你可以學習一下?[使用sprite的時機及內存占用](http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/)，如果需要了解更多關于創建sprite的總體性提示和技巧，請參閱?[Mozilla 開發博客](http://blog.mozilla.com/webdev/2009/03/27/css-spriting-tips/)。
### 圖片格式
你應該會用到四種主要的圖片格式，細節如下：
1. **JPEG.**?- 這種格式涵蓋了所有基于攝影的圖片，例如主頁和目錄頁推銷廣告圖片，或任何顏色數很高的圖片。
2. **PNG24.**?- 這種格式在Photoshop里用起來很方便，它輸出高顏色數圖片，并完全支持像素級的漸變透明度。相對來說，它是相當重量級的格式，達到KB級大小。它也是IE6唯一需要執行pngfix的格式。在那種情況下，本公司推薦使用?[DD_belatedPNG 腳本](http://www.dillerdesign.com/experiment/DD_belatedPNG/)?（這是一個 pngfix ，它能修正 PNG24 在 IE6 里冒出灰色或淺藍色背景的問題。它們并不總是和?`background-position`?兼容）。
在很多情況下，你可以使用GIF替代PNG24作為對IE6的應變方案。這在需要用PNG24做sprite的情況下尤其適用。所有的 pngfixes 都會特別慢而且開銷巨大，所以最好不要用它們。
3. **PNG8.**?- 在256色中可以抓取到如此多樣的顏色，所以用JPG之前嘗試一下PNG是值得的。而且，PNG比GIF有更高的可壓縮度（使用類似 pngcrush 和 pngquant的工具）。這種格式支持在幾乎所有瀏覽器中實現漸變透明度，但在IE6中那些半透明像素會顯示為100%透明。不過在很多情況下這也夠用了。它也無需運行pngfix腳本，所以對于速度是優化的。
Photoshop 無法正確輸出這些半透明文件，但是Fireworks 可以。更多細節請參閱：[http://www.sitepoint.com/png8-the-clear-winner/](http://www.sitepoint.com/png8-the-clear-winner/)
4. **透明 GIF 89a.**?- GIF 89a 提供透明度的靈活性和廣泛的瀏覽器支持，但也有限制，它不支持漸變透明度和超過256的色深。就我們的經驗而言，64的色深就可以提供質量很好的縮略圖，并保持相對小的文件大小。
所有低顏色數圖片，例如圖表或主題圖形應該用PNG8格式制作，因為它是這四種格式中具有最高文件大小效率的。PNG8是我們對于大部分網站圖形的主要推薦方案。
關于PNG格式、瀏覽器支持以及各種格式優缺點的詳細信息可以在?[這篇優秀的文章](http://calendar.perfplanet.com/2010/png-that-works/)?中找到。
如需進一步優化所有這些格式，從?[Yahoo的 Smush.It](http://smush.it/)?查看圖片可以發現縮小它們的辦法。
### 緩存
對于靜態內容，瀏覽器應該把文件在本地緩存，在合理的前提下，保留盡可能長的時間。應該較長遠期緩存的內容包括：
* CSS 和 JavaScript
* 產品圖片
* 主題圖形
* favicon.ico
* flash .swf's
* 優惠信息圖片（可能緩存時間會略短）
為了最佳緩存效果，利用http頭部的Expires。下面是一個遠期的Expires頭，它告訴瀏覽器這個響應在2015年5月15日之前都無需更新：
~~~
Expires: Thu, 15 Apr 2015 20:00:00 GMT
~~~
如果你的服務器是Apache，可以使用?`ExpiresDefault`?指令設置相對當前日期的失效日期。下面的例子設置失效日期為請求時間的一年之后：
~~~
ExpiresDefault "access plus 1 year"
~~~
http頭部的 Expires 必須設為據現在一個月到一年（遠期）之間的值。緩存只適用于那個指定的URL，所以文件名或任何資源的改變都會產生一個新的拷貝。很多開發者使用build過程來給它們的資源增加一個版本號或時間戳。每個隨后的build會開始一個全新的緩存版本，讓你在使用遠期緩存日期時無需擔心。?[Google 的這篇文章里有更多關于瀏覽器緩存的細節信息](http://code.google.com/speed/page-speed/docs/caching.html#LeverageBrowserCaching)。
### 把資源文件跨域分片[?](http://coderlmn.github.io/code-standards/#_shard_resources_across_domains "Permalink")
靜態內容當然應該由不同于HTML所在服務器的另一個域提供訪問。這是優化的方案，這樣?[對所有靜態內容的請求就無需額外的cookies頭](http://developer.yahoo.com/performance/rules.html#cookie_free)。而且為整個域編寫緩存規則也就容易得多了。（同時，當前域的任何子域會繼承當前域的cookies，所以使用全新的域是值得的）。
不過，對于足夠多的資源（特別是圖片），請求數的增加足以讓頁面加載變慢。很多瀏覽器對于他們從每個域能并發下載的資源數有比較低的限制。（在IE6和IE7，這個數字僅僅是2）。在這種情況下，我們可以把資源存放在多個子域，例如：
* static1.otherdomain.com
* static2.otherdomain.com
* static3.otherdomain.com
[Google Speed 上更多有關域分片的信息](http://code.google.com/speed/page-speed/docs/rtt.html#ParallelizeDownloads)
### 避免用IFRAME
Iframe 是能添加到指定頁面的各種元素中上開銷最大的一個。它們會阻塞頁面讓它無法觸發onload事件，直到它們加載完成。有時候它們被其他機構用來處理追蹤腳本。例如 Doubleclick floodlight 標簽就是一個 iframe，管理員可以從他們的管理面板向里面增加追蹤像素。在加入iFrame的任何情況下，它應該在window的onload事件被觸發之后再動態加入到DOM中。?[更多細節請參閱 Yahoo 的性能站點。](http://developer.yahoo.com/performance/rules.html#iframes)
### 第三方集成
#### Omniture
我們推薦在頁面加載完成（DOM ready 事件或 window 的 load事件）之后，再用 Javascript 把 Omniture Javascript 代碼加入DOM中。通過使用這個技術，可以避免外部域腳本的依賴性，這種依賴性會減慢（并可能掛起）頁面加載過程。
#### Flash
在所有情況下， Flash 的位置必須有備選的HTML內容，以使SEO值最大化。對于 XML 驅動的 Flash，備選 HTML 內容必須利用同一個 XML 文件，以確保數據的一致性。
所有替換內容必須使用 SWFObject ，但不應加入內聯腳本標簽。 SWFObject 的初始化必須在 DOM Ready 事件后觸發。最小的播放器版本必須設置為最小 v9，以確保 AS3 兼容性。
## 跨瀏覽器性能策略
談到瀏覽器體驗，有兩個主要的事實：
1. 每個人都想要可能實現的響應性最好的體驗。
2. 加到頁面上的所有內容都會使它變慢。
那么，基于這兩條人生真諦，我們需要通過什么樣的步驟讓大家滿意呢？
### 與客戶一起確定成功的性能指標
這些指標必須針對你的客戶和項目來定制，在線框圖布局階段之前完成。這些目標從技術角度必須是合理的，也是可測試的。
**可能適用的一些目標**
1. 在支持的瀏覽器中，最慢的那個也必須在5秒鐘之內完成從空白緩存到完全加載并初始化的過程。
2. 懸停狀態（以及其他實時變化）必須在100毫秒內響應。
3. 動畫必須流暢顯示，其中跳變發生的時間 < 15%（包括所有瀏覽器）。
對于加載時間的目標，定義基準系統是很重要的。類似于?[PageTest](http://www.webpagetest.org/)?的工具是個好的選擇。另外，目標也可以分開多個頁面來定義，例如：訪問量最大的兩個目標網頁（比如主頁和支持頁面）。
如果客戶對于意向設計有比合理目標更激進的目標，就必須在整個項目決策委員會中統一期望值，并讓項目組了解性能指標是最關鍵的。
### 在設計階段溝通性能的影響
**內部**
在 IA、IxD 和視覺設計階段，前端工程師是負責溝通性能對于交互特性的影響或在目標瀏覽器上采用特定的視覺技術的角色。要給出設計師的限制條件：“如果我們使用Cufon，每個頁面上用到定制字體的元素就不能超過10個。”
**外部**
需要設定期望值：?**并不是所有的瀏覽器都有相同的體驗**。它們的表現不會彼此相同，指望它們的特性完全一樣也不現實。在IE7的體驗中放棄一些新的特性也許是合理的。會考慮被放棄的一些特性可能是：?陰影、過渡、圓角、透明度、漸變色。
**當溝通某件事的影響時**
* 盡可能詳細地明確影響程度：“這對頁面加載有害” vs “這會在IE中增加2秒的頁面加載時間“
* 如有可能，提供快捷的概念驗證（Proof of Concept）：”沒有siFR的相似頁面在2秒鐘內加載，而用了siFR的用了8秒，而且在滾動時有延遲“
### 遵循最佳實踐進行開發
選擇那些性能優化的庫和插件。基于性能目標做出明智的架構決定。同時在可能的前提下盡量減少 DOM 操作，設計樣式要讓頁面在加載和初始化的時候?[避免視覺變化](http://paulirish.com/2009/avoiding-the-fouc-v3/)?。
### 在QA流程中評估性能
QA 團隊也應該把性能相關的因素和視覺、功能和可用性問題放在一起來確定優先級。開發者和 QA 必須確定如何分配優先級。在 QA 過程中，成功的指標必須定期測試。
**測試用的工具**
* [YSlow](http://developer.yahoo.com/yslow/),?[Page Speed](http://code.google.com/speed/page-speed/),?[Hammerhead](http://stevesouders.com/hammerhead/),?[MSFast](http://msfast.myspace.com/),?[PageTest](http://www.webpagetest.org/)
**如果性能指標沒有達到，有三個選擇：**
1. 代碼返工?- 重做架構，發現瓶頸，重構代碼，優化指標讓系統在瀏覽器里更快執行
2. 放棄該特性?- 只對較慢的瀏覽器關閉它
3. 重新設計用戶交互方式?- 也許新的設計會有一招搞定問題的辦法
我們認為，通過這個方法，在應對性能挑戰的過程中，項目相關各方都有更好的機會統一期望，共同前進，并形成更加行之有效的工作流程。
