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