|
|
51CTO旗下网站
|
|
移动端

HTML 5可见性API以及页面预渲染

页面可见性API是第一个针对这个问题的HTML5提案,再加上浏览器的预渲染功能也试图帮助我们减少Web应用的网络延迟——下面就让我们来一探究竟吧!

作者:YUANYI来源:黑客志|2011-07-29 11:04

不管是桌面还是Web,减少UI延迟一直是增强用户体验的关键。对于原生应用来说,减少延迟的最佳办法就是解耦UI和控制线程,以避免耗时任务造成UI阻塞,而对于Web,情况有点不同:因为我们的Javascript运行时都是单线程的,我们没法借助额外的线程来降低延迟,而不得不依赖事件驱动的编程模型,甚至更糟,即使运算是在本地进行的,同服务器的一次交互也可以很轻易的就消耗掉几百毫秒。

没什么好吃惊的,过去几年我们发明了无数的Javascript UI框架,全都是异步的,全部把精力放在如何降低交互延迟。理论上,这些点子都不错,但是在实际应用中,他们都有各自的副作用,比如这些#!,我想大家一定都写过这种快速消耗客户端CPU及电池寿命的setTimeout代码。

实际上,因为浏览器的虚拟机是一个共享资源,我们都不可避免的要遭遇这样的问题:如果所有应用都融洽相处,那么大家都可以得到最佳体验,但是我们并没有足够的动力去这么做。并且问题是,直到最近我们甚至都没有一个针对这个问题的工具!页面可见性API是第一个针对这个问题的HTML5提案,再加上浏览器的预渲染功能也试图帮助我们减少Web应用的网络延迟——下面就让我们来一探究竟吧!

浏览器预读取 vs 预渲染

渲染一个页面除了页面本身的HTML内容,往往还需要获取几十个额外的资源,如果你看看你的浏览器的debug控制台,就会发现一个页面花10几秒完成渲染是司空见惯的事情,幸运的是,浏览器已经为我们提供了一些手段来让读取更加快速——并行下载,高度优化的渲染引擎,以及对于Javascript执行速度永无停歇的优化,但不管怎么说,这些都还不足以击败“原生体验”。

另外,服务器也可以帮到我们:像SPDY这样的新协议就致力于减少抓取多个资源的网络延迟,并且甚至还可以让服务端自动推送相关的页面资源。但是让我们想想如果你知道用户下一步要点击什么页面,我们是不是可以做点什么?Firefox 3.5就提供了一个预读取API让我们可以通知浏览器预先抓取后续请求可能会用到的资源:

  1. <!--  Specify any & all resources to pre-fetch --> 
  2. <link rel="prefetch" href="/images/big.jpg"> 
  3.  
  4. <!-- or send an HTTP header --> 
  5. Link: </images/big.jpeg>rel=prefetch 

预读取是一个很简单的优化,但是它需要你明确的指定每一个单独的资源,而不是简单的列出下一个可能的被访问的URL,所以很难在用户体验上带来大的改善。

而预渲染就可以很好的解决这个问题:同预读取相比,预渲染不需要指定单个资源,取而代之,浏览器会抓取下一个请求的整个页面并进行预渲染,并且直到你点击那个链接,这个页面都是不可见的,大约1个月前,Webkit已经增加了对预渲染的支持,并且Google也已经发布了Instant Pages的原型(视频需翻墙):

预渲染的利与弊

就目前来看,预渲染API还存在很大的限制:整个浏览器只能预渲染一个页面,并且每个tab只能向预渲染队列中加入一个页面,并且,预加载整个页面也会增加服务器和客户端的负担,因此你需要确定你真的需要它,举个例子,对于Google Web搜索来说,它的搜索结果页就可以用到预渲染,因为他们可以非常确信你有很大的概率会点击排名第一的搜索结果。

另外,因为我们现在是预先渲染整个页面(HTML,CSS以及JS),这也会对页面上的交互性内容造成影响,如果你的页面对预渲染一无所知,预先加载的页面可能会白白的浪费我们的CPU,比如向广告服务器发送请求轮换广告页面,而用户实际上根本就看不到这些广告,为了解决这个问题,Webkit也增加了页面可见性API:

  1. function handleVisibilityChange(){  
  2.   if(document.webkitHidden){  
  3.     pausePageJavascript();  
  4.   }else{  
  5.     startPageJavascript();  
  6.   }}  
  7.  
  8. document.addEventListener("webkitvisibilitychange", handleVisibilityChange, false); 

webkitHidden属性告诉我们当前页面的状态,这就解决了可见性的问题,并且webkitvisibilitychange事件还为我们提供了另外一个可能:客户端可以很简单的通过这个事件判断当前页面所在tab是否在后台运行,这有什么用呢?想象你的程序如果需要定期轮询服务器去获取更新,有了可见性API,当你的页面进入后台运行时,你就可以很容易的暂停或是降低定时器的触发频率,从而节省客户端和服务器的资源。

最小化网络延迟

预读取以及可见性API都还在开发中,但我们还是很高兴看到有越来越多的客户端工具来帮助web开发者降低网络延迟带来的影响,有了这些API,我们就不需要再依赖异步Javascript,如果你有一个多页面的表单,你就可以在webkit中预先渲染下一页的表单,让客户端可以得到实时响应。

尽管像Chrome这样的浏览器已经对后台运行的Tab做了CPU降权处理,但有个客户端API可以判断程序是在前台还是后台运行总是会有好处,让我们期待Firefox,Opera以及IE也尽快增加这个功能吧!

原文:http://heikezhi.com/2011/07/06/html5-visibility-api-page-pre-rendering/

【编辑推荐】

  1. 13个强大的基于HTML 5的Web应用
  2. 我们离HTML 5还有多远?
  3. HTML 5和CSS3表单示例和详细教程汇总
  4. HTML 5华丽丽的新特性
  5. 29个非常实用的HTML 5实例、教程和技巧
【责任编辑:陈贻新 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

Redis运维秘籍

Redis运维秘籍

运维标配技术
共15章 | one叶孤舟

57人订阅学习

活学活用 Ubuntu Server

活学活用 Ubuntu Server

实战直通车
共35章 | UbuntuServer

235人订阅学习

Java EE速成指南

Java EE速成指南

掌握Java核心
共30章 | 51CTO王波

89人订阅学习

读 书 +更多

非常网管——网络服务

本书使用通俗易懂的语言,通过大量的实例,从实际应用的角度出发,全面系统地介绍了网络服务操作系统平台、电子邮件系统、Web站点和FTP站点...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO播客