在多页应用中，每一个路由本来就只会请求这个路由所需要的资源，并且通常依赖也都比较扁平。饿了么移动站的大部分脚本依赖都是普通的 元素，因此他们可以在文档解析早期就被浏览器的preloader扫描出来并且开始请求，其效果其实与显式的是一致的，见图1所示。
图1 有无 的效果对比
我们还将所有关键的静态资源都伺服在同一域名下（不再做域名散列），以更好地利用HTTP2带来的多路复用（Multiplexing）。同时，我们也在进行着对API进行Server Push的实验。
Render，渲染初始路由，尽快让应用可被交互
既然所有初始路由的依赖都已经就绪，我们就可以尽快开始初始路由的渲染，这有助于提升应用诸如首次渲染时间、可交互时间等指标。多页应用并不使用基于JavaScript的路由，而是传统的HTML跳转机制，所以对于这一部分，多页应用其实不用额外做什么。
Precache，用Service Worker预缓存剩下的路由
这一部分就需要Service Worker的参与了。Service Worker是一个位于浏览器与网络之间的客户端代理，它已可拦截、处理、响应流经的HTTP请求，使得开发者得以从缓存中向Web应用提供资源而闻名。不过， Service Worker其实也可以主动发起 HTTP 请求，在“后台”预请求与预缓存我们未来所需要的资源，见图2所示。
图2 Service Worker预缓存未来所需要的资源
我们已经使用Webpack在构建过程中进行.vue编译、文件名哈希等工作，于是我们编写了一个Webpack插件来帮助收集需要缓存的依赖到一个“预缓存清单”中，并使用这个清单在每次构建时生成新的Service Worker文件。在新的Service Worker被激活时，清单里的资源就会被请求与缓存，这其实与SW-Precache 这个库的运行机制非常接近。
实际上，我们只对标记为“关键路由”的路由进行依赖收集。你可以将这些“关键路由”的依赖理解为我们整个应用的"App Shell" 或者说“安装包”。一旦它们都被缓存，或者说成功安装，无论用户是在线离线，我们的Web应用都可以从缓存中直接启动。对于那些并不那么重要的路由，我们则采取在运行时增量缓存的方式。我们使用的SW-Toolbox提供了LRU替换策略与TTL失效机制，可以保证我们的应用不会超过浏览器的缓存配额。
Lazy-Load，按需懒加载、懒实例化剩下的路由
懒加载与懒实例化剩下的路由对于SPA是一件相对麻烦点儿的事情，你需要实现基于路由的code splitting与异步加载。幸运的是，这又是一件不需要多页应用担心的事情，多页应用中的各个路由天生就是分离的。
值得说明的是，无论单页还是多页应用，如果在上一步中，我们已经将这些路由的资源都预先下载与缓存好了，那么懒加载就几乎是瞬时完成的了，这时候我们就只需要付出实例化的代价。
至此，我们对PRPL的四部分含义做了详细说明。有趣的是，我们发现多页应用在实现PRPL这件事甚至比单页还要容易一些。那么结果如何呢？
根据Google推出的Web性能分析工具Lighthouse（v1.6），在模拟的3G网络下，用户的初次访问（无任何缓存）大约在2秒左右达到“可交互”，可以说非常不错，见图3所示。而对于再次访问，由于所有资源都直接来自于Service Worker缓存，页面可以在1秒左右就达到可交互的状态了。
图3 Lighthouse跑分结果
但是，故事并不是这么简单得就结束了。在实际体验中我们发现，应用在页与页的切换时，仍然存在着非常明显的白屏空隙，见图4所示。由于PWA是全屏运行，白屏对用户体验所带来的负面影响甚至比以往在浏览器内更大。我们不是已经用Service Worker缓存了所有资源了吗，怎么还会这样呢？
图4 从首页点击到发现页，跳转过程中的白屏
多页应用的陷阱：重启开销
与SPA不同，在多页应用中，路由的切换是原生的浏览器文档跳转（Navigating across documents），这意味着之前的页面会被完全丢弃而浏览器需要为下一个路由的页面重新执行所有的启动步骤：重新下载资源、重新解析HTML、重新运行JavaScript、重新解码图片、重新布局页面、重新绘制……即使其中的很多步骤本是可以在多个路由之间复用的。这些工作无疑将产生巨大的计算开销，也因此需要付出相当多的时间成本。
图5中为我们的入口页（同时也是最重要的页面）在两倍CPU节流模拟下的Profile数据。即使我们可以将“可交互时间”控制在 1 秒左右，我们的用户仍然会觉得这对于“仅仅切换个标签”来说实在是太慢了。
图5 入口页在两倍CPU节流模拟下的Profile数据
巨大的JavaScript重启开销
根据Profile，我们发现在首次渲染（First Paint）发生之前，大量的时间（900ms）都消耗在了JavaScript的运行上（Evaluate Script）。几乎所有脚本都是阻塞的（Parser-blocking），不过因为所有的UI都是由JavaScript/Vue.js驱动的，倒也不会有性能影响。这900ms中，约一半是消耗在Vue.js运行时、组件、库等依赖的运行上，而另一半则花在了业务组件实例化时Vue.js的启动与渲染上。从软件工程角度来说，我们需要这些抽象，所以这里并不是想责怪JavaScript或是Vue.js所带来的开销。
但是，在SPA中， JavaScript的启动成本是均摊到整个生命周期的：每个脚本都只需要被解析与编译一次，诸如生成Virtual DOM等较重的任务可以只执行一次，像Vue.js的ViewModel或是Virtual DOM这样的大对象也可以被留在内存里复用。可惜在多页应用里就不是这样了，我们每次切换页面都为JavaScript付出了巨大的重启代价。
浏览器的缓存啊，能不能帮帮忙？
能，也不能。
V8提供了代码缓存（code caching），可以将编译后的机器码在本地拷贝一份，这样我们就可以在下次请求同一个脚本时一次省略掉请求、解析、编译的所有工作。而且，对于缓存在Service Worker配套的Cache Storage中的脚本，会在第一次执行后就触发V8的代码缓存，这对于我们的多页切换能提供不少帮助。
另外一个你或许听过的浏览器缓存叫做“进退缓存”， Back-Forward Cache，简称bfcache。浏览器厂商对其的命名各异， Opera称之为Fast History Navigation， Webkit称其为Page Cache。但是思路都一样，就是我们可以让浏览器在跳转时把前一页留存在内存中，保留JavaScript与DOM的状态，而不是全都销毁掉。你可以随便找个传统的多页网站在iOS Safari上试试，无论是通过浏览器的前 进后退按钮、手势，还是通过超链接（会有一些不同），基本都可以看到瞬间加载的效果。
Bfcache其实非常适合多页应用。但不幸的是，Chrome由于内存开销与其多进程架构等原因目前并不支持。 Chrome现阶段仅仅只是用了传统的HTTP磁盘缓存，来稍稍简化了一下加载过程而已。对于Chromium内核霸占的Android生态来说，我们没法指望了。
03
为“感知体验”奋斗
尽管多页应用面临着现实中的不少性能问题，我们并不想这么快就妥协。一方面，我们尝试尽可能减少在页面达到可交互时间前的代码执行量，比如减少/推迟一些依赖脚本的执行，还有减少初次渲染的DOM节点数以节省Virtual DOM的初始化开销。另一方面，我们也意识到应用在感知体验上还有更多的优化空间。
Chrome产品经理Owen写过一篇Reactive Web Design: The secret to building web apps that feel amazing，谈到两种改进感知体验的手段：一是使用骨架屏（Skeleton Screen）来实现瞬间加载；二是预先定义好元素的尺寸来保证加载的稳定。跟我们的做法可以说不谋而合。
为了消除白屏时间，我们同样引入了尺寸稳定的骨架屏来帮助我们实现瞬间的加载与占位。即使是在硬件很弱的设备上，我们也可以在点击切换标签后立刻渲染出目标路由的骨架屏，以保证UI是稳定、连续、有响应的。我录了两个视频放在Youtube上，不过如果你是国内读者，你可以直接访问饿了么移动网站来体验实地的效果。最终效果如图6所示。
图6 在添加骨架屏后，从发现页点回首页的效果
这效果本该很轻松的就能实现，不过实际上我们还费了点功夫。
在构建时使用 Vue 预渲染骨架屏
你可能已经想到了，为了让骨架屏可以被Service Worker缓存，瞬间加载并独立于JavaScript渲染，我们需要把组成骨架屏的HTML标签、 CSS样式与图片资源一并内联至各个路由的静态*.html文件中。
不过，我们并不准备手动编写这些骨架屏。你想啊，如果每次真实组件有迭代（每一个路由对我们来说都是一个Vue.js组件），我们都需要手动去同步每一个变化到骨架屏的话，那实在是太繁琐且难以维护了。好在，骨架屏不过是当数据还未加载进来前，页面的一个空白版本而已。如果我们能将骨架屏实现为真实组件的一个特殊状态——“空状态”的话，从理论上就可以从真实组件中直接渲染出骨架屏来。
而Vue.js的多才多艺就在这时体现出来了，我们真的可以用Vue.js 的服务端渲染模块来实现这个想法，不过不是用在真正的服务器上，而是在构建时用它把组件的空状态预先渲染成字符串并注入到HTML模板中。你需要调整Vue.js组件代码使得它可以在Node上执行，有些页面对DOM/BOM的依赖一时无法轻易去除得，我们目前只好额外编写一个*.shell.vue来暂时绕过这个问题。
关于浏览器的绘制（Painting）
HTML文件中有标签并不意味着这些标签就能立刻被绘制到屏幕上，你必须保证页面的关键渲染路径是为此优化的。很多开发者相信将Script标签放在body的底部就足以保证内容能在脚本执行之前被绘制，这对于能渲染不完整DOM树的浏览器（比如桌面浏览器常见的流式渲染）来说可能是成立的。但移动端的浏览器很可能因为考虑到较慢的硬件、电量消耗等因素并不这么做。不仅如此，即使你曾被告知设为async或defer的脚本就不会阻塞HTML解析了，但这可不意味着浏览 器就一定会在执行它们之前进行渲染。
首先我想澄清的是，根据 HTML 规范 Scripting 章节， async脚本是在其请求完成后立刻运行的，因此它本来就可能阻塞到解析。只有defer（且非内联）与最新的type=module被指定为“一定不会阻塞解析”（不过defer目前也有点小问题……我们稍后会再提到），见图7所示。
图7 具有不同属性的Script脚本对HTML解析的阻塞情况
而更重要的是，一个不阻塞HTML解析的脚本仍然可能阻塞到绘制。我做了一个简化的“最小多页PWA”（Minimal Multi-page PWA，或MMPWA）来测试这个问题：我们在一个async（且确实不阻塞HTML解析）脚本中，生成并渲染1000个列表项，然后测试骨架屏能否在脚本执行之前渲染出来。图8是通过USB Debugging在我的Nexus 5真机上录制的Profile。
图8 通过USB Debugging在Nexus 5真机上录制的Profile
是的，出乎意料吗？首次渲染确实被阻塞到脚本执行结束后才发生。究其原因，如果我们在浏览器还未完成上一次绘制工作之前就过快得进行了DOM操作，我们亲爱的浏览器就只好抛弃所有它已经完成的像素，且一直要等待到DOM操作引起的所有工作结束之后才能重新进行下一次渲染。而这种情况更容易在拥有较慢CPU/GPU的移动设备上出现。
黑魔法：利用setTimeout()让绘制提前
不难发现，骨架屏的绘制与脚本执行实际是一个竞态。大概是Vue.js太快了，我们的骨架屏还是有非常大的概率绘制不出来。于是我们想着如何能让脚本执行慢点，或者说，“懒”点。于是我们想到了一个经典的Hack： setTimeout(callback, 0)。我们试着把MMPWA中的DOM操作（渲染1000个列表）放进setTimeout(callback, 0)里……
当当！首次渲染瞬间就被提前了，见图9所示。如果你熟悉浏览器的事件循环模型（Event Loop）的话，这招Hack其实是通过setTimeout的回调把DOM操作放到了事件循环的任务队列中以避免它在当前循环执行，这样浏览器就得以在主线程空闲时喘息一下（更新一下渲染）了。如果你想亲手试试 MMPWA的话，你可以访问github.com/Huxpro/mmpwa 或 huangxuan.me/mmpwa/ ，查看代码与Demo。我把UI设计成了A/B Test的形式并改为渲染5000个列表项来让效果 更夸张一些。
图9 利用Hack技术，提前完成骨架屏的绘制
回到饿了么PWA上，我们同样试着把new Vue()放到了setTimeout中。果然，黑魔法再次显灵，骨架屏在每次跳转后都能立刻被渲染。这时的Profile看起来是这样的，见图10所示。
图10 为感知体验进行各种优化后的最终Profile
现在，我们在400ms时触发首次渲染（骨架屏），在600ms时完成真实UI的渲染并达到页面的可交互。你可以详细对比下图9和图10所示的优化前后Profile的区别。
被我“defer”的有关defer的Bug
不知道你发现没有，在图10的Profile中，我们仍然有不少脚本是阻塞了HTML解析的。好吧，让我解释一下，由于历史原因，我们确实保留了一部分的阻塞脚本，比如侵入性很强的lib-flexible，我们没法轻易去除它。不过， Profile里的大部分阻塞脚本实际上都设置了defer，我们本以为他们应该在HTML解析完成之后才被执行，结果被Profile打了一脸。
我和Jake Archibald 聊了一下，果然这是Chrome的Bug： defer的脚本被完全缓存时，并没有遵守规范等待解析结束，反而阻塞了解析与渲染。Jake已经提交在crbug上了，一起给它投票吧。
最后，图11是优化后的Lighthouse跑分结果，同样可以看到明显的性能提升。需要说明的是，能影响Lighthouse跑分的因素有很多，所以我建议你以控制变量（跑分用的设备、跑分时的网络环境等）的方式来进行对照实验。
图11 优化后的Lighthouse跑分结果
最后为大家展示下应用的架构示意图，见图12所示。
图12 应用架构示意图
04
一些感想
多页应用仍然有很长的路要走
Web是一个极其多样化的平台。从静态的博客，到电商网站，再到桌面级的生产力软件，它们全都是Web这个大家庭的第一公民。而我们组织Web应用的方式，也同样只会更多而不会更少：多页、单页、 Universal JavaScript应用、 WebGL，以及可以预见的Web Assembly。不同的技术之间没有贵贱，但是适用场景的差距确是客观存在的。
Jake 曾在 Chrome Dev Summit 2016 上说过“PWA!== SPA”。可是尽管我们已经用上了一系列最新的技术（PRPL、 Service Worker、 App Shell……），我们仍然因为多页应用模型本身的缺陷有着难以逾越的一些障碍。多页应用在未来可能会有“bfcache API”、 Navigation Transition等新的规范以缩小跟SPA的距离，不过我们也必须承认，时至今日，多页应用的局限性也是非常明显的。
而PWA终将带领Web应用进入新的时代
即使我们的多页应用在升级PWA的路上不如单页应用来得那么闪亮，但是PWA背后的想法与技术却实实在在地帮助我们在Web平台上提供了更好的用户体验。
PWA作为下一代 Web 应用模型，其尝试解决的是Web平台本身的根本性问题：对网络与浏览器UI的硬依赖。因此，任何Web应用都可以从中获益，这与你是多页还是单页、面向桌面还是移动端、是用React还是Vue.js无关。或许，它还终将改变用户对移动Web的期待。现如今，谁还觉得桌面端的Web只是个看文档的地方呢？
还是那句老话，让我们的用户，也像我们这般热爱Web吧。
最后，感谢饿了么的王亦斯、任光辉、题叶，Google 的 Michael Yeung、 DevRel 团队， UC浏览器团队，腾讯X5浏览器团队在这次项目中的合作。感谢尤雨溪、陈蒙迪和Jake Archibald 在写作过程中给予我的帮助。
网友评论