重復(fù)優(yōu)化的思考

這段時間對項目做了一次整體的優(yōu)化，全站有了20%左右的提升（本來載入速度已經(jīng)1.2S左右了，優(yōu)化度很低），算一算已經(jīng)做了四輪的全站性能優(yōu)化了，回顧幾次的優(yōu)化手段，基本上幾個字就能說清楚：

傳輸層面的從來都是優(yōu)化的核心點，而這個層面的優(yōu)化要對瀏覽器有一個基本的認(rèn)識，比如：

① 網(wǎng)頁自上而下的解析渲染，邊解析邊渲染，頁面內(nèi)CSS文件會阻塞渲染，異步CSS文件會導(dǎo)致回流

② 瀏覽器在document下載結(jié)束會檢測靜態(tài)資源，新開線程下載（有并發(fā)上限），在帶寬限制的條件下，無序并發(fā)會導(dǎo)致主資源速度下降，從而影響首屏渲染

③ 瀏覽器緩存可用時會使用緩存資源，這個時候可以避免請求體的傳輸，對性能有極大提高

衡量性能的重要指標(biāo)為首屏載入速度（指頁面可以看見，不一定可交互），影響首屏的最大因素為請求，所以請求是頁面真正的殺手，一般來說我們會做這些優(yōu)化：

減少請求數(shù)

① 合并樣式、腳本文件

② 合并背景圖片

③ CSS3圖標(biāo)、Icon Font

降低請求量

① 開啟GZip

② 優(yōu)化靜態(tài)資源，jQuery->Zepto、閹割I(lǐng)Scroll、去除冗余代碼

③ 圖片無損壓縮

④ 圖片延遲加載

⑤ 減少Cookie攜帶

很多時候，我們也會采用類似“時間換空間、空間換時間”的做法，比如：

① 緩存為王，對更新較緩慢的資源&接口做緩存（瀏覽器緩存、localsorage、application cache這個坑多）

② 按需加載，先加載主要資源，其余資源延遲加載，對非首屏資源滾動加載

③ fake頁技術(shù)，將頁面最初需要顯示Html&Css內(nèi)聯(lián)，在頁面所需資源加載結(jié)束前至少可看，理想情況是index.html下載結(jié)束即展示（2G 5S內(nèi)）

④ CDN

......

從工程的角度來看，上述優(yōu)化點半數(shù)以上是重復(fù)的，一般在發(fā)布時候就直接使用項目構(gòu)建工具做掉了，還有一些只是簡單的服務(wù)器配置，開發(fā)時不需要關(guān)注。

可以看到，我們所做的優(yōu)化都是在減少請求數(shù)，降低請求量，減小傳輸時的耗時，或者通過一個策略，優(yōu)先加載首屏渲染所需資源，而后再加載交互所需資源（比如點擊時候再加載UI組件），Hybrid APP這方面應(yīng)該盡可能多的將公共靜態(tài)資源放在native中，比如第三方庫，框架，UI甚至城市列表這種常用業(yè)務(wù)數(shù)據(jù)。

攔路虎

有一些網(wǎng)站初期比較快，但是隨著量的積累，BUG越來越多，速度也越來越慢，一些前端會使用上述優(yōu)化手段做優(yōu)化，但是收效甚微，一個比較典型的例子就是代碼冗余：

① 之前的CSS全部放在了一個文件中，新一輪的UI樣式優(yōu)化，新老CSS難以拆分，CSS體量會增加，如果有業(yè)務(wù)團隊使用了公共樣式，情況更不容樂觀；

② UI組件更新，但是如果有業(yè)務(wù)團隊脫離接口操作了組件DOM，將導(dǎo)致新組件DOM更新受限，最差的情況下，用戶會加載兩個組件的代碼；

③ 胡亂使用第三方庫、組件，導(dǎo)致頁面加載大量無用代碼；

......

以上問題會不同程度的增加資源下載體量，如果聽之任之會產(chǎn)生一系列工程問題：

① 頁面關(guān)系錯綜復(fù)雜，需求迭代容易出BUG；

② 框架每次升級都會導(dǎo)致額外的請求量，常加載一些業(yè)務(wù)不需要的代碼；

