手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表2009年09月6日的文章

Yahoo优化网站策略

Yslow是所有使用firefox的用户都应该安装的插件之一吧。最早,yahoo把网站优化的14条策略放在程序里,就以此来测试,后来根据小说《第二十二条军规》,增加到了22条,如今,它已经拥有34条策略了。
帕兰映像上有了翻译,我就不客气的转载了。毕竟让我翻译的,恐怕到明年我都翻译不出来。哈哈

原文来自帕兰映像:http://paranimage.com/yahoo-given-34-web-acceleration/

Yahoo给出的包括Yslow规则(22条)的34条 详细说明 ,通过这此规则对自己页面进行一次全面的分析优化,可以提高你网站的加载速度。

1.Minimize HTTP Requests 减少HTTP请求

图片、CSS、script、flash等等这些都会增加http请求数,减少这些元素的数量就能减少响应时间。把多个JS、CSS在可能的情况下写进一个文件,页面里直接写入图片也是不好的做法,应该写进CSS里,利用 CSS sprites 将小图拼合后利用background来定位。

2.Use a Content Delivery Network 利用CDN技术

CDN 确实是好东西,8过服务器提供商的这项服务一般是要收费的,我以前买的国内空间是有这个的但是我当时根本不知道啥用,现在没了。。。

3.Add an Expires or a Cache-Control Header 设置头文件过期或者静态缓存

浏览器会用缓存来减少http请求数来加快页面加载的时间,如果页面头部加一个很长的过期时间,浏览器就会一直缓存页面里的元素。不过这样如果页面里的东西变动的话就要改名字了,否则用户端不会主动刷新,看自己衡量了~ 这项可以通过修改.htaccess文件来实现。

4.Gzip Components Gzip压缩

Gzip格式是一种很普遍的压缩技术,几乎所有的浏览器都有解压Gzip格式的能力,而且它可以压缩的比例非常大,一般压缩率为85%。压缩没压缩,可以到 这里 做下测试。

5.Put Stylesheets at the Top 把CSS放顶部

让浏览者能尽早的看到网站的完整样式。

6.Put Scripts at the Bottom 把JS放底部

网站呈现完毕后再进行功能设置,当然这些JS要在你的加载过程中不影响内容表现。

7.Avoid CSS Expressions 避免CSS Expressions

CSS表达式很可怕,这个只被IE支持的东西执行时候的运算量非常大,你移动一下鼠标它都要进行重计算的,但有时候为了做浏览器的兼容必须要用到这个||| IE6去死去死!~

8.Make JavaScript and CSS External 将JS和CSS外链

前面讲到了缓存这个事情,一些较为公用的JS和CSS,我们可以使用外链的形式,譬如我就是从Google外链来的Jquery文件,如果我的浏览者在浏览别的使用了这个外链文件的网站时已经下载并缓存了这个文件,那么他在浏览我的网站的时候就不需要再进行下载了!~

9.Reduce DNS Lookups 减少DNS查找

貌似是要减少网站从外部调用资源,我的Google分析和picasa的外链图片都算在里面了。

10.Minify JavaScript and CSS 减小JS和CSS的体积

写JS和CSS都是有技巧的,用最少的代码实现同样的功能,减少空白,增强逻辑性,用缩写方式等等,当然也有不少工具也能够帮你实现这一点。

11. Avoid Redirects 避免重定向

再写入链接时,虽然“http://www. today-s-ooxx. com”和“http://www. today-s-ooxx. com/” 仅有一个最后的“/”只差,但是结果是不同的,服务器需要花时间把前者重定向为后者然后进行跳转,这个要自己注意,也可以在Apache里用Alias 或者mod_rewrite或者DirectorySlash解决。

12. Remove Duplicate Scripts 删除重复脚本

重复调用的代码浏览器并不会识别忽略,而是会再次运算一遍,这当然是大大的浪费。

13. Configure ETags 配置ETags

搞不清楚咋回事,总之我是在. htaccess里把它删除了。

14. Make Ajax Cacheable 缓存Ajax

Ajax是实时响应的,在浏览器接收到新的数据前,旧的数据被缓存,这样能够更好的提高效率。

