Web程式效能最佳化

標籤：使用者   導致   介面   top   client   過程   包括   ati   數值   

面試的時候經常會被問到的有關於前端效能最佳化這一塊的問題，扯扯個人的理解

第一條：減少 HTTP 次數的請求

      80%的終端使用者回應時間花在前端程式上，而其大部分時間則花在各種頁面元素， 像、 樣式表、 指令碼和 Flash 等，的下載上。 減少頁面元素將會減少 HTTP 請求 次數。這是快速顯示頁面的關鍵所在。 一種減少頁面元素個數的方法是簡化頁面設計。 但是否存在其他方式，能做到既有豐富內容，又能獲得快速回應時間呢？以下是這樣一些技術： 

     Image maps 組合多個圖片到一張圖片中。總檔案大小變化不大，但減少了 HTTP 請求次數從而加快了頁面顯示速度。該方式只適合圖片連續的情況；同時座標的定義是煩人又容易出錯的工作。

     CSS Sprites 是更好的方法。它可以組合頁面中的圖片到單個檔案中，並使用 CSS 的 background-image 和 background-position 屬性來實現所需的部分圖片。 Inline images 使用 data: URL scheme 來在頁面中內嵌圖片。這將增大 HTML 檔案的大小。組合 inline images 到你的（緩衝）樣式表是既能較少 HTTP 請求， 又能避免加大 HTML 檔案大小的方法。 

     Combined files 通過組合多個指令檔到單一檔案來減少 HTTP 要求次數。樣式 表也可採用類似方法處理。 這個方法雖然簡單，但沒有得到大規模的使用。  10大 美國網站每頁平均有 7 個指令檔和 2 個樣式表。當頁面之間指令碼和樣式表變化 很大時，該方式將遇到很大的挑戰，但如果做到的話，將能加快回應時間。 

第二條：使用 CDN(Content Delivery Network, 內容分髮網絡 ) 

     使用者離 web server 的遠近對回應時間也有很大影響。從使用者角度看，把內容部 署到多個地理位置分散的伺服器上將有效提高頁面裝載速度。 但是該從哪裡開始 呢？ 
     作為實現內容地理分布的第一步，不要試圖重構 web 應用以適應分布架構。 改變 架構將導致多個週期性任務，如同步 session 狀態，在多個 server 之間複製數 據庫交易。 這樣縮短使用者與內容距離的嘗試可能被應用架構改版所延遲，或阻止。 我們還記得 80-90%的終端使用者回應時間花在下載頁面中的各種元素上，像 檔案、 樣式表、 指令碼和 Flash 等。 與其花在重構系統這個困難的任務上，還不如先 分布靜態內容。 這不僅能大大減少回應時間，而且由於 CDN 的存在，分布靜態內 容非常容易實現。 CDN 是地理上分布的 web server 的集合，用於更高效地發布內容。 通常基於網路 遠近來選擇給具體使用者服務的 web server。 一些大型網站擁有自己的 CDN，但是使用如 Akamai Technologies, Mirror Image Internet, 或 Limelight Networks 等 CDN 服務提供者的服務將是划算的。 在 Yahoo!把靜態內容分布到 CDN 減少了使用者影響時間 20%或更多。切換到 CDN 的 代碼修改工作是很容易的，但能達到提高網站的速度。 

第三條：減少 DNS 查詢次數

     DNS 用於映射主機名稱和 IP 位址，一般一次解析需要 20～120 毫秒。 為達到更高的 效能，DNS 解析通常被多層級地緩衝，如由 ISP 或區域網路維護的 caching server，本地機器作業系統的緩衝（如 windows 上的 DNS Client Service）， 瀏覽器。 的預設 DNS 緩衝時間為 30 分鐘，Firefox 的預設緩衝時間是 1 分鐘。 IE 減少主機名稱可減少 DNS 查詢的次數，但可能造成並行下載數的減少。避免 DNS 查 詢可減少回應時間，而減少並行下載數可能增加回應時間。 一個可行的折中是把 內容分布到至少 2 個，最多 4 個不同的主機名稱上。 

第四條：樣式放頭、指令碼放底

     我們發現把樣式表移到 HEAD 部分可以提高介面載入速度，因此這使得頁面元素 可以順序顯示。 在很多瀏覽器下，如 IE，把樣式表放在 document 的底部的問題在於它禁止了網 頁內容的順序顯示。 瀏覽器阻止顯示以免重畫頁面元素，那使用者只能看到空白頁 了。Firefox 不會阻止顯示，但這意味著當樣式表下載後，有些頁面元素可能需 要重畫，這導致閃爍問題。 HTML 規範明確要求樣式表被定義在 HEAD 中，因此，為避免空白螢幕或閃爍問題， 最好的辦法是遵循 HTML 規範，把樣式表放在 HEAD 中。 

     與樣式檔案一樣，我們需要注意指令檔的位置。 我們需盡量把它們放在頁面的 底部，這樣一方面能順序顯示，另方面可達到最大的並行下載。 瀏覽器會阻塞顯示直到樣式表下載完畢，因此我們需要把樣式表放在 HEAD 部分。 而對於指令碼來說，指令碼後面內容的順序顯示將被阻塞，因此把指令碼盡量放在底 部意味著更多內容能被快速顯示。 指令碼引起的第二個問題是它阻塞並行下載數量。HTTP/1.1 規範建議瀏覽器每個 主機的並行下載數不超過 2 個。 因此如果您把影像檔分布到多台機器的話，您可以達到超過 2 個的並行下載。 但是當指令檔下載時，瀏覽器不會啟動其他的 並行下載，甚至其他主機的下載也不啟動。 在某些情況下，不是很容易就能把指令碼移到底部的。如，指令碼使用 document.write 方法來插入頁面內容。 同時可能還存在域的問題。 不過在很多情 況下，還是有一些方法的。 一個備選方法是使用延遲指令碼（deferred script）。DEFER 屬性工作表明指令碼未包 含 document.write，指示瀏覽器刻繼續顯示。不幸的是，Firefox 不支援 DEFER 屬性。 IE 中，指令碼可能被順延強制，但不一定得到需要的長時間延遲。 在 不過從 另外角度來說，如果指令碼能被順延強制，那它就可以被放在底部了。 

