前端優化方案

時間  2019-11-24
標籤 前端 優化 方案 简体版
原文   原文鏈接

1 優化css

1.1 避免使用CSS表達式

用CSS表達式動態設置CSS屬性，是一種強大又危險的方式。從IE5開始支持，但從IE8起就不推薦使用了。例如，能夠用CSS表達式把背景顏色設置成按小時交替的javascript

  • 儘可能減小標籤選擇器的使用
  • 儘量少使用id選擇器，多使用樣式選擇器(通用性強)
  • 減小選擇器前綴，例如.headerBox .nav .left a{} 選擇器是從右向左查詢的
  • 避免使用css表達式
background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );
複製代碼

1.2 減小頁面中的冗餘代碼

儘量提升方法的重複使用率：「低耦合高內聚」php

1.3 選擇捨棄@import

前面提到了一個最佳實踐：爲了實現逐步渲染，CSS應該放在頂部。 在IE中用@import與在底部用<link>效果同樣，因此最好不要用它。css

1.4 避免使用濾鏡

IE專有的AlphaImageLoader濾鏡能夠用來修復IE7以前的版本中半透明PNG圖片的問題。在圖片加載過程當中，這個濾鏡會阻塞渲染，卡住瀏覽器，還會增長內存消耗並且是被應用到每一個元素的，而不是每一個圖片，因此會存在一大堆問題。
最好的方法是乾脆不要用AlphaImageLoader，而優雅地降級到用在IE中支持性很好的PNG8圖片來代替。若是非要用AlphaImageLoader，應該用下劃線hack：_filter來避免影響IE7及更高版本的用戶。html

1.5 把樣式表放在頂部

把樣式表放到文檔的HEAD部分能讓頁面看起來加載地更快。這是由於把樣式表放在head裏能讓頁面逐步渲染。
  關注性能的前端工程師想讓頁面逐步渲染。也就是說，咱們想讓瀏覽器儘快顯示已有內容，這在頁面上有一大堆內容或者用戶網速很慢時顯得尤其重要。給用戶顯示反饋（好比進度指標）的重要性已經被普遍研究過，而且被記錄下來了。在咱們的例子中，HTML頁面就是進度指標！當瀏覽器逐漸加載頁面頭部，導航條，頂部logo等等內容的時候，這些都被正在等待頁面加載的用戶看成反饋，可以提升總體用戶體驗。前端

1.6 壓縮 css

  • 使用在線網站進行壓縮
  • 使用html-minifier 對html 中的css 進行壓縮
  • 使用clean-css 對css進行壓縮
  • webpack,gulp打包工具

2 優化圖片

2.1 圖片格式

嘗試把GIF格式轉換成PNG格式，看看是否節省空間。在全部的PNG圖片上運行pngcrush（或者其它PNG優化工具）
vue

2.2 優化CSS Sprite

採用css雪碧圖(css sprit/css 圖片精靈)技術，吧一些小圖合併在一張大圖上面，使用的時候，經過北京圖片定位，定位到具體的某一張小圖上java

  • 在Sprite圖片中橫向排列通常都比縱向排列的最終文件小
  • 組合Sprite圖片中的類似顏色能夠保持低色數，最理想的是256色如下PNG8格式
  • 「對移動端友好」，不要在Sprite圖片中留下太大的空隙。雖然不會在很大程度上影響圖片文件的大小，但這樣作能夠節省用戶代理把圖片解壓成像素映射時消耗的內存。100×100的圖片是1萬個像素，而1000×1000的圖片就是100萬個像素了。
.pubBg{
	background:url('../img/sprit.png') no-repeat;
  background-size:x y; // 和原圖的大小保持一致
}

.box{
	background-position:x y; // 經過背景定位，定位到具體的位置，展現不一樣的圖片極客
}
複製代碼

頁面中無法送一次http請求，都須要完成請求+響應這個完整的http事務，會消耗一些時間，也可能會致使http連接通道的堵塞,爲了提升頁面的加載速度和運行的性能，咱們應該減小http的請求次數和減小請求內容的大小。webpack

2.3 圖像映射