15. Flush the Buffer Early 尽早的释放缓冲

当用户进行页面请求时,服务器端需要花费200到500毫秒时间来拼合HTML,将写在head与body之间,释放缓冲,这样可以将文件头先发送出去,然后再发送文件内容,提高效率。

16. Use GET for AJAX Requests 用GET方式进行AJAX请求

Get 方法和服务器只有一次交互(发送数据),而 Post 要两次(发送头部再发送数据)。

17. Post-load Components 延迟加载组件

最先加载必须的组件进行页面初始化,然后再加载其他,YUI Image Loader 是很好的例子。

18. Preload components 预加载组件

提前加载以后可能用到的东西,和延迟加载并不冲突,它的目的是为后续请求提供更快的响应,参见Google首页上的CSS sprites应用。

19. Reduce the Number of DOM Elements 减少DOM元素数量

复杂的页面结构意味着更长的下载及响应时间,更合理更高效的使用标签来架构页面,是好的前端的必备条件。

20. Split Components Across Domains 跨域分离组件

页面组件多个来源可以增大你的平行下载量,但注意不要过多,超过2-4个域名会引起上面说到的DNS查找浪费。

21. Minimize the Number of iframes 减少iframe数量

需要更有效的利用 ifames。
iframe 优点:有利于下载缓慢的广告等第三方内容,安全沙箱,并行下载脚本
iframe 缺点:即使为空也会有较大资源消耗,会阻止页面的onload,非语义

22. No 404s 不要出现404页面

站点本身里(非搜索结果)出现404页面,无意义的404页面会影响用户体验并且会消耗服务器资源。

23. Reduce Cookie Size 减小Cookie

Cookie在服务器及浏览器之间的通过文件头进行交换,尽可能减小Cookie体积,设置合理的过期时间,能够很好的提高效率。

24. Use Cookie-free Domains for Components 对组件使用无Cookie的域名

对静态组件的Cookie读取是一种浪费,使用另一个无Cookie的域名来存放你的静态组件式一个好方法,或者也可以在Cookie中只存放带www的域名。

25. Minimize DOM Access 减少DOM的访问次数

JS访问DOM是很慢的,尽量不要用JS来设置页面布局。

26. Develop Smart Event Handlers 开发灵活的事件处理句柄

DOM树上过多的元素被加入事件句柄的话,反应效率肯定会低,YUI事件工具有一个 onAvailable 方法可以帮助你灵活的设置DOM事件句柄

27. Choose < link >over @import 使用< link >而非 @import

在IE中使用@import就和在页面底部用< link >一样,我们前面说要把< link >放顶部的。

28. Avoid Filters 避免过滤器的使用

如果需要Alpha透明,不要使用AlphaImageLoader,它效率低下而且只对IE6及以下的版本适用,用PNG8图片。如果你非要使用,加上_filter以免影响IE7+用户。

29. Optimize Images 优化图片

将你的GIF转为PNG8会是个减小体积的好办法,另外有很多方法处理你的JPG及PNG图片以达到优化效果。

30. Optimize CSS Sprites 优化CSS Sprites

在CSS Sprites中竖直并尽量紧凑的排列图片,尽量将颜色相似的图片排在一起,会减小图片本身的大小及提高页面图片显示速度。

31. Don’t Scale Images in HTML 不要在HTML中缩放图片

图片要用多大的就用多大的,1000X1000的图片被width=”100″ height=”100″以后,本身的KB数是不会减少的。

32. Make favicon. ico Small and Cacheable 缩小favicon. ico的大小并缓存它

站点的浏览器ICO应该不是经常换吧,那就长时间的缓存它,并且最好控制在1K以下。

33. Keep Components under 25K 保证组件在25K以下

iPhone不能缓存25K以上的组件,并且这还是要在被压缩前。

34. Pack Components into a Multipart Document 将组件打包进一个多部分的文档中

就好像在邮件中加入附件一样,一个HTTP请求就够了,但是这一技术需要确保你的代理支持,iPhone就不支持。

Tags: yahoo, 优化, 军规, 策略

Cache测试策略

