前語：

最近一向在做功用優(yōu)化和模塊化改造的作業(yè)，并完結了一次前端重構。在這里總結出一些經歷和得失來幫助咱們思考。共兩篇文章，第一篇評論功用優(yōu)化，第二篇評論模塊化結構。而之所以把這兩個論題放到一同，是由于這兩項作業(yè)都涉及到對前端代碼進行不一樣程度的重構，并且模塊化改造其實是咱們在對功用優(yōu)化做到必定程度以后發(fā)現(xiàn)有必要要做的一件事情。本篇是功用優(yōu)化的有些，下面我把咱們的商品簡稱為N頁面。

應用場景剖析：

N頁面作為一個進口頁面，對頁面加載速度有著極高的請求。一起，N頁面內部卻又有著非常復雜的功用與交互。N頁面的第一版上線時，頁面引用的js文件有3個，總共40-50k（緊縮&Gzip以后）。頁面onload時刻在1.3秒。

1.3秒的load時刻，相比較絕大多數(shù)網站來說都是一個不錯的數(shù)值。但老板一句話“怎樣這個頁面翻開這么慢”，馬上像是給咱們的后背安了一枚定時炸彈。功用優(yōu)化成了N頁面下一步作業(yè)的重中之重。

老板注重頁面速度，關于Web前端開發(fā)人員來說其實是件幸事，這表明你將有更豐厚的時刻和資本去實習Web功用優(yōu)化這一課題，不必被輾轉反側的商品升級需要所打擾。那么關于N頁面，咱們做了哪些實習：

常規(guī)優(yōu)化手法包含：

CSS置頂，JS置底。

靜態(tài)資本外聯(lián)、兼并、緊縮。

圖像優(yōu)化。（Png運用pngcrush；Gif運用gifsicle；Jpeg運用jpegtran）

圖像推遲加載。（首要對于首屏外的圖像。）

運用CSS Sprite，首屏圖像悉數(shù)合到一張圖上。

靜態(tài)文件上CDN。（靜態(tài)文件的下載能提速20%左右。）

靜態(tài)文件設置強緩存。（射中強緩存82.4%；射中若緩存3.4%；未射中緩存14.2%。）

HTML緊縮。（Gzip后削減%5。）

增強型手法：

根底庫定制。（用代碼剖析代碼，主動打包被運用到的辦法作為根底庫，使根底庫從本來的緊縮后25K減小為9.8K，減小了61%）

頁面數(shù)據存儲優(yōu)化。（從本來的直接寫json形式的script，變?yōu)閷�json隱藏在textarea中，初始化或用到的時分才去獲取并進行解析。）

首屏CSS檢測。（對首屏用到的CSS進行檢測，將不歸于首屏的CSS代碼獨自打包并移到首屏以外進行推遲加載）

js按需加載。（在后面做要點介紹）

監(jiān)控& 丈量

功用優(yōu)化最重要的作業(yè)不是優(yōu)化而是監(jiān)控。這個道理很簡單：沒有監(jiān)控系統(tǒng)就沒辦法衡量功用優(yōu)化的作用，那么你所做的任何作業(yè)都是盲目的。

咱們對功用的監(jiān)控是從多個維度展開的，包含均勻時刻、時段散布、瀏覽器散布、省份、運營商等。便于發(fā)現(xiàn)和定位任何一個細節(jié)的疑問。

而在均勻時刻這一維度，咱們又分為四個等級：

1.Head時刻– head標簽加載完結的時刻

2.TTi時刻– 頁面可交互時刻（即首屏第一次烘托出來的時刻）

3.Dom時刻– Dom Ready的時刻

4.Load 時刻– 頁面徹底加載完結的時刻

這么區(qū)分的優(yōu)點是，頁面加載每個環(huán)節(jié)的耗時一望而知：

Head ：CSS加載時刻

TTI ：全體HTML加載和烘托時刻

DOM 減TTI ： js文件網絡傳輸時刻和在瀏覽器進行解析的時刻

Load 減Dom ： js初始化+ 圖像加載的時刻

并且，咱們經過移動tti時刻點的方位，發(fā)現(xiàn)了一個風趣的景象，如下圖

能夠看出，頁面加載的功用瓶頸就在script的下載和解析時刻。

為了進一步定位功用瓶頸，咱們在頁面內對用戶網速進行了測驗，結果很震動：有2%的用戶網速小于2k/s，5%的用戶網速小于10k/s。（國內的網絡狀況真是不忍目睹啊）

那么，優(yōu)化計劃就很顯著了：最大極限地減小js文件巨細，以減小網絡傳輸時刻，提升頁面功用。

經過后來的優(yōu)化作業(yè)咱們發(fā)現(xiàn)：js代碼緊縮、Gzip后每減小1k，頁面加載時刻就能減小10ms左右。

按需加載：

這是除了js緊縮外，你能想到的最有用減小js文件巨細的辦法了。

按需加載，望文生義，即是在頁面初次加載的時分只提供最需要的js給用戶，而剩下的js等用戶運用到了有關的功用再去加載。

按需加載合適哪種類型的網站：假如80%的用戶來到你的頁面只運用20%的功用，那么就有必要把這20%的js作為首屏加載，而剩下的js做按需加載。

從這個視點來講，幾乎一切網站都能夠做按需加載，由于總有一些功用是用戶很少會用到的。

那么，如何做按需加載：

按需加載需要有一套js模塊加載的結構。這個結構的作用是：確保在所需的js加載完結后才去履行回調辦法。

按需加載還需要有一套觸發(fā)條件。在咱們的頁面中，對鼠標移動和鼠標點擊都進行了監(jiān)聽，以確保在用戶想運用某個功用之前或進行了相應操作時，觸發(fā)js加載。

除此以外，咱們還對js根底庫進行了進一步拆分，分為首屏用到的根底辦法，和推遲加載的js所需的根底辦法。以最大極限地確保首屏js量的最小化。

經過按需加載的拆分，咱們將首屏的js代碼從本來的gzip以后40-50k減小到了只有24k。

一起，咱們對CSS的加載也進行拆分，首屏不需要的CSS代碼也隨JS進行推遲加載。

作用 & 總結

功用優(yōu)化是一個非常繁瑣的作業(yè)，頁面功用受許多要素的制約，不過相信一點：辦法總比疑問多。咱們經過優(yōu)化，最終將頁面加載時刻降到了650ms，僅為優(yōu)化前的一半。一切優(yōu)化作業(yè)中，作用最顯著的即是js按需加載了。