Velocity 2012 Day Two

6月26日开始就是正经的velocity 2012了,会场里面的人明显比前一天多很多,转场的时候人山人海。美国的胖子真够多的,我经常能在会场或者路上看到超级大吨位的胖子,男女老少都有。

最开始是Steve Souders的吹水和开场。一上午的主题演讲几乎和性能没啥关系,基本上是赞助商和运维的话题。

中间Steve Souders介绍了httparchive.org从2010年10月就开始跟踪网站的性能指标,这样就能看到网站的历史性能状况,或许对我们了解自己的网站和竞争对手的网站有一定帮助。当然,对中国的网站参考意义又会小一些,不过,文件体积这些硬指标还是值得参考的。

中午仍然是不变的自助餐,下午整个大会的“正餐”终于来了。

首先是Google带来的SPDY介绍,这一场略微有点扫兴。主要是介绍了他们自己研发的SPDY技术,里面的优化点很多,包括对连接、加载、前后端运行的优化。唯一也是最重要的不便是,这个技术要求服务端和客户端同时具备相应的支持才能完成性能优化,他们开发了各大web server的mod,但是浏览器只有chrome支持。在国内来说,花这么大的成本,受益却颇小。

接着是LogNormal和Facebook三个人混搭讲RUM for Breakfast – Distilling Insights From the Noise。这个session的入手点很细,这也是老外们比国人钻研的更深入的一个体现,他们主要的思路是从一大堆数据里面,找到和收益(PV、跳出率)存在明确关系的部分,然后有针对性的优化。

  1. 对CDN做优化,他们不是用传统的ip库来解决问题,而是通过对没一个用户随机的请求一个anyname.dns.fb.com 的空图片,计算请求时间,来为所有的ip段寻找最优的服务器。
  2. 在做数据分析的时候,他们发现很多时候,曲线并不服从正态分布,他们认为是由于数据噪音引起的。他们做了一些简单的过滤,把异常数据去除。
  3. 将性能数据和收益数据结合来做分析,他们统计了跳出率和加载、DOM load等时间的关系,并且发明了一个LD50的指标,就是当跳出率大于50%时,这些性能指标的值,这样能更精确地来进行优化。

接下来是Google的人讲Selecting and Deploying Automated Optimization Solutions。这个session内容比较少,就介绍了一个自动做web前端代码优化的思路,以及相应的服务提供商。

他的主要思路是通过在前端服务器之前架一个代理,用户从这个代理请求到的代码是经过自动优化的,主要是优化可以通过机器来自动化的部分:

  • 为不同的浏览器生成不同的代码
  • 图片转成URI、WebP
  • 自动压缩图片,cache
  • 根据用户访问路径预加载

此外,他还提出了一些通过修改原有页面逻辑的方法来做优化的思路,包括根据用户的行为,来对页面的不同部分做优先级判断,然后将代码重组。不知道这块他们具体效果怎么样,很科幻啊。

他们的思路和FIS的相似,只是把我们线下处理放到了线上。好处是能做到更好的实时和动态性,不过这让线上服务的复杂度提高了很多,运维更难了。

下面一个Session是讲CDN优化的:Getting A Grip On CDN Performance: Why And How,前面的一堆数据和中国国情差距比较大,主要是为每个关键国家、州找到最快的CDN,没太细听。后面的测量方式还有点意思:

  1. 不要用服务器到服务器的速度来做测量,要用真实用户
  2. 不要用Google Analytics来做测量,用Resource Timing API
  3. 测量的文件应该是16kB,这是他们统计中占比最大的文件大小
  4. 排除那些不靠谱的数据(今天多个session都提到了这一点)

CDN和我现在的工作距离比较远,中间跑到隔壁的Using Node.js to improve the performance of Mobile apps and Mobile web去听了一会儿。主要是Yahoo!的人在介绍他们在NodeJS方面的应用,他们在mobile应用中,用nodejs将一些需要前端渲染的MVC内容,在后端服务器运行后,将HTML直接发送到前端。这样减少了前端的运行时间,更省电,不过会牺牲流量。似乎他们这个系统还可以动态(或者通过配置?)决定哪部分内容由后端渲染。也是一个比较科幻的想法,不知道真正使用起来效果如何。

接下来一个session很有新意:Rendering Slow? Too Much CSS3? Ask RSlow,Twitter和CBS的几个工程师仿照YSlow,做了一个RSlow,用来测量CSS方面的性能。但雷声大雨点小,现在还没有成品,只有一套方法论,很遗憾。

随着CSS3技术的兴起,CSS的渲染和执行性能就被逐步提上了考虑范围。主要包括两部分:payload,rending(paint/restyle/layout),他们测量了一堆CSS和非CSS实现的类似效果,得到了一些数据,简单列举一下,当然,如果要在生产环境中用这些结论,一定要看当时他们的测试条件。

  1. png24的渲染速度最快,css3的加载速度最快
  2. 实现背景渐变渲染,css3的渲染速度比背景图快3-5倍
  3. 用img标签显示前景图片和background显示同一张图片,背景方式更快一点,但几乎相差无几
  4. 实现loading的旋转图标,用css3比gif慢很多

其实他们所设想的Rslow,只是在chrome中用timeline的export功能,把css相关的时间导出,然后用一个脚本做分析而已,还没法应用。

今日的最后一个session是Twitter的人介绍Time To First Tweet,算是一个成功的性能优化案例,将用户的可交互时间提高了数倍。

他们的优化首先有一个漂亮的目标:“Time To First Tweet”,即用户从搜索引擎或者什么别的地方,打开twitter页面,直到他能发推的时间。简单列举他们的优化过程:

  1. 用Navigation Timing API来抽样测量性能,最后得到了四个时间:connect,process,repsonse,render;
  2. 测量不同的地区的性能,举了旧金山和巴西的两个例子,巴西的用户render时间比旧金山长许多;
  3. 结合实现技术和前面得到的数据,通过延迟加载JS(和FIS一样用的是AMD)来提速
  4. 为延迟加载,并行加载提供不同的静态文件包,来针对不同的用户优化
  5. 加大对pushState的应用,减少页面整体重新渲染,在twitter网站内部切换页面速度更快

晚餐的时候,在Exhibit Hall还有很多展台,而国外的公司都很慷慨。整个展厅里面,tee随便拿,各种小礼物见人就发,留个名片就是抽奖iPad…

总的来说,今天的session不如去年的精彩,没有什么猛料爆出,但velocity仍然不失为很经典的会议。因为整个性能优化的思路已经基本形成,在大的方法论上,可能近1-2年都不会有大的突破了;大家主要的着力点在细节之处,比较精彩几个的session,都是从小处入手,在过去被大家忽略的地方发力,通过性能优化来提升产品价值。

我的twitter是 @cnberg ;新浪微博是 @berg ,欢迎各位关注。

2 条评论

  1. Franky 于 2012-08-22 @ 22:23:40

    赞!

  2. ici 于 2012-12-23 @ 03:34:12

    ici…

    Velocity 2012 Day Two | 冰山一角…

发表评论

火花来自思想的碰撞,请留下你宝贵的评论吧: