本文转载自:众成翻译 译者:dainiel 链接:http://www.zcfy.cc/article/4200 原文:https://developers.google.com/web/progressive-web-apps/checklist
渐进式WEB应用(PWA)是可靠、快速和吸引人的,有很方法是可以把一个PWA从初级提升到高级。
为了帮助团队尽可能的提升体验,我们整理了这个checklist,其涵盖了所有我们认为构建一个基础PWA所需的,以及通过提供更好的离线体验,达到更快的交互和关心更多的重要细节,来进一步构建一个高级的PWA。
Lighthouse工具可以自动化验证表中的很多项,同时在简易测试页面上也很有帮助。
测试
使用Lighthouse来验证是否通过HTTPS加载
修复
实施HTTPS,通过 letsencrypt.org着手开始。
测试
修复
试着实现响应式设计,或者适配提供一个viewport友好的页面。
测试
使用Lighthouse验证URL responds with a 200 when offline。
修复
测试
使用Lighthouse验证User can be prompted to Add to Home screen是否都是Yes。
修复
给你的项目添加Web App Manifest文件。
测试
在Nexus 5(或者类似的机器)上使用Lighthouse验证在模拟3G网络下,首次访问时可交互时间是否小于10S。
修复
<script async>
来异步加载脚本,同时确保阻塞渲染的CSS被标记出来。测试
在Chrome, Edge, Firefox和Safari中测试页面
修复
修复应用跨浏览器运行时的问题
当你四处触碰时过渡应该表现顺畅点,哪怕在弱网络下,这是感知性能上的关键。
测试
在很慢的模拟网络下打开app。每次你在app中触碰一个链接或者按钮,页面应该立即响应,可以使用以下方案:
如果使用的是单页应用,直接把用户过渡到下个页面,同时展示一个加载占位图,并且使用加载时已经可用的内容,像是标题或者缩略图。
测试
确保每个单独的页面100%可以通过URL访问,并且在社交媒体上分享时URL是唯一的,可以用这个方法进行测试:每个单独的页面都可以被新的浏览器窗口打开和访问。
修复
如果构建一个单页应用,确保客户端路由可以通过给定的URL重建应用的状态。
这里的的很多检查项需要人工执行,因为它们还没有在Lighthouse中实现。
测试
使用Google抓取方式工具来预览站点被抓取时Google是怎么看待它的。
修复
Google的索引系统确实会运行JavaScript,但是有些问题可能需要被修复来让内容可以访问。例如,如果你正在使用新的浏览器特性像Fetch API,确保它们在不支持的浏览器里面也可以被兼容。
Schema.org metadata可以帮助提升你的页面在搜索引擎中的表现。
测试
使用 测试工具来确保标题、图片、描述等是可以用的。
**修复
标记内容。例如:
测试
使用Open Graph标签标记内容,记得遵循Twitter的建议。
只有你的内容有多个URL时这一点才需要。
测试
在每个页面的<head>
添加规范链接tag,让其指向规范资源文档。查看使用规范URL了解更多。
测试
对于单页应用,确保页面没有使用片段标识符。例如在https://example.com/#!user/26601
的#!
之后的所有内容。
修复
使用 History API替代片段标识符。
测试
在PWA里面加载不同的页面,确保页面加载时内容或界面不会“跳动”
修复
确保所有内容,特别是图片和广告,在CSS或者元素属性里有固定尺寸。在图片加载前,你可以展示一个灰色的方块或者模糊/小的版本(如果可能的话)来作为占位符。
测试
在应用中找一个列表区域。向下滚动。触碰项目进入详情页。在详情页上下滚动。点击返回,确保列表区域滚动到详情链接/按钮触碰前的位置。
修复
用户点击返回时,恢复列表的滚动位置。一些路由库会有帮你做这个的特性。
测试
找到一个有文本输入框的页面。把文本输入框滚动到刚好在屏幕底部。点击输入框,验证键盘出现时其没有被遮住。
修复
试一下像Element.scrollIntoView()
和Element.scrollIntoViewIfNeeded()
这样的方法来保证输入框被点击时是可见的。
测试
确保独立模式(也就是把应用添加到主屏后)下,你可以从应用的界面把内容分享出来。
修复
提供社交分享按钮,或者界面的通用分享按钮。如果是通过按钮,你可能希望用户触碰时能复制URL,提供给他们可以分享的社交网络,或者试试整合了原生Android分享系统的新Web分享API。
测试
在大中小屏幕上查看PWA,确保其都能正常运行。
修复
在实现响应式界面中回顾下我们的方案。
测试
检查加载完成时PWA没有使用应用安装广告
修复
测试
检查浏览没有在不恰当的时候展示添加到主屏,例如当用户正在进行某项操作时,或者另外一个提示已经在屏幕上显示时。
修复
beforeinstallprompt
事件,并且随后再提示测试
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秒目标)
修复
<script async>
来异步加载脚本,同时确保阻塞渲染的CSS被标记出来。测试
修复
在可行的地方使用缓存优先响应。也可以看下我们的service worker库,它们可以让实现这些模式更加容易。
测试
模拟离线网络,验证当你处于离线状态时PWA是否有提示
修复
使用Network Information API来决定用户处于离线状态是否提示。
这个检查点只有通知功能可用时才生效。对于高级PWA来说,添加推送通知不是必要的功能点。
测试
了解下创建用户友好的通知权限允许流程的相关指导。
测试
访问站点,找到推送通知同意流程。确保你取消后,这次访问站点不会再弹提示。
修复
如果用户明确表示他们不想要某种提醒,至少在一段日子里(例如,一周)不要重复提示。
测试
访问站点,找到推送通知同意流程。当Chrome展示允许请求时,确保与站点需要推送通知原因无关的内容,页面都有进行模糊处理(放一个深色的遮盖层)。
修复
调用Notification.requestPermission
时模糊屏幕。当promise resolve时,取消模糊。
测试
开启站点的推送通知功能,确保使用推送通知时能做到以下几点:
修复
看下我们在创建好的推送通知里的指南内容以找到相关建议。
测试
开启站点的推送通知功能。确保页面上有可以让你管理允许或者禁止通知的地方。
修复 创建允许用户管理他们通知偏好的界面。
这个只在你的站点有登录流程时生效。
测试
查看下我们的凭据管理API集成指南
这个检查只有在你的站点可以支付才有用。
测试
进入支付流程。不需要填写常规表格,验证用户可以通过Payment Request API触发的原生界面顺利支付。
修复
查看我们的支付请求API集成指南。