使用预呈现优化浏览
目前为止我们介绍过的每一项优化都是帮助减少用户进行浏览的直接请求和标签页上呈现最终页面之间的延迟的。但是,要真正得到即刻展示页面的体验,需要什么呢?根据我们之前看到的UX数据,这样的交互时间需要低于100毫秒,这样,留给网络延迟的余地可不算多。我们怎么才能在100毫秒内把呈现好的页面展示出来呢?
当然,你已经知道答案了,因为这是很多用户所用的共同模式:如果你打开多个标签页,标签页间的切换就是即刻的,比在一个前景标签页中浏览同样资源之间的等待要快得多。那么,如果浏览器提供一个API来实现这一点呢?
![]()
你可能猜到了,这就是Chrome中的预呈现。不是如“预获取”提示实现的那样只下载单项资源,“预呈现”属性命令Chrome在隐藏标签页中预呈现页面以及所有子资源。隐藏标签页本身对用户不可见,但当用户触发浏览行为时,该标签页就会从后台切换出来实现“即刻体验”。
想看看这是如何实现的吗?可以访问prerender-test.appspot.com上还在开发中的演示版,要查看你的profile的预呈现页面的历史记录和状态,访问:chrome://net-internals/#prerender。(见图1.11)

图1.11 当前profile的预呈现页面
可以预见的是,在隐藏标签页中呈现完整页面可能会耗费CPU和网络的大量资源,所以仅当我们高度确信应该使用隐藏标签页时才应该使用。例如,当你使用Omnibox时,对高度确信的建议可能会触发预呈现。类似地,Google搜索如果估计认为它的第一条检索结果是高度确信的目标站点,有时会在其标记中添加预呈现提示(也称为Google即开页面)。
你还可以为自己的站点添加预呈现提示。在你这样做之前,请先了解并记住预呈现过程具有的以下局限之处:
所有线程总共至多只能有一个预呈现标签页
HTTPS和需要HTTP身份鉴证的页面不能使用
如果所请求资源或其任何子资源需要进行非幂等请求(只允许GET请求),预呈现会被放弃
所有资源都以最低的网络优先级进行获取
该页面以最低的CPU优先级进行呈现
如果内存需求超过100MB则该页面会被放弃
插件初始化被推迟,如果出现了HTML5的多媒体元素则预呈现被放弃
换言之,预呈现不保证一定发生,并只适用于安全的页面。此外,因为JavaScript和其他逻辑可能在隐藏页面中被执行,实践中最好使用页面可见性API来检测一下该页面是否可见——这是你本就应该做的。
Chrome会随着你的使用越来越快
无需多言,Chrome的网络栈绝非一个简单的socket管理器。我们这次走马观花的概述介绍了在网站浏览的背后多层次的透明运行的优化手段。Chrome对网站拓扑结构和你的浏览模式了解越是深入,它的效果就越好。就像魔法一样,Chrome会随着你的使用越来越快。可你知道它并不是魔法,你了解这背后的机制。
最后,还要注意一点,Chrome团队持续试验着优化性能的新想法——这个过程从未停止。在你阅读本文时,就可能有新的试验项目和优化手段正在开发、测试或部署着。也许只有当我们能够对每个站点每个页面都实现即刻加载(小于100毫秒)时,才会停下脚步吧。在那之前,总有工作等着我们去完成。
注释:
第10章:《移动网络性能的秘密》详细解释了这个问题。
如果你感兴趣,Chromium的百科页面上有详细的介绍。
Http://code.google.com/searchframe#OAMlx_jo-ck/src/content/public/browser/resource_dispatcher_host.h&exact_package=chromium&q=ResourceDispatcherHost.
16KB以内的资源保存在共享数据块文件中,更大的文件在磁盘上有自己的专用文件。
英文原文:http://aosabook.org/en/posa/high-performance-networking-in-chrome.html
译者:unione
转载:http://www.toutiao.com/i6307361226703766018/
相关文章
网友评论(共有 0 条评论)