PWA Checklist
本文轉載自：衆成翻譯
譯者：dainiel
連結：http://www.zcfy.cc/article/4200
原文：https://developers.google.com/web/progressive-web-apps/checklist
漸進式WEB應用(PWA)是可靠、快速和吸引人的，有很方法是可以把一個PWA從初級提升到進階。
為了幫助團隊盡可能的提升體驗，我們整理了這個checklist，其涵蓋了所有我們認為建構一個基礎PWA所需的，以及通過提供更好的離線體驗，達到更快的互動和關心更多的重要細節，來進一步建構一個進階的PWA。
初級PWA Checklist
Lighthouse工具可以自動化驗證表中的很多項，同時在簡易測試頁面上也很有幫助。
頁面通過HTTPS加載
測試
使用Lighthouse來驗證是否通過HTTPS加載
修複
實施HTTPS，通過
letsencrypt.org着手開始。
頁面在平闆和移動裝置上有進行響應式适配
測試
- 使用Lighthouse的Design is mobile-friendly來驗證，盡管手工檢查也可以。
- 使用Mobile Friendly Test來檢查
修複
試着實作響應式設計，或者适配提供一個viewport友好的頁面。
離線狀态時通路的URL（至少）要加載
測試
使用Lighthouse驗證URL responds with a 200 when offline。
修複
使用Service Worker.
Metadata提供添加到主螢幕的功能
測試
使用Lighthouse驗證User can be prompted to Add to Home screen是否都是Yes。
修複
給你的項目添加Web App Manifest檔案。
首次加載流暢，即使是在3G下
測試
在Nexus 5（或者類似的機器）上使用Lighthouse驗證在模拟3G網絡下，首次通路時可互動時間是否小于10S。
修複
- 有許多提升性能的方法。
- 你可以通過使用Pagespeed Insights (旨在把分數提升 >85)和WebPageTest (旨在首次通路3G下Nexus 5 Chrome的時間 <4000)的SpeedIndex來更深入了解性能。
- 還有一些關于加載更少腳本的小建議：確定盡可能多的使用
<script async>
- 你也可以使用PRPL模式和像PageSpeed Module的伺服器端工具進行研究。
頁面跨浏覽器相容性
測試
在Chrome, Edge, Firefox和Safari中測試頁面
修複
修複應用跨浏覽器運作時的問題
頁面過渡不要表現得像網絡阻塞
當你四處觸碰時過渡應該表現順暢點，哪怕在弱網絡下，這是感覺性能上的關鍵。
測試
在很慢的模拟網絡下打開app。每次你在app中觸碰一個連結或者按鈕，頁面應該立即響應，可以使用以下方案：
- 立即過渡到下一屏，同時在等待網絡内容時展示一個占位加載。
-
當app等待網絡響應時，展示一個加載訓示。
修複
如果使用的是單頁應用，直接把使用者過渡到下個頁面，同時展示一個加載占位圖，并且使用加載時已經可用的内容，像是标題或者縮略圖。
每個頁面都有一個URL
測試
確定每個單獨的頁面100%可以通過URL通路，并且在社交媒體上分享時URL是唯一的，可以用這個方法進行測試：每個單獨的頁面都可以被新的浏覽器視窗打開和通路。
修複
如果建構一個單頁應用，確定用戶端路由可以通過給定的URL重建應用的狀态。
進階PWA Checklist
這裡的的很多檢查項需要人工執行，因為它們還沒有在Lighthouse中實作。
索引性和社交
想了解更多資訊，可以看下我們的社交優化和社交探索指南。
頁面内容被Google索引
測試
使用Google抓取方式工具來預覽站點被抓取時Google是怎麼看待它的。
修複
Google的索引系統确實會運作JavaScript，但是有些問題可能需要被修複來讓内容可以通路。例如，如果你正在使用新的浏覽器特性像Fetch API，確定它們在不支援的浏覽器裡面也可以被相容。
Schema.org metadata在适當的地方被提供
Schema.org metadata可以幫助提升你的頁面在搜尋引擎中的表現。
測試
使用 測試工具來確定标題、圖檔、描述等是可以用的。
**修複
标記内容。例如：
- 一個菜單應用應該有Rich Card的菜單類型标記
- 一個新聞應用應該有Rich Card的新聞文章類型标記，也可以加上AMP支援
- 一個電商引用應有Rich Card的産品類型标記
社交metadata在适當的地方被提供
測試
- 在Facebook爬蟲中打開一個典型的頁面，并且確定其看起來沒什麼問題。
-
檢查Twitter
Cards meta data是否存在，（例如）如果你覺得這必要的話。
修複
使用Open Graph标簽标記内容，記得遵循Twitter的建議。
必要時提供規範網址
隻有你的内容有多個URL時這一點才需要。
測試
-
Determine whether any piece of content is available at two
different URLs.
-
Open both of these pages and ensure they use tags in the head to indicate the
canonical version
- 判斷兩個不同URL的内容是否都可通路；
-
打開這兩個頁面，確定它們在head裡面有使用表現規範版本的<link rel=canonical>tag
修複
在每個頁面的
<head>
添加規範連結tag，讓其指向規範資源文檔。檢視使用規範URL了解更多。
頁面使用History API
測試
對于單頁應用，確定頁面沒有使用片段辨別符。例如在
https://example.com/#!user/26601
的
#!
之後的所有内容。
修複
使用 History API替代片段辨別符。
使用者體驗
頁面加載時内容不閃
測試
在PWA裡面加載不同的頁面，確定頁面加載時内容或界面不會“跳動”
修複
確定所有内容，特别是圖檔和廣告，在CSS或者元素屬性裡有固定尺寸。在圖檔加載前，你可以展示一個灰色的方塊或者模糊/小的版本（如果可能的話）來作為占位符。
從詳情頁回退到之前的清單頁面時，清單頁保持滾動距離
測試
在應用中找一個清單區域。向下滾動。觸碰項目進入詳情頁。在詳情頁上下滾動。點選傳回，確定清單區域滾動到詳情連結/按鈕觸碰前的位置。
修複
使用者點選傳回時，恢複清單的滾動位置。一些路由庫會有幫你做這個的特性。
觸碰時，輸入框不會被螢幕鍵盤遮擋
測試
找到一個有文本輸入框的頁面。把文本輸入框滾動到剛好在螢幕底部。點選輸入框，驗證鍵盤出現時其沒有被遮住。
修複
試一下像
Element.scrollIntoView()
和
Element.scrollIntoViewIfNeeded()
這樣的方法來保證輸入框被點選時是可見的。
内容在獨立或全屏模式下分享毫無難度
測試
確定獨立模式（也就是把應用添加到主屏後）下，你可以從應用的界面把内容分享出來。
修複
提供社交分享按鈕，或者界面的通用分享按鈕。如果是通過按鈕，你可能希望使用者觸碰時能複制URL，提供給他們可以分享的社交網絡，或者試試整合了原生Android分享系統的新Web分享API。
在處理手機、平闆和桌上型電腦螢幕尺寸時，站點是響應式的
測試
在大中小螢幕上檢視PWA，確定其都能正常運作。
修複
在實作響應式界面中回顧下我們的方案。
應用安裝提示不要被過度使用
測試
檢查加載完成時PWA沒有使用應用安裝廣告
修複
- 應該隻有一個頂部或者底部應用安裝橫幅
- 在PWA被添加到使用者的主屏後，任何頂部/底部橫幅都應該被移除
攔截添加到主屏提示
測試
檢查浏覽沒有在不恰當的時候展示添加到主屏，例如當使用者正在進行某項操作時，或者另外一個提示已經在螢幕上顯示時。
修複
- 攔截
beforeinstallprompt
- Chrome可以管理什麼時候顯示提示，但是有些情況下這可能會不太理想。你可以延遲提示到之後使用應用的某個時刻。模糊螢幕，在下方請求允許也是個不錯的的方案。
性能
即使在3G下首次加載也能很快
測試
Use Lighthouse on a Nexus 5 (or similar) to verify time to interactive <5s for first visit on a simulated 3G network (as opposed to the 10s goal for baseline PWAs)
在Nexus 5（或者類似的機器）上使用Lighthouse驗證在模拟3G網絡下，首次通路時可互動時間是否小于5秒（對照初級 PWA的10秒目标）
修複
- 檢視WebFundamental的性能部分，確定你有實作最佳實踐
- 你可以通過使用 Pagespeed Insights (旨在數值>85)和WebPageTest的SpeedIndex(旨在Nexus 5 Chrome在移動3G首次通路數值<4000)更好的了解性能
- 還有一些加載更少腳本的小建議：確定盡可能多的使用
<script async>
緩存
站點網絡請求優先使用緩存
測試
- 把網絡模拟調至最低值，開始運作應用
- 然後，把網絡模拟調制離線，再運作。在離線狀态下，相比于慢連接配接應用應該不會有太大差别
修複
在可行的地方使用緩存優先響應。也可以看下我們的service worker庫，它們可以讓實作這些模式更加容易。
處于離線狀态時站點會合适地通知使用者
測試
模拟離線網絡，驗證當你處于離線狀态時PWA是否有提示
修複
使用Network Information API來決定使用者處于離線狀态是否提示。
推送通知
這個檢查點隻有通知功能可用時才生效。對于進階PWA來說，添加推送通知不是必要的功能點。
向使用者提供通知使用方式的上下文
測試
- 通路站點，找到推送通知同意流程
- 當浏覽器向你彈出許可請求時，確定上下文已經告知為什麼站點需要這個許可
-
如果頁面一加載完就彈出許可請求，確定其同時提供了明晰的上下文，告知使用者他應該允許推送通知的原因
修複
了解下建立使用者友好的通知權限允許流程的相關指導。
鼓勵使用者開啟推送通知的界面不應該太野蠻
測試
通路站點，找到推送通知同意流程。確定你取消後，這次通路站點不會再彈提示。
修複
如果使用者明确表示他們不想要某種提醒，至少在一段日子裡（例如，一周）不要重複提示。
允許請求出現時，頁面模糊螢幕
測試
通路站點，找到推送通知同意流程。當Chrome展示允許請求時，確定與站點需要推送通知原因無關的内容，頁面都有進行模糊處理（放一個深色的遮蓋層）。
修複
調用
Notification.requestPermission
時模糊螢幕。當promise resolve時，取消模糊。
推送通知必須及時、精準和相關
測試
開啟站點的推送通知功能，確定使用推送通知時能做到以下幾點：
- 及時 — 及時通知是指在使用者需要以及對使用者很重要時出現的通知。
- 精準 — 精确通知是指包含可立即采取行動的具體資訊的通知。
- 相關 — 相關消息是指有關使用者關心的人或主題的消息。
修複
看下我們在建立好的推送通知裡的指南内容以找到相關建議。
提供操縱狀态開啟和關閉通知
測試
開啟站點的推送通知功能。確定頁面上有可以讓你管理允許或者禁止通知的地方。
修複
建立允許使用者管理他們通知偏好的界面。
額外特性
使用者可以通過憑據管理 API跨裝置登入
這個隻在你的站點有登入流程時生效。
測試
- 為某個服務建立一個賬戶，確定你看到了儲存密碼/賬戶的對話框。點選"儲存"。
- 清除站點cookie（通過點選挂鎖圖示或者Chrome設定）然後重新整理站點。
-
退出然後重新整理站點。確定你看到了帳号選擇器。
修複
檢視下我們的憑據管理API內建指南
使用者可以用從Payment Request API中通過原生界面順利支付
這個檢查隻有在你的站點可以支付才有用。
測試
進入支付流程。不需要填寫正常表格，驗證使用者可以通過Payment Request API觸發的原生界面順利支付。
修複
檢視我們的支付請求API內建指南。