优化试试玩

04.17.2010, 性能优化, by Supersha.

2010-7-30 Update:

对于”Transfer-Encoding:chunked”HTTP响应头，虽然说它可以使得服务器可以以小块数据包的形式连续的发送HTML内容回来，或许有些人会认为：为什么不让他应用于Js，CSS呢，这样使得JS，CSS可以边加载边解析。理论上是可以的，但是实际是会崩溃的，在JS，CSS的响应头中应用它的时候，会造成JS，CSS加载失败，很悲剧的事情……

2010-6-2 Update:

今天捣鼓了下设置HTTP文档的响应头Transfer-Encoding:chunked。对于Transfer-Encoding的作用，在《高性能网站建设指南》中所说的就是“块编码”，它是HTTP/1.1引入的，使用它HTML文档可以被分成多个数据块立即返回，而不需要浏览器知道数据的大小和确定响应的结束时间，这就允许浏览器在下载数据包后马上进行解析，使得页面的加载速度更快。而HTTP/1.0是通过Content-Length头来发送的，而且还是将HTML一整块的发送，所以浏览器在响应结束之前，不会开始渲染页面和下载资源。

可是经过一上午的折腾，给页面加上了这个HTTP头之后，出错了，Chrome下返回错误“ERR_INVALID_CHUNKED_ENCODING”。郁闷了很久，之后在HTTPWatch官方博客上看到关于这个的文章《Content Length & Transfer Encoding》，在文章的Example中提到了一句话提醒了我：“if you are accessing this page through a proxy it may remove the chunked encoding”。想一下，还真是我设置了浏览器的代理，把Transfer-Encoding给删除了，同时经过测试，发现代理还会删除Trailer头。因此出错的原因就是跟代理冲突了。

但是代理不会删除HTTP响应头Content-transfer-encoding，不过在本站代理下测试，效果不明显，就没运用了，因为本站在未设置代理的情况下，是支持Transfer-Encoding的。下面是Transfer-Encoding有无情况的HTTP瀑布图，可以更直观的说明。

有Transfer-Encoding头的时候，HTML页面边下载边解析：

没有Transfer-Encoding头的时候，需要HTML页面全部下载完之后才开始解析：

2010-5-31 Update:

这次的优化是针对“最大化HTTP请求”这个需求来提升页面加载速度。之前注意到可以使用Data:URI的形式来连接图片，将图片通过base64编码过后直接写在页面上，但是如果使用这样方式将图片写在了HTML页面上了，这就会无疑增加了HTML页面的大小，而且Data:URI的大小跟图片的大小是直接相关的。所以在Nicholas C. Zakas的这篇博文中《Data URIs explained》提到了这么一段话：

Inline images use the data: URI scheme to embed the image data in the actual page. This can increase the size of your HTML document. Combining inline images into your (cached) stylesheets is a way to reduce HTTP requests and avoid increasing the size of your pages. Inline images are not yet supported across all major browsers.

就是将Data:URI联入的图片写到CSS文件里面，当然这样的图片是起修饰作用的（比如背景图片），这样可以利用CSS文件可缓存的特点，将图片的信息也缓存了，减少了HTTP的请求数目，达到了一定程度上的优化。本站也使用了这样的方式，但是由于IE6、7对Data:URI还不支持，所以只能通过hack的方式对IE6、7进行特殊的处理：

[html]
#body-bg{
background:url("image/png;base64,…….") no-repeat;
*background:url("image/icons.gif.php") no-repeat;
}
[/html]

对本站的具体情况来说，将背景图片base64编码之后的大小跟原本图片的大小相差无几，所以使用data:URI之后，并且将CSS文件Gzip压缩，给CSS文件增加的大小也不会有太大的影响，而对于连接数有限的虚拟主机来说，减少一个HTTP请求，优化效果会占优势，所以权衡过后，使用了这样方式，同时测试成功~

2010-5-28 Update:

刚才看了Steve Souders的这篇关于优化CSS选择符的文章《Simplifying CSS Selectors》，觉得十分在理。按照《Writing Efficient CSS for use in the Mozilla UI》这篇指出的：

The style system matches a rule by starting with the rightmost selector and moving to the left through the rule’s selectors. As long as your little subtree continues to check out, the style system will continue moving to the left until it either matches the rule or bails out because of a mismatch.

浏览器渲染系统是从右到左的形式来查询CSS选择符中指定的页面元素的。所以，精简CSS选择符就尤其显得重要。Steve Souders将CSS选择符中最右边的选择符称为“关键选择符”，比如：A.class0007 * {}。这个选择符是非常耗性能的，首先它会查询页面中全部的元素，再往上查询带有class0007类的超链接。

