本来一心想着换个传输速度快的空间，所以不怎么注意运行时间（太相信DreamHost了），知道现在发现首页居然有35次查询和3～8s的查询时间，我感觉这开始是个严重的事了。之前在yskin那照着优化了一下，优化到了0.5s以下，现在看来似乎“反弹”了，前几次升级过程可能忘记“继承传统”。
先在wp-config.php文件里添加
再在footer.php文件的
尾部加上一句
然后刷新首页（需要研究哪一页就到那一页去），查看源代码，最末处就是了，前面的几个都是提取wp_options里的设置信息，时间比较短的，然后会有一个查询最新几条文章的ID号的SQL：SELECT SQL_CALC_FOUND_ROWS zc_posts.* FROM zc_posts WHERE 1=1 AND (post_type = ‘post’ AND (post_status = ‘publish’ OR post_status = ‘private’)) ORDER BY post_date DESC LIMIT 0, 10 它在我这里的运行时间也不过0.023s，还会有查询page页的SQL语句，也不过0.01s。似乎用时比较多的就是提取文章信息，这里用了0.17s。但是总之我没有发现比较耗时的东西，难道是我的一些插件耗时？于是在页首和页尾（都应在<html></html>之内）都加了一条
反正是用来对比时间差，也没必要转成北京时间。似乎从这里看来，耗时不多，但我也不确定这样是不是整体的运行时间。那么再开cache功能吧！在wp-config.php里加上一句：
效果果然明显！查询次数立即降到16次，而Cold/Warm/Miss:38/864/0，太棒了！哥哥yskin说自己榨干了，也只不过是18次查询11个miss罢了。可是我的查询时间仍然没有减少！依然在1.75s左右，可是通过前面的方法，把所有项加起来也不过0.15s，不知道究竟是怎么回事。这里的“优化WP攻略”中要合并压缩js和css的做法有点“骨灰”，虽然K2那么乱七八糟的五六个Js经常招人骂，但是还是可以承受的，而css压缩我比较赞同，但仍不可以过火，如果希望把所有css都放在一起，那么就对修改和更新十分不利，除非你的网站一年内不会改变一点点的样式。而我前几天把date-stamp插件的css放到trueblue的custom.css里（当然要在插件的php文件里去掉在页首加入css声明的语句），一共才十几行嘛，后来觉得那个date-stamp插件实在有点小题大做，索性在theloop.php里直接写了段类似的php代码代替之。还有coolcode和pagepost几个插件的css全部给我合并到了custom.css里，不过千万注意其中引用图片的相对链接需要修改。
其实总体来说，DreamHost的空间对于国内用户，整体运行性能当然很好，但是瓶颈就在于传输速度，而其中比较重要的是http request耗时。比如现在heymu.com的DNS服务器是DreamHost.com的，通过这个测试，可以看出和google.com的DNS响应水平居然都是A＋，但是heymu.com的前几个转换都耗时较大，最终整体的联通时间较长，加之文件比较杂碎，就会产生整体速度的放缓。
