让我们看一看在实际操作中是什么样的。BuzzFeed 参加了 Instant Article 计划,他们最近发表了一篇名为13 steps to instantly improve your day的文章。 就跟你心里想的一样,移动 web 版本的文章也加载了一大堆垃圾,还有 iOS App 插件、社交按钮、广告、还有别的。

就像我们早先看到的 CNN 文章一样,BuzzFeed 的网站也加载了一大堆广告脚本、跟踪脚本和蕾丝的东西。最终整个页面发出了200多个 HTTP 请求,下载了差不多 4MB 的数据:

让我们与 Facebook 的 Instant Articles 做一个比较:

与之前的 Flipboard 例子比起来,尽管内容很相似,但这个 BuzzFeed 文章还是同样的繁杂异常。它同样加载得很快,而且在我的测试下,它仅仅发出了5个网络请求(Facebook 同样应用了几个预加载算法,并且在你点击之前就加载完毕了,这样确实让你感觉是『马上』完成的)

现在引发了许多关于这是不是出版商的良好商业模式的争论,这个争论确实是目前大家讨论的焦点。不过确实很难否认 Flipboard 和 Instant Articles 在移动设备上提供了非常优雅的阅读体验,这也正是之前移动浏览器急于解决的问题。
Flipboard 和 Facebook 并不是这场游戏的唯一玩家,科技界的最大玩家,也就是 Apple 公司,已经宣布进入这一领域——新发布的 Apple News 使用了 在本质上和 Flipboard 和 Instant Article 一样的商业模型。
这是 Web 的终点吗?
不。重要的是一定要记住,不管 Flipboard,Facebook 和 Apple 提供了多么好的用户体验,它们依然是独立公司提供的私有服务。这些公司可以控制内容如何被消费、也可以控制用户去访问内容。Apple 公司完全可以做到控制苹果设备访问什么内容。
再加上这些公司都要求与内容提供商的某种程度上的合作关系,也就是说这些 App 只提供了它们生态系统上的内容,也就是说这些 App 的内容只覆盖了整个 Web 内容的一小部分。由于在 Web 上出版和分享非常容易,这给 Web 提供了战胜这些 App 的巨大优势。
话虽如此,但相比 Flipboard 和 Facebook 的 Instant Articles 在其本地 APP 中提供的服务,很难说浏览器阅读体验更好。John Gruber 在一篇回应 Facebook 的 Instant Article 的文章中的论述也许是说得最好的:
我被对速度的强调吸引了。不仅仅是因为本地的移动代码在 APP 开发中获胜,更因为有了像Instant Articles 一样的软件,本地正在将以浏览器为基础的网络变得像一个遗迹,即使这个网络只是为了发布文章。如果我是对的,我在 Daring Fireball 中写的绝大多数文本(overwhelmingly-text)都可能会引发一个问题。Daring Fireball 的页面加载速度快,但这些页面我并不需要经常去连接它们。我担心这会继承 web 速度慢的问题,对过量产生网页的这种考虑不周的设计趋势,将会开始对 DF 的流量造成危害。
需要采取什么措施吗?
一些发展应该会对当前 Web 的发展现状有所帮助。
HTTP/2
最近出版的 HTTP/2 规范提供以基本上减少通过单一的 TCP 连接,供应压缩的 HTTP 标头,和资源加载并联在网络上的延迟。一旦在浏览器中实现,HTTP/2 显着降低依赖于大量的 HTTP 请求,如本文中所示的那些部位的加载时间。
最近出版的 HTTP/2 规范提供了一个从实质上减少网络服务延迟的方法 - 压缩 HTTP 头,并使用单个 TCP 连接实现并行加载资源。一旦 HTTP/2 在浏览器中得以实现,它将会显著降低那些依赖大量 HTTP 请求的网站的加载次数,例如本文前面部分已经展示的一些情况。
移动友好
去年,谷歌宣布他们将会在搜索结果中惩罚那些移动不友好的站点,并会在那些满足他们搜索指南中要求的站点旁边添加“移动友好”字样。

这是一个小调整,却可以刺激那些站点内容的开发者和发布者们(这些人的工作与搜索引擎的流量的关联性非常高),将他们厌恶的内容控制在最低限度。早期的研究表明,这个做法看上去对搜索结果有着显著的影响。
代理浏览器
Opera Mini 长久以来一直成功地饰演着代理浏览器的角色,它通过在自己的服务器上缓存资源来减少要发送给每一台单个设备的数据量。安卓下的 Chrome 和 iOS 现在包含了一个相似的选项,尽管它们默认情况下都是关闭的,在用户需要提升自己网络速度时仍这个选项不失为一个选择。
广告拦截器
桌面设备上,许多广告拦截器是攻击网络的主要工具,但是他们还没有进入用户的移动手机,很大程度上市因为手机系统供应商很积极的预防它们。
Google 有一个很好的理由去阻止广告拦截器,因为他们80%-90%的收入来自在线广告。新闻说 Google早在 2013 年之前广告拦截器从 Google play 中删除了。
从历史上看,苹果也阻止过广告拦截器,但是即将改变。苹果最近发表新闻,他们将要在 IOS 9 上的Safari 浏览器中开放广告拦截器 API。不管这个是否是对 Google 的攻击,还是一种对 Safari 用户的友好姿态,最终都是减少 IOS 用户繁琐的去选择广告拦截器应用。
将来
尽管有种种的缺陷,我仍然认为在浏览器领域是成熟的创新。为什么文章的出版商真正的盈利是植入庞大的广告而给每个人产生了很糟糕的体验?
我没有答案,比我更聪明的人花费了很多年的时间去解决这个问题。不过,似乎这是最好的,我们可以做的疯狂事情。我仍然认为在开放的网络中,它不会很快的遍布任何地方,但是我们真的需要开始思考怎么去清理这个烂摊子。
标题图片由Steven Depolo提供