我們先來看乙個瀑布圖來確定乙個頁面效能問題是由哪些項造成的。
chorome
自帶開發人員工具
圖中每一行表示乙個
請求，每乙個請求都有一條時間線，用於標識這個請求所花費的時間。如果將滑鼠放到某一條時間線上，可以看到以下資訊
1）首先看一下哪個請求花費的時間比較長，看看這個請求的時間線資訊，確定是伺服器響應慢了還是網路的問題。
2）如果每個請求所花費的時間都沒有明顯高於其他，那麼就看一下是不是頁面的
http請求總數太多了。因為瀏覽器對單個網域名稱的併發連線數是有限制的，需要處理完一批請求再傳送另一批請求。假設頁面有100個請求，每個請求花費1s，瀏覽器最大併發數限制為10個，那麼處理完所為請求就需要100/10*1s=10s的時間。
關於最大併發數，
http1.1的標準是2，而目前主流的瀏覽器ie、firefox、chrome為了提高速度，分別修改為10、6、6（根據具體版本可能有所變化）。
一項專門研究就網頁效能的工程師發現，乙個頁面從請到載入完成，
80%的時間花在前端上。事實也是如此，以圖一為例，整個頁面完全載入完成花費12s
，伺服器響應事件只有
391ms
，其他事件都花費在獲取頁面靜態檔案（js，
css
空連線指：
img，link script
和iframe
元素的src
或href
屬性的值為空（如：
src="")
，一般瀏覽器會將空解析為
blank
，付傳送請求。但是
ie還是會傳送請求的
層級越深的節點在初始化構建時，所占用記憶體越多
刪除對執行結果無影響的空行和注釋
瀏覽器在解析常規
script
標籤時，會等待
script
html
**就只能等待，所以應將指令碼放在文件末尾
css中沒用的控台符號刪去，達到縮減字元的目的。
我們有這樣一段
css指令碼
.test.test應用抽離原則，在很多時候我們把頁面通用的
使用sprites
，可以減少
的請求次數
相信做如果我們把所有css都放到頁面頂部，這樣就沒有重新渲染的過程了
web效能的優化，主要還得根據工具分析來檢視，對症下藥，應該主要影響方面進行優化。
web效能優化
可以用gulp的gulp uglify gulp minify css模組完成 還可以用webpack的uglifyjsplugin壓縮外掛程式完成。通過css sprites將多個整合到乙個中，在用css來定位。伺服器在處理大流量的資料是十分困難的，這最終導致頁面載入速度變慢。cdn是位於全球不同...
web 效能優化
優化方向有兩個 http 請求 js 載入 開啟瀏覽器控制台的網路，可以看到從拉取模版開始到首次渲染中間到底在載入什麼，如果中間某些資源載入速度過慢，則可以從這方面入手，否則的話有可能是解析 js 速度過慢導致。請求優化 合理使用快取 合理使用快取，降低請求等待的時間，可以通過達到效能優化 cdn ...
Web效能優化
我們先來看乙個瀑布圖來確定乙個頁面效能問題是由哪些項造成的。chorome自帶開發人員工具 圖中每一行表示乙個http請求，每乙個請求都有一條時間線，用於標識這個請求所花費的時間。如果將滑鼠放到某一條時間線上，可以看到以下資訊 網域名稱解析 搜尋dns伺服器並解析網域名稱為ip位址所花費的事件，這裡...