能夠把多張圖片合併成單張圖片，總大小是同樣的，但減小了請求數並加速了頁面加載。圖片映射只有在圖像在頁面中連續的時候纔有用，好比導航條。給image map設置座標的過程既無聊又容易出錯，用image map來作導航也不容易，因此不推薦用這種方式。ios

2.4 行內圖片（Base64編碼）

用data: URL模式來把圖片嵌入頁面。這樣會增長HTML文件的大小，把行內圖片放在（緩存的）樣式表中是個好辦法，並且成功避免了頁面變「重」。但目前主流瀏覽器並不能很好地支持行內圖片。
減小頁面的HTTP請求數是個起點，這是提高站點首次訪問速度的重要指導原則。css3

2.5 不要用HTML縮放圖片

不要由於在HTML中能夠設置寬高而使用本不須要的大圖。若是須要

<img width="100" height="100" src="mycat.jpg" alt="My Cat" />
複製代碼

那麼圖片自己（mycat.jpg）應該是100x100px的，而不是去縮小500x500px的圖片。

2.6 用小的可緩存的favicon.ico（P.S. 收藏夾圖標）

favicon.ico是放在服務器根目錄的圖片，它會帶來一堆麻煩，由於即使你無論它，瀏覽器也會自動請求它，因此最好不要給一個404 Not Found響應。並且只要在同一個服務器上，每次請求它時都會發送cookie，此外這個圖片還會干擾下載順序，例如在IE中，當你在onload中請求額外組件時，將會先下載favicon。
因此爲了緩解favicon.ico的缺點，應該確保：

  • 足夠小，最好在1K如下
  • 設置合適的有效期HTTP頭（之後若是想換的話就不能重命名了），把有效期設置爲幾個月後通常比較安全，能夠經過檢查當前favicon.ico的最後修改日期來確保變動能讓瀏覽器知道。

2.7 壓縮image

  • 使用雪花圖
  • 使用矢量圖
  • 使用base64轉換
  • 使用網站壓縮  
  • 合理使用格式圖片
    • jpg有損壓縮，壓縮率搞，不支持透明
    • png支持透明，瀏覽器兼容好
    • webp壓縮程度更好，在ios webview有兼容性問題
    • svg矢量圖，代碼內嵌，相對於較小，圖片樣式相對簡單的場景

在使用webp的過程當中，會產生一些瀏覽器兼容問題

function checkWebp() {

    try{

        return (document.createElement('canvas').toDataURL('image/webp').indexOf('data:image/webp') == 0);

       }catch(err) {

        return false;

       }

}



$(document).ready(function() {

        var webp_good = checkWebp();

        if(webp_good == false) {

            $('img').each(function() {

            var src = $(this).attr('src');

            if(typeof src != 'undefined') {

                src = src.replace('/format,webp', '/format,jpg'); //將webp格式轉換成jpg格式

                $(this).attr('src', src);

            }

            var original = $(this).attr('original');        //針對用了懶加載的狀況

            if(typeof original != 'undefined') {

                original = original.replace('/format,webp', '/format,jpg'); //將webp格式轉換成jpg格式

                $(this).attr('original', original);

            }

        })

    }

})
複製代碼

2.8 圖片懶加載

採用圖片懶加載技術，在頁面開始加載時候，不請求真實的圖片地址，而是默認圖佔位，當頁面加載完成後，在根據相關的條件依次加載真實的圖片(減小頁面首次加載http請求的次數)
真實項目中，咱們開始圖片都不加載，頁面首次加載完成，先把第一屏幕中看見的圖片進行加載，隨着頁面的滾動，在下面區域中可以呈現出來的圖片進行加載

  • 根據圖片懶加載技術，咱們還能夠擴充出，數據懶加載

開始加載頁面的時候，咱們只把首屏或者前兩屏的數據從服務器進行請求(有些網站首屏數據是後臺渲染好，總體返回給客戶端呈現的)

  • 當頁面下拉，滾動到哪一個區域，在把這個區域須要的數據進行請求(請求回來數據綁定以及圖片延遲加載等)
  • 分頁展現技術採用的也是數據懶加載思想實現的:若是咱們開始請求獲取的數據是不少的數據，咱們最好分批請求，開始只請求第一頁的數據，當頁面點擊第二頁(微博是下拉到必定距離後，再請求第二頁數據)的時候請求第二頁數據。

3 優化js

