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.
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.
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 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> <IfModule mod_headers.c> #Make sure proxies don't deliver the wrong content Header append Vary User-Agent env=!dont-vary </IfModule> </IfModule>
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.
The configuration settings are similar to the gzip compression settings. They can go into the .htaccess file, or a globally included configuration file:
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.
Other WordPress Speed Tweaks
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!