前端頁面的性能優化

減小HTTP請求

文件合併

合併css或js文件使要下載的文件數減小

css sprites

使用圖片精靈將大量的背景圖片整合到一張圖片，而後用background-image和background-position控制背景圖片的位置定位到要顯示的圖片，適用於數量多，體積小的圖表等圖片。

行內圖片（base64格式）

將圖片轉化爲base64格式直接嵌入html內部

服務端設計配置

跨域分離組件

分離組件能夠最大化並行下載，但要確保只用不超過2-4個域，由於存在DNS查找的代價。例如，能夠把HTML和動態內容部署在www.example.org，而把靜態組件分離到static1.example.org和static2.example.org。

減小DNS查詢（較少主機數量）

當在瀏覽器導航欄中輸入網站地址時，瀏覽器會按照瀏覽器DNS緩存、計算機DNS緩存、DNS服務器的順序以此查找與域名相映射的IP。

DNS查找數與頁面主機數相同，較少主機數就能夠較少DNS查找數，可是減小主機數也減小了頁面組件可以並行下載的數量。所以找到一個平衡值能夠兼顧二者的須要。2-4個主機名是同時減小DNS查找和容許高併發下載的折中方案。

避免重定向

重定向會拖慢用戶體驗，在用戶和HTML文檔之間插入重定向會延遲頁面上的全部東西，頁面沒法渲染，組件也沒法下載，直到新的文檔被送到瀏覽器。

壓縮組件資源

支持壓縮的Accept-Encoding HTTP請求頭。

Content-Encoding響應頭

儘量多地用gzip壓縮減小資源體積。

使用CDN（內容分發網絡）

內容分發網絡（CDN）是一組分散在不一樣地理位置的web服務器，用來給用戶更高效地發送內容。

使用緩存

使用緩存能夠避免重複下載資源，加快響應時間

設置響應頭Expires

Expires 頭指定了一個日期/時間， 在這個日期/時間以後，HTTP響應被認爲是過期的；在這以前的時間均可以使用緩存。

通用消息頭cache-control（單項指令，意味着在響應裏設置的指令，在請求中不用包含相同的指令。）

能夠指定多項配置控制緩存是否可用、以及可用時間、或者根據驗證器判斷緩存是否可用。能夠覆蓋expires的設置。

響應頭Last-Modified/請求頭If-Modified-Since

因爲精確度比 ETag 要低，因此這是一個備用機制。指定服務器資源的下次更新時間，在這以前均可以使用緩存。

響應頭ETag/請求頭If-None-Match

服務器接收到請求時根據If-None-Match的驗證碼判斷資源是否已改變，若是給定URL中的資源更改，則必定要生成新的Etag值，而後返回給客戶端。

前端設計配置

延遲加載組件

JavaScript是分隔onload（資源加載完畢）事件以前和以後的一個理想選擇。例如，若是有JavaScript代碼和支持拖放以及動畫的庫，這些均可以先等會兒，由於拖放元素是在頁面最初渲染以後的。其它能夠延遲加載的部分包括隱藏內容（在某個交互動做以後纔出現的內容）和摺疊的圖片。

預加載組件

經過預加載組件能夠充分利用瀏覽器空閒的時間來請求未來會用到的組件（圖片，樣式和腳本）。用戶訪問下一頁的時候，大部分組件都已經在緩存裏了，因此在用戶看來頁面會加載得更快。

減小DOM元素數量

一個複雜的頁面意味着要下載更多的字節，dom數的生成也會受到影響，並且用JavaScript訪問DOM也會更慢。

儘可能少使用iframe

• 代價高昂，即便是空白的iframe

• 阻塞頁面加載

• 非語義

把JavaScript和CSS放到外面

用外部文件可讓頁面更快，由於JavaScript和CSS文件會被緩存在瀏覽器。

HTML文檔中的行內JavaScript和CSS在每次請求該HTML文檔的時候都會從新下載。

這樣作減小了所需的HTTP請求數，但增長了HTML文檔的大小。 並且另外一方面，若是JavaScript和CSS在外部文件中，而且已經被瀏覽器緩存起來了，那麼咱們就成功地把HTML文檔變小了，並且尚未增長HTTP請求數。

壓縮JavaScript和CSS

從代碼中去除沒必要要的字符以減小大小，從而提高加載速度。代碼最小化就是去掉全部註釋和沒必要要的空白字符（空格，換行和tab）

對Ajax用GET請求

瀏覽器的POST請求是經過一個兩步的過程來實現的：先發送HTTP頭，在發送數據。因此最好用GET請求，它只須要發送一個TCP報文（除非cookie特別多）。

css部分

把樣式表放在頂部

把樣式表放到文檔的HEAD部分能讓頁面看起來加載地更快。這是由於把樣式表放在head裏能讓頁面逐步渲染。

