2016年8月19日 星期五

[ASP.NET C#] 改善網頁下載時間的最佳做法

Reference：http://mydiamond.pixnet.net/blog/post/10608252-%E6%94%B9%E5%96%84%E7%B6%B2%E9%A0%81%E4%B8%8B%E8%BC%89%E6%99%82%E9%96%93%E7%9A%84%E6%9C%80%E4%BD%B3%E5%81%9A%E6%B3%95

網頁效能不佳時，通常會有以下幾個考量點。
1.網路問題
2.硬體設備
3.程式設計不佳
4.資料庫效能不佳
關於程式方面的考量，可參考下列內容。這裡提供許多程式面的設計觀念，以及檢測效能的工具值得深入研究。
----------------------------------------------------------------------------------------------------------------------------------------

改善網頁下載時間的最佳做法作者：Cody Lindley | 2010 年 6 月 11 日

眼前的問題很簡單：在開發網頁時，導入哪一個最佳化的做法影響最鉅？這在網頁開發領域，劃分在下載時間最佳化中。這篇文章將檢驗幾個重要的下載時間最佳化，以便開發出更快速的網站。
在另一篇文章裡，我會介紹執行時期的最佳化。執行時期最佳化聚焦在頁面效能最佳化，也就是下載到用戶端（例如瀏覽器）之後的效能。它尤其關切頁面下載後，使用者參與的互動和使用經驗。不過，在本篇文章中，我們將先專注在頁面下載的最佳化。下載時間最佳化在降低下載頁面，以及後續頁面所需時間上，表現的很好。
在正式開始之前，我想提出一個建議。使用測量工具來檢測下載時間。我知道特別指出一個顯而易見的道理，聽起有點笨，但是測量實在是太重要了。在我的經驗中，很多開發人員忘了要測量網頁的效能。所以，請把測量網頁效能當作是身為網頁開發者的例行工作。
我使用的測量工具，可以到 http://www.webpagetest.org 網站中找到，另外你也可以在 "Web Page Test" done on the homepage of this site 這篇文章中，快速瀏覽這個測量工具。
"Web Page Test" 是用來測量頁面下載的時間。而上面說的工具不只能拿來測試下載時間，也可以用來診斷頁面下載緩慢的原因。總之，它提供必要的細節，可以讓你知道 HTML 頁面下載時，時間消耗的訊息，包括檔案大小、http 請求和產生文件等。
線上版的 "Web Page Test" 可以詳細查看下載時 HTTP 的各種活動。它會將這些活動轉成各種表單、圖片和視覺化元素和報表等，讓你了解 HTTP 請求時，所有發生的事。此外，它也提供了 HTTP 請求的深入資訊，整體來說，每個涉及部分的關聯就在整體下載時間。
老實說，這個工具簡單到只要看過網站介紹就會用。假如你讀這篇文章時，主要在尋找效能瓶頸的解決之道，而不是這個工具提供的功能和相關資訊，建議你就開始用它就對了。你可以打開瀏覽器，然後選擇 "Web Page Test" 來測試網頁。假如你還需要進一步的介紹，建議你可以看 Dave Artz 的screencast。Dave 是 AOL 網站最佳化的總監，所以他應該知道一些對我們有幫助的事。
這個測量工具雖然是我的最愛，但不見得就適合你，因此，我再介紹幾個類似的工具。
下列的清單是下載時間最佳的化替代測量工具。我自己結合使用前面提過AOL的“Web Page Test”和下面這些工具，從中獲益許多。
  • YSlow 由 Yahoo 提供 (firefox 外掛)
  • Page Speed 由 Google 提供 (firefox 外掛)
  • Pingdom Tools 全頁測試 (線上工具)
  • FireBug 網路 tab (Firefox外掛)
  • Web Developer Tools (內建於 Safari和Chrome)
現在我們已經有測量工具，我們就可以來進行最佳化的測試，以及找出最佳化的時機。讓我們看一些實際網頁最佳化的例子。
我喜歡讓事情簡單、容易消化，所以我們從一推最佳化技術中挑出五類。這些類別分別是：減少 HTTP 請求、減少檔案大小、基於速度考量來引入檔案順序、分散下載、檢查伺服器反應時間。

減少 HTTP 請求

這個最佳化的目的很簡單，就是在減少網頁請求的檔案數量。藉由減少圖片、CSS 和腳本程式，可以避免瓶頸發生在瀏覽器下載（HTTP 請求）的階段。
在開發網頁時，我們應該致力減少 HTTP 請求，達到這個目的可以藉由下面這些方法：
  1. 使用 CSS Sprite。使用 CSS sprite 這項技術就是將多張圖片組合在一張圖中。這樣做就可以避免一張圖就發出一次 HTTP 請求。使用一個 sprite 我們可以在一次 HTTP 請求中，下載多個影像元素。
  2. 上線部署時，將類似的外部檔案合併。在開發階段，CSS 和 JavaScript 維持分散的模組架構是合理的。不過，一旦要從開發階段部署上線時，就該將模組合併，成為單一的檔案（或者至少儘可能地減少檔案數量），以降低 HTTP 請求。有許多工具可以用來壓縮 CSS 和 JavaScript，並且將多檔合併。當然，這個要手工達到合併的目的也是可行的。不過在我自己的專案中，我會利用 minify 這個工具協助我自動化的合併。  

減少檔案大小

這應該沒什麼意外之處。小檔案下載、解析都比大檔案快。知道這點，我們就應該努力為檔案大小瘦身（包含圖片、CSS、JS 和 html 檔），降到可接受的最小尺寸，可以為我們帶來加速的效果。下面，我們將檢視五個可以減少檔案尺寸的方法：
  1. 壓縮 CSS 和 JavaScript 檔。CSS、JavaScript 在多檔合併後，應該進一步壓縮。壓縮的動作會移除註解、空白處以及縮短變數名稱。許多工具都提供不同程度的壓縮功能。不過某些壓縮率較高的工具，可以在壓縮 CSS 和 JavaScript 檔案時，帶來更好的效果。我個人使用過 minify、YUI compressor、shrinksafe 和 Closure Compiler。這些工具功能複雜，其實用簡單的工具也能達到相同目的，不過還是有值得推薦的地方。舉例來說，有些工具提供了線上壓縮功能（例如 Shrinksafe 和YUI Compressor）。).
  2. 選擇適當影像格式，並且壓縮到可接受的最小尺寸。並非所有的圖片格式都是一樣的，也不是所有的圖片格式都適用於各種情況。知道什麼時候該使用 .gif、.jpeg 或是 .png，是需要一點判斷的藝術。在各種處理圖片的複雜情境中，包含了像是透明度。由於瀏覽器對透明影像的支援不一，在選用時就必須考量各種情況。設計影像要設想的複雜情況，以及針對瀏覽器找出最佳的圖片格式等，所需的知識深度已經超過這篇文章的範圍，我建議可以利用 Google 找出這方面相關的文章，學習在什麼時機、什麼原因以及如何使用特定的影像格式。一旦找出適合的格式之後，下一步就是削減影像大小到可接受的最小尺寸。我會用像 pngcrush 和 smush.it 這樣的工具達到這個目的。當然 Photoshop 及 Fireworks 也可以做這些事。在我的經驗中，Fireworks 的壓縮影像效果做得比較好。這裡的關鍵概念就是確保影像有壓縮過，而使用的影像格式是最適合的。
  3. 除非必要，別輕易使用 Flash。Flash 是個好工具，前提是它必須有清楚、合理的使用目的。為了使用 Flash 而 Flash 時，它就是個昂貴的決定，為了執行 .swf 檔，它必須在瀏覽器安裝外掛（Flash player）。在適當的情況，Flash 是個救星。但請不要忘記 Flash 的昂貴成本。在我觀察，.swf 檔是所有網頁依存檔案中，體積相對較大的。此外，Flash 嵌置在網頁中，通常必須多做點程式上的額外負擔，來處理沒有適當 Flash 播放器版本的情況。我先聲明清楚，我不是一個痛恨 Flash 的人。我只是建議在沒有窮盡其他可能性之前，不要放棄那些檔案尺寸比 Flash 小的方案（像是 JavaScript）。
  4. 別讓 DOM 過於複雜。如果你還在使用表格來編輯 HTML 的版面，這個主題就是針對你而來。我並不想在這裡宣揚一些教條，然而，HTML 文件大小會影響到下載時間。其實減少 HTML 實際的元素數量，並不需要過份看待。這個削減的技巧，主要還是要讓 DOM 保持簡單。所以，維持能把事情做好的最低量標籤，有助於維持頁面語義，對於 SEO 的效果也更好。
  5. 移除 HTML 文件中不必要的空白。信不信由你，這就是我接下來要討論的。我曾見過一個包含大量空白的 HTML 頁面，在移除空白之後，縮減了將近 90K 的尺寸。不要加入不必要的元素導致頁面尺寸膨脹，移除掉頁面的空白處，或者至少意識到它會增加頁面無謂的大小。我們壓縮 CSS 和 JavaScript 以達到最佳化的目的，為什麼不也移除不必要的空白，降低 HTML 文章的大小呢？
  6. 把文字檔壓縮成 Gzip。當你看見 GZip 一詞，我要接下來要談的就是壓縮文字內容的檔案，讓傳輸過程中降低資料量。HTML、CSS 和 JavaScript 都是文字檔案。這些檔案都可以在伺服器上壓縮編碼為 Gzip 的格式，然後傳到瀏覽器後再自動解開。使用 Gzip 需要一點伺服器端的知識。想要進一步了解這方面的細節，可以看 "Better Explained" 這篇文章，或者和往常一樣，使用 Google 來搜尋 Gzip 這方面的主題。