③ 第三方庫泛濫，且難以維護，有BUG也改不了；

④ 業(yè)務(wù)代碼加載大量異步模塊資源，頁面請求數(shù)增多；

......

為求快速占領(lǐng)市場，業(yè)務(wù)開發(fā)時間往往緊迫，使用框架級的HTML&CSS、繞過CSS Sprite使用背景圖片、引入第三方工具庫或者UI，會經(jīng)常發(fā)生。當(dāng)遇到性能瓶頸時，如果不從根源解決問題，用傳統(tǒng)的優(yōu)化手段做頁面級別的優(yōu)化，會出現(xiàn)很快頁面又被玩壞的情況，幾次優(yōu)化結(jié)束后我也在思考一個問題：

工程問題在項目積累到一定量后可能會發(fā)生，一般來說會有幾個現(xiàn)象預(yù)示著工程問題出現(xiàn)了：

① 代碼編寫&調(diào)試?yán)щy

② 業(yè)務(wù)代碼不好維護

③ 網(wǎng)站性能普遍不好

④ 性能問題重復(fù)出現(xiàn)，并且有不可修復(fù)之勢

像上面所描述情況，就是一個典型的工程問題；定位問題、發(fā)現(xiàn)問題、解決問題是我們處理問題的手段；而如何防止同一類型的問題重復(fù)發(fā)生，便是工程化需要做的事情，簡單說來，優(yōu)化是解決問題，工程化是避免問題，今天我們就站在工程化的角度來解決一些前端優(yōu)化問題，防止其死灰復(fù)燃。

文中是我個人的一些開發(fā)經(jīng)驗，希望對各位有用，也希望各位多多支持討論，指出文中不足以及提出您的一些建議。

#p#

消滅冗余

我們這里做的第一個事情便是消除優(yōu)化路上第一個攔路虎：代碼冗余（做代碼精簡），單從一個頁面的加載來說，他需要以下資源：

① 框架MVC骨架模塊&框架級別CSS

② UI組件（header組件、日歷、彈出層、消息框......）

③ 業(yè)務(wù)HTML骨架

④ 業(yè)務(wù)CSS

⑤ 業(yè)務(wù)Javascript代碼

⑥ 服務(wù)接口服務(wù)

因為產(chǎn)品&視覺會經(jīng)常折騰全站樣式加之UI的靈活性，UI最容易產(chǎn)生冗余的模塊。

UI組件

UI組件本身包括完整的HTML&CSS&Javascript，一個復(fù)雜的組件下載量可以達到10K以上，就UI部分來說容易導(dǎo)致兩個工程化問題：

① 升級產(chǎn)生代碼冗余

② 對外接口變化導(dǎo)致業(yè)務(wù)升級需要額外開發(fā)

UI升級

最理想的升級是保持對外的接口不變甚至保持DOM結(jié)構(gòu)不變，但多數(shù)情況的UI升級其實是UI重做，最壞的情況是不做老接口兼容，這個時候業(yè)務(wù)同事便需要修改代碼。為了防止業(yè)務(wù)抱怨，UI制作者往往會保留兩個組件（UI+UI1），如果原來那個UI是核心依賴組件（比如是UIHeader組件），便會直接打包至核心框架包中，這時便出現(xiàn)了新老組件共存的局面，這種情況是必須避免的，UI升級需要遵守兩個原則：

① 核心依賴組件必須保持單一，相同功能的核心組件只能有一個

② 組件升級必須做接口兼容，新的特性可以做加法，絕不允許對接口做減法

UI組成

項目之初，分層較好的團隊會有一個公共的CSS文件（main.css），一個業(yè)務(wù)CSS文件，main.css包含公共的CSS，并且會包含所有的UI的樣式：

半年后業(yè)務(wù)頻道增，UI組件需求一多便容易膨脹，弊端馬上便暴露出來了，最初main.css可能只有10K，但是不出半年就會膨脹至100K，而每個業(yè)務(wù)頻道一開始便需要加載這100K的樣式文件頁面，但是其中多數(shù)的UI樣式是首屏加載用不到的。

所以比較好的做法是，main.css只包含最核心的樣式，理想情況是什么業(yè)務(wù)樣式功能皆不要提供，各個UI組件的樣式打包至UI中按需加載：

