性能黃金法則:javascript
只有10%~20%的最終用戶響應時間花在了下載HTML文檔上。其他的80%~90%時間花在了下載頁面中的全部組件下。java
HTTP概述:數據庫
(1)、 壓縮:瀏覽器:Accept-Encoding(gzip、deflate) 服務器:Content-Encoding瀏覽器
(2)、 緩存:瀏覽器:If-Modified-Since 服務器:Last-Modified緩存
若是組件自生成日期以來,沒有改變過,服務器返回304—Not Modified服務器
服務器:Expires網絡
條件GET請求和304響應有助於讓頁面加載更快,但仍須要在客服端和服務器之間進行一次往返確認,以執行有效性檢查。異步
Expires頭經過明確指出瀏覽器是否可使用組件的緩存副原本消除這個需求。函數
規則一、減小HTTP請求(CSS Sprites, 合併腳本和樣式表)性能
規則二、使用內容發佈網絡(CDN):其是一組分佈在多個不一樣地理位置的Web服務器,用於更加有效地向用戶發佈內容。
CDN用於發佈靜態內容,如圖片、腳本、樣式等,提供動態HTML頁面會引入特殊的存儲需求—數據庫鏈接等,這些複雜性超越了CDN的能力範圍。
規則三、添加Expires(HTTP1.0)頭:頁面的初訪者會進行不少HTTP請求,但經過使用一個長久的Expires頭,使這些組件能夠被緩存,這會在後續的頁面瀏覽中避免沒必要要的HTTP請求。
Expires缺點:Expires頭使用一個特定的時間,並要求服務器與客戶端的時鐘同步,且,過時日期須要常常檢查,一旦Expires失效,還須要在服務器配置中提供一個新的日期。
HTTP1.1引入Cache-Control使用max-age來指定組件被緩存多久(是以秒爲單位),從而消除Expires限制。如
:Cache-Control: max-age = 31536000
規則四、壓縮組件:經過減小HTTP響應的大小來減小響應時間。若是HTTP請求產生的響應包很小,傳輸時間就會減小,由於只須要將很小的包從服務器傳遞給客服端。
HTTP1.1 客服端
服務端
Accept-Encoding:gzip, deflate
Content-Encoding:gzip
注:圖片和PDF不該該壓縮,由於它們原本就已經被壓縮了。試圖對它們進行壓縮,只會浪費CPU資源,還可能會增長文件大小。
Apache1.3使用mod-gzip模塊壓縮文件爲gzip
Apache2.x使用mod-deflate模塊壓縮文件爲deflate
解決代理緩存問題:
Vary: Accept-Encoding 默認狀況下,mod-gzip會向全部響應添加Vary: Accept-
Encoding頭,以驅使代理執行正確操做。
Cache-Control:private 禁止代理緩存,防止邊緣情形,服務器發送加了gzip的文件給不支持gzip的瀏覽器。
規則五、將樣式表放在頂部:樣式表在頁面中的位置並不影響下載時間,但會影響頁面呈現。遵循HTML規範,將其放在頂部,兩種狀況(白屏和無樣式內容閃爍FOUC)都無需承擔風險。
規則六、將腳本放在底部,這樣頁面既能夠逐步呈現,也能夠提升下載的並行度。
規則七、避免CSS表達式
規則八、使用外部JavaScript和CSS
內聯更快一些,只限於首次請求,由於外部要承擔更多的http請求。但外部文件能夠緩存。若是網站中的每一個頁面都使用了相同JavaScript和CSS,使用外部文件能夠提升這些組件的重用率。
規則九、減小DNS查找
DNS(Domain Name
System),將主機名映射到IP地址上。減小惟一主機名的數量就能夠減小DNS查找的數量。但減小惟一主機名的數量會潛在地減小頁面中並行下載的數量。
另:能夠經過Keep-Alive,它能夠經過重用現有鏈接,從而避免TCP/IP開銷來減小時間,且確保服務器支持Keep-
Alive,還能減小DNS查找。
規則十、精簡JavaScript
規則十一、避免重定向
重定向用於將用戶從一個URL從新路由到另外一個URL,重定向有多種—301,302是最多見的兩種。重定向會使頁面變慢,由於它延遲了整個HTML文檔的傳輸。
規則十二、移除重複腳本
規則1三、配置Etag
當緩存組件過時時,會發送http請求,服務器會檢測過時組件是否和原始服務器上的組件匹配,有兩種方式:
一、 比較最新修改日期HTTP1.0—服務器(Last-Modified),瀏覽器(If-Modified-Since)
二、 比較實體標籤HTTP1.1,且優先級高於1—服務器(Etag),瀏覽器(If-None-
Match),另當網站被宿主在多個服務器上時,Etag可能會阻礙緩存。
規則1四、使Ajax可緩存
瀏覽器一般在運行JavaScript上花費的時間不多,絕大部分時間消耗在DOM上。
第二章:建立快速響應的Web應用
若是JavaScript代碼執行時間超過0.1秒,頁面將會給人不夠平滑快捷的感受;超過1秒,則會感到應用程序緩慢;超過10秒,則die。
能夠利用WebWorker和定時器解決。
第四章:無阻塞加載腳本
瀏覽器在下載和執行腳本時,出現阻塞的緣由在於,腳本可能會改變頁面或JavaScript的名字空間,它們會對後續內容形成影響,如document.write改變頁面。
下面列出來的技術既擁有外部腳本的好處,又能避免阻塞致使的減速影響:
一、 XHR Eval
二、 XHR注入
三、 Script in Iframe
四、 Script DOM Element
五、 Script Defer
六、 Document.write Script Tag,注: 雖然多個腳本能夠並行瞎子,但瀏覽器仍然阻塞其餘類型的資源。
當外部腳本按常規方式加載時,它會阻塞行內代碼的執行,競爭狀態不會發生。一旦咱們開始異步加載腳本,就須要一種技術把行內代碼和依賴行內代碼的外部腳本整合起來。以下:
一、 硬編碼回調—將依賴函數改成在外部腳本中調用它。
二、 Window.onload—缺點:異步腳本必須阻塞onload;致使延遲執行
三、 定時器—輪詢
四、 Script onload—最佳
五、 Degrading Script Tags,以下:
<script src=’M.js’ type=’text/javascript’> var a = 1; function init(){M(a)}; </script>
第六章:佈置行內腳本
雖然行內腳本不會產生額外的http請求,但會阻塞頁面上資源的並行下載,還會阻塞逐步渲染。解決方案,以下:
一、 行內腳本移至底部
二、 使用異步回調啓動JavaScript的執行
三、 使用Script的defer屬性
注:關於樣式表,瀏覽器按照樣式表在頁面中列出的順序應用它們,而與下載順序無關。
當把行內腳本放置在樣式表以後時,該行爲明顯地延遲資源的下載。這個順序致使只有樣式表下載完成而且行內腳本執行完畢,後續資源才能開始下載。
第八章:可伸縮的Comet
Comet,描述技術、協議和瀏覽器提供可行且可擴展的低延遲數據傳輸實現的集合,目標包括隨時從服務端向客戶端推送數據,提高傳統Ajax的速度和可擴展性。
在客戶端經常使用的技術包括輪詢、長輪詢、永久幀、XHR流以及WebSocket。
第十章:圖像優化
該章內容包括:
一、Web上不一樣圖像格式的特徵(GIF、JPEG和PNG)
二、自動化無損壓縮
三、AlphaImage Loader濾鏡
四、優化Sprites
五、其餘圖像技術
RGB顏色模型能夠展現256256256中顏色,支持這麼多顏色的圖像格式叫作真彩色圖像格式,如JPEG和真彩色類型的PNG.
爲了節省圖像信息存儲空間,有一項技術是將圖像中各類不一樣顏色提取出來建一個表,這個表一般叫調色板,最經常使用的調色板圖像格式爲GIF和PNG8。
GIF:是一種調色板圖像格式。
透明度只支持(0/1)狀態,即透明或不透明;支持動畫;
無損:也就是你打開任意一個GIF文件,作一些修改,保存關閉時,不會損失任何質量。
JPEG:有損,不支持透明和動畫。JPEG是Web上用來存儲照片的最佳格式。
PNG:徹底支持透明,且無損。
PNG又分爲調色板PNG和真彩色PNG。
PNG8:調色板PNG
PNG24:真彩色PNG,但不支持alpha
PNG32:真彩色PNG,支持alpha
第十一章:劃分主域
瀏覽器執行「每一個服務端最大鏈接數」的限制,是根據URL上的主機名,而不是解析出來的 IP地址。
第十三章:少用iframe
Iframe:
一、開銷最高的DOM元素;
二、iframe阻塞onload事件,能夠動態設置iframe的src屬性和在onload事件後設置src屬性來避免。
第十四章:簡化CSS選擇符
CSS選擇符是從右到左進行匹配的。
選擇符有:ID、類、類型、相鄰+、子選擇>、後代、通配符、屬性、僞類和僞元素