3.1 去除重複腳本

頁面含有重複的腳本文件會影響性能，這可能和你想象的不同。在對美國前10大web站點的評審中，發現只有2個站點含有重複腳本。兩個主要緣由增長了在單一頁面中出現重複腳本的概率：團隊大小和腳本數量。在這種狀況下，重複腳本會建立沒必要要的HTTP請求，執行無用的JavaScript代碼，而影響頁面性能。
  IE會產生沒必要要的HTTP請求，而Firefox不會。在IE中，若是一個不可緩存的外部腳本被頁面引入了兩次，它會在頁面加載時產生兩個HTTP請求。即便腳本是可緩存的，在用戶從新加載頁面時也會產生額外的HTTP請求。
  除了產生沒有意義的HTTP請求以外，屢次對腳本求值也會浪費時間。由於不管腳本是否可緩存，在Firefox和IE中都會執行冗餘的JavaScript代碼。
  避免不當心把相同腳本引入兩次的一種方法就是在模版系統中實現腳本管理模塊。典型的腳本引入方法就是在HTML頁面中用SCRIPT標籤：

<script type="text/javascript" src="menu_1.0.17.js"></script>
複製代碼

3.2 儘可能減小DOM訪問

一個複雜的頁面意味着要下載更多的字節，並且用JavaScript訪問DOM也會更慢。舉個例子，想要添加一個事件處理器的時候，循環遍歷頁面上的500個DOM元素和5000個DOM元素是有區別的。
操做dom的弊端

  • dom存在映射在機制(js中的dom元素對象和頁面中dom結構是存在映射機制的，一改則都改)，這種映射機制，是瀏覽器安卓w3c標準完成對js語言的構建和dom的構建(其實就是構建一個監聽機制)，操做dom是同事修改兩個地址，相對於一些其餘的js編程來講消耗性能的。
  • 頁面中的dom結構改變或者樣式改變，會觸發瀏覽器的迴流(瀏覽器會把dom結構從新進行計算，這個操做很耗性能)和重繪(吧一個元素的樣式從新渲染)

在作dom事件綁定的時候，儘可能避免一個個的事件綁定，二採用性能更高的事件委託來實現

事件委託(事件代理) 把時間板頂給外層容器，當裏面的後代元素相關行爲被處罰，外層容器綁定的方法也會被觸發執行(冒泡傳播機制致使)，經過的事件源是誰，咱們作不一樣的操做便可


用JavaScript訪問DOM元素是很慢的，因此，爲了讓頁面反應更迅速，應該：

  • 緩存已訪問過的元素的索引
  • 先「離線」更新節點，再把它們添到DOM樹上
  • 避免用JavaScript修復佈局問題


DOM元素的數量很容易測試，只須要在控制檯裏輸入

document.getElementsByTagName('*').length
複製代碼

3.3 用智能的事件處理器

 有時候感受頁面反映不夠靈敏，是由於有太多頻繁執行的事件處理器被添加到了DOM樹的不一樣元素上，這就是推薦使用事件委託的緣由。若是一個div裏面有10個按鈕，應該只給div容器添加一個事件處理器，而不是給每一個按鈕都添加一個。事件可以冒泡，因此能夠捕獲事件並得知哪一個按鈕是事件源。

3.4 更多異步操做編譯

  • 同步編程會致使:上面東西完不成，下面任務也作不了，咱們開發的時候，能夠把某一個區域模塊都設置爲異步編程，這樣只要模塊之間沒有必然的前後順序，均可以獨立進行加載，不會受到上面模塊的堵塞影響(用的很少)
  • 尤爲是ajax數據請求，咱們通常都要使用異步編程，最好是基於promise設計模式進行管理(項目中常用fetch、vue、axios)等插件進行ajax請求處理，由於這些插件中就是基於promise設計模式對ajax進行了封裝處理
  • 在真實的項目中，咱們儘量避免一次性循環過多數據(由於循環操做是同步編程)，尤爲是要避免while致使的死循環操做

3.5 JS中避免使用eval

  • 性能消耗大
  • 代碼壓縮後，容易出現代碼執行錯亂問題