如此UI拆分后，main.css總是處于最基礎(chǔ)的樣式部分，而UI使用時按需加載，就算出現(xiàn)兩個相同組件也不會導(dǎo)致多下載資源。

拆分頁面

一個PC業(yè)務(wù)頁面，其模塊是很復(fù)雜的，這個時候可以將之分為多個模塊：

一經(jīng)拆分后，頁面便是由業(yè)務(wù)組件組成，只需要關(guān)注各個業(yè)務(wù)組件的開發(fā)，然后在主控制器中組裝業(yè)務(wù)組件，這樣主控制器對頁面的控制力度會增加。

業(yè)務(wù)組件一般重用性較低，會產(chǎn)生模塊間的業(yè)務(wù)耦合，還會對業(yè)務(wù)數(shù)據(jù)產(chǎn)生依賴，但是主體仍然是HTML&CSS&Javascript，這部分代碼也是經(jīng)常導(dǎo)致冗余的，如果能按模塊拆分，可以很好的控制這一問題發(fā)生：

按照上述的做法現(xiàn)在的加載規(guī)則是：

① 公共樣式文件

② 框架文件，業(yè)務(wù)入口文件

③ 入口文件，異步加載業(yè)務(wù)模塊，模塊內(nèi)再異步加載其它資源

這樣下來業(yè)務(wù)開發(fā)時便不需要引用樣式文件，可以最大限度的提升首屏載入速度；需要關(guān)注的一點是，當(dāng)異步拉取模塊時，內(nèi)部的CSS加載需要一個規(guī)則避免對其它模塊的影響，因為模塊都帶有樣式屬性，頁面回流、頁面閃爍問題需要關(guān)注。

一個實際的例子是，這里點擊出發(fā)后的城市列表便是一個完整的業(yè)務(wù)組件，城市選擇的資源是在點擊后才會發(fā)生請求，而業(yè)務(wù)組件內(nèi)部又會細(xì)分小模塊，再細(xì)分的資源控制由實際業(yè)務(wù)情況決定，過于細(xì)分也會導(dǎo)致理解和代碼編寫難度上升：

demo演示地址，代碼地址

如果哪天需求方需要用新的城市選擇組件，便可以直接重新開發(fā)，讓業(yè)務(wù)之間使用最新的城市列表即可，因為是獨立的資源，所以老的也是可以使用的。

只要能做到UI級別的拆分與頁面業(yè)務(wù)組件的拆分，便能很好的應(yīng)付樣式升級的需求，這方面冗余只要能避過，其它冗余問題便不是問題了，有兩個規(guī)范最好遵守：

冗余是首屏載入速度最大的攔路虎，是歷史形成的包袱，只要能消除冗余，便能在后面的路走的更順暢，這種組件化編程的方法也能讓網(wǎng)站后續(xù)的維護更加簡單。

資源加載

解決冗余便拋開了歷史的包袱，是前端優(yōu)化的第一步也是比較難的一步，但模塊拆分也將全站分成了很多小的模塊，載入的資源分散會增加請求數(shù)；如果全部合并，會導(dǎo)致首屏加載不需要的資源，也會導(dǎo)致下一個頁面不能使用緩存，如何做出合理的入口資源加載規(guī)則，如何合理的善用緩存，是前端優(yōu)化的第二步。

經(jīng)過幾次性能優(yōu)化對比，得出了一個較優(yōu)的首屏資源加載方案：

① 核心框架層：mvc骨架、異步模塊加載器（require&seajs）、工具庫（zepto、underscore、延遲加載）、數(shù)據(jù)請求模塊、核心依賴UI（header組件消息類組件）

② 業(yè)務(wù)公共模塊：入口文件（require配置，初始化工作、業(yè)務(wù)公共模塊）

③ 獨立的page.js資源（包含template、css），會按需加載獨立UI資源

④ 全局css資源

這里如果追求極致，libs.js、main.css與main.js可以選擇合并，劃分結(jié)束后便可以決定靜態(tài)資源緩存策略了。

資源緩存

資源緩存是為二次請求加速，比較常用的緩存技術(shù)有：

① 瀏覽器緩存

② localstorage緩存

