WordPress – Slow Loading Time?

Many companies have problems with slow WordPress websites. There are many advertised ways to tweak, tune, and cache your way into the WordPress Speed Loading Championships. We’re going to show you a couple of changes that worked wonders for our clients. Hopefully they will work for you as well!

Page Speed Before

Here is a screen shot of the Google Page Speed plugin before tweaking WordPress. It was clocking in at 47/100, which means WordPress slow loading time to visitors. There were several things going on, some of which are outside the scope of this article. There are also several ways to analyze the web site to determine where exactly the bottlenecks are, some more complicated than others. We’re going to keep it simple.

For starters, the Firebug plugin for Firefox is your friend when troubleshooting speed issues on web pages. Use the “Net” time line to quickly identify the biggest delays when loading your web page. (If you’re feeling extra frisky, check out xdebug for PHP.) In boomcycle.com’s case, there were 3 images that stuck out immediately, as they were each taking over 4 seconds to load. The browser was downloading them concurrently, so it wasn’t as big of a delay as it could have been.

On to the tweaks…

MySQL Query Cache

OK, this is an easy one. Just add the following lines to your MySQL configuration file (usually my.cnf), and then restart MySQL. Unfortunately this little tweak is probably not available unless you have root access to a dedicated or VPS server. If that is the case, it doesn’t hurt to open a support ticket and ask if they would be willing to add it globally.

query-cache-type = 1
query-cache-size = 20M

These settings tell MySQL to use up to 20 Megabytes of cache to store common queries and their result sets. If there is more memory available on your server, go ahead and crank up the setting higher, but don’t go too crazy. More info on MySQL query caching can be found here.


This particular theme, Minimal, makes use of an image resizing (among other functions) script called timthumb. While this is a handy script, the version installed was fairly old and was taking over 4 seconds to read, resize, and then serve a thumbnail from a 300K image. The newest version shaved almost a full 3 seconds off the image load time due to better processing and caching.

The easiest way to tell if your theme is using TimThumb is to use the Media section of FireFox’s built-in Page Info utility. Just look for a URL with timthumb.php in it like this one:


That URL also helps you identify where the file is stored on your server. In this case, it is in wp-content/themes/Minimal, which is relative to the public html directory of the web user. Use that information to save a copy of the original and then upload the new version in its place.

gzip compression

We are constantly amazed at how many web sites out there don’t take advantage of this very useful setting. gzip compression allows the server to compress almost everything except images before sending it to the visitor, saving both time and bandwidth. Web browsers have been supporting gzip compression for years, so there’s almost never a reason not to use it.

For boomcycle.com, enabling gzip compression saved over 180k per initial page load. (After the initial view the browser has usually cached the content, unless another web server configuration setting is not enabled – more on Expires Headers in a minute.) Sure, 180KB of bandwidth savings doesn’t sound like much, but multiply that by 10,000 visitors and you’ve just saved over 1.8GB of bandwidth! That also means your web server can spend more time handling other requests instead of being tied up delivering large, single-threaded resources like Javascript (more on that subject in a minute as well.)

First, check to see if gzip compression is enabled on the web server in question. There are several ways to do this, but by far the easiest is with this web site:


That compression test will also report how much there is to gain by enabling gzip compression. One thing to keep in mind is that all modern image formats are already highly compressed, so enabling gzip compression for images will actually have the opposite result.

Various speed checking plugins for Firefox will also tell you if gzip compression is enabled, but we have experienced false information due to aggressive browser caching.  There is nothing more frustrating than chasing your tail trying to troubleshoot a issue that doesn’t really exist. Instead, use a third party point of view that hasn’t cached the web site in question.

In order to enable gzip compression on your web server, it has to be compiled in and available. If your web site is on a shared hosting provider, then you’ll have to open a ticket to request enabling gzip compression globally. It’s better for you; it’s better for them; it’s better for all of their customers.

The following settings are typical gzip compression settings for Apache 2.x web servers. The settings are surrounded by an IF statement to ensure it doesn’t break your web site if for some reason the compression module is unavailable. This configuration can be placed in the main .htaccess, or in a global included configuration file.

