前端的性能優化(針對內容方面)

性能優化


  • 減少Http請求:

1.儘量減少HTTP請求數   80%的終端用戶響應時間都花在了前端上,其中大部分時間都在下載頁面上的各種組件:圖片,樣式表,腳本,Flash等等。減少組件數必然能夠減少頁面提交的HTTP請求數。這是讓頁面更快的關鍵。

2.減少頁面組件數的一種方式是簡化頁面設計。但有沒有一種方法可以在構建複雜的頁面同時加快響應時間呢?嗯,確實有魚和熊掌兼得的辦法。

3.合併文件是通過把所有腳本放在一個文件中的方式來減少請求數的,當然,也可以合併所有的CSS。如果各個頁面的腳本和樣式不一樣的話,合併文件就是一項比較麻煩的工作了,但把這個作爲站點發布過程的一部分確實可以提高響應時間。

4.CSS Sprites是減少圖片請求數量的首選方式。把背景圖片都整合到一張圖片中,然後用CSS的background-image和background-position屬性來定位要顯示的部分。

5.圖像映射可以把多張圖片合併成單張圖片,總大小是一樣的,但減少了請求數並加速了頁面加載。圖片映射只有在圖像在頁面中連續的時候纔有用,比如導航條。給image map設置座標的過程既無聊又容易出錯,用image map來做導航也不容易,所以不推薦用這種方式。

6.行內圖片(Base64編碼)用data: URL模式來把圖片嵌入頁面。這樣會增加HTML文件的大小,把行內圖片放在(緩存的)樣式表中是個好辦法,而且成功避免了頁面變“重”。但目前主流瀏覽器並不能很好地支持行內圖片。

7.減少頁面的HTTP請求數是個起點,這是提升站點首次訪問速度的重要指導原則。


  • 減少DNS查找:

1.域名系統建立了主機名和IP地址間的映射,就像電話簿上人名和號碼的映射一樣。當你在瀏覽器輸入www.yahoo.com的時候,瀏覽器就會聯繫DNS解析器返回服務器的IP地址。DNS是有成本的,它需要20到120毫秒去查找給定主機名的IP地址。在DNS查找完成之前,瀏覽器無法從主機名下載任何東西。

2.DNS查找被緩存起來更高效,由用戶的ISP(網絡服務提供商)或者本地網絡存在一個特殊的緩存服務器上,但還可以緩存在個人用戶的計算機上。DNS信息被保存在操作系統的DNS cache(微軟Windows上的”DNS客戶端服務”)裏。大多數瀏覽器有獨立於操作系統的自己的cache。只要瀏覽器在自己的cache裏還保留着這條記錄,它就不會向操作系統查詢DNS。

3.IE默認緩存DNS查找30分鐘,寫在DnsCacheTimeout註冊表設置中。Firefox緩存1分鐘,可以用network.dnsCacheExpiration配置項設置。(Fasterfox把緩存時間改成了1小時 P.S. Fasterfox是FF的一個提速插件)

4.如果客戶端的DNS cache是空的(包括瀏覽器的和操作系統的),DNS查找數等於頁面上不同的主機名數,包括頁面URL,圖片,腳本文件,樣式表,Flash對象等等組件中的主機名,減少不同的主機名就可以減少DNS查找。

5.減少不同主機名的數量同時也減少了頁面能夠並行下載的組件數量,避免DNS查找削減了響應時間,而減少並行下載數量卻增加了響應時間。我的原則是把組件分散在2到4個主機名下,這是同時減少DNS查找和允許高併發下載的折中方案。


  • 避免重定向 重定向用301和302狀態碼,下面是一個有301狀態碼的HTTP頭:

1.HTTP/1.1 301 Moved Permanently Location: http://example.com/newuri Content-Type: text/html   瀏覽器會自動跳轉到Location域指明的URL。重定向需要的所有信息都在HTTP頭部,而響應體一般是空的。其實額外的HTTP頭,比如Expires和Cache-Control也表示重定向。除此之外還有別的跳轉方式:refresh元標籤和JavaScript,但如果你必須得做重定向,最好用標準的3xxHTTP狀態碼,主要是爲了讓返回按鈕能正常使用。

2.牢記重定向會拖慢用戶體驗,在用戶和HTML文檔之間插入重定向會延遲頁面上的所有東西,頁面無法渲染,組件也無法開始下載,直到HTML文檔被送達瀏覽器。

3.有一種常見的極其浪費資源的重定向,而且web開發人員一般都意識不到這一點,就是URL尾部缺少一個斜線的時候。例如,跳轉到http://astrology.yahoo.com/as...://astrology.yahoo.com/astrology/的301響應(注意添在尾部的斜線)。在Apache中可以用Alias,mod_rewrite或者DirectorySlash指令來取消不必要的重定向。

4.重定向最常見的用途是把舊站點連接到新的站點,還可以連接同一站點的不同部分,針對用戶的不同情況(瀏覽器類型,用戶帳號類型等等)做一些處理。用重定向來連接兩個網站是最簡單的,只需要少量的額外代碼。雖然在這些時候使用重定向減少了開發人員的開發複雜度,但降低了用戶體驗。一種替代方案是用Alias和mod_rewrite,前提是兩個代碼路徑都在相同的服務器上。如果是因爲域名變化而使用了重定向,就可以創建一條CNAME(創建一個指向另一個域名的DNS記錄作爲別名)結合Alias或者mod_rewrite指令。


  • 讓Ajax可緩存:

