I was particularly interested in attending the WordPress Optimization session presented by Ben Metcalfe of WP Engine during WordCamp Philly. Considering that most of our end-users are on shared hosting and not well-versed on technical jargon, it’s common to receive questions on the support forums related to slow sites / servers / and optimization tips.

Ben provided a list of to-dos for WordPress optimization. Some are a bit technical and you may need a server admin to perform them, however others are do-able right from within WordPress. If I find a link to Ben’s presentation online, I’ll be sure to link directly to it. For now, here’s the quick list to consider depending on your setup and circumstances:

For all users

• Keep WP Updated – Always stay updated.
• Use a Cache Plugin – WP Super Cache or W3 Total Cache work for most users. Even WordPress.com uses a cache plugin.
• Deactivate Unused Plugins – If you have plugins you are not using, deactivate them. If you’re sure you do not need them, delete the plugins. Note that in some cases, even if a plugin is deactivated, it may still be loaded into memory. In short, be a neat-freak about your plugins.
• Avoid Bad Plugins – I provide a list of some of these on the support forums.
• Review Your Theme – roughly 1/3 of all optimization problems are due to theme code. Ensure it validates. When possible, place CSS at top and Javascript at bottom (not inline). If you see any weird code (i.e., making requests to other sites on the internet) then abandon that theme.
• Hosting – Check your hosting solution. Who is on your server? Use YouGetSignal’s Reverse IP Lookup if you wish to see other sites on your site. If you have non-kosher sites on the same server, ask your host to move you to another one. If you have a thousand other sites on your server, you have quite a packed server (or said differently, a terrible host).
• Offloading (poor-man’s CDN) – If you have the ability to offload your images or other large files (videos, etc.), do it. Flickr is a great solution for serving images.
• Feedburn your RSS Feed – Let Google’s FeedBurner handle your feed. Check your logs to see how many requests are made to your /feed url.
• Repair your MySQL Database – Be consistent in repairing your MySQL database. Once a month is fine for most users.
  • OptimizeDB plugin by Joost does this for you without any overhead
  • Use PHPMyAdmin – only if you are tech and db-savvy
  • Manually – only if you are tech and db-savvy
• Load from Multiple Sub-domains – To bypass limits on simultaneous processing, if you understand domain mapping and server administration, then look into using multiple sub-domains for serving files. Even better, try using different domains.

  Good: foo1.yourdomain.com, foo2.yourdomain.com
  Better: foo1.otherdomain.com, foo2.otherdomain2.com

• Browser Caching – W3 Total Cache will take care of this – HTTP cache-control, expires header, and entitry tags.

For Advanced Users and High Traffic Sites

• Log Slow MySQL Queries – check your logs! What’s taking the most time? Dig into it.
• Check Site with Profile Tools– use any of the tools below to dig into your site’s performance.
  • WP-Tuner
  • WPDB Profiling
  • WP Engine’s Speed Test
  • YSlow
• CDN – Use a CDN. It can be used all the time – OR – just in “emergencies.”
  • MaxCDN (used by WP Engine)
  • Amazon CloudFront
  • CloudFlare
• Smush Images – Let’s face it – you don’t sit there and optimize every image before uploading it to your site. The plugin below will do it for you.
  WPSmush.it plugin
• APC / Opcode cache – PHP-APC + W3-Total-Cache

• Apache Optimization – your server admin should be able to optimize your Apache server. When possible, disable .htaccess and use httpd.conf instead (central library that Apache uses).

  Do NOT attempt this unless you know what you are doing! It is not for beginners.

• Dedicated MySQLDB Box – Consider moving your MySQLDB Box to another server in the same data center.
• Reverse-proxy with nginx – Run Apache on port 8080. Cache static pages.
• Varnish Cache – Ideally, do not run Varnish on port 80 (even though some tutorials tell you to do so on port 80). Varnish cache doesn’t like cookies. Send cookies to nginx.
  Update – Jake’s Comment: Varnish VCL should be configured to destroy cookies when unnecessary (not logged) and to destroy cookie of static content.
• Memcache – Ideally, run Memcache on a separate box in the same datacenter under the same subnet.
• HyperDB – multiple database servers – not intended for the standard user.
• Static Site on Amazon S3 – If you can generate your site as static pages, Amazon can host them. Do not do this if your site requires any dynamic widgets or data processing.

Finally, here’s something that should be reinforced by everyone, do not edit WordPress core files. It’s not good practice and will be overwritten when you upgrade your WP installation.

Now, go optimize your site!