0

Not sure whether this one has been covered before - I certainly couldn't find anything relevant.

I am developing a fairly decent sized photography site which utilises a few different custom post types. The traffic of the current site is small at a few thousand visits a month.

The site is running on Genesis and my child theme is a completely custom theme.

Here is my basic query:

<?php
    $args = array( 'post_type' => 'venues', 'orderby' => 'menu_order', 'order' => 'ASC');
    $loop = new WP_Query( $args );
    if( $loop->have_posts() ):
    while( $loop->have_posts() ): $loop->the_post(); global $post;
?>

   <a href="<?php echo get_permalink();?>">
      <h3 itemprop="headline"><?php echo get_the_title(); ?></h3>
   </a>
   <p itemprop="description"><?php the_excerpt() ?></p>

<?php       
   endwhile;
   endif;
?>

The WP_Query is exactly as I have although the HTML that gets the title and the excerpt differs slightly.

The site loads at decent speed - around 800ms on the archive page with 18 posts, each containing a thumbnail of around 200kb.

My server is a VPS running 2GB RAM, Centos with Apache, PHP 5.5 FPM and Varnish. The site is running a PHP limit of 125MB, W3 Total Cache and 4 other minimal plugins (Yoast SEO, Ithemes security, ACF and Ninja Forms) so it's not a particularly heavy install IMO. The server is also running around 7 other light weight WP installs.

My question is - can I optimise the custom post type query to make it more efficient? The archive page only displays the post title, an advance custom field showing an image and the excerpt of the post.

I have seen blogs about using get_post and bypassing the caching to help increase performance but I didn't really notice any difference.

I know the site isn't very slow in comparison to other sites and the child theme is very lean indeed (I have optimisation OCD!) but I just wonder whether I can optimise the query any more.

Thanks in advance, D

1 Answer 1

0

It's not clear if you mean 800ms for total page load with assets and network overhead (which is quite good) or for page generation time alone (much less good).

In any case you are making a large mistake of guessing that query is your performance bottleneck. That's not how performance optimization works.

You need to measure what is happening first and draw any conclusions from that. There are both high level WP tools for that (Laps, Query Monitor, etc) and low level PHP tools (xhprof, blackfire, etc).

Speaking generally it is relatively rare for WP post queries to be easy to optimize. WP mostly uses database as dumb data store and is pretty decent at producing SQL for requests. Your query hardly looks complicated there either.

If you want to push it even further it is often practical to just cache data. Sounds like you are already doing that with Varnish for pages overall, but you can still cache bits and pieces explicitly for reuse to improve general performance. See Transients API.

4
  • That's on the high side, more so with Varnish in use... Still advice stands — measure properly before all else. :)
    – Rarst
    Commented Oct 8, 2015 at 14:49
  • The 800ms is according to Pingdom Tools for total page load testing from their Amsterdam site (My hosting data centre is in central London). In terms of optimisation of the query, I was just hoping that their might be a way of limiting what is called. From what I understand, when you query the post it brings up various things from the database. However, I only really need the excerpt and title from the database. I wasn't sure whether you can just limit the query to those, thus saving on database calls and 'optimising' the query.
    – WPDEVE
    Commented Oct 8, 2015 at 14:49
  • I have read about Transient API's however, I've never dabbled in it or looked at how I can implement it into my sites.
    – WPDEVE
    Commented Oct 8, 2015 at 14:50
  • Also, the 800ms is without using the cache, it's more like ~300-500ms to load around 2MB on the post type archive page.
    – WPDEVE
    Commented Oct 8, 2015 at 14:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.