3.6 JS中儘可能減小閉包的使用

  • 閉包會造成一個不銷燬的棧內存，過多的棧內存累積影響頁面的性能
  • 還會容易致使內存的泄露
  • 閉包也有本身的優點:保存和保護，咱們只能儘可能減小，可是沒法避免

3.7 儘可能使用css3動替代js動畫

css3的動畫或者變形都開啓了硬件加速，性能比js動畫好

3.8 緩存作處理

對於不常常更新的數據，最好採用瀏覽器的304緩存作處理
例如:
第一次請求css和js下拉，瀏覽器會把請求的內容緩存起來，若是作了304處理，用戶再次請求css和js直接從緩存中讀取，不須要再去服務器獲取了(減小了http請求次數)
當用戶強制刷新頁面(ctrl+f5)或者當前緩存的css或者js發生了變更，都會重新從服務器端拉取
對於客戶端來說，咱們還能夠基於localStronge來作一些本地存儲，例如:第一次請求的數據或者不常常更新的css和js，咱們均可以吧內容存儲在本地，下一次頁面加載，咱們從本地中獲取便可，咱們設定必定的期限或者一些標識，能夠控制在某個階段從新從服務器獲取

3.9 設計模式

編寫js代碼的時候儘量使用設計模式來構建體系，方便後期的維護，也提升了擴充性等

3.10 把腳本放在底部

腳本會阻塞並行下載，HTTP/1.1官方文檔建議瀏覽器每一個主機名下並行下載的組件數不要超過兩個，若是圖片來自多個主機名，並行下載的數量就能夠超過兩個。若是腳本正在下載，瀏覽器就不開始任何其它下載任務，即便是在不一樣主機名下的。
  有時候，並不容易把腳本移動到底部。舉個例子，若是腳本是用document.write插入到頁面內容中的，就沒辦法再往下移了。還可能存在做用域問題，在多數狀況下，這些問題都是能夠解決的。
  一個常見的建議是用推遲（deferred）腳本，有DEFER屬性的腳本意味着不能含有document.write，而且提示瀏覽器告訴他們能夠繼續渲染。不幸的是，Firefox不支持DEFER屬性。在IE中，腳本可能被推遲，但不盡如人意。若是腳本能夠推遲，咱們就能夠把它放到頁面底部，頁面就能夠更快地載入。

3.11 壓縮js

  • 使用在線網站進行壓縮
  • 使用html-minifier 對html 中的css 進行壓縮
  • 使用uglifjs2對js進行壓縮
  • webpack,gulp打包工具

4 優化html

4.1 audio或者video標籤

若是當頁面中出現audio或者video標籤，咱們最好設置它們的preload=:頁面加載的時候，音視頻資源不進行加載，播放的時候再開始加載(減小頁面首次加載http請求的次數)

  • preload=auto 頁面首次加載的時候就把音頻資源進行加載
  • preload=metadata 頁面首次加載的時候只能音視資源的頭部信息進行加載

4.2 儘可能少用iframe

  用iframe能夠把一個HTML文檔插入到父文檔裏，重要的是明白iframe是如何工做的並高效地使用它。
<iframe>的優勢：

  • 引入緩慢的第三方內容，好比標誌和廣告
  • 安全沙箱
  • 並行下載腳本

<iframe>的缺點：

  • 代價高昂，即便是空白的iframe
  • 阻塞頁面加載
  • 非語義

4.3 杜絕404

  HTTP請求代價高昂，徹底沒有必要用一個HTTP請求去獲取一個無用的響應（好比404 Not Found），只會拖慢用戶體驗而沒有任何好處。
  有些站點用的是有幫助的404——「你的意思是xxx？」，這樣作有利於用戶體驗，，但也浪費了服務器資源（好比數據庫等等）。最糟糕的是連接到的外部JavaScript有錯誤並且結果是404。首先，這種下載將阻塞並行下載。其次，瀏覽器會試圖解析404響應體，由於它是JavaScript代碼，須要找出其中可用的部分。

5 移動端

5.1 保證全部組件都小於25K

這個限制是由於iPhone不能緩存大於25K的組件，注意這裏指的是未壓縮的大小。這就是爲何縮減內容自己也很重要，由於單純的gzip可能不夠。

5.2 把組件打包到一個複合文檔裏

