Progressive Web Apps - Part.1 為什麼是 PWA？

01-25

在 2016 年杭州雲棲大會上，UC 瀏覽器發布了新一代的瀏覽器內核 —— U4，標準支持有大幅度提升，其中就包含 PWA 技術所包含的各項標準規範。PWA 全稱 Progressive Web Apps，與一般的 Web App 的區別在於 Progressive，所以 PWA 首先是為了性能體驗考慮的。移動網路非常慢，網路經常延遲，帶寬傳輸效率不穩定，這一眾所周知的客觀現實已成為大部分移動前端開發者的共識。

在一些閱讀類的業務上，大多數都採用純服務端渲染 Web 頁面的技術，當業務發展到另一階段時，如越來越注重交互體驗操作、前後端各自加速專業化，大多數轉而採用前端渲染的技術，解決強交互與前後端分離的問題，卻無法忽視一個嚴重的問題，頁面載入反而變得更慢了，隨前後端同構的提出，頁面載入緩慢的問題得到了緩解，但也沒有從根本上解決用戶打開 Web App 頁面緩慢的問題。

在使用和開發過的 Web App 業務中，都有如下的共同表現：

主文檔會渲染基本的頁面結構
頁面中間會有 loading 提示/動畫
優先載入首屏資源，渲染首屏內容
非首屏內容延遲載入，如圖片懶載入、根據路由載入不同的頁面資源

其實這些優化手段，也體現出漸進式載入的設計意圖。另外，在一些 Hybrid App 業務上，也會採取其他私有方案：

後台啟動 webview 預載入網頁包括網頁引用的資源
與客戶端結合預下髮網頁資源到用戶設備上，提前更新業務頁面

以上這些優化手段，我們再稍微總結下：

Push 推送首屏關鍵資源到初始頁面，初始頁面只包含頁面基本結構和樣式；
Render 渲染頁面基本結構和樣式，然後渲染首屏其他內容
Pre-cache 預載入、預緩存剩餘其他頁面資源
Lazy-load 懶載入非首屏資源、基於 Route-base/Component Chunk 的頁面按需載入策略

在 2016 年Google IO 大會上，Polymer 團隊提出了 PRPL 這一模式，背後的理念其實已廣泛被運用在業務的體驗優化上。PRPL 模式也僅僅只是 PWA 的基本目標和標準，還在不斷地優化完善中。我們知道，業務的快速迭代，產品的快速試錯，使得各家瀏覽器廠商、 Hybrid App 開發者不斷探索私有方案，儘可能地緩解或彌補標準規範的缺位所造成的惡劣影響。當然，沒有經過大量的業務實踐或充分的討論而提出的規範標準，往往都帶有局限性，比如 AppCache。PWA 的誕生正是基於這樣的背景，把各家的私有方案規範化標準化，未來甚至還可以跨平台化。

PWA 代表著 Web App 新的發展階段，具備一些 Native 的能力，Google 甚至公開宣布要開放更多的能力給 PWA，深度整合到 Android 系統中，但這是否意味著 Web 真正的 App 化？我想，只是為了讓 Web 具備之前欠缺的優秀 App 用戶體驗，現階段的 Web App 仍不具備成為一個 App 的條件，甚至客觀環境不允許，Google 可以不理 Apple 自己繼續折騰下去，但是我們業務卻無法放棄 iOS。iOS 不支持，意味著我們無法做什麼嗎？顯然不是，JS to Native 仍是不錯的替代方案。