您所在的位置:主页 > 网络营销 > Web2.0 > 正文
文字大小:

Web前端技术趋势:HTML5仍不宜用作生产

Pandor Cai博客 Pandor Cai 2010-12-13 11:10 次阅读

    经过这段时间国内(百度,淘宝,新浪)及国外(Facebook,Youtube,Yahoo)各大公司的集中自曝,我们可以从中总结出2010 Web前端技术的一些趋势。总的来说,随着后端技术(存储,并发,分布式)的成熟,各大公司已经把重点从后端架构调整/建设转移至前端(TTI时间,快速发布,带宽利用率)。但作为明星技术的HTML5/CSS3,都未正式成为各公司的考虑重心,虽有所尝试,但在关键功能上,均未成为主力。这也W3C对当前HTML5/CSS3标准现状的表述:“不适宜用作生产环境”一致。
  基本概念
  Web前端技术的范围
  1. 编程语言/技术(HTML,JavaScript,CSS等)
  2. 跨浏览器兼容性/支持(JS Framework,CSS Library)
  3. 网络传输性能(并行下载,带宽利用率)
  4. 浏览器渲染时间/性能(TTI即用户可交互前等待时间,JS执行性能)
  今年就我个人的感觉,Facebook无疑又成为了技术上的明星,在大家还在感慨其对于PHP的重大改进HipHop(Blocked inside China mainland)的时候,今年Facebook又在前端技术方面给大家带来了惊喜。
  Facebook面临的问题
  500M(Million)注册用户,50%每天至少访问一次,用户平均每日在线时间为5小时25分钟。带宽及服务器压力均很大。
  Facebook的解决方案
  Quickling
  Facebook提出了一个新名词Ajaxify,顾名思义,就是将传统的POST/GET转换为Ajax请求。优点显而易见,首先减少了不必要的HTML传输,只请求和渲染页面需要更新的部分,这就相应减少了所需传输的内容加快了内容送达至用户的时间。并且也减少了服务端对HTML的不必要的渲染。Facebook也提到了可以减少session的重复load/unload。
  使用Ajax也许不是什么新鲜的新闻,大家拒绝这项技术的原因可能很大程度基于SEO的需求。解决方案也很简单,将Ajax只是作为提高用户体验的手段,而不是浏览网站必须的方法,即可解决SEO的问题(P.S. Facebook不需要SEO)。
  一些实现细节:
  整套方案包括:Link Controller, HistoryManager, BootLoader, Busy Indicator, CSS Unloading, Permanent link support, Resetting timer functions。这些方案本身没有什么特殊的,大部分都可以顾名思义,需要解释一下的可能是link controller,其含义是将标准的HTML LINK请求转换为Ajax请求(通过绑定click事件)。Facebook的可贵之处是提供了这一整套完整的解决方案,最大程度上保证了网站的可用性。
  效果:
  提高了10%-30% 的网站传输时间,并提高了20%-30%的服务端页面渲染速度。
  使用范围:
  45%的Facebook页面使用了此项技术。
  PageCache
  简单的说,就是将访问过的页面缓存在客户端。但我们知道,作为Facebook这样交互性很强的网站,需要保障用户能尽早的获得更新后的信息,而不是给用户展示一个毫无意义的过期页面。
  Facebook设计了一个框架来识别一个页面是否来自于缓存(猜测:页面首次加载完毕后将所有Ajax的Callback和Result缓存在本地。Facebook页面是基于Ajax获取页面内容,参见BigPipe),若来自于缓存,通过Ajax来更新所需更新的模块(猜测:通过JS预先定义本页面所需更新的div Id及对应的callback handler,并在页面下载时同时下载下来)。
  其提到了三种更新类型:增量更新,用户复写(例如用户在页面上回复了一则评论)及跨页更新(例如在消息详细页面将一则消息标识为已读,需将首页的未读消息数进行更新。)。核心思路还是依据Ajax进行更新。具体思路为:
  增量更新:只要页面来自于缓存,即更新所有预定义的需增量更新的模块。
  用户复写:通过HistoryManager记录用户操作并在cache页面读取后重放所有被标记为“replayable”的操作。
  跨页更新:通过服务端Database API发送信号至客户端将过期缓存标识为invalid(不清楚如何实现。也许是DB端提供一个开放的webservice,客户端通过Ajax持续访问此API来获得此信息)。获得了缓存过期信号后,通过Ajax更新需要更新的信息。
  Facebook顺带提到了一个更新Ajax内容避免页面变化/闪烁的小技巧,就是先将需更新的地方设置为blank,而非直接更新其内容。
  效果:
  加速了10倍的网站响应时间并节约了20%的服务端页面渲染成本。
  BigPipe
  此项技术通过将页面分割为各个Pagelets的方式,将整张页面的获取/渲染变成了并行的方式(感觉非常像iframe sets,但Facebook使用Ajax实现。)。此项技术是Quickling和PageCache的基石。此技术包含了服务端/客户端两方面,在前后端均打破了以往页面的渲染形式。
  实现细节:
  Pagelet的Response为JSON格式,包括id,css,js,content,onload等属性及相应内容,收到后会通过预定义好的JS function来进行渲染。
  Pagelet提供的高级功能:Pagelet的继承,Phased Rendering(猜测:依据规则渲染,也就是依据Pagelet的Response进行渲染),跨Pagelet依赖(数据依赖,显示依赖,JS依赖)。
  BigPipe的三种模式:
  一次渲染模式:即普通模式,支持搜索引擎,用来支持那些不支持JS的客户端。
  管线模式:即并行模式,并行请求,并即时渲染。
  并行模式:并行请求,但在获得所有请求的结果后再渲染。
  效果:
  提高了2倍的页面响应时间。
  YouTube面临的问题
  每天2Billion的访问。每分钟上传35小时的内容。可YouTube需要即时播放视频!越快越好。
  YouTube解决方案
  1. 将JS引用位置从页首移至页尾。
  2. 直接嵌入Flash Player(YouTube之前使用JS来加载Flash Player)。通过页尾的JS来判断客户端的Flash版本(或不支持Flash),来替换预先嵌入的Flash Player或内容(如果需要的话),用来支持特定的客户群。
  效果:页面渲染时间从~400ms降低为~200ms。Flash播放时间从~1200ms降低为~1100ms。
  3. 预加载视频连接: 通过使用JS创建Image引用视频内容来与解析DNS并预开启一个connection供之后使用。
  效果:建立视频连接的总时间从~260ms降低为~180ms。
  4. 提供简化版: 这个很无聊,就是提供一个简版。
  效果:页面加载时间从~1750ms降低为~1100ms。
  5. UIX Widget系统:延迟加载非关键内容。其实整段没什么新意,大部分省略,无非是通过Ajax在页面渲染完后再来动态加载非关键内容。比较特别的是利用JS的事件冒泡,在最上层用一个handler来处理各种事件(优点不详。。也许只是代码比较简洁集中吧),通过CSS来标识和识别对应的handler。
  Yahoo Mail
  Yahoo如何构建下一代的Mail系统?答案就是通过YUI3。Yahoo的技术绝对是最优的,其已经将web前端技术发展到一个非常成熟的地步,照顾到web的方方面面(数据压缩,模块化,高效CSS,非阻碍式JS加载,静态内容提供,利用浏览器cache等等),所以也鲜有创新了。某种程度上来说,Facebook的一些所谓创新也不过是后知后觉,Yahoo早已考虑并实现了这些方案,只是也许不是那么有针对性而已。
  Baidu
  感觉整体倾向于组织结构介绍及一些比较过时的内容。如有兴趣可移驾至http://v.youku.com/v_show/id_XMjE5OTM0NTA4.html 自行观赏。
  Taobao
  还在讨论一些何时使用Ajax,何时不使用的问题。略过不提。有兴趣的可以移驾http://ued.taobao.com/blog/2007/12/20/d2-2/ 自行观赏。

QQ书签 百度搜藏 Google书签 新浪ViVi 雅虎收藏 分享到校内人人网 转贴到开心网
    相关文章
    
    发表评论
    验证码点击我更换图片
    最新评论 查看全部评论
    推荐阅读

    乐淘是如何玩转微博的

    乐淘是如何玩转微博的不久前,派代上有个关于乐淘微博营销的帖子: 微博乐淘千万微博营销的败笔之作 其实,乐淘在微博营销上未必有如此充足