When it comes to web page load time, she should always say “wow, that was fast”.

A Quick update based on Frederick’s comment below

** Please do not take these tips as THE answer, this is a complement, not a replacement. I have purposely not given specifics on how to configure anything, or what value to set, because I don’t want people copy pasting things, and then having their site crashing. Regarding mod_pagespeed, I said it’s the most bang for OUR buck.. it’s not recommended in production, nor do we have it on for everyone else. **.

Webpage load time is getting more and more important these days, if you go into Google Webmaster Tools, you’ll see “Site Performance” under the labs link. This is a very good indicator of what Google thinks how fast your site is compared to the rest of the internet. As you can see from the graph, your site should load in less than 1.5 seconds. According to Google, this site is faster than 63% of the websites on the internet. At one point, we were faster, but then we went plugin crazy and got slower.. we’re working on making things fast again.

Here’s what we’re doing:

1. Use Mod Pagespeed . This is by far, the most bang for our buck. I’ve timed subsequent reloads of our page to less than 1 second now. Using this module, I can compress images, resize images, minify html, css, and javascript. I can even combine multiple css/js files into one.

2. Switch MySQL tables to InnoDB. But, only do this if the number of comments versus posts is disproportionate. Switching to InnodB prevents full table locks.

3. Turn on the MySQL query cache. Whenever possible, let the server do the caching, rather than a plugin.

4. Setup a reverse proxy using nginx (EngineX). This works great as you may still need multiple heads, and nginx gives you the best bang for the buck when it comes to reverse proxy/load balancing.

5. Setup your reverse proxy to serve certain assets via a static cache, this speeds up your load balancer even more, as it doesn’t need to go back to apache.

6. Setup your static cache to be in memory using tmpfs.

7. Use APC (this is a no brainer, but just in case, you forgot).

I’ll have more detailed posts along these topics in the coming weeks, I wanted to know what other methods you are using, before using the caching plugin du jour.

Caveat: Mod-Pagespeed is beta, it may eat your files, or kill puppies, don’t use it until you’ve tested it very very well.

7 thoughts on “How to make WordPress faster without the use of a plugin

  1. Frederick Townes

    I’ll apologize in advance for chiming in here. When I see posts that have circumstantial, superfluous or misleading “solutions” from a value perspective, it’s important that the uninitiated are not led astray into the world of diminishing returns, which in terms reducing the adoption rate and success stories for WordPress users. Specifically:

    – #1: mod_pagespeed is not a panacea and it will likely never be because services/tools that attempt to make assumptions about a web site will require just as much tuning for a complex site as they do for the webmaster to manually tune them (if doing that manually). Web app’s should be optimized from the inside out first, and your points #7, #3 do speak to that (so that’s nice). Learn more here about mod_pagespeed versus actually optimizing WP internally using proper tools: http://wordpress.org/support/topic/plugin-w3-total-cache-googles-mod_pagespeed-and-w3

    – #4, #5: This is not trivial and actually not enough. One of the most important things that one should do when trying to tune their site without the use of plugins is set correct headers for various mime types. That’s actually the number one tip. Followed closely by using a Content Delivery Network that supports mirroring of one’s entire site (pages and CSS, JS, images et al).

    – #6: A bad tip. The way that the kernel works in operating systems is such that when a file is written to the disk and frequently accessed, the kernel keeps that file in memory. When you use “RAM disks” the kernel cannot apply it’s algorithm and being the kernel offers the highest performance in the stack, you’re accomplishing nothing here except fragmenting your memory. Diminishing returns.

    – #2: Be specific about what you’re asking users to do, switching all tables to InnoDB means that search in WP becomes impossibly slow for even robust web servers. So the tip here really should be to switch the comments table and some others to InnoDB and then do others later as the needs change and therefore the server resources / options (like Sphinx etc). You should give settings on what safe query cache settings are for a stock WP install.

    – #7: What about the exact details on how to tune your APC settings to know that you’ve got things in a good place?

    What about other tips like: optimizing image sizes, moving javascript to the bottom of the page, (satisfying webpagetest.org’s test etc), reducing queries by using replacing bloginfo() calls in your theme etc etc?

    Most of performance tuning, like SEO, CRO etc is not just about turning things on or one-size-fits all solutions, it’s about learning some principles and applying them as appropriate.

    As for this site, it’s tough for me to say that it’s optimized: http://www.webpagetest.org/result/101214_34HE/

  2. fak3r

    As someone above just mentioned, Varnish is really an amazing tool in this regard. My current setup:

    Varnish (cache, load balancing, reverse proxy) -> nginx (serves all static content, uses memcached) -> fastcgi for PHP (uses APC) -> mysql (also uses memcached, and cached queries)

    For some testing a few months back I had to turn off Varnish for a time, immediately the mysql calls went up 2-3x. From this graph, you can see what happened on the 30th when I ran without Varnish: http://dl.dropbox.com/u/649440/geek/db_queires_graph-week.png

    I’ve posted about Varnish on my site, and continue to try and improve my setup, but Varnish gives a huge ‘bang for the buck’

  3. Vid Luther

    I agree on the varnish aspect, we’re using it for a client of ours as well, I actually found the setup of varnish simpler and faster than nginx. there are some minor issues with how WP does cookies that I’m troubleshooting, that’s why I haven’t mentioned it in this post yet. For our custom/higher traffic plans we’re really considering standardizing on varnish.

Leave a Reply