性能黃金法則：

 

只有10%~20%的最終用戶響應時間花在了下載HTML文檔上。其余的80%~90%時間花在了下載頁面中的所有組件上。

 

提升加載速度的方式：
 

 

(1).合并腳本 和樣式表

 

將多個樣式表或者腳本文件合并到一個文件中，可以減少HTTP請求的數量從而縮短效應時間。 不過：合并所有的樣式文件或者腳本文件可能會導致在一個頁面加載時加載了多于自己所需要的樣式或者腳本，對于只訪問該網站一個頁面的人來說反而增加了下載量，所以大家應該自己權衡利弊。

 

(2).字體圖標

 

(3).雪碧圖

 

(4).圖片地圖

 

知識點鏈接：krq623.cn，將所有點擊提交到同一個url，同時提交用戶點擊的x、y坐標，服務器端根據坐標映射響應

 

 CDN（內容發布網絡）是一組分布在多個不同地理位置的Web服務器，如果應用程序web服務器離用戶更近，那么HTTP請求的響應時間將縮短。

 

瀏覽器在第一次訪問頁面時加載的資源會緩存起來，第二次訪問判斷在緩存中是否已有該資源并且有沒有更新過，如果已有該資源且沒有更新過，則去緩存去取，這樣減少了下載資源的時間。原理上是通過HTTP Rquest Header中的 if-modified-since 和Response Headers中的last-modified來實現，HTTP請求把if-modified-sincede 時間傳給服務端，服務端把last-modified時間與之對比，如果相同，則意味著文件沒有改動，則返回304，瀏覽器則從緩存中獲取資源，無需下載。雖然這種方法減少了已緩存資源的下載時間，但是仍然發起了一次http請求。

而HTTP的Expires和Cache-Control就是來免去該資源的http請求。

Cache-Control在服務端配置文件緩存有效期（3個月，1年...），有效期內讀緩存數據，不HTTP請求。

expires在服務端配置，添加的是該資源過期的日期，瀏覽器會根據該過期日期與客戶端時間對比，到期 了再重新讀取，expires時間可能存在客戶端時間跟服務端時間不一致的問題，最好與Cache-Control結合使用。更多詳細請參考：krq623.cn

 

在HTTP請求中，accept-encoding: gzip, deflate, sdch, br是指客戶端瀏覽器（這里是我的chrome瀏覽器）支持的壓縮方式。參考Yahoo！工程師的說法，支持gzip的瀏覽器范圍最廣，使用gzip的壓縮效果最佳?？蛻舳瞬挥萌魏闻渲茫诜斩伺渲眉纯?，服務器不同，配置方法也不盡相同。

 

Accept-Encoding: gzip,deflate...如果Web服務器看到請求中有這個頭，就會使用客戶端列出來的方法中的一種來進行壓縮。

 

 

代理緩存

 

放在頭部對于實際頁面加載的時間并不能造成太大影響，但可以減少頁面首屏出現的時間，使頁面內容逐步呈現，改善用戶體驗，防止“白屏”。

 

我們總是希望頁面能夠盡快顯示內容，為用戶提供可視化的回饋，這對網速慢的用戶來說是很重要的。

 

將樣式表放在文檔底部會阻止瀏覽器中的內容逐步出現。為了避免當樣式變化時重繪頁面元素，瀏覽器會阻塞內容逐步呈現，造成“白屏”。這源自瀏覽器的行為：如果樣式表仍在加載，構建呈現樹就是一種浪費，因為所有樣式表加載解析完畢之前不需繪制任何東西

 

與樣式表相同，腳本放在底部對于實際頁面加載的時間并不能造成太大影響，但是這會減少頁面首屏出現的時間，使頁面內容逐步呈現。

 

js的下載和執行會阻塞Dom樹的構建（嚴謹地說是中斷了Dom樹的更新），所以script標簽放在首屏范圍內的HTML代碼段里會截斷首屏的內容。

 

因為腳本可能修改頁面內容，因此瀏覽器會等待；另外，也是為了保證腳本能夠按照正確的順序執行，因為后面的腳本可能與前面的腳本存在依賴關系，不按照順序執行可能會產生錯誤。

 

內聯腳本或者樣式可以減少HTTP請求，按理來說可以提高頁面加載的速度。然而在實際情況中，當腳本或者樣式是從外部引入的文件，瀏覽器就有可能緩存它們，從而在以后加載的時候能夠直接使用緩存，而HTML文檔的大小減小，從而提高加載速度。

 

這時候就要分情況來看，如果一個用戶每個月只訪問你的網站一兩次，那么這種情況下內聯將會更好。而如果該用戶能夠產生很多頁面瀏覽量，那么緩存的樣式和腳本將會極大減少下載的時間，提交頁面加載速度。

 

當我們在瀏覽器的地址欄輸入網址（譬如： krq623.cn） ，然后回車，回車這一瞬間到看到頁面到底發生了什么呢？

 

域名解析 --> 發起TCP的3次握手 --> 建立TCP連接后發起http請求 --> 服務器響應http請求，瀏覽器得到html代碼 --> 瀏覽器解析html代碼，并請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給用戶

 

域名解析是頁面加載的第一步，那么域名是如何解析的呢？見文章：（后面補上，or自行百度）

 

DNS也是開銷，通常瀏覽器查找一個給定域名的IP地址要花費20~120毫秒，在完成域名解析之前，瀏覽器不能從服務器加載到任何東西。那么如何減少域名解析時間，加快頁面加載速度呢？

 

當客戶端DNS緩存（瀏覽器和操作系統）緩存為空時，DNS查找的數量與要加載的Web頁面中唯一主機名的數量相同，包括頁面URL、腳本、樣式表、圖片、Flash對象等的主機名。減少主機名的 數量就可以減少DNS查找的數量。

 

而減少唯一主機名的數量會潛在減少頁面中并行下載的數量，這樣減少主機名和并行下載的方案會產生矛盾，需要大家自己權衡。建議將組件放到至少兩個但不多于4個主機名下，減少DNS查找的同時也允許高度并行下載。

 

對于一些圖片，費首屏的，后面scroll到的時候再加載

 

模塊化開發，只需加載用到的資源

 

預加載是在瀏覽器空閑時請求將來可能