表格1 性能優(yōu)化原則分類

目前大多數(shù)前端團(tuán)隊(duì)可以利用yui compressor或者google closure compiler等壓縮工具很容易做到“精簡(jiǎn)Javascript”這條原則；同樣的，也可以使用圖片壓縮工具對(duì)圖像進(jìn)行壓縮，實(shí)現(xiàn)“圖像優(yōu)化”原則。這兩條原則是對(duì)單個(gè)資源的處理，因此不會(huì)引起任何工程方面的問(wèn)題。很多團(tuán)隊(duì)也通過(guò)引入代碼校驗(yàn)流程來(lái)確保實(shí)現(xiàn)“避免css表達(dá)式”和“避免重定向”原則。目前絕大多數(shù)互聯(lián)網(wǎng)公司也已經(jīng)開(kāi)啟了服務(wù)端的Gzip壓縮，并使用CDN實(shí)現(xiàn)靜態(tài)資源的緩存和快速訪問(wèn)；一些技術(shù)實(shí)力雄厚的前端團(tuán)隊(duì)甚至研發(fā)出了自動(dòng)CSS Sprites工具，解決了CSS Sprites在工程維護(hù)方面的難題。使用“查找-替換”思路，我們似乎也可以很好的實(shí)現(xiàn)“劃分主域”原則。

我們把以上這些已經(jīng)成熟應(yīng)用到實(shí)際生產(chǎn)中的優(yōu)化手段去除掉，留下那些還沒(méi)有很好實(shí)現(xiàn)的優(yōu)化原則。再來(lái)回顧一下之前的性能優(yōu)化分類：

優(yōu)化方向

表格2 較難實(shí)現(xiàn)的優(yōu)化原則

現(xiàn)在有很多頂尖的前端團(tuán)隊(duì)可以將上述還剩下的優(yōu)化原則也都一一解決，但業(yè)界大多數(shù)團(tuán)隊(duì)都還沒(méi)能很好的解決這些問(wèn)題。因此，本文將就這些原則的解決方案做進(jìn)一步的分析與講解，從而為那些還沒(méi)有進(jìn)入前端工業(yè)化開(kāi)發(fā)的團(tuán)隊(duì)提供一些基礎(chǔ)技術(shù)建設(shè)意見(jiàn)，也借此機(jī)會(huì)與業(yè)界頂尖的前端團(tuán)隊(duì)在工業(yè)化工程化方向上交流一下彼此的心得。

靜態(tài)資源版本更新與緩存

如表格2所示，“緩存利用”分類中保留了“添加Expires頭”和“配置ETag”兩項(xiàng)?；蛟S有些人會(huì)質(zhì)疑，明明這兩項(xiàng)只要配置了服務(wù)器的相關(guān)選項(xiàng)就可以實(shí)現(xiàn)，為什么說(shuō)它們難以解決呢？確實(shí)，開(kāi)啟這兩項(xiàng)很容易，但開(kāi)啟了緩存后，我們的項(xiàng)目就開(kāi)始面臨另一個(gè)挑戰(zhàn)：如何更新這些緩存。

相信大多數(shù)團(tuán)隊(duì)也找到了類似的答案，它和《高性能網(wǎng)站建設(shè)指南》關(guān)于“添加Expires頭”所說(shuō)的原則一樣——修訂文件名。即：

最有效的解決方案是修改其所有鏈接，這樣，全新的請(qǐng)求將從原始服務(wù)器下載最新的內(nèi)容。

思路沒(méi)錯(cuò)，但要怎么改變鏈接呢？變成什么樣的鏈接才能有效更新緩存，又能最大限度避免那些沒(méi)有修改過(guò)的文件緩存不失效呢？

先來(lái)看看現(xiàn)在一般前端團(tuán)隊(duì)的做法：

或者

大家會(huì)采用添加query的形式修改鏈接。這樣做是比較直觀的解決方案，但在訪問(wèn)量較大的網(wǎng)站，這么做可能將面臨一些新的問(wèn)題。

通常一個(gè)大型的web應(yīng)用幾乎每天都會(huì)有迭代和更新，發(fā)布新版本也就是發(fā)布新的靜態(tài)資源和頁(yè)面的過(guò)程。以上述代碼為例，假設(shè)現(xiàn)在線上運(yùn)行著index.html文件，并且使用了線上的a.js資源。index.html的內(nèi)容為：

