Web性能優化筆記

時間 2019-12-13

標籤 web 性能優化筆記欄目 HTML 简体版

原文原文鏈接

網頁性能優化的目的

減小服務器壓力
加強用戶體驗，減小加載時間，通俗地說就是用戶感受打開你的網頁很快，等待頁面資源加載的時間很短

方法

回答這題的思路要從另外一道面試題：從敲回車開始到頁面展示這個過程發生了什麼入手。如下是其中的一些過程：css

看請求的html頁面有沒緩存，沒有就進行下面步驟
dns查詢
創建TCP鏈接
發送HTTP請求
後臺處理
接收響應
接收完成
讀取html的DOCTYPE
逐行解析
看到<link href='#'>,<script src='#'>就會像服務器發起請求

優化以上每一個步驟，這樣子整個web網頁的性能就提升了html

減小dns查詢

你在瀏覽器地址欄輸入網址，經過DNS查詢獲得網站真實IP。前端

好比你的一個網站，須要向 baidu.com 請求一個js文件，向 bootcdn.cn 請求一個css文件，這樣子就要進行2次dns查詢（沒有dns緩存的狀況下），解決方法就是各類資源放在數量儘可能少的域名下java

域名解析的流程

瀏覽器緩存 – 瀏覽器會緩存DNS記錄一段時間
系統緩存 - 從 Hosts 文件查找是否有該域名和對應 IP。
路由器緩存 – 通常路由器也會緩存域名信息。
ISP DNS 緩存 – 好比到電信的 DNS 上查找緩存。
若是都沒有找到，則向根域名服務器查找域名對應 IP，根域名服務器把請求轉發到下一級，知道找到 IP

把資源分散到不一樣的域名

把資源分散到不一樣的域名容許你最大化並行下載數git

例如chrome，只能同時向一個域名最多發8個請求，把資源分散到不一樣的域名容許你最大化並行下載數，但這樣子dns查詢時間就變長，和前面的「減小dns查詢「衝突了github

若是文件不多，例如只有3個文件，放在1個域名下，這樣dns查詢時間就很快，此時若是把這3個文件分散到更多的域名下，速度也不會提升，由於3個請求尚未達到chrome的只能同時向一個域名最多發請求的數量的極限web

若是文件不少，例如16個文件，還所有放在1個域名下，雖然dns查詢時間很快，但請求時間會很慢，由於只能同時向一個域名最多發8個請求，那另外8個請求要等前面的請求發送完才能再發送面試

懶加載和預加載

懶加載就是例如打開一個網頁，viewport如下的網頁內容先不加載，等到用戶滾動看到那部份內容再加載相應的資源，好處：節省CDN費用，下降服務器壓力chrome

預加載就是預先加載用戶即將要看到的內容，例如當你在第一頁時就預先加載第二頁的內容，這樣子用戶打開第二頁的時候就不用等待加載時間npm

使用CDN

cdn即內容分發網絡，例如谷歌的主服務器1在美國，在北京有個服務器2，服務器2不斷地把主服務器1上的內容複製過來（可能說得不是很準確），這樣子在北京訪問谷歌，直接訪問北京的服務器，比你訪問美國的主服務器要快

傳輸時gzip壓縮資源

從HTTP/1.1開始，客戶端經過http請求中的Accept-Encoding頭部來提示支持的壓縮：

Accept-Encoding: gzip, deflate

若是服務器看到這個頭部，它可能會選用列表中的某個方法壓縮要請求的資源。服務器經過響應中的Content-Encoding頭部提示客戶端：

Content-Encoding: gzip

客戶端接收到響應後會解壓縮

gzip通常可減少響應的70%。儘量去gzip更多（文本）類型的文件。html，腳本，樣式，xml和json等等都應該被gzip，而圖片，pdf等等不該該被gzip，由於它們自己已被壓縮過，gzip它們只是浪費cpu，甚至增長文件大小。

