前端優化帶來的思考,淺談前端工程化

重復優化的思考

這段時間對項目做了一次整體的優化,全站有了20%左右的提升(本來載入速度已經1.2S左右了,優化度很低),算一算已經做了四輪的全站性能優化了,回顧幾次的優化手段,基本上幾個字就能說清楚:
傳輸層面:減少請求數,降低請求量
執行層面:減少重繪&回流
傳輸層面的從來都是優化的核心點,而這個層面的優化要對瀏覽器有一個基本的認識,比如: ① 網頁自上而下的解析渲染,邊解析邊渲染,頁面內CSS文件會阻塞渲染,異步CSS文件會導致回流 ② 瀏覽器在document下載結束會檢測靜態資源,新開線程下載(有并發上限),在帶寬限制的條件下,無序并發會導致主資源速度下降,從而影響首屏渲染 ③ 瀏覽器緩存可用時會使用緩存資源,這個時候可以避免請求體的傳輸,對性能有極大提高 衡量性能的重要指標為首屏載入速度(指頁面可以看見,不一定可交互),影響首屏的最大因素為請求,所以請求是頁面真正的殺手,一般來說我們會做這些優化:

減少請求數

① 合并樣式、腳本文件 ② 合并背景圖片 ③ CSS3圖標、Icon Font

降低請求量

① 開啟GZip ② 優化靜態資源,jQuery->Zepto、閹割IScroll、去除冗余代碼 ③ 圖片無損壓縮 ④ 圖片延遲加載 ⑤ 減少Cookie攜帶 很多時候,我們也會采用類似“時間換空間、空間換時間”的做法,比如: ① 緩存為王,對更新較緩慢的資源&接口做緩存(瀏覽器緩存、localsorage、application cache這個坑多) ② 按需加載,先加載主要資源,其余資源延遲加載,對非首屏資源滾動加載 ③ fake頁技術,將頁面最初需要顯示Html&Css內聯,在頁面所需資源加載結束前至少可看,理想情況是index.html下載結束即展示(2G 5S內) ④ CDN ...... 從工程的角度來看,上述優化點半數以上是重復的,一般在發布時候就直接使用項目構建工具做掉了,還有一些只是簡單的服務器配置,開發時不需要關注。 可以看到,我們所做的優化都是在減少請求數,降低請求量,減小傳輸時的耗時,或者通過一個策略,優先加載首屏渲染所需資源,而后再加載交互所需資源(比如點擊時候再加載UI組件),Hybrid APP這方面應該盡可能多的將公共靜態資源放在native中,比如第三方庫,框架,UI甚至城市列表這種常用業務數據。

攔路虎

有一些網站初期比較快,但是隨著量的積累,BUG越來越多,速度也越來越慢,一些前端會使用上述優化手段做優化,但是收效甚微,一個比較典型的例子就是代碼冗余: ① 之前的CSS全部放在了一個文件中,新一輪的UI樣式優化,新老CSS難以拆分,CSS體量會增加,如果有業務團隊使用了公共樣式,情況更不容樂觀; ② UI組件更新,但是如果有業務團隊脫離接口操作了組件DOM,將導致新組件DOM更新受限,最差的情況下,用戶會加載兩個組件的代碼; ③ 胡亂使用第三方庫、組件,導致頁面加載大量無用代碼; ...... 以上問題會不同程度的增加資源下載體量,如果聽之任之會產生一系列工程問題: ① 頁面關系錯綜復雜,需求迭代容易出BUG; ② 框架每次升級都會導致額外的請求量,常加載一些業務不需要的代碼; ③ 第三方庫泛濫,且難以維護,有BUG也改不了; ④ 業務代碼加載大量異步模塊資源,頁面請求數增多; ...... 為求快速占領市場,業務開發時間往往緊迫,使用框架級的HTML&CSS、繞過CSS Sprite使用背景圖片、引入第三方工具庫或者UI,會經常發生。當遇到性能瓶頸時,如果不從根源解決問題,用傳統的優化手段做頁面級別的優化,會出現很快頁面又被玩壞的情況,幾次優化結束后我也在思考一個問題:
前端每次性能優化的手段皆大同小異;代碼的可維護性也基本是在細分職責;
既然每次優化的目的是相同的,每次實現的過程是相似的,而每次重新開發項目又基本是要重蹈覆轍的,那么工程化、自動化可能是這一切問題的最終答案
工程問題在項目積累到一定量后可能會發生,一般來說會有幾個現象預示著工程問題出現了: ① 代碼編寫&調試困難 ② 業務代碼不好維護 ③ 網站性能普遍不好 ④ 性能問題重復出現,并且有不可修復之勢 像上面所描述情況,就是一個典型的工程問題;定位問題、發現問題、解決問題是我們處理問題的手段;而如何防止同一類型的問題重復發生,便是工程化需要做的事情,簡單說來,優化是解決問題,工程化是避免問題,今天我們就站在工程化的角度來解決一些前端優化問題,防止其死灰復燃。 文中是我個人的一些開發經驗,希望對各位有用,也希望各位多多支持討論,指出文中不足以及提出您的一些建議。