本文来自于淘宝QA,这是第一次看到有这样的贴子,是测试cache的贴子。虽然他不是测试cache本身,但从文中的测试要点来说,还是有借鉴意义的。像他说的:触发点、何时使用cache等都是一个要点。
众所周知,任何一个程序,为了效率,总有部分资料是需要被缓存的。比如,系统配置,这玩意一旦设定,很可能就再也不会修改了(或者说,修改的频率非常低),如果每次都查询数据库,那效率也太低了。所以它应该是被缓存的对象之一。
分类也是应该能够被缓存的,谁TMD有事没事去修改分类、删除分类?一个成熟的网站,分类定下来后,基本也就定下来了,除非更改业务方向,增加业务范围,才会去修改分类。当然还有一种情况,那就是为了促销,人为修改(但这应该不属于分类了啦)所以,分类也应该是被缓存的对象之一。。。

好了不说废话了,看测试是怎么说的吧:
原文:http://rdc.taobao.com/blog/qa/?p=3434

        前段时间做了一个cache相关的接口测试,这里要说的并不是测试cache本身,而是测试一个使用了cache的业务系统,该业务系统通过调用另一个专 门提供cache服务的系统来实现数据的cache。也就是说cache服务本身对于我来说是黑盒的。那么在这种情况下,我们应该从哪些方面来考虑测试, 才能够保证业务系统对cache服务的调用是正确的呢?我是从以下几方面考虑的:

一.Cache的触发点

        如果一个系统使用了cache,那么它就一定会有cache的触发点,所谓触发点就是会触发cache缓存数据或者更新数据的事件。这些事件往往就是对某 些接口的调用。例如查询数据的时候,如果缓存里没有该数据应该会触发cache来缓存该数据。更新数据的时候,如果缓存里有该数据,应该会触发cache 删除该数据的缓存等等。我们必须要掌握每一个触发点才能够知道如何来设计针对cache的测试,因为我们的目的就是要验证所有的触发点是否都正确的触发了 我们所期望的缓存事件。

二.何时应该使用cache,何时应该使用数据库

         掌握了系统中所有的cache触发点之后我们就可以开始设计如何来验证这些触发点了。一般来说,被缓存起来的数据都是供查询使用的,明确了这点之后,其实 归结起来,我们只需要考虑两个问题:一是何时应该查询cache中的数据,二是何时应该查询数据库中的数据。

         举例来说,一个典型的使用了cache的查询接口应该是这样的,当查询数据的时候,接口会首先去缓存中查找数据,如果缓存中没有数据,再去数据库中查找, 如果在数据库中找到了指定的数据,它会在返回数据的同时,对该数据做缓存处理。了解了这个过程之后,你可以先通过直接插数据库的方式准备一条数据,这个时 候该数据是没有缓存的,因为没有触发缓存数据的事件发生,那你如何来验证这个数据确实没有缓存呢?很简单,直接把该数据从数据库删除掉,再调用查询接口查 询该数据,如果没有查询到,说明该数据确实没有被缓存。另外一方面,你还应该保证如果数据被查询到了,那么它就应该被缓存起来,这个时候你同样可以直接删 除数据库中的数据,再次查询该数据,如果可以查询到,那么就说明它确实是被缓存起来了。总的来说就是了解缓存过程,分解过程,保证过程的每一步结果都是所 期望的,这就有别于通常的接口测试只关注输入和最终的输出结果了。它的思想和切面编程的思想有点类似,也许我们可以把这种测试方法叫做切面测试。

三.多触发点联合测试

         在保证了每个触发点的正确性之后。我们还应该进一步把这些触发点按照实际的业务场景串联起来测试。例如,可能会有这样一个业务场景:生成数据→查询数据→ 编辑数据→查询数据→删除数据→查询数据。值得注意的是对于这样的联合测试除了保证每个步骤的结果都正确的同时,我们应该尽量采用调用业务系统接口的方式 来完成每一步,尽量避免直接操作数据库,因为这样更能模拟出真实的调用场景。

        不同的cache方式会有不同的测试方法,以上仅是我在测试特定cache的时候的一些想法,仅供参考。如果你测试过cache,不妨也来说说你自己的测试方法,如果你没有测试过cache也可以来谈谈自己的想法。

Tags: cache, 测试