1.Ajax的一個好處是可以給用戶提供即時反饋,因爲它能夠從後臺服務器異步請求信息。然而,用了Ajax就無法保證用戶在等待異步JavaScript和XML響應返回期間不會非常無聊。在很多應用程序中,用戶能夠一直等待取決於如何使用Ajax。例如,在基於web的電子郵件客戶端中,用戶爲了尋找符合他們搜索標準的郵件消息,將會保持對Ajax請求返回結果的關注。重要的是,要記得“異步”並不意味着“即時”。

2.要提高性能,優化這些Ajax響應至關重要。最重要的提高Ajax性能的方法就是讓響應變得可緩存,就像在添上Expires或者Cache-Control HTTP頭中討論的一樣。下面適用於Ajax的其它規則:

3.Gzip組件 減少DNS查找 壓縮JavaScript 避免重定向 配置ETags   我們一起看看例子,一個Web 2.0的電子郵件客戶端用了Ajax來下載用戶的通訊錄,以便實現自動完成功能。如果用戶從上一次使用之後再沒有修改過她的通訊錄,而且Ajax響應是可緩存的,有尚未過期的Expires或者Cache-Control HTTP頭,那麼之前的通訊錄就可以從緩存中讀出。必須通知瀏覽器,應該繼續使用之前緩存的通訊錄響應,還是去請求一個新的。可以通過給通訊錄的Ajax URL裏添加一個表明用戶通訊錄最後修改時間的時間戳來實現,例如&t=1190241612。如果通訊錄從上一次下載之後再沒有被修改過,時間戳不變,通訊錄就將從瀏覽器緩存中直接讀出,從而避免一次額外的HTTP往返消耗。如果用戶已經修改了通訊錄,時間戳也可以確保新的URL不會匹配緩存的響應,瀏覽器將請求新的通訊錄條目。

4.即使Ajax響應是動態創建的,而且可能只適用於單用戶,它們也可以被緩存,而這樣會讓你的Web 2.0應用更快。


  • 延遲加載組件:
可以湊近看看頁面並問自己:什麼纔是一開始渲染頁面所必須的?其餘內容都可以等會兒。

1.JavaScript是分隔onload事件之前和之後的一個理想選擇。例如,如果有JavaScript代碼和支持拖放以及動畫的庫,這些都可以先等會兒,因爲拖放元素是在頁面最初渲染之後的。其它可以延遲加載的部分包括隱藏內容(在某個交互動作之後纔出現的內容)和摺疊的圖片。

2.工具可幫你減輕工作量:YUI Image Loader可以延遲加載摺疊的圖片,還有YUI Get utility是一種引入JS和CSS的簡單方法。Yahoo!主頁就是一個例子,可以打開Firebug的網絡面板仔細看看。

3.最好讓性能目標符合其它web開發最佳實踐,比如“漸進增強”。如果客戶端支持JavaScript,可以提高用戶體驗,但必須確保頁面在不支持JavaScript時也能正常工作。所以,在確定頁面運行正常之後,可以用一些延遲加載腳本增強它,以支持一些拖放和動畫之類的華麗效果。


  • 預加載組件:
預加載可能看起來和延遲加載是相反的,但它其實有不同的目標。通過預加載組件可以充分利用瀏覽器空閒的時間來請求將來會用到的組件(圖片,樣式和腳本)。用戶訪問下一頁的時候,大部分組件都已經在緩存裏了,所以在用戶看來頁面會加載得更快。

實際應用中有以下幾種預加載的類型:

1.無條件預加載——儘快開始加載,獲取一些額外的組件。google.com就是一個sprite圖片預加載的好例子,這個sprite圖片並不是google.com主頁需要的,而是搜索結果頁面上的內容。 條件性預加載——根據用戶操作猜測用戶將要跳轉到哪裏並據此預加載。在search.yahoo.com的輸入框裏鍵入內容後,可以看到那些額外組件是怎樣請求加載的。 提前預加載——在推出新設計之前預加載。經常在重新設計之後會聽到:“這個新網站不錯,但比以前更慢了”,一部分原因是用戶訪問先前的頁面都是有舊緩存的,但新的卻是一種空緩存狀態下的體驗。可以通過在將要推出新設計之前預加載一些組件來減輕這種負面影響,老站可以利用瀏覽器空閒的時間來請求那些新站需要的圖片和腳本。


  • 減少DOM元素的數量:
一個複雜的頁面意味着要下載更多的字節,而且用JavaScript訪問DOM也會更慢。舉個例子,想要添加一個事件處理器的時候,循環遍歷頁面上的500個DOM元素和5000個DOM元素是有區別的。

1.大量的DOM元素是一種徵兆——頁面上有些內容無關的標記需要清理。正在用嵌套表格來佈局嗎?還是爲了修復佈局問題而添了一堆的<div>s?或許應該用更好的語義化標記。

2.YUI CSS utilities對佈局有很大幫助:grids.css針對整體佈局,fonts.css和reset.css可以用來去除瀏覽器的默認格式。這是個開始清理和思考標記的好機會,例如只在語義上有意義的時候使用<div>,而不是因爲它能夠渲染一個新行。

3.DOM元素的數量很容易測試,只需要在Firebug的控制檯裏輸入:

document.getElementsByTagName(‘*’).length

4.那麼多少DOM元素纔算是太多呢?可以參考其它類似的標記良好的頁面,例如Yahoo!主頁是一個相當繁忙的頁面,但只有不到700個元素(HTML標籤)。


  • 跨域分離組件:

1.分離組件可以最大化並行下載,但要確保只用不超過2-4個域,因爲存在DNS查找的代價。例如,可以把HTML和動態內容部署在www.example.org,而把靜態組件分離到static1.example.org和static2.example.org。

後續還會整理,目前對性能的優化先寫這麼多........
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章