③ application緩存

application緩存更新一塊不好把握容易出問題，所以更多的是依賴瀏覽器以及l(fā)ocalstorage，首先說下瀏覽器級別的緩存。

時間戳更新

只要服務(wù)器配置，瀏覽器本身便具有緩存機制，如果要使用瀏覽器機制作緩存，勢必關(guān)心一個何時更新資源問題，我們一般是這樣做的：

這樣做要求必須先發(fā)布js文件，才能發(fā)布html文件，否則讀不到最新靜態(tài)文件的。一個比較尷尬的場景是libs.js是框架團隊甚至第三方公司維護的，和業(yè)務(wù)團隊的index.html是兩個團隊，互相的發(fā)布是沒有關(guān)聯(lián)的，所以這兩者的發(fā)布順序是不能保證的，于是轉(zhuǎn)向開始使用了MD5的方式。

MD5時代

為了解決以上問題我們開始使用md5碼的方式為靜態(tài)資源命名：

每次框架更新便不做文件覆蓋，直接生成一個唯一的文件名做增量發(fā)布，這個時候如果框架先發(fā)布，待業(yè)務(wù)發(fā)布時便已經(jīng)存在了最新的代碼；當(dāng)業(yè)務(wù)先發(fā)布框架沒有新的時，便繼續(xù)沿用老的文件，一切都很美好，雖然業(yè)務(wù)開發(fā)偶爾會抱怨每次都要向框架拿MD5映射，直到框架一次BUG發(fā)生。

seed.js時代

突然一天框架發(fā)現(xiàn)一個全局性BUG，并且馬上做出了修復(fù)，業(yè)務(wù)團隊也馬上發(fā)布上線，但這種事情出現(xiàn)第二次、第三次框架這邊便壓力大了，這個時候框架層面希望業(yè)務(wù)只需要引用一個不帶緩存的seed.js，seed.js要怎么加載是他自己的事情：

當(dāng)然，由于js加載是順序是不可控的，我們需要為seed.js實現(xiàn)一個最簡單的順序加載模塊，映射什么的由構(gòu)建工具完成，每次做覆蓋發(fā)布即可，這樣做的缺點是額外增加一個seed.js的文件，并且要承擔(dān)模塊加載代碼的下載量。

localstorage緩存

也會有團隊將靜態(tài)資源緩存至localstorage中，以期做離線應(yīng)用，但是我一般用它存json數(shù)據(jù)，沒有做過靜態(tài)資源的存儲，想要嘗試的朋友一定要做好資源更新的策略，然后localstorage的讀寫也有一定損耗，不支持的情況還需要做降級處理，這里便不多介紹。

Hybrid載入

如果是Hybrid的話，情況有所不同，需要將公共資源打包至native中，業(yè)務(wù)類就不要打包了，否則native會越來越大。

服務(wù)器資源合并

之前與淘寶的一些朋友做過交流，發(fā)現(xiàn)他們居然做到了零散資源在服務(wù)器端做合并的地步了......這方面我們還是望洋興嘆吧

#p#

工程化&前端優(yōu)化

所謂工程化，可以簡單認(rèn)為是將框架的職責(zé)拓寬再拓寬，主旨是幫業(yè)務(wù)團隊更好的完成需求，工程化會預(yù)測一些常碰到的問題，將之扼殺在搖籃，而這種路徑是可重用的，是具有可持續(xù)性的，比如第一個優(yōu)化去除冗余，是在多次去除冗余代碼，思考冗余出現(xiàn)的原因而最終思考得出的一個避免冗余的方案，前端工程化需要考慮以下問題：

構(gòu)建工具

要完成前端工程化，少不了工程化工具，requireJS與grunt的出現(xiàn)，改變了業(yè)界前端代碼的編寫習(xí)慣，同時他們也是推動前端工程化的一個基礎(chǔ)。

requireJS是一偉大的模塊加載器，他的出現(xiàn)讓javascript制作多人維護的大型項目變成了事實；grunt是一款javascript構(gòu)建工具，主要完成壓縮、合并、圖片壓縮合并等一系列工作，后續(xù)又出了yeoman、Gulp、webpack等構(gòu)建工具。

