思量再三，换成了 ProwerV6 这个主题，把用了许多年的 iGoogler 主题换掉了。为什么要换呢？因为——响应式设计。这可以省掉插件。但是，问题就来了——不支持IE6，这个真的没办法，算了吧。

旧主题的各种优化教程，我还是会发，算是为 iGoogler 主题做的最后一点贡献。

找不到“友情链接”的博主，请留意底部。

因为原主题在某些特殊IE内核浏览器的侧边栏会出问题，不用侧边栏又不爽，所以又换了一个主题。加上学习一下 WordPress 子主题的制作，在每天挤出短短时间，使用 WordPress 子主题方式做出了这个主题。

部分修改：

• 增加版权信息提示
• 修改底部
• 完善 Google 结构化数据
• 添加“无插件”PageNavi
• 汉化部分
• 合并 JS、CSS 文件

而且，这个主题支持 Retina 显示屏，不错，但是不好的地方是需要加载的 JS 太多了，我调了半天，勉强不需要那么多了。

这个教程主要是方便和我一样使用 iGoogler 主题的人，能给自己的站点提一下速。因为一个效率优化做得那么好的主题，如果你还觉得速度慢，那真的是你不会使用了。

WordPress Object Cache 简介

WordPress Object Cache（WordPress 对象缓存）是 WordPress 自身的缓存机制，它的主要功能是把负责查询或者运算的结果按照 Key-Value 这样的方式（WordPress 还支持按照 Group 来划分和避免缓存的内容冲突）存储到对象里面，下次进行同样操作的时候，可以让直接从这个对象中取出数据，不用重复到数据库中或者其他外部网站获取数据。

由于 WordPress Object Cache 的特性，这个自身的缓存机制注定要配合服务器设置（财大气粗呀～）以及插件。如果你和我一样，没办法接触到类似于 Memcached 之类的东西的话，我推荐你使用 WP File Cache，他能帮助你把数据查询缓存到文件中。这样效率和速度都非常快的。如果不配合服务器设置和插件的话，个人感觉是没有什么作用的。

使用 WordPress Object Cache

下面我将以 iGoogler 主题的“相关文章”为例，说一下如何使用 WordPress Object Cache。

我们知道 “相关文章”的获取原理是通过文章的 Tags 来获取相关文章，相同的 Tag 越多，相关性越强，这样就需要进行大量的数据查询，大大降低了站点的效率。但是，一篇文章，在短时间内，它的“相关文章”是不会变动的，所以我们就可以使用 WordPress Object Cache 对“相关文章”进行加速。

下面是把“相关文章”的数据写入缓存的例子，缓存时间为一个小时，即 3600 秒。

打开主题的 loop_single.php，将

<?php echo wp_get_related_posts_igoogler(10); ?>

替换为

<?php
global $post;
$related_posts_data = wp_cache_get($post->ID, 'related_posts');
if(false === $related_posts_data){
	$related_posts_data = wp_get_related_posts_igoogler(10);
	wp_cache_set($post->ID, $related_posts_data, 'related_posts', 3600);
}
echo $related_posts_data;
?>

代码大意是：如果在缓存中找不到数据，就查询数据库，然后再将数据写入缓存，并设定过期时间为一个小时，即 3600 秒；如果找得到缓存，并且缓存没有过期，就直接使用缓存的数据。

这个教程主要是方便和我一样使用 iGoogler 主题的人，能给自己的站点提一下速。因为一个效率优化做得那么好的主题，如果你还觉得速度慢，那真的是你不会使用了。

WordPress Transients API 简介

Transients 是瞬时的意思，WordPress 的 Transients API 就是 WordPress 用来存储一些缓存的数据到数据库中最简单也是最标准的方法，Transients API 给这些缓存的数据一个过期时间，并且时间到就会自动删除，所以如果你需要存储一些有生命周期的选项的时候，Transients API 就是最好的选择。

更让人感到欣喜的是，WordPress Transients API 不需要配合任何的服务器设置和插件。

使用 WordPress Transients API

下面我将以 iGoogler 主题的“最多评论的文章”为例，说一下如何使用 WordPress Transients API。

