前端性能優化黃金法則

時間 2019-12-09

標籤前端性能優化黃金法則欄目系統性能简体版

原文原文鏈接

前端是龐大的，包括 HTML、 CSS、 Javascript、Image 、Flash等等各類各樣的資源。前端優化是複雜的，針對方方面面的資源都有不一樣的方式。那麼，前端優化的目的是什麼 ?Tips:我的博客排版、UI更佳；地址：https://haonancx.github.io/

從用戶角度而言，優化可以讓頁面加載得更快、對用戶的操做響應得更及時，可以給用戶提供更爲友好的體驗。前端
從服務商角度而言，優化可以減小頁面請求數、或者減少請求所佔帶寬，可以節省可觀的資源。git
總之，恰當的優化不只可以改善站點的用戶體驗而且可以節省至關的資源利用。github

前端性能優化 - Yahoo前端性能團隊總結的35條黃金定律

Yahoo 的Excetional Performance 團隊總結出了一系列能夠提升網站速度的方法。能夠分爲 7大類 35條（包括內容、服務器、CSS、JavaScript、Cookie、圖片、移動應用）。

內容部分

儘可能減小 HTTP 請求web
減小 DNS 查找express
避免跳轉瀏覽器
緩存 Ajax緩存
推遲加載性能優化
提早加載服務器
減小 DOM 元素數量cookie
用域名劃分頁面內容
使 frame 數量最少
避免404錯誤

合併文件是經過把全部的腳本放到一個文件中來減小 HTTP請求的方法。

CSS Sprites是減小圖像請求的有效方法。

緩存 DNS查找能夠改善頁面性能。

跳轉是使用 301和 302代碼實現的（可是要記住跳轉會下降用戶體驗）。

爲了提升性能，優化 Ajax響應是很重要的。提升 Ajxa性能的措施中最重要的方法就是使響應具備可緩存性。

你能夠仔細看一下你的網頁，問問本身「哪些內容是頁面呈現時所必需首先加載的？哪些內容和結構能夠稍後再加載？預加載和後加載看起來彷佛偏偏相反，但實際上預加載是爲了實現另一種目標。預加載是在瀏覽器空閒時請求未來可能會用到的頁面內容（如圖像、樣式表和腳本）。使用這種方法，當用戶要訪問下一個頁面時，頁面中的內容大部分已經加載到緩存中了，所以能夠大大改善訪問速度。

一個複雜的頁面意味着須要下載更多數據，同時也意味着JavaScript遍歷DOM的效率越慢。好比當你增長一個事件句柄時在500和5000個 DOM元素中循環效果確定是不同的。

把頁面內容劃分紅若干部分可使你最大限度地實現平行下載。

使iframe的數量最小，ifrmae元素能夠在父文檔中插入一個新的HTML文檔。瞭解iframe的工做理而後才能更加有效地使用它，這一點很重要。

HTTP請求時間消耗是很大的，所以使用HTTP請求來得到一個沒有用處的響應（例如404沒有找到頁面）是徹底沒有必要的，它只會下降用戶體驗而不會有一點好處。

服務器部分

使用內容分發網絡
爲文件頭指定 Expires 或 Cache-Control
Gzip壓縮文件內容
配置ETag
儘早刷新輸出緩衝
使用 GET 來完成 AJAX 請求
避免空的圖像來源

用戶與你網站服務器的接近程度會影響響應時間的長短。把你的網站內容分散到多個、處於不一樣地域位置的服務器上能夠加快下載速度。

爲文件頭指定Expires或Cache-Control，這條守則包括兩方面的內容：對於靜態內容：設置文件頭過時時間Expires的值爲「Never expire」（永不過時）；對於動態內容：使用恰當的Cache-Control文件頭來幫助瀏覽器進行有條件的請求。

網絡傳輸中的HTTP請求和應答時間能夠經過前端機制獲得顯著改善。的確，終端用戶的帶寬、互聯網提供者、與對等交換點的靠近程度等都不是網站開發者所能決定的。可是還有其餘因素影響着響應時間。經過減少HTTP響應的大小能夠節省HTTP響應時間。

Entity tags（ETags）（實體標籤）是web服務器和瀏覽器用於判斷瀏覽器緩存中的內容和服務器中的原始內容是否匹配的一種機制（「實體」就是所說的「內容」，包括圖片、腳本、樣式表等）。增長ETag爲實體的驗證提供了一個比使用「last-modified date（上次編輯時間）」更加靈活的機制。

當用戶請求一個頁面時，不管如何都會花費200到500毫秒用於後臺組織HTML文件。（儘早刷新輸出緩衝）。

Yahoo!Mail團隊發現，當使用XMLHttpRequest時，瀏覽器中的POST方法是一個「兩步走」的過程：首先發送文件頭，而後才發送數據。所以使用GET最爲恰當，由於它只需發送一個TCP包（除非你有不少cookie）。IE中URL的最大長度爲2K，所以若是你要發送一個超過2K的數據時就不能使用GET了。