這次我們更新了頁(yè)面中的一些內(nèi)容，得到一個(gè)index.html文件，并開(kāi)發(fā)了新的與之匹配的a.js資源來(lái)完成頁(yè)面交互，新的index.html文件的內(nèi)容因此而變成了：

好了，現(xiàn)在要開(kāi)始將兩份新的文件發(fā)布到線上去?？梢钥吹?，index.html和a.js的資源實(shí)際上是要覆蓋線上的同名文件的。不管怎樣，在發(fā)布的過(guò)程中，index.html和a.js總有一個(gè)先后的順序，從而中間出現(xiàn)一段或大或小的時(shí)間間隔。對(duì)于一個(gè)大型互聯(lián)網(wǎng)應(yīng)用來(lái)說(shuō)即使在一個(gè)很小的時(shí)間間隔內(nèi)，都有可能出現(xiàn)新用戶訪問(wèn)。在這個(gè)時(shí)間間隔中，訪問(wèn)了網(wǎng)站的用戶會(huì)發(fā)生什么情況呢？

1. 如果先覆蓋index.html，后覆蓋a.js，用戶在這個(gè)時(shí)間間隙訪問(wèn)，會(huì)得到新的index.html配合舊的a.js的情況，從而出現(xiàn)錯(cuò)誤的頁(yè)面。
2. 如果先覆蓋a.js，后覆蓋index.html，用戶在這個(gè)間隙訪問(wèn)，會(huì)得到舊的index.html配合新的a.js的情況，從而也出現(xiàn)了錯(cuò)誤的頁(yè)面。

這就是為什么大型web應(yīng)用在版本上線的過(guò)程中經(jīng)常會(huì)較集中的出現(xiàn)前端報(bào)錯(cuò)日志的原因，也是一些互聯(lián)網(wǎng)公司選擇加班到半夜等待訪問(wèn)低峰期再上線的原因之一。此外，由于靜態(tài)資源文件版本更新是“覆蓋式”的，而頁(yè)面需要通過(guò)修改query來(lái)更新，對(duì)于使用CDN緩存的web產(chǎn)品來(lái)說(shuō)，還可能面臨CDN緩存攻擊的問(wèn)題。我們?cè)賮?lái)觀察一下前面說(shuō)的版本更新手段：

我們不難預(yù)測(cè)，a.js的下一個(gè)版本是“1.0.1”，那么就可以刻意構(gòu)造一串這樣的請(qǐng)求“a.js?v=1.0.1”、“a.js?v=1.0.2”、……讓CDN將當(dāng)前的資源緩存為“未來(lái)的版本”。這樣當(dāng)這個(gè)頁(yè)面所用的資源有更新時(shí)，即使更改了鏈接地址，也會(huì)因?yàn)镃DN的原因返回給用戶舊版本的靜態(tài)資源，從而造成頁(yè)面錯(cuò)誤。即便不是刻意制造的攻擊，在上線間隙出現(xiàn)訪問(wèn)也可能導(dǎo)致區(qū)域性的CDN緩存錯(cuò)誤。

此外，當(dāng)版本有更新時(shí)，修改所有引用鏈接也是一件與工程管理相悖的事，至少我們需要一個(gè)可以“查找-替換”的工具來(lái)自動(dòng)化的解決版本號(hào)修改的問(wèn)題。

對(duì)付這個(gè)問(wèn)題，目前來(lái)說(shuō)最優(yōu)方案就是基于文件內(nèi)容的hash版本冗余機(jī)制了。也就是說(shuō)，我們希望工程師源碼是這么寫的：

：

但是線上代碼是這樣的：

其中”_82244e91”這串字符是根據(jù)a.js的文件內(nèi)容進(jìn)行hash運(yùn)算得到的，只有文件內(nèi)容發(fā)生變化了才會(huì)有更改。由于版本序列是與文件名寫在一起的，而不是同名文件覆蓋，因此不會(huì)出現(xiàn)上述說(shuō)的那些問(wèn)題。同時(shí)，這么做還有其他的好處：