把各個組件打包成一個像有附件的電子郵件同樣的複合文檔裏，能夠用一個HTTP請求獲取多個組件（記住一點：HTTP請求是代價高昂的）。用這種方式的時候，要先檢查用戶代理是否支持（iPhone就不支持）。

6 cookie

6.1 給Cookie減肥

使用cookie的緣由有不少，好比受權和個性化。HTTP頭中cookie信息在web服務器和瀏覽器之間交換。重要的是保證cookie儘量的小，以最小化對用戶響應時間的影響。

  • 清除沒必要要的cookie
  • 保證cookie儘量小，以最小化對用戶響應時間的影響
  • 注意給cookie設置合適的域級別，以避免影響其它子域
  • 設置合適的有效期，更早的有效期或者none能夠更快的刪除cookie，提升用戶響應時間

6.2 把組件放在不含cookie的域下

當瀏覽器發送對靜態圖像的請求時，cookie也會一塊兒發送，而服務器根本不須要這些cookie。因此它們只會形成沒有意義的網絡通訊量，應該確保對靜態組件的請求不含cookie。能夠建立一個子域，把全部的靜態組件都部署在那兒。
若是域名是www.example.org，能夠把靜態組件部署到static.example.org。然而，若是已經在頂級域example.org或者www.example.org設置了cookie，那麼全部對static.example.org的請求都會含有這些cookie。這時候能夠再買一個新域名，把全部的靜態組件部署上去，並保持這個新域名不含cookie。Yahoo!用的是yimg.com，YouTube是ytimg.com，Amazon是images-amazon.com等等。
 把靜態組件部署在不含cookie的域下還有一個好處是有些代理可能會拒絕緩存帶cookie的組件。有一點須要注意：若是不知道應該用example.org仍是www.example.org做爲主頁，能夠考慮一下cookie的影響。省略www的話，就只能把cookie寫到*.example.org，因此由於性能緣由最好用www子域，而且把cookie寫到這個子域下。

7 服務器

7.1 Gzip組件

  前端工程師能夠想辦法明顯地縮短經過網絡傳輸HTTP請求和響應的時間。毫無疑問，終端用戶的帶寬速度，網絡服務商，對等交換點的距離等等，都是開發團隊所沒法控制的。但還有別的可以影響響應時間的因素，壓縮能夠經過減小HTTP響應的大小來縮短響應時間。
從HTTP/1.1開始，web客戶端就有了支持壓縮的Accept-Encoding HTTP請求頭。

1 Accept-Encoding: gzip, deflate

  若是web服務器看到這個請求頭，它就會用客戶端列出的一種方式來壓縮響應。web服務器經過Content-Encoding相應頭來通知客戶端。

1 Content-Encoding: gzip

  儘量多地用gzip壓縮可以給頁面減肥，這也是提高用戶體驗最簡單的方法。
 
 

7.2 避免圖片src屬性爲空

Image with empty string src屬性是空字符串的圖片很常見，主要以兩種形式出現：

  1. straight HTML

  3. JavaScript

  4. var img = new Image(); img.src = 「」;

這兩種形式都會引發相同的問題：瀏覽器會向服務器發送另外一個請求。
 

7.3 配置ETags

  實體標籤（ETags），是服務器和瀏覽器用來決定瀏覽器緩存中組件與源服務器中的組件是否匹配的一種機制（「實體」也就是組件：圖片，腳本，樣式表等等）。添加ETags能夠提供一種實體驗證機制，比最後修改日期更加靈活。一個ETag是一個字符串，做爲一個組件某一具體版本的惟一標識符。惟一的格式約束是字符串必須用引號括起來，源服務器用相應頭中的ETag來指定組件的ETag：

1
2
3
4		 HTTP/1.1 200 OK
``Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
``ETag: "10c24bc-4ab-457e1c1f"
``Content-Length: 12195

  而後，若是瀏覽器必須驗證一個組件，它用If-None-Match請求頭來把ETag傳回源服務器。若是ETags匹配成功，會返回一個304狀態碼，這樣就減小了12195個字節的響應體。
GET /i/yahoo.gif HTTP/1.1
      Host: us.yimg.com
      If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
      If-None-Match: "10c24bc-4ab-457e1c1f"
      HTTP/1.1 304 Not Modified

** **

