大型Web應用對速度的追求并沒有止步于僅僅利用瀏覽器緩存，因為瀏覽器緩存始終只是為了提升二次訪問的速度，對于首次訪問的加速，我們需要從網絡層面進行優化，最常見的手段就是CDN（Content Delivery Network，內容分發網絡）加速。通過將靜態資源緩存到離用戶很近的相同網絡運營商的CDN節點上，不但能提升用戶的訪問速度，還能節省服務器的帶寬消耗，降低負載。

　　不同地區的用戶會訪問到離自己最近的相同網絡線路上的CDN節點，當請求達到CDN節點后，節點會判斷自己的內容緩存是否有效，如果有效，則立即響應緩存內容給用戶，從而加快響應速度。如果CDN節點的緩存失效，它會根據服務配置去我們的內容源服務器獲取最新的資源響應給用戶，并將內容緩存下來以便響應給后續訪問的用戶。因此，一個地區內只要有一個用戶先加載資源，在CDN中建立了緩存，該地區的其他后續用戶都能因此而受益。

　　如上圖所示，之所以不同地區的用戶訪問同一個域名卻能得到不同CDN節點的IP地址，這要依賴于CDN服務商提供的智能域名解析服務，瀏覽器發起域名查詢時，這種智能DNS服務會根據用戶IP計算并返回離它最近的同網絡CDN節點IP，引導瀏覽器與此節點建立連接以獲取資源。

　　結合上述兩點，為了使用CDN網絡緩存，我們至少要對靜態資源的部署做兩項改變：

　　　　1、將靜態資源部署到不同網絡線路的服務器中，以加速對應網絡中CDN節點無緩存時溯源的速度。

　　　　2、加載靜態資源時使用與頁面不同的域名，一方面是便于接入為CDN而設置的智能DNS解析服務，另一方面因為靜態資源和主頁面不同域，這樣加載資源的HTTP請求就不會帶上主頁面中的Cookie等數據，較少了數據傳輸量，又進一步加快網絡訪問。

　　CDN服務基本上已經成為現代大型Web應用的標配，這項技術“幾乎”是一種對開發透明的網絡性能優化手段，使用它的理由很充分，但是這里既然強調了“幾乎透明”而不是“完全透明”，是因為使用CDN服務所需要的兩項改變對前端工程產生了一定的影響，而這些影響我在之前的文章中已經介紹了，就是前端工程必須引入非覆蓋式發布的根本原因。

　　
　　前端工程多米諾骨牌

　　上圖向大家展示了整個前端靜態資源緩存技術所帶來的連鎖性工程問題。很多人不理解為什么要選擇FIS，而不是grunt，從本質上來說，工具并么有什么差異，只是fis的設計出發點是以上這些工程問題，設計中優先考慮了現代互聯網應用是如何進行工程化部署與開發的，面臨的問題是哪些，基于這些問題，要怎么解決。

　　比如我們在上圖中可以看到，整個靜態資源緩存技術的最終影響的節點是前端靜態資源定位問題，而且前端資源定位又會進一步影響到開發，包括代碼中的模塊化加載、各種資源加載等。所以fis的設計核心之一就是資源定位。比如fis的核心配置roadmap，其目的就是為了解決在前端代碼中的所有資源定位問題，連接開發和部署規范：

　　

　　此外，fis的靜態資源表生成功能也是為了給模塊化框架提供加載部署到其他域名下的路徑中md5戳的資源部署路徑，并建立資源之間的依賴關系。

至于文件壓縮之類的功能，那只是工具問題，而非工程問題。

?

原文地址：https://div.io/topic/930