翻译 | Progressive Web AMPs

小萝卜（沪江前端开发工程师）
本文原创翻译，有不当的地方欢迎指出。转载请指明出处。

若是你在过去几个月一直关注web开发社区，你极可能已经阅读了 progressive web apps,下面简称PWAs （中文有译做渐进式web应用）.它是一个术语，统称那些拥有离线支持， 可安装，“Retina”，满屏显示，个性化支持，流畅的浏览效果，推送通知和强大的UI等能够和原生媲美的web应用。

https://www.smashingmagazine....

这是一些谷歌Progressive Web APPs示范
虽然当你网站一加载，Service Work API就会帮你缓存全部网站资源，但就像你初次见一我的第一眼印象很重要，最新DoubleClick study的数据代表，若是首次加载花费的时间超过3秒，超过53%的用户会离开。

3秒，在现实中是一个很是残酷的目标。移动端链接，平均有300毫秒的延迟，还受制于带宽、弱信号，因此实际上你只有不到1秒的时间去下载你app所须要初始化所须要的资源。

以上显示了用户请求的延时

固然，咱们有办法去减小首次加载的时间，好比服务端预渲染基本布局、按需懒加载等等，可是咱们能作到的是有限的，还必须专门有我的去作性能优化。因此，既要迅速加载又要有原生的体验，咱们该怎样作？
AMP, For Accelerated Mobile Pages

https://codelabs.developers.g...

网站一个巨大的优点在于无摩擦的入口——它不须要安装，用户老是只需点击一下便可当即加载。

为了享受这么轻松、瞬间的浏览体验，你全部要作的是让你的网站跑的飞快，可是如何让你的网站跑到飞快？咱们能够适当的减小开销，没有兆级别容量的图片，没有阻塞渲染的广告，不超过10万行的js代码，全部的只是纯内容的展现。

Accelerated Mobile Pages, 简称AMPs, 就很是擅长作这些，事实这也是它们的宗旨。经过它精心设计的规则能保证优先显示页面的主要内容。经过建立要严格的静态布局，它能使平台像google Search经过首屏预加载达到瞬间加载的效果。

https://www.ampproject.org/
https://www.ampproject.org/le...
https://www.ampproject.org/le...

这个AMP 的hero image 和 headline会预加载， 以保证用户能够立马看到它
AMP 仍是 PWA?

为了快速加载你引入了AMP， 但你引入AMP的同时你不少功能会受限。AMP并不适用一些高级的功能 好比通知推送，网页支付或者一切须要引入其它js的功能。以及由于AMP的页面是受AMP Cache控制的，你享受不到PWA的的优点，由于你本身的Service Worker不能运行。另外一方面PWA并不能像AMP在第一次加载那么快，而且能安全且容易的嵌入。

因此AMP仍是渐进式的app？是一次性加载仍是选择性的加载，是最新的平台特性仍是轻巧的应用代码？咱们是否是有可能结合二者，综合两个的好处？
PWAMP 结合模式

你能够经过如下方式结合AMPs和progressive web apps

• AMP AS PWA

当你能接受AMP的局限性

• AMP TO PWA

当你但愿在二者之间无缝过分

• AMP IN PWA

当你但愿AMP做为一个资源在你的PWA里面可复用, 如今让咱们来单独的谈谈它们。

AMP AS PWA

不少网站在AMPs范围不须要别的功能。例如，Amp by Example既是一个AMP APP，也是PWA APP。

https://ampbyexample.com/

• 它有一个service worker，所以它容许离线访问等。

• 它有一个manifest，因此支持“添加到主屏幕”。

当用户在google search页面点击Amp by Example，而后点击该网站上的另外一个连接时，他们将脱离AMP Cache去远程拉数据。网站仍然使用AMP库，固然，可是由于它依赖远程，因此它可使用service worker，而后安装及激活等等。

你可使用此技术让你的AMP网站支持离线访问，而后在线时及时更新你的网页，由于在线时您能够经过service workor的fetch事件修改响应，返回你想要返回的内容：

AMP TO PWA

若是上面的不能知足你，你须要非凡的PWA体验围绕你的内容，这是你能够考虑为高级的模式