7.4 對Ajax用GET請求

  郵箱團隊發現使用XMLHttpRequest時，瀏覽器的POST請求是經過一個兩步的過程來實現的：先發送HTTP頭，在發送數據。因此最好用GET請求，它只須要發送一個TCP報文（除非cookie特別多）。IE的URL長度最大值是2K，因此若是要發送的數據超過2K就沒法使用GET了。
POST請求的一個有趣的反作用是實際上沒有發送任何數據，就像GET請求同樣。正如HTTP說明文檔中描述的，GET請求是用來檢索信息的。因此它的語義只是用GET請求來請求數據，而不是用來發送須要存儲到服務器的數據。
 
 

7.5 儘早清空緩衝區

 當用戶請求一個頁面時，服務器須要用大約200到500毫秒來組裝HTML頁面，在這期間，瀏覽器閒等着數據到達。PHP中有一個flush()函數，容許給瀏覽器發送一部分已經準備完畢的HTML響應，以便瀏覽器能夠在後臺準備剩餘部分的同時開始獲取組件，好處主要體如今很忙的後臺或者很「輕」的前端頁面上（P.S. 也就是說，響應時耗主要在後臺方面時最能體現優點）。
  較理想的清空緩衝區的位置是HEAD後面，由於HTML的HEAD部分一般更容易生成，而且容許引入任何CSS和JavaScript文件，這樣就可讓瀏覽器在後臺還在處理的時候就開始並行獲取組件。
例如：

&emsp;<br />... <!-- css, js --><br />    </head><br />    <?php flush(); ?><br />    <body><br />      ... <!-- content --><br /> 
複製代碼

 

7.6 使用CDN（內容分發網絡）

  用戶與服務器的物理距離對響應時間也有影響。把內容部署在多個地理位置分散的服務器上能讓用戶更快地載入頁面。但具體要怎麼作呢？
  實現內容在地理位置上分散的第一步是：不要嘗試去從新設計你的web應用程序來適應分佈式結構。這取決於應用程序，改變結構可能包括一些讓人望而生畏的任務，好比同步會話狀態和跨服務器複製數據庫事務（翻譯可能不許確）。縮短用戶和內容之間距離的提議可能被推遲，或者根本不可能經過，就是由於這個難題。
  記住終端用戶80%到90%的響應時間都花在下載頁面組件上了：圖片，樣式，腳本，Flash等等，這是業績黃金法則。最好先分散靜態內容，而不是一開始就從新設計應用程序結構。這不只可以大大減小響應時間，還更容易表現出CDN的功勞。
  內容分發網絡（CDN）是一組分散在不一樣地理位置的web服務器，用來給用戶更高效地發送內容。典型地，選擇用來發送內容的服務器是基於網絡距離的衡量標準的。例如：選跳數（hop）最少的或者響應時間最快的服務器。
 

7.7 添上Expires或者Cache-Control HTTP頭

這條規則有兩個方面：

  • 對於靜態組件：經過設置一個遙遠的未來時間做爲Expires來實現永不失效
  • 多餘動態組件：用合適的Cache-ControlHTTP頭來讓瀏覽器進行條件性的請求

  網頁設計愈來愈豐富，這意味着頁面裏有更多的腳本，圖片和Flash。站點的新訪客可能仍是不得不提交幾個HTTP請求，但經過使用有效期能讓組件變得可緩存，這避免了在接下來的瀏覽過程當中沒必要要的HTTP請求。有效期HTTP頭一般被用在圖片上，但它們應該用在全部組件上，包括腳本、樣式和Flash組件。
  瀏覽器（和代理）用緩存來減小HTTP請求的數目和大小，讓頁面可以更快加載。web服務器經過有效期HTTP響應頭來告訴客戶端，頁面的各個組件應該被緩存多久。用一個遙遠的未來時間作有效期，告訴瀏覽器這個響應在2010年4月15日前不會改變。

1 Expires: Thu, 15 Apr 2010 20:00:00 GMT


若是你用的是Apache服務器，用ExpiresDefault指令來設置相對於當前日期的有效期。下面的例子設置了從請求時間起10年的有效期：
ExpiresDefault "access plus 10 years"
 
 
 

7.8 減小dns查詢

