前端上線部署最佳實踐

這是乙個很有趣的，感覺和前端這個領域不太搭嘎的話題，今天這個話題主要是聊聊利用我們前端相關的解決方案來解決前端開發和相關上線發布優化的複雜問題。其實開啟工程化始祖應該是facebook。

ok,那麼接下來我們從最基本的技術原理開始講起吧。

讓我們從最先最原始的前端開發入手。如上所示是乙個index.html頁面與乙個樣式檔案a.css，我們可以用我們最熟悉的文字編輯器進行編碼，然後本地測試，再將**直接上傳至伺服器，這樣就算上線發布完成了。是不是覺得很easy呢？

接著，我們用瀏覽器看看線上的頁面，一切正常，好的，完美上線！

但是，但是，在一些大公司的話，因為考慮到各種頁面訪問相關的指標，你覺會知道，前端也不是這麼隨意的。

這裡強制讓瀏覽器使用本地的快取，不和伺服器連線。這樣的頁面優化幾乎是達到了極限了。但是如果想讓快取更新怎麼辦呢？

估計很多人都會知道這樣的乙個做法：改變一下資源的路徑，瀏覽器就會載入新的資源了。像下面這樣：

比如頁面裡有3個外部css檔案，在某次迭代中只修改了a.css檔案，但是將所有鏈結位址都改了，那麼就會讓另外的兩個檔案快取也失效，是不是有點浪費貸款了呢。

那麼並著精益求精的精神，我們可以讓檔案的url和檔案變更建立某種聯絡，就是說，如果某個檔案內容變更了，就會相應的改變其url位址，這樣就讓變更加的精準了。

那麼，要採取什麼方式與檔案變更相關聯呢，我們可以很容易想到的是檔案資料摘要演算法對檔案算摘要資訊，那麼檔案的內容就和得到的摘要資訊唯一對應了，那麼就有了精確到乙個檔案粒度的控制根據了。現在我們將url位址變成其內容的摘要資訊：

這樣如果檔案有變更，那麼就變更檔案對應的url位址了，是不是感覺這樣非常的ferfect呢。

現在是這樣的，我們同時改變了html和頁面的靜態資源的url位址，現在要上線了，那麼我們是先發布html頁面呢，還是先發布我們變更後的靜態資源呢？

：這樣的話，在二者部署的時間期間內，假如有新的訪問，那麼html頁面將載入的是就的靜態資源，瀏覽器將會把這個舊的資源當成新的資源快取起來。那麼就導致：使用者看到的是乙個亂的網頁，除了強制重新整理，否則在資源失效之前一直都是這樣的樣式錯亂的頁面。

：這樣呢就會導致在這二者部署的期間內，具有舊靜態檔案本地快取的使用者，因為瀏覽器會取本地的快取，那麼這樣頁面就是正常的。到那時如果哪些本地沒有快取的使用者訪問時，結果就是頁面訪問的是新版本的靜態資源，那麼頁面就會錯亂了。

那麼，既然先部署那乙個都會出問題，那怎麼辦呢？現在很多訪問量不大的**，就是在半夜或者凌晨偷偷的線上靜態資源，然後上頁面，問題比較少。

但是呢，有些訪問量巨大的專案，就沒有所謂的訪問低谷期了，所以怎麼辦呢？

這個難解的問題就是覆蓋式發布造成的，我們用待發布的資源去替換已經發布的資源，那麼就會出現這種情況。那麼怎麼解決呢？其實我們可以用非覆蓋式的發布方式：

如圖所示，我們用檔案的摘要資訊對靜態檔案來命名，然後將摘要資訊放到資源檔案要發布的路徑之中，如此，變更之後的檔案舊成了乙個要發布上線的檔案了，並不會覆蓋已經上線的靜態資源檔案。上線發布的時候，先進行完全部署靜態資源檔案，然後在進行頁面的灰度部署，這樣的方案就比較的perfect了。

因此，有些公司靜態資源優化的習慣，基本上需要滿足下面幾個原則：

設定比較長的本地快取 —— 提高效能，節省頻寬

利用摘要資訊進行檔案變更依據 —— 快取的精確控制

將靜態資源部署到cdn節點上 ——節省網路請求

利用非覆蓋式發布來更新靜態資源 —— 漸進替換

那麼，這一整個流程下來，就是乙個相對比較perfect 的解決辦法了。

最後，現在我們知道餓怎麼優化前端工程裡的靜態資源部署的難題，那麼新的issue又來了，那就是前端工程師怎麼去coding呢？

那麼要想理解優化和工程相融合的思維方式，那麼就會衍生出一系列有關模組化開發、資源的載入、資源合併、前端架構等等的工程相關的問題。上面只是拋磚引玉，解決方案才是關鍵，但是這又要一大堆篇幅才能說明白了。

總結：前端效能優化就是乙個工程化的問題。

這裡比較推薦大家多關注一下前端工程相關的一些東西，或者有些人覺得我的產品規模很小啊，不用這麼認真吧，然而你也不大後那天你確實需要這樣做了呢。而且如果我們能將工作做的更好那麼，為什麼不去做的更完美一些呢？

另外要注意的是，不要覺得這些應該丟給後端或者運維去做。你要想想，如果什麼難題都讓別人解決了，那麼我們前度工程師的角色價值會大打折扣。