我们知道 “最多评论的文章”的获取需要进行大量的数据查询，大大降低了站点的效率。但是在短时间内，一个博客的“最多评论的文章”是不会变动的，所以我们就可以使用 WordPress Transients API 对“最多评论的文章”进行加速。

下面是把“相关文章”的数据写入缓存的例子，缓存时间为一天，即 86400 秒。

打开主题的 sidebar_r.php，将

<?php echo get_most_comments_posts_igoogler(5);?>

替换为

<?php
$most_comments_posts_data = get_transient('most_comments_posts');
if(false === $most_comments_posts_data){
	$most_comments_posts_data = get_most_comments_posts_igoogler(5);
	set_transient('most_comments_posts', $most_comments_posts_data, 86400);
}
echo $most_comments_posts_data;
?>

代码大意是：如果在缓存中找不到数据，就查询数据库，然后再将数据写入缓存，并设定过期时间为一天，即 86400 秒；如果找得到缓存，并且缓存没有过期，就直接使用缓存的数据。

由于我的博客较小，所以不需要太短的时间（在短时间内不会变动），如果你的博客较大，并且配上了其他缓存插件，你可以尝试使用“我爱水煮鱼”推荐的一个值——12 小时，即 43200 秒。

这个教程主要是方便和我一样使用 iGoogler 主题的人，能给自己的站点提一下速。因为一个效率优化做得那么好的主题，如果你还觉得速度慢，那真的是你不会使用了。

下面我将以 iGoogler 主题的“相关文章”为例，说一下如何巧用 PostMeta 提速。

我们知道 “相关文章”的获取原理是通过文章的 Tags 来获取相关文章，相同的 Tag 越多，相关性越强，这样就需要进行大量的数据查询，大大降低了站点的效率。但是，一篇文章，在短时间内，它的“相关文章”是不会变动的。所以我们就可以使用缓存对“相关文章”进行加速。

第一个方法是使用 WordPress Object Cache，这个方法需要配合服务器设置或插件，，否则基本没用，这也许会令某些人大感不爽。

所以下面我就要讲第二个方法——巧用 PostMeta：

PostMeta 加速原理

我们知道，PostMeta 表是用来存储 Post 其他自定义字段，比如你可以在 WordPress 编辑界面自定义字段那里使用它。那么我可以把当前文章的“相关文章”数据写到 PostMeta 中去，并记录写入的时间。然后再取出，就可以达到加速的效果。

巧用 PostMeta 提速

下面是把“相关文章”的数据写入缓存（PostMeta）的例子，缓存时间为一个小时，即 3600 秒。

打开主题的 loop_single.php，将

<?php echo wp_get_related_posts_igoogler(10); ?>

替换为

<?php
global $id;
$related_posts_data_old = get_post_meta($id, "related_posts", $single = true);
if($related_posts_data_old){
	$time = time();
	if(($time - $related_posts_data_old["time"]) < 3600){
		echo $related_posts_data_old["related_posts"];
	}
}else{
	$related_posts_data = wp_get_related_posts_igoogler(10);
	$related_posts_data_new = array("time"=>time(), "related_posts"=>$related_posts_data);
	if($related_posts_data_old){
		update_post_meta($id, 'related_posts', $related_posts_data_new);
	}else{
		add_post_meta($id, 'related_posts', $related_posts_data_new, true);
	}
	echo $related_posts_data;
}
?>

代码大意是：如果在缓存（PostMeta）中找不到数据，就查询数据库，然后再将数据写入缓存，并设定过期时间为一个小时，即 3600 秒；如果找得到缓存，并且缓存没有过期，就直接使用缓存的数据。

今天在网上看到一个很有意思的段子，在接送回家的路上，深有所感，略作修改：

放学路上，千里车流，万里人潮。望大街内外，车行如龟，司机烦躁，一步不动，总是红灯憋出尿。交通如此多焦，引无数学生上公交。惜奥迪A6，慢如蜗牛。奔驰宝马，无处发飙。一代天骄，兰博基尼，泪看电驴子把车超。俱往矣，还数自行车，边蹬边笑。

其实这首诗有点儿万能，很多都能套上去。

