Showing related content to your users is important. I don’t think there’s anyone disputing that (at least not that I’m listening to). The real question is “how?” How can you show your user good related content without adding a ton of extra work for yourself? This is where related posts plugins come into play.
There are a lot of options out there. So many that it’s quite time consuming to try them all until you find one that suits you. Two of my favorites are WordPress Related Posts and Yet Another Related Posts Plugin (YARPP). Yarpp gives you more control over how matches are made, but for that very reason it’s also less efficient. Joost de Valk referred to it as a “heavy plugin” in his article on Optimizing WordPress database performance, and it definitely is. WordPress Related Posts is far more efficient, but offers you a little less control over how matches are made. Unfortunately they share the same problem.
So what is this problem? They all find matches to a post in the front end rather than the back end. They do it when a user views a specific post, rather than when a post is created or modified. On a brand new site I launched, which has only 7 posts, we’ve received roughly 2000 pageviews. That’s pretty low, but lets take a look at it. About 700 of those visits were to the home page and about 1300 were to single post pages. If you only show related posts on single post pages (which is how we currently do it) then the related posts plugin has been run over 1300 times for only 7 posts, which is roughly 185 times per post! If I were to show related posts for each post on the front page then it would have run another 4000 times (which is a conservative estimate), bringing it to 757 times per post. If you think this seems excessive, lets take a look at the stats for Web Developer News. It has had over 13,500 page views in the last 30 days. About 750 were to the home page, about 140 were to other static pages, roughly 550 were to tag pages, and another 250 were to miscellaneous pages such as search pages. That leaves 11,810 visits to single post pages and 21 posts during that same time. That’s about 562 times per post! If I added related posts to the home page, tag pages, and search pages it would need to be run roughly another 15,000 or 1,276 times per post.
In addition to the simple waste of memory and cpu cycles, putting the calculation of related posts on the front end means that when they start to slow down your users are left with a bad experience and slow loading pages. And they will slow down eventually, if your site gets big enough. I just recently worked on a site with more than 6,000 posts and over 1,800 tags (they offer investing advice, and have a lot of tags that correspond to ticker symbols). At that point, some of the related posts queries were taking 10 seconds to run. That’s really show. We can do better than that right? Well it’s not easy but I think we can.
I would always prefer that I (or my content creators) have to wait, rather than make my users wait. So, the logical solution would be to match related posts when a post is saved, and store them in the post’s meta data. Simple and solved right? Wrong. If that’s all you did, then posts would only ever be related to posts older than themselves. This would mean that part two of a series would likely relate to part one, but part one would never relate to part two. We solved the speed issue, but we took a huge hit in functionality. However, a plugin that I’ve developed and am testing takes it farther than that. When a post is saved, it’s related posts are saved, but all possible related posts are spidered and checked to see if they need to have new matches calculated for them.
For extremely large sites, the plugin still causes delays when you save a post. However, better you than your user. If you’re interested in using this plugin, I’ll be releasing it soon and I’ll add a link to it here when I do ((Efficient Related Posts)). However, for now I need a name for it! I originally called it Related Posts – High Volume because it was meant to fix issues on high-volume sites. However, since it can apply to almost any site, I’m looking for an inspired name that really lets people know what it can do. You can leave any ideas you have in the comment here or send them via twitter to @aaroncampbell or @wpinformer.