Cache-Control

//後臺代碼
 if (path  ==='/js/main.js') {
   let  string  =    fs.readFileSync('./js/main.js', 'utf8')；
   response.setHeader('Content-Type',   'application/javasript;charset=utf-8')；
  response.setHeader('Cache-Control',   'max-age=30')；
  response.write(string)；
  response.end()
}

max-age=30指當第一次請求並下載/js/main.js後，30s內遇到一樣/js/main.js的請求(例如刷新當前頁面），會從緩存裏直接讀取main.js,不會再向服務器發請求

靜態資源：將 Expires 響應頭設置爲未來很遠的時間，實現「永不過時」策略；
動態資源：設置合適的 Cache-Control 響應頭，讓瀏覽器有條件地發起請求。

ETag

在典型用法中，當一個URL被請求，Web服務器會返回資源和其相應的ETag值，它會被放置在HTTP的「ETag」字段中：

ETag: "686897696a7c876b7e"

而後，客戶端能夠決定是否緩存這個資源和它的ETag。之後，若是客戶端想再次請求相同的URL，將會發送一個包含已保存的ETag和「If-None-Match」字段的請求。

If-None-Match: "686897696a7c876b7e"

客戶端請求以後，服務器可能會比較客戶端的ETag和當前版本資源的ETag。若是ETag值匹配，這就意味着資源沒有改變，服務器便會發送回一個極短的響應，包含HTTP 「304 未修改」的狀態。304狀態告訴客戶端，它的緩存版本是最新的，並應該使用它。

然而，若是ETag的值不匹配，這就意味着資源極可能發生了變化，那麼，一個完整的響應就會被返回，包括資源的內容，就好像ETag沒有被使用。這種狀況下，客戶端能夠用新返回的資源和新的ETag替代先前的緩存版本。

部分的後臺Node.js示例代碼：

上圖代碼的md5(string)能輸出string的md5值，用的是https://www.npmjs.com/package... ，170k指的是string的大小

用沒有cookie的域名提供資源

當瀏覽器請求靜態圖片並把cookie一塊兒發送到服務器時，cookie此時對服務器沒什麼用處。因此這些cookie只是增長了網絡流量。因此你應該保證靜態資源的請求是沒有cookie的。能夠建立一個子域名來託管全部靜態組件。

好比，你域名是www.example.org，能夠把靜態資源託管在static.example.org。不過，你若是把cookie設置在頂級域名example.org下，這些cookie仍然會被傳給static.example.org。這種狀況下，啓用一個全新的域名來託管靜態資源

另一個用沒有cookie的域名提供資源的好處是，某些代理可能會阻止緩存待cookie的靜態資源請求。

減小cookie體積

後端代碼經過 Set-Cookie 響應頭設置 Cookie的內容
瀏覽器獲得 Cookie 以後，每次訪問相同域名的網頁時, 每次請求的header都會帶上 Cookie,例如

Cookie:sessionId=44438.40790818172

http cookie的使用有多種緣由，好比受權和個性化。cookie的信息經過http頭部在瀏覽器和服務器端交換。儘量減少cookie的大小來下降響應時間。

消除沒必要要的cookie。
儘量減少cookie的大小來下降響應時間。
注意設置cookie到合適的域名級別，則其它子域名不會被影響。

選擇`<link>`而不是`@import`。

以前的一個最佳原則是說CSS應該在頂部來容許逐步渲染。

在IE用@import和把CSS放到頁面底部行爲一致，因此最好別用

減小/最小化 http 請求數。

有如下幾個技術：

Combined files。合併文件，如合併js，合併css都能減小請求數。若是頁面間腳本和樣式差別很大，合併會更具挑戰性。
CSS Sprites。雪碧圖能夠合併多個背景圖片，經過background-image 和 background-position 來顯示不一樣部分。
Inline images。使用data:url scheme來內連圖片。