渐进式Web应用清单（翻译转载）
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。
修复
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>来异步加载脚本，同时确保阻塞渲染的CSS被标记出来。 - 你也可以使用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可以帮助提升你的页面在搜索引擎中的表现。
测试
使用 测试工具来确保标题、图片、描述等是可以用的。
**修复
标记内容。例如：
社交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>来异步加载脚本，同时确保阻塞渲染的CSS被标记出来。
缓存
站点网络请求优先使用缓存
测试
- 把网络模拟调至最低值，开始运行应用
- 然后，把网络模拟调制离线，再运行。在离线状态下，相比于慢连接应用应该不会有太大差别
修复
在可行的地方使用缓存优先响应。也可以看下我们的service worker库，它们可以让实现这些模式更加容易。
处于离线状态时站点会合适地通知用户
测试
模拟离线网络，验证当你处于离线状态时PWA是否有提示
修复
使用Network Information API来决定用户处于离线状态是否提示。
推送通知
这个检查点只有通知功能可用时才生效。对于高级PWA来说，添加推送通知不是必要的功能点。
向用户提供通知使用方式的上下文
测试
- 访问站点，找到推送通知同意流程
- 当浏览器向你弹出许可请求时，确保上下文已经告知为什么站点需要这个许可
- 如果页面一加载完就弹出许可请求，确保其同时提供了明晰的上下文，告知用户他应该允许推送通知的原因 修复
了解下创建用户友好的通知权限允许流程的相关指导。
鼓励用户开启推送通知的界面不应该太野蛮
测试
访问站点，找到推送通知同意流程。确保你取消后，这次访问站点不会再弹提示。
修复
如果用户明确表示他们不想要某种提醒，至少在一段日子里（例如，一周）不要重复提示。
允许请求出现时，页面模糊屏幕
测试
访问站点，找到推送通知同意流程。当Chrome展示允许请求时，确保与站点需要推送通知原因无关的内容，页面都有进行模糊处理（放一个深色的遮盖层）。
修复
调用Notification.requestPermission时模糊屏幕。当promise resolve时，取消模糊。
推送通知必须及时、精准和相关
测试
开启站点的推送通知功能，确保使用推送通知时能做到以下几点：
- 及时 — 及时通知是指在用户需要以及对用户很重要时出现的通知。
- 精准 — 精确通知是指包含可立即采取行动的具体信息的通知。
- 相关 — 相关消息是指有关用户关心的人或主题的消息。
修复
看下我们在创建好的推送通知里的指南内容以找到相关建议。
提供操纵状态开启和关闭通知
测试
开启站点的推送通知功能。确保页面上有可以让你管理允许或者禁止通知的地方。
修复 创建允许用户管理他们通知偏好的界面。
额外特性
用户可以通过凭据管理 API跨设备登录
这个只在你的站点有登录流程时生效。
测试
- 为某个服务创建一个账户，确保你看到了保存密码/账户的对话框。点击"保存"。
- 清除站点cookie（通过点击挂锁图标或者Chrome设置）然后刷新站点。
- 退出然后刷新站点。确保你看到了帐号选择器。 修复
查看下我们的凭据管理API集成指南
用户可以用从Payment Request API中通过原生界面顺利支付
这个检查只有在你的站点可以支付才有用。
测试
进入支付流程。不需要填写常规表格，验证用户可以通过Payment Request API触发的原生界面顺利支付。
修复
查看我们的支付请求API集成指南。