解決網站效能問題的關鍵做法（上）

直接花錢解決效能問題是下下策。通常是在現有資源限制下已經優化得差不多了，才會列入軟硬體擴充預算規畫，否則只是將問題延後處理罷了。
善用工具尋求專長的建議解也是不錯的方式，例如現今坊間的一些效能分析工具，提供了專家知識庫建議的功能。

面對網頁內容傳輸時間過長的問題

會發生網路傳輸時間過長的現象，主要是因為網頁本身及所包含的檔案內容較大，相對花費在傳輸上的時間就會變長，尤其當遇到網路頻寬較有限的環境，這樣的現象會更加明顯，可針對網頁內容構成元素來逐一檢視。問題大致可分成以下幾類：

圖片檔案或Flash特效元件過大

若你利用前篇文章提到的效能分析工具（像是FireBug等）追蹤後得知，頁面中過多的內容元素需要花上較長時間來完成資料回應，首先你可以先思考這些元素的內容大小是否合適。

一般而言，以一個100 × 100 pixels的圖檔，大小通常約在3到5KB範圍內，而250 × 250 pixels的圖檔，也要儘可能限定在20KB以內。Flash的元件大小也應在合理的範圍內。至於後臺的上稿介面，也應該加入上傳檔案大小上限值的檢查機制，以免不慎使用，造成前臺效能變差。

若圖檔或Flash元件過大，而且這些圖檔元件內容是透過網站管理人員由後臺介面進行上傳（例如黃金廣告版面圖片，活動頁面中的主視覺圖，文章內容頁面的插圖等），需要針對圖檔內容解析度及壓縮格式進行再最佳化，運用坊間常見的影像處理工具軟體，即可以解決。

若團隊裡沒有熟悉此類工具的好手，也可利用像是Yahoo提供的線上圖檔處理工具Smush.it快速處理亦可。它可以結合YSlow工具直接顯示最佳化後省下的K數大小，可同時處理多個檔案，讓使用者更清楚改善的程度。

像是運用在網站活動網頁的主視覺圖片，圖檔會很大，一般處理方式都是將一大圖切割成多個小圖，可同時利用多個Request來同時下載。另外，切圖的方式則需要考慮到，讓同一個圖檔內顏色種類盡可能單純，才能發揮圖檔本身壓縮的效益。

如果真的優化空間有限，亦可考慮將圖檔以交錯式（Interlace）技術來處理。這是指瀏覽器在載入圖檔時是隔行方式下載，像是電視掃描線，可讓使用者在瀏覽網頁時逐步顯示圖片內容，在未全部載入時即可預先看圖，因此有較佳的使用者體驗。

若圖檔是透過系統自動化處理（像是相簿服務），則程式所使用的處理邏輯及演算法需要再重新檢視；或者是因所選用的顯像處理套件先天的限制使然，需要重新評估選用合適的方案。像是開源專案中的jmagick就是常被運用的解決方案，在圖檔處理上具備較佳效率及品質，亦獲得許多知名網站使用上的肯定。

Javascript、CSS檔案內容過大

運用Ajax、jQuery技術處理網頁特效愈來愈普遍，網頁中包含大量的JavaScript程式已經是常態，但網站在不斷地改版及功能強化的演化過程中，時常會造成引用的JavaScript檔案逐漸增多，載入速度漸行漸緩的現象。

另外常見的不良現象是同一頁面引用載入了重複的Script檔案內容，而且甚至相同的邏輯被重複執行，浪費下載及執行時間。請檢視一下你目前網站所使用的Script程式內容，看看那些函式已經是不會再呼叫的？有那些外部檔案已經是不會再引用的，整理一下吧！

另一種立即見效的作法是，直接啟動網站伺服器端的gzip機制，提供傳輸內容壓縮的功能，像是Apache的mod_deflate。

透過壓縮傳輸內容這個解法，針對網頁中包含大量文字內容的效果尤其顯著，壓縮比甚至可達80％以上，即100KB壓縮後，僅僅不到20KB。不管是HTML、JavaScript、CSS、TXT，都會受到有效壓縮。再加上現今市場的幾大主流瀏覽器，均可支援gzip功能，故可考慮利用相對廉價的CPU效能，來換取傳輸速度。

大部分頁面所需要的JavaScript程式，並不需在頁面載入時立即執行，所以頁面所需的Script檔案，也可以置於網頁的最末段，讓內容放在頁面載入的最後階段傳輸，至少先完成頁面呈現，使用者瀏覽時因等候JavaScript下載的感受，就不致於那麼明顯。

資料交換傳輸量過大

因Ajax流行之故，不少網站在制定API資料交換規格時都以XML格式定義，不但資料長度較長，而且XML資料的處理效率有先天上的限制，當面臨巨量資料在效能表現上更是令人失望。早期若不當使用Web Service方式來開發資料交換介面，也會有類似的狀況發生，因為訊息內容過於冗長，也會造成傳輸時間變長。

在資料交換的技術規格上，近期業界逐漸以JSON格式取代XML，其簡明的資料結構，明顯比XML方式的定義為短，而且前端瀏覽呈現目前亦有專屬套件可以直接剖析處理，在資料長度及處理速度上皆優於XML，你可以往這方面思考改善。

使用Ajax進行資料交換還要注意一件事。若盡可能地採用HTTP GET的方式，來促使Cache效益的發揮，也是節省傳輸時間的方式，主要可運用在一些資料來源異動頻率較低的查詢上。

此外，Cookie運用在網站設計中已經是十分常見，但若未能有效的控管內容長度，每個Request都會將Cookie內容隨同發至伺服器端，累積起來亦花上可觀的傳輸時間。由於不見得每個請求都需要將Cookie內容同步提交，所以我們最好能重新審視Cookie變數，或是透過不同網域的方式來區分Cookie的用途。

常見的例子，像是將圖片網址以有別於主網站網址的不同網域來定義，在請求這些圖片時，就可避免送出主網站才需要用到的Cookie內容，浪費無謂傳輸時間。

網頁內容延後載入的做法

延後載入（Lazy Loading）的概念並不新，只是實務上還不常見，但像是在Facebook、Plurk都大量運用。在頁面捲動時再載入所需顯示的內容，可避免網頁在首次載入大量資料造成效能問題。

因頁面效果所額外需要的圖檔，其下載時機是否適當，則需視內容被使用者瀏覽的使用行為來決定載入的時間點。例如，在網物網站內常見當使用者游標移至商品圖片上，會再浮現一圖層顯示放大圖片特寫，這樣的功能需求，就可以在Mouse Over時，再立即時到伺服器端取得該圖檔，而不在頁面一開啟時即下載所有的圖檔，浪費多餘的時間。

另外一項較進階的做法，則是等到使用者捲動頁面至可視範圍時，才動態載入範圍內所需要的圖檔內容。這樣，在開啟頁面時，可以不需要在第一時間即下載整個頁面所需的圖檔。這個做法適用於網站的頁面中包含較大量的圖片數，而且頁面長度較長的內容，像是內容網站中圖文並茂的開箱文，或是購物網站的分類頁商品列表的頁面等。較常見搭配的套件，像是Lazy Load Plugin for jQuery、YUI的ImageLoader等。

一樣的觀念也可以運用在HTML DOM文件。在頁面初始的內容不會在一開始就完全載入，而是在該元件受到點選時才載入內容，像是針對一些選項很多的下拉選單（常見的像是地址──縣、市、區，新聞網站的文章列表下拉選單等），亦可搭配像是Lazy Ready Plugin for jQuery的套件來達到。