Hexo使用Web Push Notification 浏览器通知推送

Web Push Notification 是怎么工作的？个人博客为什么要使用它？如何使用它？

Intro

最近你可能总是遇上这种弹窗。

这便是浏览器通知推送。如果你同意网站给你推送通知，你就会收到类似这样的消息。

但这对个人博客又有什么好处呢？

个人博客推送消息的渠道很少。能来访问个人博客的都是有缘人。一篇新的博客发布了，又有多少有缘人会知道呢？这些曾经访问过你的博客的人还会再次来访么？

大部分人了解博客是否有更新是通过 Rss 订阅。但是有多少读者订阅了博客的 Rss，又有多少收到 Rss 更新后来阅读了新文章，Rss 并不能给出任何统计数据。相比于 App 的通知推送，Rss 订阅对于博客主是静悄悄的。

另一个方式是邮件列表订阅。读者访问网站的时候，输入自己的邮箱。当博客更新的时候，读者会收到邮件提醒。这听起不错，至少作者可以很轻易地对读者进行广播。但是到底有多少读者会愿意输入自己的邮箱，又有多少读者会经常检查自己的邮箱呢？

Web Push Notification 给予了网站与用户交流的能力。虽然无法达到原生 app 那样，但也解决了前两种方式的问题。

Web-push 的优势

与传统的邮件列表相比，Web push Notification 有这样几点不同：

1. 使用邮件推送，只有打开邮件的人才能看到推送的内容。如果使用 Web push Notification，任何一个在使用浏览器的人都会看到推送的内容。
2. 由于阅读信息的比例高，点击通知的比例也会更高。更多的人会跳转到你的站点。PushEngage 曾看到过百分之五十的点击率。
3. Web push notification 还是一个较新的技术。浏览器通知的信噪比没有邮件那么高。

从用户体验上来说，相较于传统的弹出式邮件输入框，Web-push Notification 更加的便捷。用户不需要输入一长串的邮箱字符，只需要按一下便可以接收之后的更新。并且一般弹出式的邮件输入框会降低谷歌的搜索排名。

传统的邮件列表的转换率为 1%-4%,然而 Web push notification 的转换率有 30%。或许因为大家对垃圾邮件都很讨厌，但是浏览器通知推送相对较新，还没有成为垃圾信息的象征。相较于潜在的垃圾邮件，大家更愿意接受一些新颖的科技。

根据PushEngage的研究，Web push notification 可以为你的站点带来额外 20%到 30%的重复访问。即那些曾经访问过你网站的人在收到浏览器通知推送后重新访问你的网站。除了流量的增加，Web push notification 的投资回报率是邮件的 2 倍 10 倍。这意味着在 Web push notification 十分之一的投入可以达到和邮件一样的效果。

Web Push Notification 原理

Web Push Notification 其实分为两块。一个是推送，另一个是通知。

推送就是服务器向浏览器发送信息。通知则是浏览器显示信息的一种方式。

通过调用 NotificationAPI,网站可以向用户发送通知。但是不管发送什么通知，第一步是申请权限。只有用户给予网站通知权限，网站才可以展示通知。通知的样式为系统通知样式。往往具有一个头像，标题，正文以及两个按钮。

推送的过程可以参照下图。

图中的 web page 是网站。Service worker 是独立于网页，运行在浏览器后台的脚本。Use agent 为用户端，也就是浏览器。 Application server 为业务服务器，决定着推送的内容和什么时候触发 Push service。Push service 则是推送服务。当 Application server 将准备好的内容发送给 Push service 后，push service 负责将内容分发给所有订阅这个网站的用户。

从时序上来说，网站首先获取客户端的推送的权限。接着网站会注册一个 service worker 用来接收推送信息。Service worker 是运行在浏览器（客户端）后台的脚本。这样即使网站被关闭，用户照样可以收到来自网站的消息。网站注册了推送用的 Service worker 后，客户端会返回PushSubscription。PushSubscription包含了推送消息所需要的一切数据。

当业务服务器想要推送消息时，它便去调用 Push service。Push service 会通过Web Push Protocol向客户端推送消息。

需要注意的是不同的浏览器会使用不同的 Push service。

如何添加 Web-push

静态站点的一个特点便是他没有后端服务器。但是 Web push 必须要一个业务服务器来调用 Push service。云服务或许是一个很好的选择。

下面这张图对比了市场上主流的 Web push notification 云服务。

如果你是学生，或许pushbots也在你的考虑范围之内。因为 Github Student pack 包含了pushbots六个月的免费使用。

综合来说我最后选择了Webpushr。主要原因有：

1. 它免费额度很多。
2. 它的通知弹窗可以自定义。不是单单只有浏览器自带的申请通知权限的小弹窗。
3. 它支持主流浏览器和 Safari。
4. 它的 Dashboard 比较清楚。

安装

接下来需要做的就是跟着官方教程，将它的 SDK 插入到网页当中。

第一步是将官方提供的webpushr-sw.js放到网站根目录中。

接着将以下代码插入到网页中就可以了。确保每一个你想要询问用户接受通知的页面都要包含以下代码。对于 hexo 用户，建议将其加入index.ejs即可。

<!-- start webpushr tracking code -->
<script>(function(w,d, s, id) {w.webpushr=w.webpushr||function(){(w.webpushr.q=w.webpushr.q||[]).push(arguments)};var js, fjs = d.getElementsByTagName(s)[0];js = d.createElement(s); js.id = id;js.src = "https://cdn.webpushr.com/app.min.js";
fjs.parentNode.appendChild(js);}(window,document, 'script', 'webpushr-jssdk'));
webpushr('init','ABCDpbdgvBCWXqXI6PtsUzobY7TLV9gwJU8bzMktrwfrSERg_xnLVbjpCw8x2GmFmi1ZcLTz0ni6OnX5MAwoK95');</script>
<!-- end webpushr tracking code -->

Safari

如果你正确安装了SDK，那么除了 Safari 的所有浏览器都是可以收到通知推送了。如果想要让 Safari 浏览器接受通知，还要多做一些步骤。

首先你需要一个苹果开发者账号，接着生成一张全新的证书就可以了。

思路看上去很简单。但是具体做起来需要 20 分钟到半个小时。详细的教程在这里。

如果你上传了证书，但是 Safari 还是没有弹窗和通知，你也不要慌。这似乎需要时间。等上个半天，再打开看看有没有生效。

Ask-for-Notification Prompt

这指的是询问读者是否要接收通知的弹窗（以下简称为弹窗）。在 Set up>Edit custom prompts 中可以对弹窗进行自定义。具体可以对标题，正文，头像和两个按钮进行自定义。

通知自定义

通知可以自定义的主要部分有标题，正文，点击时跳转的链接，以及两个按钮。

值得一提的是你可以对你的用户进行分类。对不同类别的观众进行推送。比如对于不同地区的读者，推送不同语言的通知。

总结

相信有了 Web push notification，你的站点的流量会增加。如果你的内容足够有趣，那些曾经访问过你站点的人在收到新文章的通知后，又有什么理由不点开呢？

个人站点的流量本来就很少，如果不能好好抓住那些曾经来过的人，流量的增长会十分的缓慢，甚至没有任何增长。Web push notification 就可以帮助你有效的抓住那些曾经来访的人，将他们转换为稳定的流量。未来，他们还会回来访问你的博客。

新文章发布，通知推送。这两个流程如何结合在一起？我们如何做到发布新文章，消息便自动被推送给用户？这些问题会在下一篇文章中进行讨论。

这儿是特殊解决方案。

这儿是泛用解决方案。