分類  >  Web前端 >

前端性能優化的14個守則

tags:    時間:2013-12-09 23:14:46
前端性能優化的14個規則

作為一個半前端工程師,而且只會寫點HTML5和CSS3的「假」前端工程師,為了能更好地理解一下前端的花花世界,最近拜讀了《高性能網站建設指南》一書,對作者提出的前端性能優化的14個規則獲益匪淺,為了讓自己印象更深刻點,決定作此文,當做學習筆記也好,知識總結也罷,總歸看過的東西要讓自己很好地掌握很好地運用起來才是王道。在解讀這些規則的同時,我會用我一年半多的移動網站開發經歷提出一些針對移動網站的優化建議。

規則01:盡量減少HTTP請求

前端優化的黃金準則指導著前端頁面的優化策略:只有10%-20%的最終用戶響應時間花在接受請求的HTML文檔上,剩下的80%-90%時間花在為HTML文檔所引用的所有組件(圖片、腳本、樣式表等)進行的HTTP請求上。因此,改善響應時間的最簡單途徑就是減少組件的數量,並由此減少HTTP請求的數量。當然很多人就會說,既然這樣,那我們就減少頁面組件的數量不就OK了嗎?那你試試,你會掀起一場性能優化和產品設計之間的大PK。所以,我們要減少HTTP請求是要平衡性能和設計的。如果找到這個平衡點呢?書中從以下幾個方面做了介紹,我逐一說明:

① 圖片地圖

初看「圖片地圖」四個字,對非專業的前端人員來說一頭霧水,我的第一印象就是這樣的,咱們以京東的移動站點為例,右側用戶和購物車的圖標,正常實現我會選擇如下方式:

1
2
3
4
5
6
<a href=」用戶跳轉頁面URL」>
           <div class=」定義用戶icon顯示的樣式表」></div>
</a>
<a href=」購物車跳轉頁面URL」>
           <div class=」 定義用戶icon顯示的樣式表」></div>
</a>

 

這種方式無可厚非的,但是兩張圖片就有兩個HTTP請求,這明顯是增加了頁面中的HTTP請求。

那麼我們可以把這兩個HTTP請求變成一個嗎?答案當然是可以的,這就是圖片地圖:允許在一張圖片上關聯多個URL,而目標URL的選擇取決於用戶單擊了圖片上的哪個位置。這樣上面京東兩個圖標合併成一張圖片,這樣圖片的HTTP請求就減少了一個。

示例代碼如下:

1
2
3
4
5
<img src=」合併后的圖片」>
<map name=」map1」>
           <area shape=」rect」 coords=」0,0,40,40」 href=」用戶跳轉頁面URL」>
           <area shape=」rect」 coords=」50,0,90,40」 href=」購物車跳轉頁面URL」>
</map>

 

不過圖片地圖只支持矩形形狀,其他形狀不支持。

② 請CSS喝「雪碧」(CSS Sprites)

CSS Sprites一句話:將多個圖片合併到一張單獨的圖片,這樣就大大減少了頁面中圖片的HTTP請求。

③ 內聯圖片和腳本

使用data:URL(Base64編碼)模式直接將圖片包含在Web頁面中而無需進行HTTP請求。

但是此種方法存在明顯缺陷:

- 不受IE的歡迎;

- 圖片太大不宜採用這種方式,因為Base64編碼之後會增加圖片大小,這樣頁面整體的下載量會變大;

- 內聯圖片在頁面跳轉的時候不會被緩存。(大圖片可以使用瀏覽器的本地緩存,在首次訪問的時候保存到瀏覽器緩存中,典型的是HTML5的manifest緩存機制以及LocalStorage等)。

④ 樣式表的合併

將頁面樣式定義、腳本、頁面本身代碼嚴格區分開,但是樣式表、腳本也不是分割越細越好,因為沒多引用一個樣式表就增加一次HTPP請求,能合併的樣式表盡量合併。一個網站有一個公用樣式表定義,每個頁面只要有一個樣式表就OK啦。

通過以上四個努力之後,你會發現你的網頁響應時間最多能減少一半,這不是作者說大話,也不是我狂吹,我親手用我的移動網站首頁做了一個嘗試,本地測試之後響應時間能減少40%左右。所以減少頁面HTTP請求數量,是一個很重要的原則。遵循此原則可以同時改善首次訪問和後續訪問的響應時間,而每一個網站的首次響應時間會決定用戶之後還來不來的重要原因。

規則02:使用內容發布網路(CDN的使用)

什麼叫內容發布網路(CDN)?它是一組分佈在多個不同地理位置的Web伺服器,用於更加有效地向用戶發布內容。主要用於發布頁面靜態資源:圖片、css文件、js文件等。如此,能輕易地提高響應速度。

關於CDN的具體詳細原理以及優缺點,各位可以自行詢問度娘或者google。

規則03:添加Expires頭

瀏覽器使用緩存來減少HTTP請求的數據,並減小HTTP響應的大小,使頁面載入更快。Web伺服器使用Expires頭來告訴瀏覽器它可以使用一個組件的當前副本,直到指定的deadline為止。HTTP規範中稱此頭為:在這一時間之後響應被認為失效。

個人對這塊表示不想使用,其實就是一句話,把一些css、js、圖片在首次訪問的時候全部緩存到瀏覽器本地,從我做移動網站的過程中發現,其實沒有這麼複雜,完全可以使用HTML5提供的本地緩存機制就OK了。關於HTML5本地緩存機制,各位可以查閱相關資料。後續我也會對HTML5的緩存機制進行介紹的。

規則04:壓縮組件(使用Gzip方式)

書中關於壓縮從gzip壓縮方式到如何壓縮講了很多,我想直接跳過,對於做PC網站或者移動網站來說,急需要壓縮的是css文件和js文件,至於如何壓縮,網上有很多在線工具,去挑選一個自己用的順手看的順眼的就好,當然也有人選擇對HTML進行壓縮,這樣也可以。但是實際工作中我沒有這麼做。之所謂沒有這麼做,是因為我覺得很麻煩。不要鄙視我,畢竟我不是一個真正意義上的前端工程師,哈哈!

規則05:將CSS樣式表放在頂部

如果將css樣式定義放在頁面中或者頁面底部,會出現短暫白屏或者某一區域短暫白板的情況,這和瀏覽器的運營機制有關的,不管頁面如何載入,頁面都是逐步呈現的。所以在每做一個頁面的時候,用Link標籤把每一個樣式表定義放在head中。

規則06:將javascript腳本放在底部

瀏覽器在載入css文件時,頁面逐步呈現會被阻止,直到所有css文件載入完畢,所以要把css文件的引用放到head中去,這樣在載入css文件時不會組織頁面的呈現。但是對於js文件,在使用的時候,它下面所有也頁面內容的呈現都會被阻塞,將腳本放在頁面越靠下的地方,就意味著越多的內容能夠逐步呈現。

規則07:避免使用CSS表達式

CSS表達式是動態玩CSS的一種很強大的方式,但是強大的同時也存在很高的危險性。因為css表達式的頻繁求值會導致css表達式性能低下。如果真想玩css表達式,可以選用只求值一次的表達式或者使用事件處理來改變css的值。

規則08:使用外部javascript和CSS

內聯js和css其實比外部文件有更快的響應速度,那為什麼還要用外部呢?因為使用外部的js和css可以讓瀏覽器緩存他們,這樣不僅HTML文檔大小減少,而且不會增加HTTP請求數量。

另外,使用外部js和css可以提高組件的可復用性。

規則09:減少DNS查詢

DNS查詢有時間開銷,通常一個瀏覽器查找一個給定主機名的IP地址需要20-120ms。

緩存DNS:緩存DNS查詢可以很好地提高網頁性能,一旦緩存了DNS查詢,之後對於相同主機名的請求就無需進行再次的DNS查找,至少短時間內不需要。

所以在使用頁面中URL、圖片、js文件、css文件等時,不要使用過多不同的主機名。

規則10:精簡javascript

如何精簡?最初始的精簡方式就是移除不必要的字元減小js文件大小,改善載入時間。包括所有的註釋、不必要的空白字元。

高級一點的精簡方式就是:混淆。它不但會移除不必要的字元,還會改寫代碼,比如函數和變數的名字會被改成很短的字元串,這樣使js代碼更簡練更難閱讀。

但是我一般很少使用混淆,一個現在互聯網時代,代碼沒有必要整的那麼神秘,大可以大家一起share,天下代碼一起抄,只要抄出自己的特色就ok了。而且一旦使用混淆,對於js代碼的維護和調試都很複雜,因為有時候混淆之後的js代碼完全看不懂。

其實實際開發過程中,從文件大小和代碼可復用性來說,不僅僅是js代碼需要精簡,css代碼一樣也很需要精簡。

規則11:避免重定向

重定向的英文是Redirect,用於將用戶從一個URL重新跳轉到另一個URL。最常見的Redirect就是301和302兩種。

關於重定向的性能影響這裡就不說了,自行查閱相關資料吧。

在我們實際開發中避免重定向最簡單也最容易被忽視的一個問題就是,設置URL的時候,最後的「/」,有些人有時候會忽略,其實你少了「/」,這時候的URL就被重定向了,所以在給頁面鏈接加URL的時候切記最後的「/」不可丟。

規則12:刪除重複腳本

重複的js代碼除了有不必要的HTTP請求之外,還會浪費執行js的時間。

將你使用的js代碼模塊化,可以很好地避免這個問題,至於js模塊化如何實現,現在有很多可以使用的開源框架,我用的比較多的是我們公司玉伯的Sea.js。

規則13:配置ETag

Etag(Entity Tag),實體標籤,是Web伺服器和瀏覽器用戶確認緩存組件的有效性的一種機制。

寫的很複雜,對我這種非專業的前端開發人員來說,有點過了,關於這個原則有興趣的自己看吧。

規則14:使Ajax可緩存

針對頁面中主動的Ajax請求返回的數據要緩存到本地,當然這個是針對短期內不會變化的數據。如果不確定數據變化周期的話,可以增加一個修改標識的判斷,我正常處理過程中會給一些Ajax請求返回的數據增加一個MD5值的判斷,每次請求會判斷當前MD5是否變化,如果變化了取最新的數據,如果不變化,則不變。

噼里啪啦說了一堆,14個規則啊,那我們開發過程中要針對這每一個規則對自己的前端代碼做check嗎?我反正不這麼干,做前端頁面,尤其是移動網站的頁面,我所記住的準則就是:盡量減少頁面大小,盡量降低頁面響應時間。在頁面性能和交互設計之中找平衡點。

推薦閱讀文章

Bookmark the permalink ,來源:互聯網