This is a guest post by Neil Matthews of WPDude.com. You can find out more about him at the end of the post.
I’ve been working with Joe for some time offering him WordPress technical support on his new site Zen Optimise and on his previous site seotraining.org.uk. At times he has found his WordPress website slow.
Joe hired me to provide a performance tune-up of his new site after it went live and thought it would be a great idea to document the process and show what you should be doing to speed up your site.
Why You Should Performance Tune Your Site?
I’m possibly stepping outside of my area of expertise and into Joe’s, but you should speed up your site because it is suspected that page load speed is one of the variables Google and other search engines use when they rank your site.
Research by Google showed that slow-loading sites have a larger abandonment rate than fast sites. It’s Google’s job to send searchers to the best match for their search phrase, so if it is known slow-loading sites are not the best match and your site is slow, why would Google send people your way?
Performance Tuning Methodology
The rest of this post will focus on what I did to optimise Joe’s site and to get it loading as quickly as possible.
I’ve got a fixed method for performance tuning a site: I go through each layer of WordPress looking for and fixing bottlenecks as I go. These are the steps I take:
- Create a baseline so I have objective not subjective data on the performance of a site, e.g. “it takes 10 seconds to load” not “it’s dead slow.”
- Test the theme for errors and bottlenecks and fix any issues noted.
- Test plugins and fix any issues noted, and remove any redundant plugins.
- Test WordPress core, make sure WordPress is configured optimally.
- Check the database for optimisation, huge tables, index issues and remove any redundant tables.
- Hosting configuration, make sure disk space is not maxed, ensure there is enough memory in php for WordPress, and make sure the correct version of php is present and it is configure optimally.
- Misc tests – review number of pages, spam comments, permalinks.
- Install and config cache plugin.
- Install and config CDN.
The first thing I always do when performance tuning a site is to take a base line. This give me subjective not objective data to work with. I can say at the start of the process “the site was loading in 10 seconds” rather than “the site is loading slowly.” I can say “Google page speed score is 45/100” rather than “traffic has dropped but I don’t know why.”
Here are the baseline stats I took before any work was done:
Google Page Speed Insights
Google’s page speed score 55/100 for desktop and 42/100 for mobile. You can get your own Google page speed score here.
Web Page Test
Using httpwatch I took a reading of an un-cached home page, it loaded in 12.9 seconds.
The site is installed on a high end server so this was an unacceptable set of results.
A Word Of Caution
Backup your site!
Always, always take a full backup of your site and know how to recover it before starting any performance tuning. We will be making changes to WordPress so know how to roll those changes back.
I did an analysis of the theme page load using a tool called httpwatch.com. Using this I can see what is being loaded from the theme (and plugins but I’ll discuss plugins later) and what is taking the most time. It helps me to spot bottlenecks.
Httpwatch gives me a detailed break down of load times. During the baseline test, I delete all cached files and cookies so we have a “cold” load time analysis. This give us the worst timing and something to build upon.
I’m looking for slow loading theme items, errors with the theme such as 404 errors. In the case of Zen Optimise, I cannot see any slow loading objects, but what I can see are a large number of very small images and theme files. These are good candidates for offloading to a CDN (content delivery network), more about that later.
At the time of review, 24 plugins were active on the site. No known performance hogs were seen (such as stat packages or membership site plugins). It’s hard to explain what is a known performance hog, this is something I have gained through experience tuning sites. Plugins like Statpress, redirection plugins with large logs, membership site plugins like Wishlist Member can all cause performance issues.
Two plugins were noted that were redundant:
- Hello Dolly – this is a test plugin to show how plugins work, this was disabled.
- Regen Thumbnails – this is a useful plugin but only need to be active when you want to regenerate your thumbnails.
My recommendation is to disable plugins that are not required 100% of the time, as each loaded plugin takes up memory and can impact on performance.
During my analysis of the page load speed I noted that the plugin ‘share this’ was introduction errors on the page load. These errors added on average 1 second to page load times. This is where performance tuning becomes a juggling act. This site needs to retain this plugin for the following functionality so sometimes slow loading components need to stay.
The total database size was 42 MB: this is not very large at all for a WordPress site. 100+ MB is very common for a site that has been around for some time.
The largest table by far was the posts table at 24 MB. There are not a huge number of posts and pages on this site so this made me think that there are a lot of redundant revision copies of Joe’s content.
I installed and configured wp-optimize and deleted all posts revisions. There were 3000+ revisions. After this process the options table was 7MB.
I added a new line to wp-config to prevent the number of revisions per post going above 5 copies.
define( 'WP_POST_REVISIONS', 3 );
Again just to re-iterate, I took a full backup before I deleted these revisions, just in case.
A corruption was noted on the options table (see below); this was repaired.
WordPress Core & Hosting Setup
When I reviewed the way Joe’s hosting was setup, it was not great. It had a low memory config of 32MB. This is a very small amount and it should be increased to at least 128MB, with 256 MB being a safer bet.
I reviewed the disk space used by the site and found it was at 2.4 GB. This did not cause me any great concern except for one area. wp-admin was the largest directory by far, when I analysed this further I found a massive error log.
Inside the error log where tens of thousands of reference to an error on the options table
21-Oct-2013 01:34:09 UTC] WordPress database error Table ‘wp_options’ is marked as crashed and should be repaired for queries
The error log was referring to an issue with the options table. I attached to the database and ran a repair process to fix this. Immediately the site appeared quicker. It’s likely this corruption in the database table may have been causing problems.
I made checks on the following:
- Number of pages used – the site has 30+ pages, this is not an issue, but sites with hundreds of pages (think 500+) can have performance issues. Always use posts over pages where it makes sense as WordPress is designed for them.
- Number of categories and tags – if there are huge numbers of categories or tags it can cause issues when adding new content. There are 0 tags and 9 categories on this site, no issue noted.
- Permalink settings – sometimes weird permalink settings can cause performance issues from the Settings -> Permalinks page, but this site has standard permalinks configured.
- Comment spam – I’ve seen several sites crash to their knees under the weight of comment spam, none was noted.
- .htaccess file – if there are unusual settings in the .htccess file such as cyclical redirects this can cause problems. I’m happy to report this was a vanilla .htaccess file.
Always the greatest performance increase I find is to install a cache plugin. My preferred plugin is W3 Total Cache. These are the modules I installed:
- Page cache – activating this makes the plugin capture a copy of a page and save it as a static web page. Removing the need to fetch the data from the database dramatically increases load speed.
- Browser cache – by activating the browser cache we tell Firefox, Chrome, IE et al. to save certain static things such as images locally and to not fetch them from the web server. A great example would be a browser cached copy of your logo, Instead of downloading it and having that load time, it fetches it directly from your hard disk. I also configured the site to send the data to browsers in a compressed format so the browser has to download small (read quicker) files.
Content Delivery Network
A content delivery network (CDN) is a way of downloading your content to a browser in parallel. Using a CDN we can offload loading of static content like images and static scripts to that service and just allow WordPress to concentrate on dynamic content.
Using W3 Total Cache we can add a CDN. I added a CDN from Amazon S3 and asked it to manage:
- Attachments and image uploaded
- Theme files
- wp-includes directory
Joe was a little uncertain about the validity of a CDN for a small site like Zen Optimise; it introduces a layer of complexity he did not want.
I installed the CDN and did a before and after test. The resulting performance increase was minimal so we decided to go without it.
I guess you want to know what all this work produced.
Home page load time 2.3 seconds with most of that time being made up of offsite scripts such as Share This and Google Fonts, the local files on the site loaded in 1.2 seconds.
Google page speed score of 90/100, the final 10% are for script files we are unable to change.
Webpagetest.org gave us 91/100, mostly As one B and an F for progressive JPEGs. I’m not a graphics person, but a quick re-save of those images will remove that F, so that job is back to the graphics designer.
You can find the full report here.
Guest author: Neil Matthews
Neil is the owner of WP Dude.com a small web development agency based in Newcastle that specialises in WordPress.