基於速度考量來引入檔案順序

信不信由你，網頁引入相關檔案的順序，會直接影響到瀏覽器需要花多少時間來產生及載入頁面。這和瀏覽器管理 HTTP 請求有關。特別是瀏覽器在進行 HTTP 請求時，相關的各種檔案（例如 .css 相對於 .js）的處理方式。底下我將討論兩個改變引入順序就能改善頁面下載時間的技巧。
  1. 在頁面底部引入 JavaScript。網頁瀏覽器一遇到下載 JavaScript，就會停止產生頁面，直到整個下載完為止。這有可能會造成瀏覽器在產生頁面時相當慢。當你把 JavaScript 移到頁面底部後，使用者馬上就能看到頁面產生速度快上許多。這一樣來，使用者對頁面載入速度的看法，應該就會變成「怎麼那麼快！」。
  2. 在頁面上方（Header 區塊）引入 CSS。 讓使用者儘快可以看到資訊，就是這裡的關鍵。讓 CSS 檔案置於網頁上方，頁面就能依序展現，使用者就能越快看到內容。

分散下載

分散下載會是一個非常複雜的議題。一般而言，網頁瀏覽器在一個網域名稱中，只會啟用一定的連線數。假如我們把檔案分散到三、四個網域中，瀏覽器會同時啟用各個連線，一次將相關檔案從不同的伺服器中拉過來。當然，當中有些限制。你可以看看 browserscope 網站的資訊 ，它有各個瀏覽器的支援情況。要分散下載，取得同時作用的連線，我們可以用下面這些方法來改善：
  1. 使用 CDN。為了讓瀏覽器分散下載，我們可以借助內容傳送網絡（content delivery network，CDN）機制來提升。它不僅僅分散下載，也會同時提供多個分散於各地的網站伺服器，能讓使用者存取地理位置最接近的伺服器。
  2. 使用次網域偽裝 CDN。一個取代 CDN 或買更多網域的替代方案，是用次網域來偽裝 CDN。次網域能提供同時下載所需的唯一 URL。
  3. 透過免費 CDN 的免費工具來提升。如果情況允許的話，就將相關檔案放置在免費的 CDN。舉例來說，Google 的人很友善地提供了 CDN，在上面放置了許多常用的 JavaScript 函式庫。如果使用這些 CDN 是合理的情況，我們就應該好好利用這些免費的服務，加速下載時間。

