重複優化的思考

這段時間對專案做了一次整體的優化，全站有了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載入需要一個規則避免對其它模組的影響，因為模組都帶有樣式屬性，頁面迴流、頁面閃爍問題需要關注。

一個實際的例子是，這裡點擊出發後的城市列表便是一個完整的業務元件，城市選擇的資源是在點選後才會發生請求，而業務元件內部又會細分小模組，再細分的資源控制由實際業務情況決定，過於細分也會導致理解和程式碼編寫難度上升：

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

只要能做到UI級別的拆分與頁面業務元件的拆分，便能很好的應付樣式升級的需求，這方面冗餘只要能避過，其它冗餘問題便不是問題了，有兩個規範最好遵守：

冗餘是首屏載入速度最大的攔路虎，是歷史形成的包袱，只要能消除冗餘，便能在後面的路走的更順暢，這種元件化程式設計的方法也能讓網站後續的維護更加簡單。

資源載入

解決冗餘便拋開了歷史的包袱，是前端優化的第一步也是比較難的一步，但模組拆分也將全站分成了很多小的模組，載入的資源分散會增加請求數；如果全部合併，會導致首屏載入不需要的資源，也會導致下一個頁面不能使用快取，如何做出合理的入口資源載入規則，如何合理的善用快取，是前端優化的第二步。

經過幾次效能優化對比，得出了一個較優的首屏資源載入方案：

① 核心框架層：mvc骨架、非同步模組載入器（require&seajs）、工具庫（zepto、underscore、延遲載入）、資料請求模組、核心依賴UI（header元件訊息類元件）

② 業務公共模組：入口檔案（require配置，初始化工作、業務公共模組）

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

④ 全域性css資源

這裡如果追求極致，libs.js、main.css與main.js可以選擇合併，劃分結束後便可以決定靜態資源快取策略了。

資源快取

資源快取是為二次請求加速，比較常用的快取技術有：

① 瀏覽器快取

② localstorage快取

③ application快取

application快取更新一塊不好把握容易出問題，所以更多的是依賴瀏覽器以及localstorage，首先說下瀏覽器級別的快取。

時間戳更新

只要伺服器配置，瀏覽器本身便具有快取機制，如果要使用瀏覽器機制作快取，勢必關心一個何時更新資源問題，我們一般是這樣做的：

每次框架更新便不做檔案覆蓋，直接生成一個唯一的檔名做增量釋出，這個時候如果框架先發布，待業務釋出時便已經存在了最新的程式碼；當業務先發布框架沒有新的時，便繼續沿用老的檔案，一切都很美好，雖然業務開發偶爾會抱怨每次都要向框架拿MD5對映，直到框架一次BUG發生。

seed.js時代

突然一天框架發現一個全域性性BUG，並且馬上做出了修復，業務團隊也馬上釋出上線，但這種事情出現第二次、第三次框架這邊便壓力大了，這個時候框架層面希望業務只需要引用一個不帶快取的seed.js，seed.js要怎麼載入是他自己的事情：