cyril.hcwang@gmail.com

網頁效能分析簡介

數據觀察

分析與改進建議

在上一個投影片中，我介紹了如何利用

xhprof 來監測 php 程式執行的速度。我最

後也提到，光看 php 程式執行速度，往往

並不能代表使用者真正的感受。

在這次投影片當中，我們將從使用者的角

度來觀看整個網頁的下載行為，並試著提

出一些改進的建議。

網站效能測試是一件很複雜的事情

使用者可能分散在世界各地

使用者上網的方式各有不同

使用者電腦效能差異

如大家所知，網路並不是可預測的，遇到塞車

的狀況並不算意外

實際運作中的主機本身也是不可預測的

不同工具顯示的數據不盡相同

外部或自建

是否可以支援完整的網頁解析與資源下載

是否可以支援透過外掛程式(如flash)下載的

資源

是否可以模擬不同的瀏覽器

是否可以模擬不同的連線方式與速度

外部

測試來源地點的選取非常重要。

難以對"模擬環境"進行測試。

自建

難以模擬不同的網路設定與狀態。

難以模擬用戶端不同的狀況。

難以模擬來自不同地區的使用者。

第一次瀏覽

用戶端快取機制通常沒有任何作用

根據研究，有接近一半的使用者在瀏覽網頁時

是沒有該網站的快取記錄(可視為第一次瀏覽)

重複瀏覽

可利用各式快取機制減少資源的要求或加快下

載速度。

免費

線上直接使用

支援多個不同的國家/區域

支援多組瀏覽器(跟測試點有關) 可支援多次存取，以確保快取機制的作用

可匯出結果

同時提供第一次瀏覽 (First view)與重複瀏覽(Repeat view)的結果

以時間軸方式呈現，方便了解時間的關係 垂直線－瀏覽器開始分析網頁 垂直線－觸發 onLoad 事件

前面提到網站效能測試是一件很複雜的事

情，因此除非你有很完整的計畫與充分的

時間，否則解除獲得的資料時需要多加小

心。舉例來說，下載時間的絕對值、或是

兩個資源下載時間的差距，都是可能產生

很大誤差的資料。我們應將精神放在整體

數據的分佈狀態，以避免落入找尋根本不

存在的問題的窘境。

www.webpagetest.org

線上網站服務器群

(www.example.com

static.example.com)分析專用網站服務器

(ap1.example.com)

除非修改程式，否則無法完全避免使用到線上網路服務器群的資源。

沒有使用壓縮功能

沒有使用圖片的壓縮

靜態內容沒有提供快取的檔頭

沒有使用 CDN

我們看到第一次瀏覽與重複瀏覽的時間分別為 7.868秒與 4.331秒，約僅減少 45% 的時間。

資料量由 2890KB減少為 92KB，減少比例為97%。

重複瀏覽所減少的時間遠低於減少的資料量。

每一條橫線代表一個資源

圖示說明

橫線－表示TCP連結時間

橫線－表示資料開始傳遞

橫線－表示資料傳遞

並不是每次傳遞資源前都

必須建立連結，這是

Keep-Alive 的作用

共下載了 109 個資源

即使對於明顯不需要使用者資訊的資源 (如圖片)，也會傳遞餅乾(Cookie)。

共下載了 104 個資源

大多數資源都沒有實際資

料的傳輸（？）

多數資源為304 ，所以沒有實際資源的下載。

每一個hostname同時最多六個請求 (跟瀏覽器有關)。

超過六個就必須等待，造成網頁下載時間的增加。

下載 Google Plus +1 按鈕的 js 與 png 圖檔

首頁上並沒有相關功能

從標準檔頭中引入

沒有使用壓縮功能

沒有圖片資源

靜態內容沒有提供快取的檔頭

沒有使用 CDN

共有 242542 個 DOM 元素。

重複瀏覽的時間幾乎沒有任何改進。

下載時間很長 (718KB)。 favicon.ico 不存在，造成額外 404.html 的

存取。

首頁下載資源過多

未使用壓縮(文字檔或圖檔) 未使用快取相關的檔頭

Cookie 的濫用

favicon.ico 不存在