檢查伺服器反應時間

不是所有的事都和用戶端（像是 Web 瀏覽器）可以多快載入、解析 HTML 頁面有關。伺服器也扮演了重要的角色。在你最佳化用戶端之前，確認一下伺服器端有沒有瓶頸，也是合理的作法。舉例來說，這些議題可能包含過於複雜的 SQL 查詢、資料庫模型有問題、伺服器超載、或是應用程式架構不佳等。
一般而言，假如網頁下載速度慢，就要先確認不是由伺服器造成的。我曾經遇過一個狀況，無論最佳化怎麼調校，速度仍然難以接受。後來才發現是由伺服器造成的。用戶端的最佳化能加速下載時間到一定的程度，但是當伺服器要花上 7、8 秒的時間來回應 HTTP 請求時，用戶端最佳化能做的就很有限。那次的專案，浪費許多時間在錯誤的最佳化方向。之後我只要一遇到下載效能問題，一定先檢查伺服器回應 HTTP 請求的速度如何。
網頁效能已經變成了一個龐大而複雜的領域，值得深入研究。這篇文件只是概述這個領域知識的冰山一角。在現實中，最佳化工程師是我們自己工作的時候，需要扮演的一個角色。事實上，越來越多的公司都在僱用最佳化工程師，他們的職責就像那些專職最佳化電腦、手機程式碼的人一樣。
假如你想進一步深入了解文章裡的一些內容，深入研究下載時間最佳化，我強烈建議到下面的這些文章一探究竟：
 作者：Cody Lindley | 2010 年 6 月 11 日
----------------------------------------------------------------------------------------------------------------------------------------
張貼者： 於
標籤：

沒有留言:

張貼留言

訂閱： 張貼留言 (Atom)