Tag Archives: caching

#wcbos: Advanced Theme Performance Techniques

Frederick Townes is the founder of W3 Edge, CTO at Mashable and author of W3 Total Cache. He’s presenting today on WordPress theme performance best practices.First, he recommends contributing back to the WordPress Codex because everyone in the room thinks it could be improved.

Pay lots of attention to the hierarchy with page templates.

Think about how many files you’re loading into memory, and the overall footprint they end up consuming. You can track this down using xdebug.

Fundamentals:

  • The larger the heap, the greater the execution time.
  • “Graduate” groups functions to plugins.
  • The fewer files the better.
  • Explore and use microformats for reviews, businesses & organizations, products, and people.
  • Use external services and fail gracefully.

W3 Total Cache has a debug mode that will show you what’s being cached on a request and what’s being missed.

Trick to debug on production:

define( 'WP_DEBUG', true );
// log to wp-content/debug.log, useful tests on production
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Proxy caching WordPress with Nginx

Nginx is a lightweight web server/load balancer/reverse proxy designed to drive blazingly fast websites. It has low resource requirements compared to Apache, the defacto standard for PHP-based applications, and can handle an order of magnitude more requests per second.

With WordPress, Nginx is often used in a few different ways: to serve static media assets, to execute PHP for WordPress, or to reverse cache Apache responses. You’ll want to install Nginx, put it in front of Apache, and then choose one option or go for all three. Mike Green has comprehensive documentation to cover the first and third scenarios. It’s more or less what I did at the J-School.

Epic foo is using Nginx as a reverse proxy cache. “Reverse proxy cache” means Nginx will generate a static cache of everything Apache responds with, and then serve this cache as long as you’d like. For us, this means homepage response time has dropped from an average of 1.5 seconds to around 25 milliseconds. On pages without a lot of secondary images and Javascript (e.g. not the homepage), load times are now wicked fast.

It’s worthwhile to note we’re only serving cache to non-authenticated users. Students and faculty expect our website to behave like an application, and to have changes they make appear immediately. This is less of an issue for other visitors. Caching also gives us protection against bursts of unexpected traffic.

Proxy caching was deceptively simple to implement. I spent around 15 work hours in September trying to get it to work, gave up until November, and then solved the problem in 15 minutes with a stroke of brilliance. Originally, I followed the configuration settings specified in Dan Collis-Puro’s awesome WordPress plugin and it took our setup to 80% completion. I then learned the most important thing is to tell Nginx to log cache hits; this makes it far easier to determine whether caching is working or not. The second most important thing is to turn proxy_redirect off. I still don’t fully understand what the declaration does, but it was the crucial missing piece. Seeing dozens of “HIT”s scroll by never felt so good.

Check out our commented master Nginx configuration file [txt] and the configuration file specific to journalism.cuny.edu [txt].