網站性能的優化

具體的從兩方面進行總結

一, 網絡通訊 (下降請求次數,下降傳輸量)

1,合併文件 (下降請求次數)
複製代碼

1.資源緩存

1.1 使用CDN

將網站的靜態資源分離，如靜態HTML、圖片Image、樣式CSS、腳本JS等，把靜態資源部署到CDN中，能夠明顯加快這部分資源的加載速度。
複製代碼

1.2 利用HTTP緩存機制

HTTP緩存會把瀏覽器加載過的資源緩存到本地，下次加載時，只要緩存的資源沒有過時，就能夠直接使用本地的資源，減小了HTTP請求次數，加快了資源加載速度。具體作法是設置HTTP Header 中的Cache-Control參數。HTTP 1.0 中使用Pragma和Expires兩個參數進行緩存，不過早已不推薦使用。
複製代碼

2. 資源的合併壓縮

2.1 減小HTTP請求

用一個HTTP請求去加載一個10M的文件，和把這個文件拆分紅1M的10個文件，用10個HTTP請求並行去加載，哪種方式能更快完成加載？既然提到減小HTTP請求能夠提升網站響應速度，那麼結論貌似應該是用一個HTTP請求的方式更快。其實正確的答案是：不必定！
我作了一個小實驗：有兩個html文件，index1.html和index2.html，index1.html中用1個<script>標籤加載一個2M的js文件bundle.js，index2.html中用6個<script>標籤分別加載bundle1.js, bundle2.js …… bundle6.js，這6個js文件由bundle.js平均拆分獲得。分別請求index1.html和index2.html 10次，獲得加載bundle.js的時間和加載bundle1.js 到 bundle6.js的時間（以最後一個js文件加載完成爲結束時間），計算平均加載時間分別爲：1.07s 和 1.87s。
實驗結論證實了，一個HTTTP請求加載一個合併後的資源文件，比多個HTTTP請求併發加載多個資源文件效率高。但結論只是針對平均加載時間而言，對於單次的比較，徹底可能出現相反的結論，例如個人實驗過程當中，單一HTTTP請求加載時間的最大值爲2.36s，超過了第二種加載方式的平均時間1.87s。可能有些人會比較疑惑，爲何並行的效率反而比串行的要低呢？其實，HTTP請求加載資源的瓶頸在帶寬，而不是請求的數量，在一個請求已經利用帶寬很充分的狀況下，增長新的請求並不能減小總體的資源加載時間。
其實，減小HTTP請求來提升網站性能主要是基於如下2個緣由：

HTTP鏈接的創建是比較耗時的，通常須要上百ms，每一個HTTP請求還有必定的網絡延時，須要的HTTP請求越多，這兩部分產生的耗時也就越多。固然，HTTP 1.1 對keep-alive的默認支持，能夠實現鏈接的複用，很大程度上優化了這個問題。

2）每一個HTTP請求都須要附帶額外的數據，好比請求和響應中的頭信息，Cookie信息。當請求的資源很小時，附帶的額外數據可能比實際的資源還大。
複製代碼

3. 服務器端開啓gzip

服務端開啓gzip壓縮，能夠減小資源文件在網絡傳輸過程當中的體積大小。 啓用gzip壓縮(網絡傳輸的壓縮傳輸的數據代碼量會減少爲原來的三分之一, 傳入後再進行解壓)

4, 圖片的壓縮

減少文件的體積

使用WebP格式的圖片。WebP是一種支持有損壓縮和無損壓縮的圖片文件格式，派生自圖像編碼格式 VP8。根據 Google 的測試，無損壓縮後的 WebP 比 PNG 文件少了 45％ 的文件大小，即便這些 PNG 文件通過其餘壓縮工具壓縮以後，WebP 仍是能夠減小 28％ 的文件大小。

2）使用字體圖標IconFont。能夠任意設置Icon圖形的大小和顏色（只能是單色，由於本質上是給字體設置顏色）。
3）使用CSS Sprites將多張圖片合併成一張，從而減小HTTP請求數量。
4）使用Base64直接把圖片編碼成字符串寫入CSS文件，也是從減小HTTP請求數量考慮。但須要注意，Base64編碼的圖片最好是小圖片（最好幾十字節級別的），由於圖片通過Base64編碼後，通常會比原文件更大些。並且太長的Base64編碼字符串也會影響CSS的總體可讀性。
5）對於須要大量圖片的網站，應該把圖片資源單獨部署，並使用不一樣的域名來訪問。由於圖片資源佔帶寬很大，若是把圖片和其餘資源部署到一臺服務器或一個集羣中，服務器端的出口帶寬會受到很大影響。使用不一樣的域名加載圖片資源，能夠更好的利用瀏覽器並行下載的特性，由於瀏覽器對於一個域名下的最大並行請求數是有限制的。
複製代碼

二, 代碼層

節省內存,節省CPU

1,儘可能不使用閉包(節省內存)

2,杜絕無效的循環

3,遞歸過程優化(添加緩存)
複製代碼