消滅冗余

我們這里做的第一個事情便是消除優化路上第一個攔路虎:代碼冗余(做代碼精簡),單從一個頁面的加載來說,他需要以下資源: ① 框架MVC骨架模塊&框架級別CSS ② UI組件(header組件、日歷、彈出層、消息框......) ③ 業務HTML骨架 ④ 業務CSS ⑤ 業務Javascript代碼 ⑥ 服務接口服務 因為產品&視覺會經常折騰全站樣式加之UI的靈活性,UI最容易產生冗余的模塊。

UI組件

UI組件本身包括完整的HTML&CSS&Javascript,一個復雜的組件下載量可以達到10K以上,就UI部分來說容易導致兩個工程化問題: ① 升級產生代碼冗余 ② 對外接口變化導致業務升級需要額外開發

UI升級

最理想的升級是保持對外的接口不變甚至保持DOM結構不變,但多數情況的UI升級其實是UI重做,最壞的情況是不做老接口兼容,這個時候業務同事便需要修改代碼。為了防止業務抱怨,UI制作者往往會保留兩個組件(UI+UI1),如果原來那個UI是核心依賴組件(比如是UIHeader組件),便會直接打包至核心框架包中,這時便出現了新老組件共存的局面,這種情況是必須避免的,UI升級需要遵守兩個原則: ① 核心依賴組件必須保持單一,相同功能的核心組件只能有一個 ② 組件升級必須做接口兼容,新的特性可以做加法,絕不允許對接口做減法

UI組成

項目之初,分層較好的團隊會有一個公共的CSS文件(main.css),一個業務CSS文件,main.css包含公共的CSS,并且會包含所有的UI的樣式: 半年后業務頻道增,UI組件需求一多便容易膨脹,弊端馬上便暴露出來了,最初main.css可能只有10K,但是不出半年就會膨脹至100K,而每個業務頻道一開始便需要加載這100K的樣式文件頁面,但是其中多數的UI樣式是首屏加載用不到的。 所以比較好的做法是,main.css只包含最核心的樣式,理想情況是什么業務樣式功能皆不要提供,各個UI組件的樣式打包至UI中按需加載: 如此UI拆分后,main.css總是處于最基礎的樣式部分,而UI使用時按需加載,就算出現兩個相同組件也不會導致多下載資源。

拆分頁面

一個PC業務頁面,其模塊是很復雜的,這個時候可以將之分為多個模塊: 一經拆分后,頁面便是由業務組件組成,只需要關注各個業務組件的開發,然后在主控制器中組裝業務組件,這樣主控制器對頁面的控制力度會增加。 業務組件一般重用性較低,會產生模塊間的業務耦合,還會對業務數據產生依賴,但是主體仍然是HTML&CSS&Javascript,這部分代碼也是經常導致冗余的,如果能按模塊拆分,可以很好的控制這一問題發生: 按照上述的做法現在的加載規則是: ① 公共樣式文件 ② 框架文件,業務入口文件 ③ 入口文件,異步加載業務模塊,模塊內再異步加載其它資源 這樣下來業務開發時便不需要引用樣式文件,可以最大限度的提升首屏載入速度;需要關注的一點是,當異步拉取模塊時,內部的CSS加載需要一個規則避免對其它模塊的影響,因為模塊都帶有樣式屬性,頁面回流、頁面閃爍問題需要關注。 一個實際的例子是,這里點擊出發后的城市列表便是一個完整的業務組件,城市選擇的資源是在點擊后才會發生請求,而業務組件內部又會細分小模塊,再細分的資源控制由實際業務情況決定,過于細分也會導致理解和代碼編寫難度上升: demo演示地址,代碼地址 如果哪天需求方需要用新的城市選擇組件,便可以直接重新開發,讓業務之間使用最新的城市列表即可,因為是獨立的資源,所以老的也是可以使用的。 只要能做到UI級別的拆分與頁面業務組件的拆分,便能很好的應付樣式升級的需求,這方面冗余只要能避過,其它冗余問題便不是問題了,有兩個規范最好遵守:
1 避免使用全局的業務類樣式,就算他建議你使用
2 避免不通過接口直接操作DOM
冗余是首屏載入速度最大的攔路虎,是歷史形成的包袱,只要能消除冗余,便能在后面的路走的更順暢,這種組件化編程的方法也能讓網站后續的維護更加簡單。