避免使用CSS表達式

用CSS表達式動態設置CSS屬性，是一種強大又危險的方式。從IE5開始支持，但從IE8起就不推薦使用了。

選擇<link>捨棄@import

@import的導入方式至關於在文檔底部引入css文件，不利於頁面的加載體驗

js部分

去除重複腳本

重複腳本會建立沒必要要的HTTP請求，執行無用的JavaScript代碼，而影響頁面性能。

儘可能減小DOM訪問

用JavaScript訪問DOM元素是很慢的，因此，爲了讓頁面反應更迅速，應該：

• 緩存已訪問過的元素的索引

• 先「離線」更新節點，再把它們添到DOM樹上

• 避免用JavaScript修復佈局問題

使用事件委託

有時候感受頁面反映不夠靈敏，是由於有太多頻繁執行的事件處理器被添加到了DOM樹的不一樣元素上。事件可以冒泡，因此能夠捕獲事件並得知哪一個按鈕是事件源。

把腳本放在底部

腳本會阻塞並行下載，HTTP/1.1官方文檔建議瀏覽器每一個主機名下並行下載的組件數不要超過兩個，若是圖片來自多個主機名，並行下載的數量就能夠超過兩個。若是腳本正在下載，瀏覽器就不開始任何其它下載任務，即便是在不一樣主機名下的。

可是若是腳本是用document.write插入到頁面內容中的，就沒辦法再往下移了。

用推遲（deferred）腳本，有DEFER屬性的腳本意味着不能含有document.write，而且提示瀏覽器告訴他們能夠繼續渲染。

圖片

優化選擇圖片

嘗試把GIF格式轉換成PNG格式，看看是否節省空間。在全部的PNG圖片上運行pngcrush（或者其它PNG優化工具）

優化CSS Sprite

• 在Sprite圖片中橫向排列通常都比縱向排列的最終文件小

• 組合Sprite圖片中的類似顏色能夠保持低色數，最理想的是256色如下PNG8格式

• 「對移動端友好」，不要在Sprite圖片中留下太大的空隙。雖然不會在很大程度上影響圖片文件的大小，但這樣作能夠節省用戶代理把圖片解壓成像素映射時消耗的內存。100×100的圖片是1萬個像素，而1000×1000的圖片就是100萬個像素了

儘可能使用尺寸恰好知足需求的圖片

不要由於在HTML中能夠設置寬高而使用本不須要的大圖。若是須要

<img width="100" height="100" src="mycat.jpg" alt="My Cat" />

那麼圖片自己（mycat.jpg）應該是100x100px的，而不是去縮小500x500px的圖片。

用小的可緩存的favicon.ico（P.S. 收藏夾圖標）

favicon.ico是放在服務器根目錄的圖片，它會帶來一堆麻煩，由於即使你無論它，瀏覽器也會自動請求它，因此最好不要給一個404 Not Found響應。並且只要在同一個服務器上，每次請求它時都會發送cookie，此外這個圖片還會干擾下載順序，例如在IE中，當你在onload中請求額外組件時，將會先下載favicon。

避免圖片src屬性爲空

圖片src屬性爲空會致使瀏覽器向服務器發送另外一個請求。

Cookie

給Cookie減肥

發送cookie也會影響性能，因此保證cookie儘量的小，以最小化對用戶響應時間的影響。

• 清除沒必要要的cookie

• 保證cookie儘量小，以最小化對用戶響應時間的影響

• 注意給cookie設置合適的域級別，以避免影響其它子域

• 設置合適的有效期，更早的有效期或者none能夠更快的刪除cookie，提升用戶響應時間

把組件放在不含cookie的域下

當瀏覽器發送對靜態資源的請求時，cookie也會一塊兒發送，而服務器根本不須要這些cookie。因此它們只會形成沒有意義的網絡通訊量，應該確保對靜態組件的請求不含cookie。能夠建立一個子域，把全部的靜態組件都部署在那兒。

有一點須要注意：若是不知道應該用example.org仍是www.example.org做爲主頁，能夠考慮一下cookie的影響。省略www的話，就只能把cookie寫到*.example.org，因此由於性能緣由最好用www子域，而且把cookie寫到這個子域下。

www是一個主域的二級子域，但指向的仍是主域。

移動端

保證全部組件都小於25K

這個限制是由於iPhone不能緩存大於25K的組件，注意這裏指的是未壓縮的大小。這就是爲何縮減內容自己也很重要，由於單純的gzip可能不夠。

把組件打包到一個複合文檔裏

把各個組件打包成一個像有附件的電子郵件同樣的複合文檔裏，能夠用一個HTTP請求獲取多個組件（記住一點：HTTP請求是代價高昂的）。用這種方式的時候，要先檢查用戶代理是否支持（iPhone就不支持）。