前端性能優化 雅虎軍規35條

如下爲雅虎軍規35條,對前端性能優化的總結:

1、儘量減少HTTP請求個數——須權衡

合併圖片(如css sprites,內置圖片使用數據)、合併CSS、JS,這一點很重要,但是要考慮合併後的文件體積。

2、使用CDN(內容分發網絡)

這裏可以關注CDN的三類實現:鏡像、高速緩存、專線,以及智能路由器和負載均衡;

3、爲文件頭指定Expires或Cache-Control,使內容具有緩存性。

區分靜態內容和動態內容,避免以後頁面訪問中不必要的HTTP請求。

4、避免空的src和href

留意具有這兩個屬性的標籤如link,script,img,iframe等;

5、使用gzip壓縮內容

Gzip壓縮所有可能的文件類型以來減少文件體積

6、把CSS放到頂部

實現頁面有秩序地加載,這對於擁有較多內容的頁面和網速較慢的用戶來說更爲重要,同時,HTML規範清楚指出樣式表要放包含在頁面的<head />區域內;

7、把JS放到底部

HTTP/1.1 規範建議,瀏覽器每個主機名的並行下載內容不超過兩個,而問題在於腳本阻止了頁面的平行下載,即便是主機名不相同

8、避免使用CSS表達式

頁面顯示和縮放,滾動、乃至移動鼠標時,CSS表達式的計算頻率是我們要關注的。可以考慮一次性的表達式或者使用事件句柄來代替CSS表達式。

9、將CSS和JS放到外部文件中

我們需要權衡內置代碼帶來的HTTP請求減少與通過使用外部文件進行緩存帶來的好處的折中點。

10、減少DNS查找次數

我們需要權衡減少 DNS查找次數和保持較高程度並行下載兩者之間的關係。

11、精簡CSS和JS

目的就是減少下載的文件體積,可考慮壓縮工具JSMin和YUICompressor。

12、避免跳轉

爲了確保“後退”按鈕可以正確地使用,使用標準的 3XXHTTP狀態代碼;同域中注意避免反斜槓 “/” 的跳轉;
跨域使用 Alias或者 mod_rewirte建立 CNAME(保存一個域名和另外一個域名之間關係的DNS記錄)

13、剔除重複的JS和CSS

重複調用腳本,除了增加額外的HTTP請求外,多次運算也會浪費時間。在IE和Firefox中不管腳本是否可緩存,它們都存在重複運算JavaScript的問題。

14、配置ETags

Entity tags(ETags)(實體標籤)是web服務器和瀏覽器用於判斷瀏覽器緩存中的內容和服務器中的原始內容是否匹配的一種機制(“實體”就是所說的“內 容”,包括圖片、腳本、樣式表等),是比last-modified date更加靈活的機制,單位時間內文件被修過多次,Etag可以綜合Inode(文件的索引節點(inode)數),MTime(修改時間)和Size來精準的進行判斷,避開UNIX記錄MTime只能精確到秒的問題。 服務器集羣使用,可取後兩個參數。使用ETags減少Web應用帶寬和負載。

15、使AJAX可緩存

利用時間戳,更精巧的實現響應可緩存與服務器數據同步更新。

16、儘早刷新輸出緩衝

尤其對於css,js文件的並行下載更有意義

17、使用GET來完成AJAX請求

當使用XMLHttpRequest時,瀏覽器中的POST方法是一個“兩步走”的過程:首先發送文件頭,然後才發送數據。在url小於2K時使用GET獲取數據時更加有意義。

18、延遲加載

確定頁面運行正常後,再加載腳本來實現如拖放和動畫,或者是隱藏部分的內容以及摺疊內容等。

19、預加載

關注下無條件加載,有條件加載和有預期的加載。

20、減少DOM元素個數

使用更適合或者在語意是更貼切的標籤,要考慮大量DOM元素中循環的性能開銷。

21、根據域名劃分頁面內容

很顯然, 是最大限度地實現平行下載

22、儘量減少iframe的個數

考慮即使內容爲空,加載也需要時間,會阻止頁面加載,沒有語意,注意iframe相對於其他DOM元素高出1-2個數量級的開銷,它會在典型方式下阻塞onload事件,IE和Firefox中主頁面樣式表會阻塞它的下載。

23、避免404

HTTP請求時間消耗是很大的,有些站點把404錯誤響應頁面改爲“你是不是要找***”,這雖然改進了用戶體驗但是同樣也會浪費服務器資源(如數據庫等)。最糟糕的情況是指向外部 JavaScript的鏈接出現問題並返回404代碼。首先,這種加載會破壞並行加載;其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分當作JavaScript代碼來執行。