这个教程主要是方便和我一样使用 iGoogler 主题的人，能给自己的站点提一下速。因为一个效率优化做得那么好的主题，如果你还觉得速度慢，那真的是你不会使用了。WordPress 小工具其实是速度变慢的根源之一，因为这会引发许许多多的数据查询。所以，尝试自己手写 SideBar 吧，这并不难。而且，这样也有利于我们使用 WordPress Transients API 和 WordPress Object Cache 等缓存。

如果你不会写，那么可以参考我的：

打开主题的 sidebar_l.php，全部替换为：

<h3 class="lbar_title">
	<a><?php _e('分类目录')?> </a>
</h3>
<div class="lbar_content">
	<ul>
		<?php wp_list_categories('show_count=1&hierarchical=1depth=2&title_li='); ?>
	</ul>
</div>
<h3 class="lbar_title">
	<a><?php _e('时间选择');?> </a>
</h3>
<div class="lbar_content">
	<ul>
		<?php wp_get_archives(); ?>
	</ul>
</div>
<h3 class="lbar_title">
	<a><?php _e('标签云')?> </a>
</h3>
<div class="lbar_content">
	<ul>
		<?php wp_tag_cloud('smallest=10&largest=14&number=20&order=RAND'); ?>
	</ul>
</div>
<h3 class="lbar_title">
	<a class="current"><?php _e('友情链接')?> </a>
</h3>
<div class="lbar_content" style="display:block;">
	<ul>
		<?php wp_list_bookmarks('title_li=&categorize=0');?>
	</ul>
</div>
<div class="line"></div>

打开主题的 sidebar_r.php，全部替换为：

<h3>最新文章</h3>
<ul>
	<?php echo get_latest_posts_igoogler(5); ?>
</ul>
<h3>随便看看</h3>
<ul>
	<?php echo get_random_posts_igoogler(5); ?>
</ul>
<h3>最受欢迎</h3>
<ul>
	<?php
	$most_comments_posts_data = get_transient('most_comments_posts');
	if(false === $most_comments_posts_data){
		$most_comments_posts_data = get_most_comments_posts_igoogler(5);
		set_transient('most_comments_posts', $most_comments_posts_data, 86400);
	}
	echo $most_comments_posts_data;
	?>
</ul>

效果可参考本站。

因为原主题 Google PageSpeed 得分太低，令我感觉各种不爽，所以，又换了一个主题。

挑来挑去不见喜欢，最终发现。其实 WordPress Twenty Twelve 主题也挺不错的，然后 Copy 一份，动手修修改改，就弄成了现在这副模样。

具体修改有：

• 更改为 Page Navi（免插件）
• 去除 CSS 自动大写
• 静态化侧边栏
• 添加 Ajax Comments
• 完善结构化数据
• 添加版权信息
• ……

Page Speed  一下，85 分，令我感觉不错了，也许有一段时间不会再换了。

大家都知道，我爱水煮鱼写了一个“WPJAM DeBug”插件，用于检测 WordPress 的效率。主要是针对“很多同学说 WordPress 的效率很低，但是又说不出哪里效率低的”问题。

可是这个插件竟然要收 ￥4.99，所以，我也折腾了一下，以代码的形势山寨了一个 WPJAM Debug。

功能很简单，在当前页面的 url 后面加上 ?debug，然后页脚就会显示当前页面有多少条 SQL 查询，页面生成花了多少时间，并且把 SQL 按照执行顺序和按照耗时两种方式列出。

其实启用这个功能很简单：

1、编辑 wp-config.php，在合适的地方加上

define('SAVEQUERIES', true);

2、编辑主题的 Functions.php，在末尾加上

<?php
function nikbobo_debug()
{
	if ( isset($_GET['debug']) && current_user_can('level_10') ) {
	echo "Made " . get_num_queries() . " queries in " . timer_stop(0) . " seconds";
	global $wpdb;
	echo "<pre>";
	print_r($wpdb->queries);
	echo "</pre>";
	}
}
add_action('wp_footer', 'nikbobo_debug');
?>

好了，登录试试看吧！在任意页面加上 ?debug，是不是在页脚显示了？各位 WordPresser，大胆根据这个找出令你站点变慢的原因吧！