1. 線上的a.js不是同名文件覆蓋，而是文件名+hash的冗余，所以可以先上線靜態(tài)資源，再上線html頁(yè)面，不存在間隙問(wèn)題；
2. 遇到問(wèn)題回滾版本的時(shí)候，無(wú)需回滾a.js，只須回滾頁(yè)面即可；
3. 由于靜態(tài)資源版本號(hào)是文件內(nèi)容的hash，因此所有靜態(tài)資源可以開(kāi)啟永久強(qiáng)緩存，只有更新了內(nèi)容的文件才會(huì)緩存失效，緩存利用率大增；
4. 修改靜態(tài)資源后會(huì)在線上產(chǎn)生新的文件，一個(gè)文件對(duì)應(yīng)一個(gè)版本，因此不會(huì)受到構(gòu)造CDN緩存形式的攻擊

雖然這種方案是相比之下最完美的解決方案，但它無(wú)法通過(guò)手工的形式來(lái)維護(hù)，因?yàn)橐揽渴止さ男问絹?lái)計(jì)算和替換hash值，并生成相應(yīng)的文件。這將是一項(xiàng)非常繁瑣且容易出錯(cuò)的工作，因此我們需要借助工具。我們下面來(lái)了解一下fis是如何完成這項(xiàng)工作的。

首先，之所以有這種工具需求，完全是由web應(yīng)用運(yùn)行的根本機(jī)制決定的：web應(yīng)用所需的資源是以字面的形式通知瀏覽器下載而聚合在一起運(yùn)行的。這種資源加載策略使得web應(yīng)用從本質(zhì)上區(qū)別于傳統(tǒng)桌面應(yīng)用的版本更新方式。為了實(shí)現(xiàn)資源定位的字面量替換操作，前端構(gòu)建工具理論上需要識(shí)別所有資源定位的標(biāo)記，其中包括：

• css中的@import url(path)、background:url(path)、backgournd-image:url(path)、filter中的src
• js中的自定義資源定位函數(shù)，在fis中我們將其規(guī)定為_(kāi)_uri(path)。
• html中的<script src=”path”>、<link href=”path”>、<imgsrc=”path”>、已經(jīng)embed、audio、video、object等具有資源加載功能的標(biāo)簽。

為了工程上的維護(hù)方便，我們希望工程師在源碼中寫的是相對(duì)路徑，而工具可以將其替換為線上的絕對(duì)路徑，從而避免相對(duì)路徑定位錯(cuò)誤的問(wèn)題（比如js中需要定位圖片路徑時(shí)不能使用相對(duì)路徑的情況）。

fis的資源定位設(shè)計(jì)思想

fis有一個(gè)非常棒的資源定位系統(tǒng)，它是根據(jù)用戶自己的配置來(lái)指定資源發(fā)布后的地址，然后由fis的資源定位系統(tǒng)識(shí)別文件中的定位標(biāo)記，計(jì)算內(nèi)容hash，并根據(jù)配置替換為上線后的絕對(duì)url路徑。

要想實(shí)現(xiàn)具備hash版本生成功能的構(gòu)建工具不是“查找-替換”這么簡(jiǎn)單的。我們考慮這樣一種情況：

資源引用關(guān)系

由于我們的資源版本號(hào)是通過(guò)對(duì)文件內(nèi)容進(jìn)行hash運(yùn)算得到，如上圖所示，index.html中引用的a.css文件的內(nèi)容其實(shí)也包含了a.png的hash運(yùn)算結(jié)果，因此我們?cè)谛薷膇ndex.html中a.css的引用時(shí)，不能直接計(jì)算a.css的內(nèi)容hash，而是要先計(jì)算出a.png的內(nèi)容hash，替換a.css中的引用，得到了a.css的最終內(nèi)容，再做hash運(yùn)算，最后替換index.html中的引用。

這意味著構(gòu)建工具需要具備“遞歸編譯”的能力，這也是為什么fis團(tuán)隊(duì)不得不放棄gruntjs等task-based系統(tǒng)的根本原因。針對(duì)前端項(xiàng)目的構(gòu)建工具必須是具備遞歸處理能力的。此外，由于文件之間的交叉引用等原因，fis構(gòu)建工具還實(shí)現(xiàn)了構(gòu)建緩存等機(jī)制，以提升構(gòu)建速度。

在解決了基于內(nèi)容hash的版本更新問(wèn)題之后，我們可以將所有前端靜態(tài)資源開(kāi)啟永久強(qiáng)緩存，每次版本發(fā)布都可以首先讓靜態(tài)資源全量上線，再進(jìn)一步上線模板或者頁(yè)面文件，再也不用擔(dān)心各種緩存和時(shí)間間隙的問(wèn)題了！

在本系列的下一部分，我們將介紹靜態(tài)資源管理與模板框架的思路和用法。