前端性能優化（更新中...）

 今天網站上線本身蒐集總結了一些前端的優化
1.精靈圖

  多個圖片拼成一個圖片，而後經過CSS來控制在什麼地方具體顯示這整張圖片的什麼位置（畢竟流量
都是錢啊）

1. Sprite 中水平排列圖片，垂直排列會增長文件大小

2. Sprite 中把顏色較近的組合在一塊兒能夠下降顏色數，理想情況是低於256色以便適用PNG8格式

3. 不要在Spirite的圖像中間留有較大空隙。這雖然不大會增長文件大小,但對於用戶代理來講它須要更少的內存來把圖片解壓爲像素地圖。100×100的圖片爲1萬像素，1000×1000就是100萬像素

2 css優化

　　 （1 ）css 命名 、書寫規範；（好的代碼看上去就很整齊 頗有條理性這樣方便往後的維護和管理）
 　　（2） 少用濾鏡，少用hack，多使用繼承屬性。
 　　（3 ） 不要在ID選擇器和class選擇器前 使用標籤名 例如：div.box { color: #f00; }; 直接 能夠
           用類名， .box { color:#f00;} 這樣瀏覽器找到這個class後 就不用再匹配是否存在div標籤.從而
             提升了渲染效率 藉助相關繼承關係
      （4 ） 儘可能少的去使用後代選擇器，下降選擇器的權重值 後代選擇器的開銷是最高的，儘可能將選擇器
    　　  的深度降到最低，最高不要超過三層，更多的使用類來關聯每個標籤元素
　　（5 ）不濫用浮動 雖然浮動本科避免 但不能否認不少css bug是因爲浮動而引發。
　　（6 ） 值爲0時不須要任何單位
　　（7 ） 遵照盒模型規則

其次還有：

1. 按需加載，把統計、分享等 js 在頁面 onload 後再進行加載，能夠提升訪問速度；

2. 優化 cookie ，減小 cookie 體積；

3. 避免 <img> 的 src 爲空；

4. 儘可能避免設置圖片大小，屢次重設圖片大小會引起圖片的屢次重繪，影響性能；

5. 合理使用display屬性：

　　 a.display:inline後不該該再使用width、height、margin、padding以及float
　　 b.display:inline-block後不該該再使用float 　　 c.display:block後不該該再使用vertical-align 　　 d.display:table-*後不該該再使用margin或者float

3. js改變樣式直接操做類名　

事件委託

將多個節點上的事件放到其父節點（經典案例：將 li 上的事件綁定到 ul 上）。

 

 

4. js直接操做dom節點

    

　　當操做節點時儘可能將節點添加在元素的後面，若是插入到節點的前面時，會使插入節點以後的節點都引發迴流，而插入到後面時只須要被插入的節點回流一次就能夠了。
　　使用innerHTML的方式代替用appendChild; 由於innerHTML開銷更小,速度更快,同時也更加內存安全.用 createElement方式建立一個dom節點,有一個很重要的細節: 在執行完createElement代碼以後,應該馬     上append到dom樹中; 不然,若是在將這個孤立節點加載到dom樹以前所作的賦值它的屬性和innerHTML的操做都會引起該dom片斷內存沒法回收的問題. 這個不起眼細節,一旦遇到大量dom增刪操做,就會引起內存     的災　難.刪除dom節點以前,必定要刪除註冊在該節點上的事件,不論是用observe方式仍是用attachEvent方式註冊的事件,不然將會產生沒法回收的內存.

5.正則匹配選擇器
6.js獲取元素優化

7.內存溢出

 　　　　 通常在遞歸運行時，會產生內存溢出，形成在運行遞歸時性能大幅度降低，在運行結束後內存
　　會被系統回收，因此在運行遞歸時須要用對象將值保存，在每次遞歸運算時檢測，若是存在則直接返
　　　回，不存在則添加，這樣就能夠解決遞歸的很大性能。

8.對Ajax用GET請求

  　　  POST請求是經過先發送HTTP請求頭，再發送數據來實現的，GET而是沒有請求頭的，可是須要注
　　意：GET大小限制約4K，POST則沒有限制；但POST的安全性要比GET的安全性高。

9.延遲加載圖片

 　　 在頁面發起請求時，請求量過大，可使圖片進行懶加載，當頁面滾到到圖片的位置時，再
　　進行加載圖片。

10 減小http請求次數
　　  使用圖片地圖
 　 　使用CSS Sprites
　 　 合併JS和CSS文件
 　 　避免內部無效的連接
 　 　合理設置 HTTP緩存 恰當的緩存設置能夠大大的減小 HTTP請求
  　　瀏覽器對同一個host有並行下載的限制,http請求越多,整體下載速度越慢

       刪除重複的JS和CSS 重複調用腳本，除了增長額外的HTTP請求外，屢次運算也會浪費時間。在IE和Firefox中無論腳本是否可緩存，它們都存在重複運算JavaScript的問題

　　緩存控制

    請求頭裏，能夠發送 If-Modified-Since 以及 If-None-Match 等信息，來詢問服務端請求內容是否有更新，若是沒有更新，可返回304，告訴瀏覽器使用緩存，避免從新下載資源。Pragma 和 Cache-Control 等    也     能控制緩存。如告訴服務端不要緩存等。

　發送請求時，cookies 也在請求之中。所以，cookies 也能夠做爲減小請求的優化對象。如，根據同源限制策略，可使用多個域名加載資源，如加載靜態資源，就不會發送多餘的 cookies；同時，合理設置 cookies 的路徑和域名，如在子站避免沒必要要的來自父站的 cookies。

11 減小DNS查詢次數
  DNS 是域名系統 (Domain Name System) 的縮寫 DNS查詢也消耗響應時間
  經過使用Keep-Alive和較少的域名來減小DNS查找

 

12 緩存Ajax
「異步」並不意味着「即時」：Ajax並不能保證用戶不會在等待異步的JavaScript和XML響應上花費時間。 Ajax能夠幫助咱們異步的下載網頁內容.咱們仍是要注意儘可能應用如下規則提升ajax的響應速度添加Expires 或 Cache-Control報文頭使回覆能夠被客戶端緩存

壓縮回復內容

減小dns查詢
精簡javascript
避免跳轉
配置Etags
確保Ajax請求遵照性能知道,必要時候應具有長久的expires頭
13 減小DOM元素數量
   DOM操做應該是腳本中最耗性能的一類操做

   經過在瀏覽器中的一條簡單命令就能夠算出使用了多少標籤，
   document.getElementsByTagName('*').length

14 Gzip壓縮傳輸文件

15 減小Cookie大小 

16 移動客戶端
保持單個內容小於25KB
這限制是由於iphone，他只能緩存小於25K，注意這是解壓後的大小。因此單純gzip不必定夠用，精
簡文件工具要用上了。
17 使用CDN緩存

全部網站都會用到第三方資源，對於第三方資源，若是選擇讓本身的服務器提供，那麼對於小型站點，本就不大的帶寬至關一部分還要被公共資源佔用，無形之中壓縮了服務器帶寬，若是把這部分資源讓第三方 cdn 提供，那麼對於網站加載速度會有不小的提高。

博主選用的是 bootstrap 中文站提供的 cdn 靜態庫 ，很多國內 cdn 靜態庫，能夠說 bootstrap 家的仍是很良心的，更新及時，資源如今也很豐富，基本用的三方資源都能在上面找到，因而接下來就是搜索靜態資源 ＋ 替換靜態資源：

<script src="/s/js/jquery.min.js"></script> 改成 <script src="//cdn.bootcss.com/jquery/3.1.1/jquery.min.js"></script>通常網站 90% 的流量都用於靜態資源的加載，除了用免費 cdn 加載第三方資源，還能夠本身申請雲空間儲存本身的靜態資源，進一步減少服務器的開銷，讓服務器只專一於提供數據或者網頁渲染服務。18 避免404有些站點把404錯誤響應頁面改成「你是否是要找***」，這雖然改進了用戶體驗可是一樣也會浪費服務器資源（如數據庫等）。最糟糕的狀況是指向外部 JavaScript的連接出現問題並返回404代碼。首先，這種加載會破壞並行加載；其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分看成JavaScript代碼來執行。