大型Web應用對速度的追求並無止步於僅僅利用瀏覽器緩存，由於瀏覽器緩存始終只是爲了提高二次訪問的速度，對於首次訪問的加速，咱們須要從網絡層面進行優化，最多見的手段就是CDN（Content Delivery Network，內容分發網絡）加速。經過將靜態資源緩存到離用戶很近的相同網絡運營商的CDN節點上，不但能提高用戶的訪問速度，還能節省服務器的帶寬消耗，下降負載。前端
不一樣地區的用戶會訪問到離本身最近的相同網絡線路上的CDN節點，當請求達到CDN節點後，節點會判斷本身的內容緩存是否有效，若是有效，則當即響應緩存內容給用戶，從而加快響應速度。若是CDN節點的緩存失效，它會根據服務配置去咱們的內容源服務器獲取最新的資源響應給用戶，並將內容緩存下來以便響應給後續訪問的用戶。所以，一個地區內只要有一個用戶先加載資源，在CDN中創建了緩存，該地區的其餘後續用戶都能所以而受益。瀏覽器
如上圖所示，之因此不一樣地區的用戶訪問同一個域名卻能獲得不一樣CDN節點的IP地址，這要依賴於CDN服務商提供的智能域名解析服務，瀏覽器發起域名查詢時，這種智能DNS服務會根據用戶IP計算並返回離它最近的同網絡CDN節點IP，引導瀏覽器與此節點創建鏈接以獲取資源。緩存
結合上述兩點，爲了使用CDN網絡緩存，咱們至少要對靜態資源的部署作兩項改變：性能優化
一、將靜態資源部署到不一樣網絡線路的服務器中，以加速對應網絡中CDN節點無緩存時溯源的速度。服務器
二、加載靜態資源時使用與頁面不一樣的域名，一方面是便於接入爲CDN而設置的智能DNS解析服務，另外一方面由於靜態資源和主頁面不一樣域，這樣加載資源的HTTP請求就不會帶上主頁面中的Cookie等數據，較少了數據傳輸量，又進一步加快網絡訪問。網絡
CDN服務基本上已經成爲現代大型Web應用的標配，這項技術「幾乎」是一種對開發透明的網絡性能優化手段，使用它的理由很充分，可是這裏既然強調了「幾乎透明」而不是「徹底透明」，是由於使用CDN服務所須要的兩項改變對前端工程產生了必定的影響，而這些影響我在以前的文章中已經介紹了，就是前端工程必須引入非覆蓋式發佈的根本緣由。框架
前端工程多米諾骨牌模塊化
上圖向你們展現了整個前端靜態資源緩存技術所帶來的連鎖性工程問題。不少人不理解爲何要選擇FIS，而不是grunt，從本質上來講，工具並麼有什麼差別，只是fis的設計出發點是以上這些工程問題，設計中優先考慮了現代互聯網應用是如何進行工程化部署與開發的，面臨的問題是哪些，基於這些問題，要怎麼解決。grunt
好比咱們在上圖中能夠看到，整個靜態資源緩存技術的最終影響的節點是前端靜態資源定位問題，並且前端資源定位又會進一步影響到開發，包括代碼中的模塊化加載、各類資源加載等。因此fis的設計核心之一就是資源定位。好比fis的核心配置roadmap，其目的就是爲了解決在前端代碼中的全部資源定位問題，鏈接開發和部署規範：工具
此外，fis的靜態資源表生成功能也是爲了給模塊化框架提供加載部署到其餘域名下的路徑中md5戳的資源部署路徑，並創建資源之間的依賴關係。
至於文件壓縮之類的功能，那只是工具問題，而非工程問題。
原文地址：https://div.io/topic/930