漸進式Web應用（PWA）帶來的未來前端思考

PWA的前世今生你了解嗎？未來前端發展方向，你了解嗎？縱觀PC桌面端發展過程，從早期的Delphi/VB/VF/VC， 到Node Webkit，比如nw.js和electron，到PWA Desktop，帶給我們對未來前端怎樣的思考？

2017年一個爆炸性新聞是Twitter Lite使用PWA，對性能提升75%，並且明顯減少了數據使用量，核心技術棧是Node.js，Express和React PWA。

本身PWA是瀏覽器機制，和Node.js關係不大，但搭配Node.js的Web框架和React無疑是前端極好的解決方案，使用Node.js做Api聚合輸出，搭配PWA緩存，既保證性能，又讓前端有足夠的靈活性。

核心概念

Google對Web的2個重點是amp && pwa

AMP（Accelerated Mobile Pages）是Google推出法人一種為靜態內容構建 web 頁面，提供可靠和快速的渲染，加快頁面載入的時間，特別是在移動 Web 端查看內容的時間。包括2部分，AMP HTML，AMP JS和Google AMP Cache。

AMP HTML： 定義了一套HTML標籤，如amp-img, amp-video。使用這些tag可以確保載入的順滑。同時amp也負責管理資源何時載入，避免不必要的流量。

AMP JS： 實現了所有的AMP性能優化實踐。其中最大的優化就是保證外部所有資源都是非同步裝載，另外還包括Sandbox處理iFrame的模塊，資源裝載的同時預先計算出每一個元素的位置和大小；禁用慢的CSS樣式。

Google AMP Cache： 為了推動AMP，谷歌提供免費的全球CDN服務，可以緩存圖片，靜態文件等，使用HTTP2.0協議保證緩存的高效率。免費的代價就是必須使用AMP格式。

其實要想保證所有的最佳實踐都能用上，就要從組件到渲染引擎都自己做，所以amp的做法是很明智的。amp和react/vue等沒有本質差別。唯一不同的就是瀏覽器兼容性，amp兼容所有瀏覽器。另外google的cdn幫你緩存amp頁面，這是把雙刃劍，能加速，也可能會有緩存同步問題，而且國內還存在可用性問題。

相較而言，pwa（Progressive Web App）是具有一定顛覆性的，對於h5的體驗提升極其明顯。在介紹pwa之前我們先看一下h5的缺點。

留白時間過長。移動端網路非常不穩定，經常會出現弱網環境，這樣會導致資源載入速度非常慢，留白時間相對原生會慢很多。

沒網路就沒響應，不具備離線能力，以前只有App能（大量緩衝優化），h5的緩存用的極少。因為資源都在線上伺服器,每次訪問H5的頁面強烈依賴網路，原生因為資源都在應用包裡面,就算斷網也會給一個相對友好的展示界面和用戶提醒。

無法全屏訪問。H5絕大部分都是跟瀏覽打交道，但是各大瀏覽器廠商都會有一個討厭的頭部和一個討厭的尾部，導致用戶的可視區域大大被壓縮。原生大家都知道可視區域隨意控制。

不像APP一樣能進行消息推送。

手機桌面入口不夠便捷，沒有自己的啟動圖標，每次都需要輸入網址或者依靠搜索引擎引流。

隨著App的膨脹，隨便一個app都在50m左右，可能還不包含熱更新內容，這讓很多人重拾對h5的熱情。如果h5能解決這些問題，你是否願意用呢？通過pwa是可以實現上面內容的。打開Chrome的審查面板，如果你打開的是pwa頁面，在Application里你能看到3個選項：Menifest、Service Workers、Clear storage。它們便是Pwa的核心。

Service Workers是瀏覽器在後台獨立於網頁運行的腳本，它打開了通向不需要網頁或用戶交互的功能的大門。這個 API 之所以令人興奮，是因為它可以支持離線體驗，讓開發者能夠全面控制這一體驗。

Service Workers要點：

它是一種 JavaScript 工作線程，無法直接訪問 DOM。 服務工作線程通過響應 postMessage 介面發送的消息來與其控制的頁面通信，頁面可在必要時對 DOM 執行操作。

服務工作線程是一種可編程網路代理，讓您能夠控制頁面所發送網路請求的處理方式。

它在不用時會被中止，並在下次有需要時重啟，因此，您不能依賴於服務工作線程的 onfetch 和 onmessage 處理程序中的全局狀態。如果存在您需要持續保存並在重啟後加以重用的信息，服務工作線程可以訪問 IndexedDB API。

服務工作線程廣泛地利用了 promise。

