上一篇的文章提到 什麼是 App Shell？

An application shell is the secret to reliably good performance.

今天參考 Google 的文件 以及 udacity 的教學影片，一起來查看 App Shell architecture 所帶來的效益。

App Shell 的執行效益

我們來看 2 個案例，同樣使用以下條件的環境來做測試：

• 頻寬：3G
• 設備：Nexus 5
• 瀏覽器：Chrome Dev

測試案例一

DEMO: 很單純的 App Shell 範例檔案 from Google

我們使用比較緩慢的 3G 連線，第一次瀏覽這個應用程式、必須先透過網路去 fetch 所有的 resources，看到畫面時、就花費了 2.5 秒，而完全載入則需要 7.1 秒，之後藉由 service worker caching，只需要 0.8 秒就可以看到畫面。

測試案例二

DEMO: weather app from Google codeLab

接著使用 Google 在 Codelabs 釋出的 weather app 作為測試網站，
藉由 WEBPAGETEST 來測試，我們從上圖可以看到
第一次載入時、要在 3.0s 才會出現畫面，完全 render 網頁內容，則需要 1.9s。

感謝 App Shell 和 Service Worker 的完美搭配，接下來瀏覽網站，在 0.3s 就出現主要畫面，只需要 0.6s 即可將網頁內容 render 完畢。

我們發現到 3G 的頻寬，能夠相差約 10 倍的速度，觀察某些國家、例如印度，在網路收訊較差的環境裡，PWA 所帶來的體驗、是非常具有吸引力的。

App Shell 的設計方向

從上述內容，我們知道使用 App Shell 所帶來的好處，
那麼要怎麼開始設計一個 App Shell？有什麼內容會被放在 App Shell？

第一步是要打散原本的設計、找出比較核心的元件
像是下圖左側，一開始載入畫面，可能希望有基本的 LOGO、背景圖片、Top Bar、導覽列等。

以下方圖片為例，我們可以思考 First Paint 希望出現什麼樣的畫面，作為 App Shell 內容。

圖片來源：Why does The Washington Post’s Progressive Web App increase engagement on iOS?

舉個例子，有個 TODO List 範例如下：

• 問問自己，有什麼畫面是要馬上顯示在網站上的？
• 網站上關鍵的 UI 元件是什麼？
• 有哪些 resources 是 App Shell 所需要的？
  • 像是： images, javascript, styles 等等

於是我們可以這樣設計 App Shell，找出基本的顯示元件，像是 Header、Logo、輸入框、預設 Icon 和固定的文字等等，透過 Service Worker 儲存 resources，即時顯示預設內容。

今日小結

本篇測試兩個 App Shell 的簡單案例，實際觀察 App Shell 所帶來的優異體驗，並說明設計 App Shell 的執行方向，接下來想要筆記的是 PWA 還提出了哪些觀點？ 能夠幫助應用程式獲得更佳的效能提升，Day 07、要分享『RAIL Model』

本人小小筆記，如有錯誤或需要改進的部分，歡迎給予回饋。
我將會用最快的速度修正，m(_ _)m。謝謝