前端的性能優化（針對內容方面）

時間 2019-11-07

標籤前端性能優化針對內容方面欄目系統性能简体版

原文原文鏈接

性能優化

減小Http請求:

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

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

3.合併文件是經過把全部腳本放在一個文件中的方式來減小請求數的，固然，也能夠合併全部的CSS。若是各個頁面的腳本和樣式不同的話，合併文件就是一項比較麻煩的工做了，但把這個做爲站點發布過程的一部分確實能夠提升響應時間。前端

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

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的輸入框裏鍵入內容後，能夠看到那些額外組件是怎樣請求加載的。提早預加載——在推出新設計以前預加載。常常在從新設計以後會聽到：「這個新網站不錯，但比之前更慢了」，一部分緣由是用戶訪問先前的頁面都是有舊緩存的，但新的倒是一種空緩存狀態下的體驗。能夠經過在將要推出新設計以前預加載一些組件來減輕這種負面影響，老站能夠利用瀏覽器空閒的時間來請求那些新站須要的圖片和腳本。