域名系統創建了主機名和IP地址間的映射，就像電話簿上人名和號碼的映射同樣。當你在瀏覽器輸入www.shanghai70.com的時候，瀏覽器就會聯繫DNS解析器返回服務器的IP地址。DNS是有成本的，它須要20到120毫秒去查找給定主機名的IP地址。在DNS查找完成以前，瀏覽器沒法從主機名下載任何東西。
  DNS查找被緩存起來更高效，由用戶的ISP（網絡服務提供商）或者本地網絡存在一個特殊的緩存服務器上，但還能夠緩存在我的用戶的計算機上。DNS信息被保存在操做系統的DNS cache(微軟Windows上的」DNS客戶端服務」)裏。大多數瀏覽器有獨立於操做系統的本身的cache。只要瀏覽器在本身的cache裏還保留着這條記錄，它就不會向操做系統查詢DNS。
  IE默認緩存DNS查找30分鐘，寫在DnsCacheTimeout註冊表設置中。Firefox緩存1分鐘，能夠用network.dnsCacheExpiration配置項設置。(Fasterfox把緩存時間改爲了1小時 P.S. Fasterfox是FF的一個提速插件)
  若是客戶端的DNS cache是空的（包括瀏覽器的和操做系統的），DNS查找數等於頁面上不一樣的主機名數，包括頁面URL，圖片，腳本文件，樣式表，Flash對象等等組件中的主機名，減小不一樣的主機名就能夠減小DNS查找。
  減小不一樣主機名的數量同時也減小了頁面可以並行下載的組件數量，避免DNS查找削減了響應時間，而減小並行下載數量卻增長了響應時間。個人原則是把組件分散在2到4個主機名下，這是同時減小DNS查找和容許高併發下載的折中方案。

7.9 避免重定向

重定向用301和302狀態碼，下面是一個有301狀態碼的HTTP頭

HTTP/1.1 301 Moved Permanently       Location: example.com/newuri       Content-Type: text/html

瀏覽器會自動跳轉到Location域指明的URL。重定向須要的全部信息都在HTTP頭部，而響應體通常是空的。其實額外的HTTP頭，好比Expires和Cache-Control也表示重定向。除此以外還有別的跳轉方式：refresh元標籤和JavaScript，但若是你必須得作重定向，最好用標準的3xxHTTP狀態碼，主要是爲了讓返回按鈕能正常使用。
  牢記重定向會拖慢用戶體驗，在用戶和HTML文檔之間插入重定向會延遲頁面上的全部東西，頁面沒法渲染，組件也沒法開始下載，直到HTML文檔被送達瀏覽器。
  有一種常見的極其浪費資源的重定向，並且web開發人員通常都意識不到這一點，就是URL尾部缺乏一個斜線的時候。例如，跳轉到www.shanghai70.com/a會返回一個重定向到www.shanghai70.com/b的301響應（注意添在尾部的斜線）。在Apache中能夠用Alias，mod_rewrite或者DirectorySlash指令來取消沒必要要的重定向。
  重定向最多見的用途是把舊站點鏈接到新的站點，還能夠鏈接同一站點的不一樣部分，針對用戶的不一樣狀況（瀏覽器類型，用戶賬號類型等等）作一些處理。用重定向來鏈接兩個網站是最簡單的，只須要少許的額外代碼。雖然在這些時候使用重定向減小了開發人員的開發複雜度，但下降了用戶體驗。一種替代方案是用Alias和mod_rewrite，前提是兩個代碼路徑都在相同的服務器上。若是是由於域名變化而使用了重定向，就能夠建立一條CNAME（建立一個指向另外一個域名的DNS記錄做爲別名）結合Alias或者mod_rewrite指令。

7.10 Json格式傳輸

在客戶端和服務器端進行數據通訊的時候，咱們儘可能採用json格式進行數據傳輸

  • json格式的數據，可以清晰明瞭的展現出數據結構，並且也方便咱們獲取的操做
  • 相對於很早之前的xml格式傳輸，json格式的數據更加輕量級
  • 客戶端和服務器端都支持json格式數據的處理，處理起來很是的方便

真實項目中:並非全部的數據都基於json，咱們儘量這樣作，可是對於某些特殊的需求(例如文件流的傳輸或者文檔傳輸)，使用json就不合適了

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程