這里這里要記住一件事情，我們的目的是完成前端工程化，無論什么模塊加載器或者構(gòu)建工具，都是為了幫助我們完成目的，工具不重要，目的與思想才重要，所以在完成工程化前討論哪個加載器好，哪種構(gòu)建工具好是舍本逐末的。

理想的載入速度

現(xiàn)在站在前端優(yōu)化的角度，以下面這個頁面為例，最優(yōu)的載入情況是什么呢：

以這個看似簡單頁面來說，如果要完整的展示涉及的模塊比較多：

① 框架MVC骨架模塊&框架級別CSS

② 幾個UI組件（header組件、日歷、彈出層、消息框......）

③ 業(yè)務(wù)HTML骨架

④ 業(yè)務(wù)CSS

⑤ 業(yè)務(wù)Javascript代碼

⑥ 服務(wù)接口服務(wù)

上面的很多資源事實上對于首屏渲染是沒有幫助的，根據(jù)之前的探討，得出的理想首屏加載所需資源是：

① 框架MVC骨架&框架級別CSS => main.css+libs.js

② 業(yè)務(wù)入口文件 => main.js

③ 業(yè)務(wù)交互控制器 => page.js

有了這些資源，便能完成完整的交互，包括接口請求，列表展示，但若是只需要給用戶“看見”首頁，便能采用一種fake的手段，只需要這些資源：

① 業(yè)務(wù)HTML骨架 => 最簡單的index.hrml載入

② 內(nèi)嵌CSS

這個時候，頁面一旦下載結(jié)束便可完成渲染，在其它資源加載結(jié)束后再將頁面重新渲染即可，很多時候前端優(yōu)化要做的就是靠近這種理想載入速度，解決那些制約的因素，比如：

CSS Sprite

由于現(xiàn)代瀏覽器的與解析機制，在拿到一個頁面的時候馬上會分析其靜態(tài)資源，然后開線程做下載，這個時候反而會影響首屏渲染，如圖（模擬2G）：

如果做fake頁優(yōu)化的話，便需要將樣式也做異步載入，這樣document載入結(jié)束便能渲染頁面，2G情況都能3S內(nèi)可見頁面，大大避免白屏?xí)r間，而后面的單個背景圖片便是需要解決的工程問題。

CSS Sprite旨在降低請求數(shù)，但是與去處冗余問題一樣，半年后一個CSS Sprite資源反而不好維護，容易爛掉，grunt有一插件支持將圖片自動合并為CSS Sprite，而他也會自動替換頁面中的背景地址，只需要按規(guī)則操作即可。

PS：其它構(gòu)建工具也會有，各位自己找下吧

CSS Sprite構(gòu)建工具：https://www.npmjs.com/package/grunt-css-sprite

正確的使用該工具便可以使業(yè)務(wù)開發(fā)擺脫圖片合并帶來的痛苦，當(dāng)然一些弊端需要去克服，比如在小屏手機使用小屏背景，大屏手機使用大屏背景的處理辦法

其它工程化的體現(xiàn)

又比如，前端模板是將html文件解析為function函數(shù)，這一步驟完全可以在發(fā)布階段，將html模板轉(zhuǎn)換為function函數(shù)，免去了生產(chǎn)環(huán)境的大量正則替換，效率高還省電；

然后ajax接口數(shù)據(jù)的緩存也直接在數(shù)據(jù)請求底層做掉，讓業(yè)務(wù)輕松實現(xiàn)接口數(shù)據(jù)緩存；

而一些html壓縮、預(yù)加載技術(shù)、延遲加載技術(shù)等優(yōu)化點便不一一展開......

#p#

渲染優(yōu)化

當(dāng)請求資源落地后便是瀏覽器的渲染工作了，每一次操作皆可能引起瀏覽器的重繪，在PC瀏覽器上，渲染對性能影響不大，但因為配置原因，渲染對移動端性能的影響卻非常大，錯誤的操作可能導(dǎo)致滾動遲鈍、動畫卡幀，大大降低用戶體驗。

減少重繪、減少回流降低渲染帶來的耗損基本人盡皆知了，但是引起重繪的操作何其多，每次重繪的操作又何其微觀：

① 頁面滾動

② javascript交互

③ 動畫