• 全部的内容子页面（那些指定的内容，不是全局的页面）做为AMP发布，享受当即加载

• 这些AMP页面用AMP特定的元素<amp-install-serviceworker>在用户阅读你内容的时候为缓存和PWA脚本作准备

• 当用户点击你网站的另一个连接（好比唤起相似原生app的操做），这时候service worker截取请求，接管页面控制权加载PWA脚本

你能够实施这三部，若是你熟悉Service Works的是怎样运行的（若是你不熟悉，我强烈推荐你阅读我同事 Jake’s Udacity 的课程）。

https://www.udacity.com/cours...

首先在你全部AMP引入入Service Worker.

第二步， 在Service Worker安装事件中，缓存PWA须要的全部数据

最后， 仍是在Service Worker里面， 用返回PWA取代原有的AMP导航请求
（下面的代码只是为了展现原理因此简化了，高级的例子在最后的Demo里）

如今，当用户在你从AMP Cache返回的页面里面点击一个连接，Service Worker会注册这个navigate 请求而后接管， 变成一个彻底成型的已经缓存的PWA。

这个技术有意思的在于它是渐进加强的从AMP转变成PWA. 这也意味着，若是你的浏览器不支持Service Worker，它将不会被导航到PWA, 而是AMP跳AMP
AMP经过shell url rewriting实现这种渐进加强。经过在<amp-install-serviceworker>添加一个回调属性， 若是检测到不支持Service Worker，AMP会用shell Url重写全部匹配全部链接，全部的后续的点击再也不会导航到PWA.

https://www.ampproject.org/do...

AMP IN PWA

在此模式中，用户已经在一个渐进式的app里面了，你正好用AJAX获取获取数据，可是你的真实需求是获得两种后端返回的数据，一种是AMP内容，另外一种是你Progressive Web App所须要的JSON格式数据。

固然，一种简单方式是在iframes里面加载 AMP内容。可是iframe比较慢，并且你须要一次又一次从新编译和从新初始化AMP Library。今天cutting-edge 技术提供一个更好的办法: shadow-dom

AMP 能够安全的被嵌入其余网站， mp liabrary在整个PWA只会被编译和加载一次。

整个过程是这样

1. PWA劫持任何导航点击

2. 而后它发一个XMLHttpRequest 去fetch AMP页面

3. 拉到后它把内容放到一个新的shadow root

4. 而后它通知 main AMP Library， “这里有个新的document，请检查”(运行的时候叫 attachShadowDoc)

用这个技术，AMP Library在PWA只编译和加载一次，它会响应每一个你绑定的shadow document。而且由于你是经过XMLHttpRequests去fetch页面，你能够在插入到新的 shadow document以前更改AMP 资源。打个比方你能够用来:

• 过滤掉不须要的信息，好比headers 和footers

• 插入额外的内容， 好比广告和工具

• 用更动态的内容替换某些内容

如今你把你的渐进式Web APP变得稍微复杂点了，你能够减轻后端的复杂度。

准备好了，走你~

为了阐述 shadow dom的这个方法（PWA包含AMP）,AMP团队已经制做了React-based demo called The Scenic, ---- 一个虚拟的旅游杂志.

这个Demo在GitHub

https://github.com/ampproject...

来点干货

咱们看看 Mic’s new PWA（in beta）这个以及上线的例子： 若是你强刷任意一个页面（会暂时忽略Service Worker），而后你看你请求返回的结果，你会发现是AMP页面资源。如今你单价“hamburger menu”： 它会从新加载当前页面，然而由于<amp-install-serviceworker>已经加载在PWA app shell， 这个从新加载几乎是瞬间的，菜单在刷新后打开，看上去好像根本没有刷新过。

https://beta.mic.com/

最后的想法

我对这种新的结合方式很兴奋，这种结合带来了它们各自的好处, 再强调下：

• 老是很快

• 内置大型分布（经过AMP平台套件）渐进式加强

• 一种后端返回规则

• 减小客户端的复杂程度

• 更少的总体投入

可是咱们只是探索了不一样方式的差别，打造2016年及将来的最好的Web体验还仍需努力，为开辟Web新篇章继续前行。

iKcamp原创新书《移动Web前端高效开发实战》已在亚马逊、京东、当当开售。