其核心在Service Workers同步數據，本地通過CacheStorage存取。

要安裝服務工作線程，您需要通過在頁面中對其進行註冊來啟動安裝。 這將告訴瀏覽器服務工作線程 JavaScript 文件的位置。

此代碼用於檢查 Service Worker API 是否可用，如果可用，則在頁面載入後註冊位於 /sw.js 的服務工作線程。

從星巴克的pwa應用來看，使用了41.2m的緩存空間，可見，緩存的能力是極強的。針對各種應用場景的多種緩存策略，主要有這幾種：cache-first、cache-only、network-first、network-only、stale-while-revalidate。

採用PWA緩存和不採用PWA緩存數據對比相當明顯。

添加到桌面

如果你想要為你的網站添加添加到桌面這個功能，那麼，你的網站只需滿足以下 3 項就足夠了：

包含一個 manifest.json 文件，其中包含 short_name 以及 icons 欄位

包含 service sorkers

使用 HTTPS

除此之外，chrome 會替你處理，你只需要點擊添加到屏幕按鈕即可。chrome會將你的pwa應用轉成webapk進行安裝。

從上面 3 點可以看到，如果你的應用已經是個 PWA 應用的話，那麼，第二，第三點就已經滿足了，添加至桌面的功能其實只需為項目添加一個描述性的配置文件 manifest.json 就可以了。

瀏覽器兼容性

瀏覽器支持情況，可以看出大部分現代瀏覽器（4/5）都已經得到了支持。移動端瀏覽器情況比pc好非常多。

PWA 涉及到從安全、性能和體驗等方面的優化，想要一次性支持所有特性，代價很高，老闆也不一定願意投入大量人力來支持這項大工程。

所以，從改造的成本考慮，我們也建議採取漸進式的方式，可以考慮按照下面的步驟來改造，最先做的是將全站 HTTPS 化，因為這是 PWA 的基礎，沒有 HTTPS，就沒有 Service Worker。接下來集成 Service Worker 來提升基礎性能，離線提供靜態文件，把用戶首屏體驗提升上來，然後App Manifest，最後考慮其他的特性，離線消息推送等。

未來展望

1）通用本地存儲的解決方案workbox

workbox 是 GoogleChrome 團隊推出的一套 Web App 靜態資源和請求結果的本地存儲的解決方案，該解決方案包含一些 Js 庫和構建工具，workbox 背後則是 Service Worker 和 Cache API 等技術和標準在驅動。在 Workebox 之前，GoogleChrome 團隊較早時間推出過 sw-precache 和 sw-toolbox 庫，罵聲很多，直到 workbox 才是真正能方便統一的處理離線能力的更完美的方案。workbox 現在已經發布到了 3.0 版本，不管你的站點是何種方式構建的，都可以為你的站點提供離線訪問能力，幾乎不用考慮太多的具體實現，只用做一些配置就可以。就算你不考慮離線能力，也能讓你的站點訪問速度更加快。

2）微軟win10全力擁抱PWA

2018年，Google IO大會上獲悉微軟win10全力擁抱pwa，通過爬蟲爬取pwa頁面，並將其轉換為Appx，繼而在其應用商店裡提供應用，體驗和原生native應用非常相近，非常看好。

3）PWA桌面版

縱觀PC桌面端發展過程，從早期的Delphi/VB/VF/VC等構建起c/s時代，即使到今天依然有很大量。最近2年隨著atom/vscode的火爆，帶動了node webkit相關模塊的爆發，比如nw.js和electron等，通過web技術來構建pc client，確實是省時省力，用戶體驗也非常好，比如釘釘客戶端，石墨文檔客戶端，最主要的是可以統一技術棧，比如某些演算法，用js寫一次，你可以到前端，node，pc client等多處復用。

Chrome還提供了相應web端的api。

web pay

web share

Credential management api

media session

Chrome作為入口是可怕，再結合Android，使得Google輕鬆完成技術創新，繼而形成標準規範，推動其他廠商，一直領先是可怕的。

PWA 必然會改變前端與移動端之間的格局，再加之 AOT(ahead-of-time) 與 WebAssembly 為 JS 帶來的性能上的突破，JS 將撼動所有領域，從移動端（PWA），到桌面應用，物聯網，VR，AR，遊戲，乃至人工智慧等等。

Google接下來會大力推進pwa的桌面版，再加上win10加持，web應用無需加殼就能達到近乎原生的體驗，前端的領域再一次被拓寬，未來真的可以大膽的想想。

作者:（美）Dean Alan Hume（迪恩·艾倫·休姆）

譯者: 鄭豐彧

出版社:電子工業出版社

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！