資源加載

解決冗余便拋開了歷史的包袱,是前端優化的第一步也是比較難的一步,但模塊拆分也將全站分成了很多小的模塊,載入的資源分散會增加請求數;如果全部合并,會導致首屏加載不需要的資源,也會導致下一個頁面不能使用緩存,如何做出合理的入口資源加載規則,如何合理的善用緩存,是前端優化的第二步。 經過幾次性能優化對比,得出了一個較優的首屏資源加載方案: ① 核心框架層:mvc骨架、異步模塊加載器(require&seajs)、工具庫(zepto、underscore、延遲加載)、數據請求模塊、核心依賴UI(header組件消息類組件) ② 業務公共模塊:入口文件(require配置,初始化工作、業務公共模塊) ③ 獨立的page.js資源(包含template、css),會按需加載獨立UI資源 ④ 全局css資源 這里如果追求極致,libs.js、main.css與main.js可以選擇合并,劃分結束后便可以決定靜態資源緩存策略了。

資源緩存

資源緩存是為二次請求加速,比較常用的緩存技術有: ① 瀏覽器緩存 ② localstorage緩存 ③ application緩存 application緩存更新一塊不好把握容易出問題,所以更多的是依賴瀏覽器以及localstorage,首先說下瀏覽器級別的緩存。

時間戳更新

只要服務器配置,瀏覽器本身便具有緩存機制,如果要使用瀏覽器機制作緩存,勢必關心一個何時更新資源問題,我們一般是這樣做的:
<script type="text/javascript" src="libs.js?t=20151025"></script>
這樣做要求必須先發布js文件,才能發布html文件,否則讀不到最新靜態文件的。一個比較尷尬的場景是libs.js是框架團隊甚至第三方公司維護的,和業務團隊的index.html是兩個團隊,互相的發布是沒有關聯的,所以這兩者的發布順序是不能保證的,于是轉向開始使用了MD5的方式。

MD5時代

為了解決以上問題我們開始使用md5碼的方式為靜態資源命名:
<script type="text/javascript" src="libs_md5_1234.js"></script>
每次框架更新便不做文件覆蓋,直接生成一個唯一的文件名做增量發布,這個時候如果框架先發布,待業務發布時便已經存在了最新的代碼;當業務先發布框架沒有新的時,便繼續沿用老的文件,一切都很美好,雖然業務開發偶爾會抱怨每次都要向框架拿MD5映射,直到框架一次BUG發生。

seed.js時代

突然一天框架發現一個全局性BUG,并且馬上做出了修復,業務團隊也馬上發布上線,但這種事情出現第二次、第三次框架這邊便壓力大了,這個時候框架層面希望業務只需要引用一個不帶緩存的seed.js,seed.js要怎么加載是他自己的事情:
<script type="text/javascript" src="seed.js"></script>
//seed.js需要按需加載的資源
<script src="libs_md5.js"></script>
<script src="main_md5.js"></script>
當然,由于js加載是順序是不可控的,我們需要為seed.js實現一個最簡單的順序加載模塊,映射什么的由構建工具完成,每次做覆蓋發布即可,這樣做的缺點是額外增加一個seed.js的文件,并且要承擔模塊加載代碼的下載量。

localstorage緩存

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

Hybrid載入

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

服務器資源合并

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

工程化&前端優化

