渐进式Web应用清单（翻译转载）

2017-10-18  本文已影响13人  杨肆月

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着手开始。

页面在平板和移动设备上有进行响应式适配

测试

修复

试着实现响应式设计，或者适配提供一个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。

修复

页面跨浏览器兼容性

测试

在Chrome, Edge, Firefox和Safari中测试页面

修复

修复应用跨浏览器运行时的问题

页面过渡不要表现得像网络阻塞

当你四处触碰时过渡应该表现顺畅点，哪怕在弱网络下，这是感知性能上的关键。

测试

在很慢的模拟网络下打开app。每次你在app中触碰一个链接或者按钮，页面应该立即响应，可以使用以下方案：

如果使用的是单页应用，直接把用户过渡到下个页面，同时展示一个加载占位图，并且使用加载时已经可用的内容，像是标题或者缩略图。

每个页面都有一个URL

测试

确保每个单独的页面100%可以通过URL访问，并且在社交媒体上分享时URL是唯一的，可以用这个方法进行测试：每个单独的页面都可以被新的浏览器窗口打开和访问。

修复

如果构建一个单页应用，确保客户端路由可以通过给定的URL重建应用的状态。

高级PWA Checklist

这里的的很多检查项需要人工执行，因为它们还没有在Lighthouse中实现。

索引性和社交

想了解更多信息，可以看下我们的社交优化和社交探索指南。

页面内容被Google索引

测试

使用Google抓取方式工具来预览站点被抓取时Google是怎么看待它的。

修复

Google的索引系统确实会运行JavaScript，但是有些问题可能需要被修复来让内容可以访问。例如，如果你正在使用新的浏览器特性像Fetch API，确保它们在不支持的浏览器里面也可以被兼容。

Schema.org metadata在适当的地方被提供

Schema.org metadata可以帮助提升你的页面在搜索引擎中的表现。

测试

使用 测试工具来确保标题、图片、描述等是可以用的。

**修复

标记内容。例如：

社交metadata在适当的地方被提供

测试

使用Open Graph标签标记内容，记得遵循Twitter的建议。

必要时提供规范网址

只有你的内容有多个URL时这一点才需要。

测试

在每个页面的<head>添加规范链接tag，让其指向规范资源文档。查看使用规范URL了解更多。

页面使用History API

测试

对于单页应用，确保页面没有使用片段标识符。例如在https://example.com/#!user/26601的#!之后的所有内容。

修复

使用 History API替代片段标识符。

用户体验

页面加载时内容不闪

测试

在PWA里面加载不同的页面，确保页面加载时内容或界面不会“跳动”

修复

确保所有内容，特别是图片和广告，在CSS或者元素属性里有固定尺寸。在图片加载前，你可以展示一个灰色的方块或者模糊/小的版本（如果可能的话）来作为占位符。

从详情页回退到之前的列表页面时，列表页保持滚动距离

测试

在应用中找一个列表区域。向下滚动。触碰项目进入详情页。在详情页上下滚动。点击返回，确保列表区域滚动到详情链接/按钮触碰前的位置。

修复

用户点击返回时，恢复列表的滚动位置。一些路由库会有帮你做这个的特性。

触碰时，输入框不会被屏幕键盘遮挡

测试

找到一个有文本输入框的页面。把文本输入框滚动到刚好在屏幕底部。点击输入框，验证键盘出现时其没有被遮住。

修复

试一下像Element.scrollIntoView()和Element.scrollIntoViewIfNeeded() 这样的方法来保证输入框被点击时是可见的。

内容在独立或全屏模式下分享毫无难度

测试

确保独立模式（也就是把应用添加到主屏后）下，你可以从应用的界面把内容分享出来。

修复

提供社交分享按钮，或者界面的通用分享按钮。如果是通过按钮，你可能希望用户触碰时能复制URL，提供给他们可以分享的社交网络，或者试试整合了原生Android分享系统的新Web分享API。

在处理手机、平板和台式机屏幕尺寸时，站点是响应式的

测试

在大中小屏幕上查看PWA，确保其都能正常运行。

修复

在实现响应式界面中回顾下我们的方案。

应用安装提示不要被过度使用

测试

检查加载完成时PWA没有使用应用安装广告

修复

拦截添加到主屏提示

测试

检查浏览没有在不恰当的时候展示添加到主屏，例如当用户正在进行某项操作时，或者另外一个提示已经在屏幕上显示时。

修复

性能

即使在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秒目标）

修复

缓存

站点网络请求优先使用缓存

测试

修复

在可行的地方使用缓存优先响应。也可以看下我们的service worker库，它们可以让实现这些模式更加容易。

处于离线状态时站点会合适地通知用户

测试

模拟离线网络，验证当你处于离线状态时PWA是否有提示

修复

使用Network Information API来决定用户处于离线状态是否提示。

推送通知

这个检查点只有通知功能可用时才生效。对于高级PWA来说，添加推送通知不是必要的功能点。

向用户提供通知使用方式的上下文

测试

了解下创建用户友好的通知权限允许流程的相关指导。

鼓励用户开启推送通知的界面不应该太野蛮

测试

访问站点，找到推送通知同意流程。确保你取消后，这次访问站点不会再弹提示。

修复

如果用户明确表示他们不想要某种提醒，至少在一段日子里（例如，一周）不要重复提示。

允许请求出现时，页面模糊屏幕

测试

访问站点，找到推送通知同意流程。当Chrome展示允许请求时，确保与站点需要推送通知原因无关的内容，页面都有进行模糊处理（放一个深色的遮盖层）。

修复

调用Notification.requestPermission时模糊屏幕。当promise resolve时，取消模糊。

推送通知必须及时、精准和相关

测试

开启站点的推送通知功能，确保使用推送通知时能做到以下几点：

修复

看下我们在创建好的推送通知里的指南内容以找到相关建议。

提供操纵状态开启和关闭通知

测试

开启站点的推送通知功能。确保页面上有可以让你管理允许或者禁止通知的地方。

修复
创建允许用户管理他们通知偏好的界面。

额外特性

用户可以通过凭据管理 API跨设备登录

这个只在你的站点有登录流程时生效。

测试

查看下我们的凭据管理API集成指南

用户可以用从Payment Request API中通过原生界面顺利支付

这个检查只有在你的站点可以支付才有用。

测试

进入支付流程。不需要填写常规表格，验证用户可以通过Payment Request API触发的原生界面顺利支付。

修复

查看我们的支付请求API集成指南。

上一篇下一篇

猜你喜欢

热点阅读