Tag Archives: Performance

新的技术产业:Web Performance Optimization

O’Reilly Velocity China 2010 大会上,业界最有影响里的 Web 性能技术专家 Steve Souders 宣告 Web Performance Optimization (WPO) 时代已经到来。这是个颇为重要的主题演讲,要知道,Google 已经开网站载入时间纳入到搜索排名因素之中(refer),或许 Web 性能优化,商业网站要考虑作为一项战略来对待了。

我们看一组数据(信息来源):

  • Amazon: 增加 100ms 延迟将导致收入下降 1%;
  • Google: 400 ms 延迟将导致每用户搜索请求下降 0.59%;
  • Yahoo!: 400ms 延迟会导致流量下降 5-9%;
  • Bing: 2 秒的延迟将导致收入降低 4.3%/用户(请问,首页用个那么大的背景图干啥?);
  • Mozilla 将下载页时间缩短 2.2 秒之后下载量增加 15.4%;
  • Google Maps 将文件大小减少 30% 后请求增加了 30%;
  • Netflix 在服务器端启用 gzip ,页面快了 13-25%,节省了 50% 的网络流量;
  • Shopzilla 将页面载入时间从 7秒缩减到 2秒,转化率提升了 7-12%,页面请求增加 25%,只用一半服务器就够了

要注意,这些只是数据,实际上,我们没有办法验证这些数据的真实性。但是可以肯定的是,网站访问速度过慢,一定对用户有负面影响。严重一些的,国外有 Friendster 因为网站访问过慢而导致的用户流失可以作为前车之鉴;网站访问速度快也可以增加竞争优势,比如Tumblr 一骑绝尘而将竞争对手 Posterous 甩在后面。国内这方面的例子比如优酷,斥重金改进用户访问速度,很大程度上保持了竞争优势。

相比投资在硬件上,我个人认为技术团队在 WPO 上的投入是可以用来评估团队技术能力的。有一次在和一位投资人聊起国内的分类网站哪个技术团队更具优势,我毫不犹豫的说看好百姓网,为何?访问一下同类网站,比较一下最终页面访问速度就知道了。这是体现一个技术团队意识和能力的地方。

当前最需要 WPO (甚至有些落后的) 的可能要数电子商务网站以及那些依托于大型 C2C 站点上的网店了。很多电子商务网站负责人非常重视 SEO,但在 SEO 已经快成为一种伪技术的今天,被忽视许久的 WPO 更应该引起重视。举例来说,可能绝大多数淘宝上的大卖家都不懂 Web 相关技术,当然也就无所谓什么 Web 性能优化了。我曾经见过有的卖家首页上一个页面放置几百个图片,一个页面动辄 7-8 Mb,用户访问速度可想而知,如果用户正常浏览都无法做到的话,要想购买产品恐怕也就无从谈起了。如果能对这一部分用户进行有针对性的处理,投入产出的价值还是显而易见的。说起图片来,可能这是最影响电子商务网站访问速度的一个因素,没有针对 Web 优化的图片、过大的尺寸或是失真的压缩图片比比皆是,无疑会严重影响用户体验与购买欲望(这里推荐做电子商务的朋友不妨关注一下 Yupoo.com 专门针对用户的这个需求而推出的图片管家服务)。

WPO 的好处?增加网站营收,降低运营开销,提升访问量,进而提升竞争力

WPO 做起来其实并没有那么难,通过一些特定的准则(比如 YSlow 14条, refer)即可取得一些卓有成效的改进。期待 WPO 能早日成为 Web 工程师必备的常识。也建议每一个技术团队的负责人应该将 WPO 作为一项战略来抓,而不是只是一两个技术人员的事情。从现在就开始吧。

EOF

补充:”快比慢好”,Google 把这句话作为十大价值观之一(refer)。而 Facebook 从创立至今,也一直将提升页面访问速度作为一项重要的策略。

补充一篇必读文章:WPO – Web Performance Optimization