所謂工程化,可以簡單認為是將框架的職責拓寬再拓寬,主旨是幫業務團隊更好的完成需求,工程化會預測一些常碰到的問題,將之扼殺在搖籃,而這種路徑是可重用的,是具有可持續性的,比如第一個優化去除冗余,是在多次去除冗余代碼,思考冗余出現的原因而最終思考得出的一個避免冗余的方案,前端工程化需要考慮以下問題:
重復工作;如通用的流程控制機制,可擴展的UI組件、靈活的工具方法
重復優化;如降低框架層面升級帶給業務團隊的耗損、幫助業務在無感知情況下做掉大部分優化(比如打包壓縮什么的)
開發效率;如幫助業務團隊寫可維護的代碼、讓業務團隊方便的調試代碼(比如Hybrid調試)

構建工具

要完成前端工程化,少不了工程化工具,requireJS與grunt的出現,改變了業界前端代碼的編寫習慣,同時他們也是推動前端工程化的一個基礎。 requireJS是一偉大的模塊加載器,他的出現讓javascript制作多人維護的大型項目變成了事實;grunt是一款javascript構建工具,主要完成壓縮、合并、圖片壓縮合并等一系列工作,后續又出了yeoman、Gulp、webpack等構建工具。 這里這里要記住一件事情,我們的目的是完成前端工程化,無論什么模塊加載器或者構建工具,都是為了幫助我們完成目的,工具不重要,目的與思想才重要,所以在完成工程化前討論哪個加載器好,哪種構建工具好是舍本逐末的。

理想的載入速度

現在站在前端優化的角度,以下面這個頁面為例,最優的載入情況是什么呢: 以這個看似簡單頁面來說,如果要完整的展示涉及的模塊比較多: ① 框架MVC骨架模塊&框架級別CSS ② 幾個UI組件(header組件、日歷、彈出層、消息框......) ③ 業務HTML骨架 ④ 業務CSS ⑤ 業務Javascript代碼 ⑥ 服務接口服務 上面的很多資源事實上對于首屏渲染是沒有幫助的,根據之前的探討,得出的理想首屏加載所需資源是: ① 框架MVC骨架&框架級別CSS => main.css+libs.js ② 業務入口文件 => main.js ③ 業務交互控制器 => page.js 有了這些資源,便能完成完整的交互,包括接口請求,列表展示,但若是只需要給用戶“看見”首頁,便能采用一種fake的手段,只需要這些資源: ① 業務HTML骨架 => 最簡單的index.hrml載入 ② 內嵌CSS 這個時候,頁面一旦下載結束便可完成渲染,在其它資源加載結束后再將頁面重新渲染即可,很多時候前端優化要做的就是靠近這種理想載入速度,解決那些制約的因素,比如:

CSS Sprite

由于現代瀏覽器的與解析機制,在拿到一個頁面的時候馬上會分析其靜態資源,然后開線程做下載,這個時候反而會影響首屏渲染,如圖(模擬2G): 如果做fake頁優化的話,便需要將樣式也做異步載入,這樣document載入結束便能渲染頁面,2G情況都能3S內可見頁面,大大避免白屏時間,而后面的單個背景圖片便是需要解決的工程問題。 CSS Sprite旨在降低請求數,但是與去處冗余問題一樣,半年后一個CSS Sprite資源反而不好維護,容易爛掉,grunt有一插件支持將圖片自動合并為CSS Sprite,而他也會自動替換頁面中的背景地址,只需要按規則操作即可。 PS:其它構建工具也會有,各位自己找下吧 CSS Sprite構建工具:https://www.npmjs.com/package/grunt-css-sprite 正確的使用該工具便可以使業務開發擺脫圖片合并帶來的痛苦,當然一些弊端需要去克服,比如在小屏手機使用小屏背景,大屏手機使用大屏背景的處理辦法

其它工程化的體現

又比如,前端模板是將html文件解析為function函數,這一步驟完全可以在發布階段,將html模板轉換為function函數,免去了生產環境的大量正則替換,效率高還省電; 然后ajax接口數據的緩存也直接在數據請求底層做掉,讓業務輕松實現接口數據緩存; 而一些html壓縮、預加載技術、延遲加載技術等優化點便不一一展開......

渲染優化