CSS部分

把樣式表置於頂部
避免使用 CSS 表達式（）
用 <link> 代替 @import
避免使用濾鏡

在研究Yahoo!的性能表現時，咱們發現把樣式表放到文檔的<head /內部彷佛會加快頁面的下載速度。這是由於把樣式表放到<head />內會使頁面有步驟的加載顯示。

避免使用CSS表達式（Expression），CSS表達式是動態設置CSS屬性的強大（但危險）方法。Internet Explorer從第5個版本開始支持CSS表達式。

對於擁有較大瀏覽量的首頁來講，有一種技術能夠平衡內置代碼帶來的HTTP請求減小與經過使用外部文件進行緩存帶來的好處。

（削減JavaScript和CSS）精簡是指從去除代碼沒必要要的字符減小文件大小從而節省下載時間。消減代碼時，全部的註釋、不須要的空白字符（空格、換行、tab縮進）等都要去掉。

前面的最佳實現中提到CSS應該放置在頂端以利於有序加載呈現。在IE中，頁面底部@import和使用<link>做用是同樣的，所以最好不要使用它。

IE獨有屬性AlphaImageLoader用於修正7.0如下版本中顯示PNG圖片的半透明效果。這個濾鏡的問題在於瀏覽器加載圖片時它會終止內容的呈現而且凍結瀏覽器。在每個元素（不只僅是圖片）它都會運算一次，增長了內存開支，所以它的問題是多方面的。

JavaScript部分

把腳本置於頁面底部
使用外部 JavaScript 和 CSS
削減 JavaScript 和 CSS
剔除重複腳本
減小DOM訪問
開發智能事件處理程序

腳本帶來的問題就是它阻止了頁面的平行下載。HTTP/1.1 規範建議，瀏覽器每一個主機名的並行下載內容不超過兩個。一個常常用到的替代方法就是使用延遲腳本。

在同一個頁面中重複引用JavaScript文件會影響頁面的性能。你可能會認爲這種狀況並很少見。對於美國前10大網站的調查顯示其中有兩家存在重複引用腳本的狀況。有兩種主要因素致使一個腳本被重複引用的奇怪現象發生：團隊規模和腳本數量。

使用JavaScript訪問DOM元素比較慢，所以爲了得到更多的應該頁面，應該作到：緩存已經訪問過的有關元素，線下更新完節點以後再將它們添加到文檔樹中，避免使用JavaScript來修改頁面佈局，有關此方面的更多信息請查看Julien Lecomte在YUI專題中的文章「高性能Ajax應該程序」。

有時候咱們會感受到頁面反應遲鈍，這是由於DOM樹元素中附加了過多的事件句柄而且些事件句病被頻繁地觸發。這就是爲何說使用event delegation（事件代理）是一種好方法了。

Coockie部分

減少Cookie體積
對於頁面內容使用無coockie域名

coockie 是經過HTTP文件頭來在web服務器和瀏覽器之間進行交流的。去除沒必要要的coockie，使coockie體積儘可能小以減小對用戶響應的影響，注意在適應級別的域名上設置coockie以便使子域名不受影響；設置合理的過時時間。較早地Expire時間和不要過早去清除coockie，都會改善用戶的響應時間。

對於頁面內容使用無coockie域名，當瀏覽器在請求中同時請求一張靜態的圖片和發送coockie時，服務器對於這些coockie不會作任何地使用。所以他們只是由於某些負面因素而建立的網絡傳輸。全部你應該肯定對於靜態內容的請求是無coockie的請求。建立一個子域名並用他來存放全部靜態內容。

Image 部分

優化圖像
優化 CSS Spirite
不要在 HTML 中縮放圖像
favicon.ico 要小並且可緩存

優化圖像和CSS Spirite，在Spirite中水平排列你的圖片，垂直排列會稍稍增長文件大小；Spirite 中把顏色較近的組合在一塊兒能夠下降顏色數，理想情況是低於256色以便適用PNG8格式；

favicon.ico是位於服務器根目錄下的一個圖片文件。它是一定存在的，由於即便你不關心它是否有用，瀏覽器也會對它發出請求，所以最好不要返回一個404 Not Found的響應。

7、 Mobile部分

保持單個內容小於25K
打包組件成複合文本

保持單個內容小於25K，這條限制主要是由於iPhone不能緩存大於25K的文件。注意這裏指的是解壓縮後的大小。因爲單純gizp壓縮可能達不要求，所以精簡文件就顯得十分重要。

打包組件成複合文本，把頁面內容打包成複合文本就如同帶有多附件的Email，它可以使你在一個HTTP請求中取得多個組件（切記：HTTP請求是很奢侈的）。當你使用這條規則時，首先要肯定用戶代理是否支持（iPhone就不支持）。