Web前端效能優化（六）減少DNS查詢、避免重定向
一、減少DNS查詢
基礎知識
DNS(Domain Name System)： 負責將域名URL轉化為伺服器主機IP。
DNS查詢流程：首先檢視瀏覽器快取是否存在，不存在則訪問本機DNS快取，再不存在則訪問本地DNS伺服器。所以DNS也是開銷，通常瀏覽器查詢一個給定URL的IP地址要花費20-120ms，在DNS查詢完成前，瀏覽器不能從host那裡下載任何東西。
TTL(Time To Live)：表示查詢返回的DNS記錄包含的一個存活時間，過期則這個DNS記錄將被拋棄。
影響DNS快取的因素
1. 伺服器可以設定TTL值表示DNS記錄的存活時間。本機DNS快取將根據這個TTL值判斷DNS記錄什麼時候被拋棄，這個TTL值一般都不會設定很大，主要是考慮到快速故障轉移的問題。
2. 瀏覽器DNS快取也有自己的過期時間，這個時間是獨立於本機DNS快取的，相對也比較短，例如chrome只有1分鐘左右。
3. 瀏覽器DNS記錄的數量也有限制，如果短時間內訪問了大量不同域名的網站，則較早的DNS記錄將被拋棄，必須重新查詢。不過即使瀏覽器丟棄了DNS記錄，作業系統的DNS快取也有很大機率保留著該記錄，這樣可以避免通過網路查詢而帶來的延遲。
最佳實踐
當客戶端的DNS快取為空時，DNS查詢的數量與Web頁面中唯一主機名的數量相等。所以減少唯一主機名的數量就可以減少DNS查詢的數量。
然而減少唯一主機名的數量會潛在地減少頁面中並行下載的數量，避免DNS查詢降低了響應時間，但減少並行下載可能會增加響應時間。當頁面的元件量比較多的時候，可以考慮將元件分別放到至少2-4個主機名，已獲得最大收益。
二、避免重定向
什麼是重定向？
重定向用於將使用者從一個URL重新路由到另一個URL。
常用重定向的型別
301：永久重定向，主要用於當網站的域名發生變更之後，告訴搜尋引擎域名已經變更了，應該把舊域名的的資料和連結數轉移到新域名下，從而不會讓網站的排名因域名變更而受到影響。
302：臨時重定向，主要實現post請求後告知瀏覽器轉移到新的URL。
304：Not Modified，主要用於當瀏覽器在其快取中保留了元件的一個副本，同時元件已經過期了，這是瀏覽器就會生成一個條件GET請求，如果伺服器的元件並沒有修改過，則會返回304狀態碼，同時不攜帶主體，告知瀏覽器可以重用這個副本，減少響應大小。
重定向如何損傷效能?
當頁面發生了重定向，就會延遲整個HTML文件的傳輸。在HTML文件到達之前，頁面中不會呈現任何東西，也沒有任何元件會被下載。
來看一個實際例子：對於ASP.NET webform開發來說，對於新手很容易犯一個錯誤，就是把頁面的連線寫成伺服器控制元件後臺程式碼裡，例如用一個Button控制元件，在它的後臺click事件中寫上：Response.Redirect("")；然而這個Button的作用只是轉移URL，這是非常低效的做法，因為點選Button後，先發送一個Post請求給伺服器，伺服器處理Response.Redirect("")後就傳送一個302響應給瀏覽器，瀏覽器再根據響應的URL傳送GET請求。正確的做法應該是在html頁面直接使用a標籤做連結，這樣就避免了多餘的post和重定向。
重定向的應用場景
1. 跟蹤內部流量
當擁有一個門戶主頁的時候，同時想對使用者離開主頁後的流量進行跟蹤，這時可以使用重定向。以yahoo.com為例，主頁新聞的連結主機名是http://hsrd.yahoo.com/，後面跟著識別的引數，點選後再產生一個301重定向，這樣就記錄了離開門戶主頁後的流量去向。
我們知道重定向是如何損傷效能的，為了實現更好的效率，可以使用Referer日誌來跟蹤內部流量去向。每個HTTP請求都有一個Referer表示原始請求頁(除了從書籤開啟或直接鍵入URL等操作)，記錄下每個請求的Referer，就避免了向用戶傳送重定向，從而改善了響應時間。
2. 跟蹤出站流量
有時連結可能將使用者帶離你的網站，在這種情況下，使用Referer就不太現實了。
同樣也可以使用重定向來解決跟蹤出站流量問題。以百度搜索為例，百度通過將每個連結包裝到一個302重定向來解決跟蹤的問題，例如搜尋關鍵字“跟蹤出站流量”，搜尋結果的第一個URL為http://www.baidu.com/link?url=後面跟著一連串字元，即使搜尋結果並沒有變，但這個字串是動態改變的，我認為這裡的搜尋連線URL好像沒有改變的需要，不知道這裡起到怎樣的作用？
除了重定向外，我們還可以選擇使用信標(beacon)——一個HTTP請求，其URL中包含有跟蹤資訊。跟蹤資訊可以從信標Web伺服器的訪問日記中提取出來，信標通常是一個1px*1px的透明圖片，不過204響應更優秀，因為它更小，從來不被快取，而且絕不會改變瀏覽器的狀態。