Using get_posts vs. WP_Query

This is directly related to, and a consequence of WordPress.com VIP

At VIP, we deal with sites that range in the hundreds of millions of page views per week. As a result, situations that can slow down your site are much more noticeable at that scale than on a small shared host, but this still impacts a site with moderate traffic in the region of 100 or so users on a decent VPS. We also code review everything before an agencys code reaches production

get_posts in particular doesn’t cache its results. If you make the same get_posts call 5 times, it will go to the database 5 times, rather than saving the result for later. WP_Query doesn’t do this, and has much better caching around it, as well as other optimisations that aren’t possible in get_posts because of how it returns the entire post fully formed.

There is a way to make get_posts cache the results however, the suppress_filters option is true by default, but if you set it to false, the caching mechanisms inside WordPress will do their work, and results will be saved for later.

As for where these are stored, there’s an object caching system called WP_Cache. By default, this will store anything you put in it and keep a hold of it ( don’t go implementing your own cache to prevent work being done multiple times in a page load, WP has you covered! ).

However, there are plugins that provide advanced-cache.php or object-cache.php, WP_Cache can be made persistent. For example, batcache will make WP_Cache use memcached to store things, letting data persist between page loads, improving performance significantly. There are similar plugins for Redis/memcache/etc

I recommend you look at https://vip.wordpress.com/documentation/, some of it is specific to the WordPress.com VIP platform, but other parts are important for performance and security. There’s also a VIP Scanner tool that detects other things, such as uncached function usage.

Leave a Comment