因此，将你的CSS选择符尽量保持简洁，并且避免那些消耗性能高的选择符，比如：全局选择符；还有避免那些累赘的选择符，比如：div#test,div.test等等；尽量避免关键选择符不要查询过多的元素。

同时在这里引用David Hyatt (architect for Safari and WebKit, also worked on Mozilla, Camino, and Firefox)对于CSS3的一段描述：

The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers.

按照他的话说，CSS3选择符也是比较消耗性能的，尤其在一些动画、阴影方面等等，都需要消耗比较大的CPU和内存来渲染。

更多阅读：《Performance Impact of CSS Selectors》，《CSS Qualified Selectors》

2010-5-13 Update:

优化了整站超链接的URL，将”http://www.ilovejs.net”替换为”/”，减少页面大小。这对于tag cloud来说尤其有优化作用。

/////////////////////////////////////////////////////////////////////////////////////

2010-5-4 Update:

1.对内容栏和边栏使用了ob_flush();flush();这两个方法，使得内容首先显示，边栏后显示的效果。毕竟内容为主，边栏就类似于“后加载”的情形吧。
2.通过修改主题css文件，发现当前编写css代码时，仍有非常多的低效的代码。
3.再离谱点，把javascript和css都各自合并到一个文件里了，删除了wordpress默认的并且已经没用的javascript文件，并且通过Google的Page Speed插件的建议，删除了无用的css样式规则，也获得了不少的优化效果。这主要是考虑到减少HTTP请求，毕竟虚拟主机对连接数的限制等等原因，还有就是可缓存，可以加快页面的加载速度。下面是首页在Page Speed和ySlow插件下的优化效果图以及firebug下的“网络”的HTTP瀑布图：

Update:

终于将“Catagroies”、“Links”、“Favorite Tags”，还有头部导航等HTML都压缩了，欣慰一下……

/////////////////////////////////////////////////////////////////////////////////////

这个礼拜总算有点时间来搞搞网站了，之前一直都很想整整网站的代码，优化一下(平时自己嘴边总说会优化，实践才出真知啊)。经过一天的捣鼓之后，发现访问速度也确实有些提高了。甚感欣慰啊……

优化的地方主要有以下几点：

因为网站内安装了syntaxhighlighter代码高亮插件，这个插件虽然强大，但是也很纠结：它会在页面内插入几个css文件以及js文件（跟高亮代码的种类成正比）。这点本人非常不满意，所以，优化的主要目标，就是这个。本来打算将几个css文件和js文件先在服务端通过php的fopen、fwrite、fclose几个方法整合为一个文件，再用link和script来链接这个整合的文件，可是发现优化失败（具体可以参见《Javascript,CSS Minify》）。所以暂时的解决方案是手动去整合那些css和js文件，再将整合的文件链入页面内。达到较少HTTP请求的优化。并且将inline的css和js代码进行了压缩。
网站内同时也安装了wordpress-thread-comment插件，它的问题跟syntaxhighlighter插件一样，动态插入了两个js文件（如果在登陆的情况下，否则插入一个js文件）。并且在head部动态插入了一段inline样式代码。因为逻辑和关联的比较复杂，所以就只能是压缩css和js代码了，将inline的css代码压缩掉，并且将插件将要用到的js文件也压缩掉。
将头部和脚部的html都压缩掉，去掉每一个多余的字符，本来想将头部一连串的link元素给帅选掉一些，但是毕竟wp对搜索引擎优化比较良好，而且也只是元素而已，不用链接外部文件，所以就暂时留住了。删除了一些无用的meta元素，并且将DOCTYPE改为html5的声明方式，更加精简。
将wp主题的php文件都进行了压缩，将html代码结构都压缩。本来想对“Categories”和“Favorite Tags”的HTML结构也压缩掉，可是在查看wp的PHP源码的时候，尝试暂时失败了，有待进一步疯狂的压缩。
去掉了link、style元素中的type属性，去掉了script中的type和language属性。
优化PNG图片，使用PNGOUTWin这个优化PNG图片的工具，确实不错，可以优化减少png图片20%的大小。
使用PHP的flush()方法，尽快的输出缓冲区的内容。
插入页面内的图片使用原始大小，并且显示声明width和height。
优化了主题style.css文件中粗糙而且耗时的代码，并且对它进行简写优化，减小文件大小。比如将全部声明border-radius的元素都放在一起来声明。圆角效果都是用CSS3的border-radius来渲染。
同时去掉了wp系统默认的很多没用的css class类
经过firebug发现，网友头像的加载会导致“忙指示器”持续很久，用户体验效果低。所以就去掉网友评论中头像动态加载显示的功能(一般都是来自：www.gravatar.com)，将动态的头像图片修改为站内的一张静态图片。
合并css和js文件并压缩（高亮插件和评论插件）