第五條：將指令碼和樣式分離

     上述很多效能最佳化法則都基於外部檔案進行最佳化。 現在，我們必須問一個問題： JavaScript 和 CSS 應該包括在外部檔案，還是在分頁檔中？ 在現實世界中，使用外部檔案會加快頁面顯示速度，因為外部檔案會被瀏覽器 緩衝。如果內建 JavaScript 和 CSS 在頁面中雖然會減少 HTTP 要求次數，但增大 了頁面的大小。 另外一方面，使用外部檔案，會被瀏覽器緩衝，則頁面大小會減 小，同時又不增加 HTTP 要求次數。 因此，一般來說，外部檔案是更可行的方式。 唯一的例外是內嵌方式對首頁更有 效，如 Yahoo!和 My Yahoo!都使用內嵌方式。一般來說，在一個 session 中，主 頁訪問此時較少，因此內嵌方式可以取得更快的使用者回應時間。 

第六條：避免重新導向

重新導向功能是通過 301 和 302 這兩個 HTTP 狀態代碼完成的，如： HTTP/1.1 301 Moved Permanently Location: http://example.com/newuri Content-Type: text/html 瀏覽器自動重新導向請求到 Location 指定的 URL 上，重新導向的主要問題是降低了 使用者體驗。 一種最耗費資源、經常發生而很容易被忽視的重新導向是 URL 的最後缺少/，如訪 問 http://astrology.yahoo.com/astrology 將被重新導向到 http://astrology.yahoo.com/astrology/。在 Apache 下，可以通過 Alias，mod_rewrite 或 DirectorySlash 等方式來解決該問題。 

第七條：代碼最佳化

　　1、避免 CSS 運算式　　

     CSS 運算式是功能強大的(同時也是危險的)用於動態設定 CSS 屬性的方式。IE， 從版本 5 開始支援 CSS 運算式，如 backgourd-color: expression((new Date()).getHours()%2?”#B8D4FF”:”#F08A00”)，即背景色每個小時切換一 次。 CSS 運算式的問題是其執行次數超過大部分人的期望。 不僅頁面顯示和 resize 時 計算運算式，而且當頁面滾屏，甚至當滑鼠在頁面上移動時都會重新計算表達 式。 一種減少 CSS 運算式執行次數的方法是一次性運算式，即當第一次執行時就以 明確的數值代替運算式。如果必須動態設定的話，可使用事件處理函數代替。如 果您必須使用 CSS 運算式的話，請記住它們可能被執行上千次，從而影響頁面 效能。

 2、函數節流

     函數節流就是用來節流函數從而一定程度上最佳化效能的。例如，DOM 操作比起非DOM 互動需要更多的記憶體和CPU時間。連續嘗試進行過多的DOM 相關操作可能會導致瀏覽器掛起，有時候甚至會崩潰。尤其在IE 中使用onresize 事件處理常式的時候容易發生，當調整瀏覽器大小的時候，該事件會連續觸發。在onresize 事件處理常式內部如果嘗試進行DOM 操作，其高頻率的更改可能會讓瀏覽器崩潰。又例如，我們常見的一個搜尋的功能，我們一般是綁定keyup事件，每按下一次鍵盤就搜尋一次。但是我們的目的主要是每輸入一些內容搜尋一次而已。為瞭解決這些問題，就可以使用定時器對函數進行節流。

 3、減少對 DOM 訪問

     當DOM樹的結構變化時，例如節點的增減、移動等，也會觸發重排。瀏覽器引擎布局的過程，類似於樹的前序走訪，是一個從上到下從左至右的過程。 通常在這個過程中，當前元素不會再影響其前面已經遍曆過的元素。所以，如果在body最前面插入一個元素，會導致整個文檔的重新渲染。既然無法避免，那就減少訪問（width、offsetTop、left。。。能少就少，可以緩衝起來的，就緩衝）。

  4、最小化代碼

     最小化 JavaScript、CSS、HTML 從代碼中刪除不必要的字元，從而降低下載時間。 常用的工具有 Gulp 和 Webpack。 混淆是最小化於源碼的備選方式。 象最小化一樣，它通過刪除注釋和空格來減少 源碼大小，同時它還可以對代碼進行混淆處理。 作為混淆的一部分，函數名和變 量名被替換成短的字串，這使得代碼更緊湊，同時也更難讀，使得難於被反 向工程。最小化是安全的、直白的過程，而混淆則更複雜，而且容易產生問題。從對大網站的調查來看，通過最小化，檔案可減少 21%，而混淆則可減少 25%。 除了最小化外部指令檔外，內嵌的指令碼代碼也應該被最小化。 即使指令碼根據法 則 4 被壓縮後傳輸，最小化指令碼刻減少檔案大小 5%或更高。 

本文主要借鑒與 雅虎軍規 及個人理解

Web程式效能最佳化