404 客製化網頁的使用(濫用) 沒有使用 CDN

1. 減少首頁下載的資源2. 開啟壓縮3. 針對靜態資源使用合適的快取標頭4. 使用多網域增加同時下載的資源數5. minify js 與 css 檔6. 把 javascript 放到檔案後方引入7. 移除Google Plus +1 按鈕資源的引用8. 使用cookie-free網域來服務靜態資源9. 製作合適的 favicon.ico10. 減少 404 網頁的使用11. 現階段不建議採用CDN

前述建議1~4對首頁下載時間的影響最大，

其中第1、4點因需修改程式，所以僅針對

第2、3點施作。此外，也同時施作了第五

點。

針對特定資源開啟Apache壓縮功能

針對特定資源設定Apache快取檔頭

▪ 此作法不適用於動態資源 (如前面第二個例子api)，動

態資源應根據個別狀態使用程式設定快取檔頭。

移除 Google Plus +1按鈕資源的引用

LoadModule deflate_module modules/mod_deflate.so AddOutputFilterByType DEFLATE text/html text/plain text/xml text/x-js

text/css text/javascript

LoadModule expires_module modules/mod_expires.so <IfModule mod_expires.c>

ExpiresActive OnExpiresByType image/gif "access plus 1 months"ExpiresByType image/jpg "access plus 1 months"ExpiresByType image/jpeg "now plus 1 months"ExpiresByType image/png "access plus 1 months"ExpiresByType image/vnd.microsoft.icon "access plus 1 months"ExpiresByType image/x-icon "access plus 1 months"ExpiresByType image/ico "access plus 1 months"ExpiresByType application/javascript "now plus 1 months"ExpiresByType application/x-javascript "now plus 1 months"ExpiresByType text/javascript "now plus 1 months"ExpiresByType text/css "now plus 1 months"ExpiresDefault "access plus 1 days"

</IfModule>

檔案壓縮已啟用

圖片壓縮尚未啟用

快取已設定，但仍有不足之處

其他hostname的資源未設定快取，此一hostname為正式上線服務器，所以無法修改設定以進行測試

從外部無法完全針對模擬環境加以測試

第一次瀏覽

7.868秒 -> 6.807 秒

重複瀏覽

4.331秒 -> 3.250秒

從HTML下載完成到開始下載其他資源有一段很長的閒置時間。 雖然我們使用快取減少資源的下載，但是瀏覽器依

舊必須從硬碟"下載"這些資源。資源一多，同樣會佔用不少時間。

頁面(含JavaScript)的解析。 此外，另外一個hostname的資源又搞鬼。

網頁結構過於複雜、引用過多的資源。

不但影響第一次瀏覽，對重複瀏覽的影響也很

大。

對用戶端電腦與瀏覽器容易產生非預期的結

果。

大多技術很難提昇整體效能。

重新檢視業務需求，保留必要之功能與資源。

檢視公用引用檔，避免非共通性資源的引入。

合併資源，包含 css、js、圖片都可以採用此法。

適當採用延後載入 (post-load) 與預先載入(pre-load)。

使用內嵌式圖片。 設定快取標頭。

使用Chrome開發者工具，發現已經設定快取的圖片依舊會嘗試從網站上載入，而非直接取自於用戶端快取。

Cookie 會造成某些快取機制拒絕理應快取

的資源

好處

避免無謂的資料傳遞

(用戶端到主機端)

避免快取機制的不正常作用

作法

static.example.com

static.simg.com (假如 cookie 已經設定到 top-level domain，也就是 example.com)

1. 減少首頁下載的資源2. 開啟壓縮3. 針對靜態資源使用合適的快取標頭4. 使用多網域增加同時下載的資源數5. minify js 與 css 檔6. 把 javascript 放到檔案後方引入7. 移除Google Plus +1 按鈕資源的引用8. 使用cookie-free網域來服務靜態資源9. 製作合適的 favicon.ico10. 減少 404 網頁的使用11. 現階段不建議採用CDN

Best Practices for Speeding Up Your Web Site @ Yahoo

YSlow

歡迎指教

cyril.hcwang@gmail.com