<IfModule mod_deflate.c>
    SetOutputFilter DEFLATE
    <IfModule mod_setenvif.c>
        # Netscape 4.x has some problems
        BrowserMatch ^Mozilla/4 gzip-only-text/html
        # Netscape 4.06-4.08 have some more problems
        BrowserMatch ^Mozilla/4.0[678] no-gzip
        # MSIE masquerades as Netscape, but it is fine
        BrowserMatch bMSIE !no-gzip !gzip-only-text/html
        # Don't compress already-compressed files
        SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary
        SetEnvIfNoCase Request_URI .(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
        SetEnvIfNoCase Request_URI .(?:avi|mov|mp3|mp4|rm|flv|swf|mp?g)$ no-gzip dont-vary
        SetEnvIfNoCase Request_URI .pdf$ no-gzip dont-vary
    <IfModule mod_headers.c>
        #Make sure proxies don't deliver the wrong content
        Header append Vary User-Agent env=!dont-vary

If the settings are put into .htaccess, the changes will take place immediately upon next page load. If they are in a main Apache include file, the service must be reloaded or restarted for the changes to take effect.

Expires Headers

Most web sites have static content that rarely or never changes. Images, style sheets, javascript, etc. This content should be delivered with appropriate expires headers so that the visitors to your site will have the content cached in their browsers instead of having to request it for every single page load. The result is less bandwidth and resources used on your server, and a much faster user experience for your visitors.

The configuration settings are similar to the gzip compression settings. They can go into the .htaccess file, or a globally included configuration file:

<IfModule mod_expires.c>
    # Remove ETags if mod_expires is controlling caching
    Header unset ETag
    FileETag None

    ExpiresActive on
    ExpiresByType image/jpg "access plus 60 days"
    ExpiresByType image/png "access plus 60 days"
    ExpiresByType image/gif "access plus 60 days"
    ExpiresByType image/jpeg "access plus 60 days"

    ExpiresByType text/css "access plus 1 days"

    ExpiresByType image/x-icon "access plus 1 month"

    ExpiresByType application/pdf "access plus 1 month"
    ExpiresByType audio/x-wav "access plus 1 month"
    ExpiresByType audio/mpeg "access plus 1 month"
    ExpiresByType video/mpeg "access plus 1 month"
    ExpiresByType video/mp4 "access plus 1 month"
    ExpiresByType video/quicktime "access plus 1 month"
    ExpiresByType video/x-ms-wmv "access plus 1 month"
    ExpiresByType application/x-shockwave-flash "access 1 month"

    ExpiresByType text/javascript "access plus 1 week"
    ExpiresByType application/x-javascript "access plus 1 week"
    ExpiresByType application/javascript "access plus 1 week"

If you’re curious what the ETags setting is for, feel free to Google it. In our experience ETags is not a big deal one way or another, but it always shows up in the speed test results if it is not disabled.

The other settings are perhaps self-explanatory. Adjust them according to your web site usage and update habits. If you frequently alter flash content, then just change the application/x-shockwave-flash expires setting to “access plus 1 day” instead of 1 month. If you have a WordPress blog where existing content never changes, then it’s probably safe to crank most of the settings to several months instead.

WordPress Plugins – DB Cache Reloaded and Hyper Cache

There are plenty of WordPress caching plugins to choose from out there, so how do you decide which one is right for your web site? The answer is by a lot of trial and error, or a lot of reading comments regarding other people’s experience.

We’ve tried many different caching plugins, and by far the most impressive is a combination of DB Cache Reloaded and Hyper Cache. They work wonders with out-of-the-box configuration, and should not interfere with anything WordPress is trying to do. Having said that, they might not be compatible with other caching plugins, so it’s best to delete the old cache stores and then disable the other plugins before activating DB Cache Reloaded and Hyper Cache.

Page Speed After Tweaks

After all the above tweaks were implemented, the increase in speed was significant, both on paper (66/100)  and most importantly, in user experience (sub-two second load times).

NOTE: When testing with Page Speed, be sure to hold down the SHIFT or CTRL key while pressing F5 in your browser. This will force the browser to request all of the content from the web server, regardless of what is in the browser’s cache. Do this a couple of times to ensure the caching has been activated in the WordPress plugins, and then run the Page Speed test. The result should be obvious in Firebug. For example – once TimThumb has cached the thumbnails, the image load times dropped from over 4 seconds to 500 – 900 milliseconds.

Interestingly, the Firefox version of the Page Speed plugin reported an even better score than the Chrome version – 79/100. That’s on par with some of the biggest and most popular web sites on the internet today.


The only way to get a much better rating is to combine JavaScript and convert everything to static content.

Other WordPress Speed Tweaks

You might have noticed that Page Speed mentions Javascript in several places in all the reports. There is a good reason for this. When the web browser requests Javascript content, it does so one at a time, essentially blocking all other requests for content until the Javascript is downloaded completely. (The reason for this seemingly odd behavior is beyond the scope of this post. Google it if you’re curious.) The impact in this case is  a 66/100 Page Speed instead of a much higher result, since the browser had to request 6 different Javascript files.

There is only one way to resolve this problem, and it can cause serious issues and upgrade headaches in the future. We do not recommend implementing the change unless you really know what you are doing. The resolution is to combine all javascript sources into one large file, and then update the source html/php/template so that it only references one file. If your WordPress theme makes proper use of headers and footers, this might actually be a fairly easy change to make. Upgrading the theme or making other WordPress changes could easily break what you’ve changed, however.

The other recommended change relating to Javascript is to move all the Javascript to the end of the page instead of at the top. The result is that all the visual content is loaded before the Javascript loads, making it appear that the page loaded much faster than it really did. This is also not a change to take lightly, as it could very easily break your web site.

By far the best method of speeding up a WordPress web site is by using a plugin that pre-caches all of the content, and then serves it as static html files instead of dynamic content. The result is blazing Page Speed times in the low to high 90’s. However, this particular method of caching will not work for a majority of WordPress blogs due to the liberal use of dynamic content – ads, tag words, comments, etc. Usually if the WordPress site is busy enough to warrant this type of pre-caching, the visitors will be expecting constant updates, defeating the whole purpose of pre-caching to begin with (and if the site is that large and busy, then it’s probably time to invest in some dedicated servers with all of that ad revenue coming in!)

We hope you’ve found this information helpful for speeding up your WordPress website. If you still need faster website speed, Boomcycle would love to help!


Leave a reply

Boomcycle is a San Ramon, California technology consulting and custom software solutions provider. We enjoy stable, long-term relationships with dozens of highly-skilled and experienced technology business experts, software engineers, project managers, web designers and software architects throughout the United States.

Would you like to save money and increase the value of your business?

Let’s Talk


The contact form prepares us to help you as quickly as possible

Let’s Talk