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.
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?
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:
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
I also took a recording from the webpagetest.org site and got some pretty poor results with lots of F grades (see above image and link) where it scored an overall page load score rating of 65%.
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.
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.
Here is a link to a spreadsheet of download times
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:
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.
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:
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:
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:
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.
Neil is the owner of WP Dude.com a small web development agency based in Newcastle that specialises in WordPress.
Designed, Built and Optimised by Joe the SEO
Leave a Reply