④ 內(nèi)容變化

⑤ 屬性計算（求元素的高寬）

......

與請求優(yōu)化不同的是，一些請求是可以避免的，但是重繪基本是不可避免的，而如果一個頁面卡了，這么多可能引起重繪的操作，如何定位到渲染瓶頸在何處，如何減少這種大消耗的性能影響是真正應(yīng)該關(guān)心的問題。

Chrome渲染分析工具

工程化其中要解決的一個問題是代碼調(diào)試問題，以前端開發(fā)來說Chrome以及Fiddler在這方面已經(jīng)做的非常好了，這里就使用Chrome來查看一下頁面的渲染。

Timeline工具

timeline可以展示web應(yīng)用加載過程中的資源消耗情況，包括處理DOM事件，頁面布局渲染以及繪制元素，通過該工具基本可以找到頁面存在的渲染問題。

Timeline使用4種顏色表示不同的事件：

以上圖為例，因為刷新了頁面，會加載幾個完整的js文件，所以js執(zhí)行耗時必然會多，但也在50ms左右就結(jié)束了。

Rendering工具

Chrome還有一款工具為分析渲染而生：

show paint rectangles

開啟矩形框，便會有綠色的框?qū)㈨撁嬷胁煌脑乜蚱饋?，如果頁面渲染便會整塊加深，舉個例子：

當(dāng)點擊+號時，三塊區(qū)域產(chǎn)生了重繪，這里也可以看出，每次重繪都會影響一個塊級（Layer），連帶反應(yīng)會影響周邊元素，所以一次mask全局遮蓋層的出現(xiàn)會導(dǎo)致頁面級重繪，比如這里的loading與toast便有所不同：

loading由于遮蓋mask的出現(xiàn)而產(chǎn)生了全局重繪，而toast本身是絕對定位元素只影響了局部，這里有一個需要注意的是，因為loading轉(zhuǎn)圈的動畫是CSS3實現(xiàn)的，雖然不停的再動，事實上只渲染了一次，如果采用javascript的話，便會不停重繪。

然后當(dāng)頁面發(fā)生滾動時，下面的支付工具條一直呈綠色狀態(tài)，意思是滾動時一直在重繪，這個重繪的頻率很高，這也是fixed元素相當(dāng)耗費性能的原因：

結(jié)合Timeline的渲染圖

如果這里取消掉fixed元素的話：

這里fixed元素支付工具欄滾動時候是綠的，但是同樣是fixed的header卻沒有變綠，那是因為header多了一個css屬性：

這個屬性會創(chuàng)建獨立的Layer，有效的降低了fixed屬性的性能損耗，如果header去掉此屬性的話，就不一樣了：

show composited layer borders

顯示組合層邊界，是因為頁面是由多個圖層組成，勾上后頁面便開始分塊了：

使用該工具可以查看當(dāng)前頁面Layer構(gòu)成，這里的+號以及header都是有自己獨立的圖層的，原因是使用了：

Layer存在的意義在于可以讓頁面最優(yōu)的方式繪制，這個是CSS3硬件加速的秘密，就如header一樣，形成Layer的元素繪制會有所不同。

Layer的創(chuàng)建會消耗額外的資源，所以不能不加節(jié)制的使用，以上面的“+”來說，如果使用icon font效果也許更好。

因為渲染這個東西比較底層，需要對瀏覽器層面的了解更多，關(guān)于更多更全的渲染相關(guān)知識，推薦閱讀我好友的博客：

http://www.ghugo.com/

結(jié)語

今天我們站在工程化的層面總結(jié)了前幾次性能優(yōu)化的一些方法，以期在后續(xù)的項目開發(fā)中能直接繞過這些性能的問題。

前端優(yōu)化僅僅是前端工程化中的一環(huán)，結(jié)合之前的代碼開發(fā)效率探討（【組件化開發(fā)】前端進階篇之如何編寫可維護可升級的代碼），后續(xù)我們會在前端工具的制作使用、前端監(jiān)控等環(huán)節(jié)做更多的工作，期望更大的提升前端開發(fā)的效率，推動前端工程化的進程。

本文關(guān)聯(lián)的代碼：

https://github.com/yexiaochai/mvc