此文作者:, 位于 Web 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

Linux 下分析性能 nmon 也挺好用

以前在 AIX 下,有的时候祭起 nmon ,比 topas 好用多了(去年 AIX 干脆集成了 nmon )。在 Linux 下,top 命令基本也是摆设。如果遇到某些机器没有安装 SYSSTAT 包, 直接把 nmon 抓回来还是挺方便的,省去了安装的麻烦。

NMON.png

最方便的就是能迅速抽取不同维度的性能概览数据。想想其实一个日常用的工具也有很多创新的,nmon 和 topas 读取的数据源是一样的(Perfstat API),但细节上做得更为到位(看来 Nigel 对用户体验也”略懂”阿)。nmon 抓取的数据很容易输出为 Round-Robin Database (RRD) 格式。便于进一步做数据展现。

AIX 提供的 Perfstat API 很赞,如果自己有兴趣,也可以自己写工具调用数据用以运维数据参考。我以前还写了两个山寨小工具,一个抽取网卡数据吞吐量,一个抽取磁盘 I/O 量。不会 C 也能照猫画虎弄出来。

EOF

Jiffy — 端到端的 Web 性能评测框架

前面几天介绍的 Web 前端优化最佳实践 系列离不开一个关键词:YSlow。简单的说,YSlow 是以最佳实践得到的规则为基础,进行 Web 页面的性能评估,并给出指导建议。

Velocity 2008 上发布的 Jiffy ,我断言是一个比 YSlow 更有前途的工具,只是当前还没引起足够的关注度。之所以说 Jiffy 更有前途,是因为 Jiffy 设计初衷是面向端到端的,不只是个工具(Jiffy 有基于 FireBug 的插件 Jiffy Firebug Extension for Firefox ),而变成了框架,对于 Web 上的每个组件,都能进行性能度量。如果说 YSlow 是类似”望闻问切”的诊断方式,那么 Jiffy 就是 CT 检查了。

下图揭示了 Jiffy 的工作机制:
Jiffy.png

通过页面中植入 Jiffy.js ,针对 Apache 做特定的设置,当用户调用页面的时候,拦截并记录 Jiffy 的相关请求,接着把所有的性能信息注入数据库中,然后从数据库中抽取数据进行展现。这正是当前绝大多数 Web 公司都缺少的性能衡量策略(尤其是 JavaScript 的精细度量)。唯一美中不足的是使用 Oracle XE 做性能信息存储的数据库,相信不久就会完美支持 MySQL 。

关心 UE 的朋友可以在自己的环境里面搭一套 Jiffy 啦,有好处没坏处。

EOF

更新:有得朋友说,安装了,点击了,没反应。这是因为页面中没有嵌入 jiffy.js 脚本。可以到我的 egosurf 页面测试一下。

Web 前端优化最佳实践之 Mobile(iPhone) 篇

Web 前端优化最佳实践最后一部分是针对移动应用的,其实只是针对 iPhone 的,目前只有两条规则。

1. 单个数据对象小于 25K (Keep Components under 25K)

这个似乎只是针对 iPhone 研究的。建议保持单个 Web 数据对象在 25 K 以下。为什么是 25K? Apple 官方信息指出可缓存到内存中的 Web 对象最大支持到 10M,但经过测试,发现也就是 25K 左右。

iPhone 在市场上的优异表现,让 Web 人员不得不考虑如何针对其进行优化。相信这部分内容也在不断变化中。

2. Pack Components into a Multipart Document

把Web 页面组件打包成一个多部分组成的文档。其目的是减少 HTTP 请求。对这部分语焉不详,等待后续更新吧。

EOF

Updated: 根据这篇 iPhone caching 的文章,可供 Cache 的最大单个数据对象是 15K,而不是前面说的 25K。iPhone 总的 Cache Size 为 1.5M。浏览器地址栏的刷新按钮将导致无条件刷新所有组件。这些也是挺有趣的。