24、減少Cookie的大小

去除不必要的coockie
使coockie體積儘量小以減少對用戶響應的影響
注意在適應級別的域名上設置coockie以便使子域名不受影響
設置合理的過期時間。較早地Expire時間和不要過早去清除coockie,都會改善用戶的響應時間。

25、使用無cookie的域

確定對於靜態內容的請求是無coockie的請求。創建一個子域名並用他來存放所有靜態內容。

26、減少DOM訪問

緩存已經訪問過的有關元素
線下更新完節點之後再將它們添加到文檔樹中
避免使用JavaScript來修改頁面佈局

27、開發智能事件處理程序

有時候我們會感覺到頁面反應遲鈍,這是因爲DOM樹元素中附加了過多的事件句柄並且些事件句病被頻繁地觸發。這就是爲什麼說使用event delegation(事件代理)是一種好方法了。如果你在一個div中有10個按鈕,你只需要在div上附加一次事件句柄就可以了,而不用去爲每一個按鈕增加一個句柄。事件冒泡時你可以捕捉到事件並判斷出是哪個事件發出的。
你同樣也不用爲了操作DOM樹而等待onload事件的發生。你需要做的就是等待樹結構中你要訪問的元素出現。你也不用等待所有圖像都加載完畢。
你可能會希望用DOMContentLoaded事件來代替 事件應用程序中的onAvailable方法。

28、用<link>代替@import

在IE中,頁面底部@import和使用<link>作用是一樣的,因此最好不要使用它。

29、避免使用濾鏡

完全避免使用AlphaImageLoader的最好方法就是使用PNG8格式來代替,這種格式能在IE中很好地工作。如果你確實需要使用 AlphaImageLoader,請使用下劃線_filter又使之對IE7以上版本的用戶無效。

30、優化圖像

嘗試把GIF格式轉換成PNG格式,看看是否節省空間。在所有的PNG圖片上運行pngcrush(或者其它PNG優化工具)

31、優化CSS Spirite

在Spirite中水平排列你的圖片,垂直排列會稍稍增加文件大小;
Spirite中把顏色較近的組合在一起可以降低顏色數,理想狀況是低於256色以便適用PNG8格式;
便於移動,不要在Spirite的圖像中間留有較大空隙。這雖然不大會增加文件大小但對於用戶代理來說它需要更少的內存來把圖片解壓爲像素地圖。 100×100的圖片爲1萬像素,而1000×1000就是100萬像素。

32、不要在HTML中縮放圖像——須權衡

不要爲了在HTML中設置長寬而使用比實際需要大的圖片。如果你需要:

<img width=”100″ height=”100″ src=”mycat.jpg” alt=”My Cat” />

那麼你的圖片(mycat.jpg)就應該是100×100像素而不是把一個500×500像素的圖片縮小使用。這裏在下文有更有趣的分析。

33、favicon.ico要小而且可緩存

favicon.ico是位於服務器根目錄下的一個圖片文件。它是必定存在的,因爲即使你不關心它是否有用,瀏覽器也會對它發出請求,因此最好不要返回一 個404 Not Found的響應。由於是在同一臺服務器上,它每被請求一次coockie就會被髮送一次。這個圖片文件還會影響下載順序,例如在IE中當你在 onload中請求額外的文件時,favicon會在這些額外內容被加載前下載。

因此,爲了減少favicon.ico帶來的弊端,要做到:
文件儘量地小,最好小於1K
在適當的時候(也就是你不要打算再換favicon.ico的時候,因爲更換新文件時不能對它進行重命名)爲它設置Expires文件頭。你可以很安全地把Expires文件頭設置爲未來的幾個月。你可以通過覈對當前favicon.ico的上次編輯時間來作出判斷。
Imagemagick可以幫你創建小巧的favicon。

34、保持單個內容小於25K

因爲iPhone不能緩存大於25K的文件。注意這裏指的是解壓縮後的大小。由於單純gizp壓縮可能達不要求,因此精簡文件就顯得十分重 要。

35、打包組件成複合文本

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

        以上就是爲大家分享的Yahoo對於性能優化的條例方案,它們把性能作爲開發者的軍規,嚴格要求性能,每一個細節都看的非常重要,這也是他們能夠成爲全球企業的基本體現,希望對於對性能感到困惑的開發者有所幫助。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章