當請求資源落地后便是瀏覽器的渲染工作了,每一次操作皆可能引起瀏覽器的重繪,在PC瀏覽器上,渲染對性能影響不大,但因為配置原因,渲染對移動端性能的影響卻非常大,錯誤的操作可能導致滾動遲鈍、動畫卡幀,大大降低用戶體驗。 減少重繪、減少回流降低渲染帶來的耗損基本人盡皆知了,但是引起重繪的操作何其多,每次重繪的操作又何其微觀: ① 頁面滾動 ② javascript交互 ③ 動畫 ④ 內容變化 ⑤ 屬性計算(求元素的高寬) ...... 與請求優化不同的是,一些請求是可以避免的,但是重繪基本是不可避免的,而如果一個頁面卡了,這么多可能引起重繪的操作,如何定位到渲染瓶頸在何處,如何減少這種大消耗的性能影響是真正應該關心的問題。

Chrome渲染分析工具

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

Timeline工具

timeline可以展示web應用加載過程中的資源消耗情況,包括處理DOM事件,頁面布局渲染以及繪制元素,通過該工具基本可以找到頁面存在的渲染問題。 Timeline使用4種顏色表示不同的事件:
藍色:加載耗時
黃色:腳本執行耗時
紫色:渲染耗時
綠色:繪制耗時
以上圖為例,因為刷新了頁面,會加載幾個完整的js文件,所以js執行耗時必然會多,但也在50ms左右就結束了。

Rendering工具

Chrome還有一款工具為分析渲染而生:
1 Show paint rectangles 顯示繪制矩形
2 Show composited layer borders 顯示層的組合邊界
3 Show FPS meter 顯示FPS幀頻
4 Enable continuous page repainting 開啟持續繪制模式 并 檢測頁面繪制時間
5 Show potential scroll bottlenecks 顯示潛在的滾動瓶頸。
show paint rectangles 開啟矩形框,便會有綠色的框將頁面中不同的元素框起來,如果頁面渲染便會整塊加深,舉個例子: 當點擊+號時,三塊區域產生了重繪,這里也可以看出,每次重繪都會影響一個塊級(Layer),連帶反應會影響周邊元素,所以一次mask全局遮蓋層的出現會導致頁面級重繪,比如這里的loading與toast便有所不同: loading由于遮蓋mask的出現而產生了全局重繪,而toast本身是絕對定位元素只影響了局部,這里有一個需要注意的是,因為loading轉圈的動畫是CSS3實現的,雖然不停的再動,事實上只渲染了一次,如果采用javascript的話,便會不停重繪。 然后當頁面發生滾動時,下面的支付工具條一直呈綠色狀態,意思是滾動時一直在重繪,這個重繪的頻率很高,這也是fixed元素相當耗費性能的原因: 結合Timeline的渲染圖 如果這里取消掉fixed元素的話: 這里fixed元素支付工具欄滾動時候是綠的,但是同樣是fixed的header卻沒有變綠,那是因為header多了一個css屬性:
.cm-header {
    -webkit-transform: translate3d(0,0,0);
    transform: translate3d(0,0,0);
}
這個屬性會創建獨立的Layer,有效的降低了fixed屬性的性能損耗,如果header去掉此屬性的話,就不一樣了: show composited layer borders 顯示組合層邊界,是因為頁面是由多個圖層組成,勾上后頁面便開始分塊了: 使用該工具可以查看當前頁面Layer構成,這里的+號以及header都是有自己獨立的圖層的,原因是使用了:
transform: translate3d(-50%,-50%,0);
Layer存在的意義在于可以讓頁面最優的方式繪制,這個是CSS3硬件加速的秘密,就如header一樣,形成Layer的元素繪制會有所不同。 Layer的創建會消耗額外的資源,所以不能不加節制的使用,以上面的“+”來說,如果使用icon font效果也許更好。 因為渲染這個東西比較底層,需要對瀏覽器層面的了解更多,關于更多更全的渲染相關知識,推薦閱讀我好友的博客: http://www.ghugo.com/

結語

今天我們站在工程化的層面總結了前幾次性能優化的一些方法,以期在后續的項目開發中能直接繞過這些性能的問題。 前端優化僅僅是前端工程化中的一環,結合之前的代碼開發效率探討(【組件化開發】前端進階篇之如何編寫可維護可升級的代碼),后續我們會在前端工具的制作使用、前端監控等環節做更多的工作,期望更大的提升前端開發的效率,推動前端工程化的進程。 來自:http://www.cnblogs.com/yexiaochai/p/4901341.html