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就不支持。
本文来自于淘宝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也可以来谈谈自己的想法。
现在研究注入性文章的不多了，但还是需要研究，特别是自己在做网站的时候。除了SQL注入，剩下的还有XSS注入等。唉。做个网站都要这么辛苦。。
对于注入而言，错误提示是极其重要。所谓错误提示是指和正确页面不同的结果反馈，高手是很重视这个一点的，这对于注入点的精准判断至关重要。本问讨论下关于几类错误和他产生的原理，希望对读者有所帮助。
错误提示主要有逻辑错误和语法错误以及脚本运行错误三类。
一：逻辑错误
简单的例子是1=1 1=2这两个，1=1与1=2页面不同的原理是什么?以$sql = "select * from news where id=$_GET[id]"为例。
select * from news where id=1 and 1=2产生的结果集为NULL，然后程序取值得时候，就会去出空值，无法显示。当然有的程序发现SQL执行结果集为空，就立即跳转，效果就不显鸟。值得注 意的是，有的如Oracle Postgresql的数据库在结果集为空情况下会再页面上表现字符型null字样，这算是个特点。如果使用or条件，比如
select * from news where id=1 or 1=1
和and 1=2得结果正好相反，他的结果集十分庞大。如果SQL语句如此，再加上程序是循环读取结果集(一些编程上的陋习)那么会取出所有结果，结果可能运行很 慢，在数据量巨大的oracle上容易出现。这个例子会出现什么呢，一般程序取出结果集中的第一条结果，那么很可能已经不是id=1的那条新闻了，这就是 由些小菜奇怪有时候or 1=1页面会发生变化的原因。
归根到底，都是结果集不同造成的，灵活掌握是关键，这并非单纯的经验问题。
二：语法错误
语法错误时比较熟悉的，比如对于SQL Server,PgSQL,Sybase的注入错误提示都很重要，因为利用它的特性来获取信息很快速。语法错误造成的结果可能是SQL错误而中断脚本执 行，但是脚本或服务器设置屏蔽错误的情况下，程序得到继续执行，但是结果集不存在，连NULL都算不上，反馈给攻击者的很可能就是结果集为空的情况，其实 这是脚本的处理结果。当然Oracle PgSQL表现null。
三：运行错误不用说了，典型的就是利用mysql注入benchmark让脚本运行超时得到物理路径，以及利用超时来获得不同的表征进行盲注入。
四：逻辑错误和语法错误的结合。
当表征极不明显的时候，利用类似iff这样的函数进行正确与否的区分有时候会成救命稻草。因为语法错误和逻辑错误的表征大多数情况都会有不同。
iff(1=1,1,'no')这个会产生结果1 注意是数字，而iff(1=2,1,'no')这个会产生'no' 是字符。那么
id=1 and 1=iff(1=1,1'no')正确是必然成立的，而id=1 and 1=iff(1=2,1,'no')会因为类型不同发生语法错误。不过可惜的是似乎支持iff函数的数据库不多，呵呵。
现在讲结果集在注入中的利用原理。
一：从'or''='开始
这是学习SQL注入的初级课程，登陆漏洞。我简略从SQL结果集上分析。
$sql = "select top 1 * from admin where username='$username' and password=md5('$password')";
显而易见，'or''='的加入使SQL语句返回了一条记录，这才使验证通过。
二：再看现在的验证中的SQL
$sql = "select top 1 * from admin where username='$username'";
结果集不为空才根据抽取的记录集中的密码值与用户提交的密码MD5值进行比对来进行验证。这样，你突然发现'or''='的计策失败鸟，但是后 台明明有注入，这就是验证方法造成的。跟进这个验证过程，'or''='的确产生了一个结果集(admin表中的第一行记录)但是遗憾的事，后来的密码比 对没法通过，验证无法成功。
思路很简单，网上有案例，我重在原理，利用union来产生想要的结果集。比如'and(1=2)union select top 1 username,'123456得md5值',id from admin where username='admin
这样产生了admin的记录信息，但是记录集中的密码那个位置的值被替换成了123456的md5值，这样，使用admin 123456通过验证并且继承他的权利。
更有甚者全部用'xxx'的方法来盲狙，这就很“过分”鸟。不过在sql2000 sybase这些严格要求类型匹配的数据库来说，这样不能撼动“管理员登陆”的，因为执行时发生了语法错误，结果集为NULL。另外以前 ewebeditor注入漏洞来上传马也是这个union操作结果集来达到目的的经典案例。
来自于：http://hi.baidu.com/isbx/blog/item/17d629349ecef3325ab5f538.html
原创作者：Dream an end （S.s.F）
说实话如果一个网站的前台都是注入漏洞，那么凭经验，万能密码进后台的几率基本上是百分之百。
可是有的人说对PHP的站如果是GPC魔术转换开启，就会对特殊符号转义，就彻底杜绝了PHP注入。
其实说这话的人没有好好想过，更没有尝试过用万能密码进PHP的后台。
其实GPC魔术转换是否开启对用万能密码进后台一点影响也没有。
如果你用这样的万能密码'or'='or'，当然进不去，理由是GPC开启的时候单引号会被转换。
PHP注入时我常用的万能密码是:'or 1=1/*.
那我们分析一下为什么这可以进后台。
如果sql语句这样写:"SELECT * FROM admin where name='".$_POST['name']."'and password='".$_POST['password']."'",那我们在帐号处输入万能密码'or 1=1/*，密码随便输，sql语句就成了select * from admin where name='’or 1=1/*' and password='任意字符'。
/*为mysql的注释符，这样后面的东西就都被注释掉了，也就是为什么密码随便输的原因。
假设GPC转换没有开启，那么请看：where name='’or 1=1（*/后面的东西被注释掉了），
name='’的逻辑值为假，而后面的1=1逻辑值则为真，对于整体就成了假 or 真，最终的逻辑值还是真，就进后台了。
那么如果GPC转换开启了，就对单引号进行了转换。语句就变成了where name='\’or 1=1,在
看一下和刚才有什么区别，无非是多了个\。name='\'与name=''的逻辑值一样，都为假，那1=1 为真，总的sql语句的逻辑值不还是真吗？那有进不去后台的理由吗？
所以总的来说，php网站的万能密码可以这样写:'or 1=1/*，而GPC转换是否开启对它没有任何影响！
所以请改变你的想法：存在字符型注入的php网站是可以用万能密码'or 1=1/*的
有意思的文章，来自于：http://hi.baidu.com/isbx/blog/item/f83b9e3de2e33f09bba16721.html
这款插件的用途是可以让你快速发表博客。功能还算是挺强大。主要是方便啦
而且，它是firefox的插件，不需要你安装软件，有firefox的地方就能够使用，多方便啊。。。
当然，在使用它为wordpress发表文章的时候，还必须在后台开启XML-RPC应用。否则是不能发表的。
博客系统看来是需要更换了，sablog用了也将近2年了。最痛苦的就是输入的文章突然消失（不小心按了Backspace键，然后回来的时候内容就没有了），出现了好几次这样的事故。。
下载地址为：https://addons.mozilla.org/en-US/firefox/addon/1730
截图：
