Wordpress Case History - Reducing Loading Time

12 Steps Taken to Reduce Loading Time from 7-15 Seconds Per Page to Less Than a Second

Last Updated Please share our content if it is helpful

A customer recently called us to say that their WordPress website was taking 5-15 seconds per page to load, with an average page load time of 7-8 seconds. We had already installed some obvious “speed” plugins – W3Cache and Smushit.

We have listed below the steps we took to reduce this time to less than one second.

Step 1: Analysing What was Taking the Time

Pingdom Website Speed Test is a useful guide. It gives you an idea of how long different images and files take to load; note, however, that this may vary from run to run. Be on the lookout for any missing images (they will massively slow the page down).

Pingdom speed test results: before changes


One of the most frustrating things about the Pingdom test, however, is that it does not break down the initial “chunk of time” (Pingdom shows this as a long line, often mainly yellow; many call this time to first byte) before any of the plugins or images will begin loading (this wait time is often the killer for WordPress speed). Indeed, it appears as if these plugins all load AFTER that initial time and do not affect it.

To get a better insight into this, temporarily install P3 Performance Profiler Plugin (it can be deleted once you have gained all useful data). This clearly showed us that the plugins were taking up a staggering 75% of our load time and it identified the plugins that were taking the longest to load.

WordPress Plugin Profile Report
Report date: January 28, 2015
Theme name: mrba
Pages browsed: 17
Avg. load time: 7.9749 sec
Number of plugins: 13
Plugin impact: 75.24% of load time
Avg. plugin time: 6.0007 sec
Avg. core time: 1.8200 sec
Avg. theme time: 0.2150 sec
Avg. mem usage: 45.79 MB
Avg. ticks: 6,865
Avg. db queries : 33.35
Margin of error : -0.0607 sec

Plugin list:
P3 (Plugin Performance Profiler) – 0.0279 sec – 0.47%
Addthis – 3.2684 sec – 54.47%
Awesome Flickr Gallery Plugin 3.tmp – 1.1659 sec – 19.43%
Cimy Header Image Rotator – 0.0306 sec – 0.51%
Image horizontal reel scroll slideshow – 0.0369 sec – 0.61%
Members – 0.1178 sec – 1.96%
Fast Secure Contact Form – 0.2371 sec – 3.95%
TinyMCE Advanced – 0.0235 sec – 0.39%
UK Cookie Consent – 0.0074 sec – 0.12%
W3 Total Cache – 0.3248 sec – 5.41%
Wordpress Seo – 0.6189 sec – 10.31%
WP-Optimize – 0.0591 sec – 0.98%
WP Smush.it – 0.0822 sec – 1.37%

Other useful tools are Google Pagespeed Insights and Yslow (from Yahoo) – they give you different suggestions on how to speed up your site.

Step 2: Plugin Pruning

As a general rule, the fewer the plugins, the faster your site. It is all too easy to add a plugin for this and a plugin for that. Reducing plugins, however, is likely to play a LARGE part in your quest for speed.

From the P3 Performance Profiler, we could see that the three main plugin culprits were:

Addthis – 3.2684 sec – 54.47%
Awesome Flickr Gallery Plugin 3.tmp – 1.1659 sec – 19.43%
Wordpress Seo – 0.6189 sec – 10.31%

Tip: On Pingdom, it often appears that Addthis is loading after all of the other plugins and images.  With the aid of Performance P3, however, we were able to see that it (and other plugins) were affecting that killer initial “chunk of time” shown on Pingdom.

Our solution was to:

1 Remove Addthis (the customer, a charity, could do without it).

Tip: Whilst the customer could manage without social sharing, we wanted this functionality for our own site. We spent a couple of days trying different social sharing plugins on a test site (and writing our own code) and finally found that Floating Social Bar (used on this post) enabled our pages to load in less than .1 of a second and then loaded its files in about .35 of a seconds at the end of the page load. Unlike the Alternative Digg Digg plugin (another quick loader), it has a horizontal display option that enables it to be visible for mobiles and tablets (important in today’s market).

2 Remove the Flickr plugin and replace it with onsite images.

Conditional Loading Tip: Unhelpfully, the Flickr plugin was loading on EACH page even though it was only needed on a few pages. As Flickr have now announced that they are stopping support for WordPress plugins, and as the plugin was no longer being updated or maintained, we decided not to pursue conditional loading. If you meet a situation like this, however, then check out conditional script loading.

3 Replace the Yoast WordPress SEO plugin with custom fields. See Replacing SEO plugins with custom fields.

Tip: For other sites, we have used the custom fields trick to eliminate the need for other plugins. For example, on this page, the top masthead image can be changed for each page using a custom field – thus avoiding a plugin that we used to use in the early days of creating WordPress websites.

Step 3: Cleaning up After Plugins

Even after your deactivate a plugin AND delete it, many plugins leave files in different database tables. This can slow down your site. We used WP Cleanup Optimizer to remove some of files from the wp-options table.

Note: this plugin only removes files from the Options table.

Important tip: try to avoid adding and removing plugins from live sites; plugins do NOT always delete cleanly. If possible, test plugins on a test site.

 Step 4: Cleaning Up Your Revisions

WordPress has a – helpful? – feature that post and page revisions are automatically saved. Each time you save a post or page, this increases the size of your database. The larger your database, the slower your page will load. Our customer’s site had 10-20 revisions per page for many pages.

We used Wp-Optimize to delete historic revisions and to optimize the database.

Note: whilst it was not relevant to our customer as comments had not been enabled, this plugin can also be used to remove spam and trashed comments.

Tip: For advanced users, WordPress gives advice on how to disable post revisions by editing wp-config.php. We found that this did not work.

Step 5: Getting Rid of Unnecessary Database Queries and Server Requests

We reduced the number of database queries from 94 to 62.

Note: the Pingdom archive in the top-left image was taken part-way through our work; unfortunately, earlier archives had been deleted from Pingdom.

Part of this reduction came from deleting plugins.

We also, however, reduced the number of database requests by going through the source code in our header.php. sidebar.php and footer.php files and searching for all instances of ?php bloginfo. Many theme templates use ?php.bloginfo so that the same code will work when copied across to a different url. If it is your own site, however, you can hard-code each instance:

Examples of how calls to the database can be hard-coded

Tip: to find out the correct path, view the page source code. You can then copy and paste to avoid typos.

Tip: Other calls to the database to be aware of are cases where you are displaying the last x number of posts. The bigger numberposts is in the code below, the more times the database is queried. (Obviously, this type of code is better than using yet another plugin to display posts!)

 Code to display the last 4 latest news posts
Ideally, where possible, hardcode – for example, the Categories in the footer of this page are all hardcoded.

Step 6: Reducing Image Sizes

The larger your images, the longer your page will take to load.

We always use the Smushit plugin to losslessly compress all images loaded into the Media Library. Theme images, however, are loaded into your theme image folder (http://mysite.co.uk/wp-content/themes/mytheme/images/). Some plugins also load images into their own image library.

Google Speed Insights is a useful way of seeing which images can be losslessly compressed. We  downloaded these images, ran these images through image reduction software such as Yahoo Smush.it, and re-uploaded more streamlined images.

Tip: TinyPNG is a useful tool for compressing transparent PNG images.

Tip: Whilst out of the scope of this post, CSS Sprites is a way of combining several images into one so that HTTP requests are reduced. The fewer images you have, the faster your load time. (We had already made some use of CSS Sprites.)

Step 7: Leveraging Browser Caching

Even though we had ticked the browser caching box in W3Cache, Google Speed Insights was still showing that browser caching was not enabled. We therefore added the following code into our .htaccess file (found in your root directory).

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg “access 1 year”
ExpiresByType image/jpeg “access 1 year”
ExpiresByType image/gif “access 1 year”
ExpiresByType image/png “access 1 year”
ExpiresByType text/css “access 1 month”
ExpiresByType application/pdf “access 1 month”
ExpiresByType text/x-javascript “access 1 month”
ExpiresByType text/javascript “access 1 month”
ExpiresByType application/javascript “access 1 month”
ExpiresByType application/x-shockwave-flash “access 1 month”
ExpiresByType image/x-icon “access 1 year”
ExpiresDefault “access 2 days”

Tip: we found that adding this as the first lines worked best. You can obviously change the times (1 month, 1 year etc) to suit your site.

Step 8: Loading Google Analytics Asynchronously

Nowadays, Google gives you a script that loads asynchronously. If, like our client, you have a site that was coded a year or so ago, then get the latest version of Google Analytics tracking script.

Note: Google has a list of other scripts that should be made asynchronous (if used): Asynchronous Scripts.

Tip: Obviously, do NOT use yet another plugin to load Google Analytics.

 Step 9: Disabling Pingbacks and Trackbacks

Pingbacks and trackbacks are both ways of automatically informing other sites that you have linked to them; both can slow your site down.

To disable, untick the box in your Settings / Discussion:

Disable pingbacks and trackbacks

In the header.php, delete lines such as:

<link rel=”pingback” href=”http://mysite/blog/xmlrpc.php” />

Step 10: Caching Plugin

A good caching plugin, can massively speed up your WordPress site (even though it does take some time to load itself).

Once we had completed the steps above, we turned W3Cache back on.

Note: W3Cache takes care of recommendations in Google Speed Insights to minify CSS, javascript and HTML.

Step 11: CDN (Content Distributed Network)

Our hosting company makes it easy for us to use Cloudflare CDN with our sites. This massively speeds up loading time.

Tip: Cloudflare will only work with a www. version of a url (http://www.mysite.co.uk rather than http://mysite.co.uk). Be aware of this when you first create your WordPress site. For our customer’s site, we ended up having to go into each page and manually changing each internal link (luckily, they had under 50 pages!)

Remember: Whilst your server can be set to redirect from a http://mysite.co.uk to http://www.mysite.co.uk, there is a time delay involved in this. Avoid.

The Result

All of the above reduced the loading time down to 5 seconds (home page) and 2-3 seconds (inner pages). It was puzzling and concerning that the home page was taking so much longer to load than the inner pages, when the content was similar in size. Nothing we did made much difference and, after research, we concluded that WordPress had been in some way “corrupted/effected” by all of the different plugins.

Step 12: Clean WordPress Reinstallation

After doing a full backup (most recommended), we backed up the theme, exported all pages, posts and images, took a manual note of the different plugin settings and then installed a clean version of WordPress and manually recreated the site. This took the better part of a weekend and is not to be undertaken lightly.

The result:

Pingdom speed test after changes

Customer feedback: “Wow what a huge difference. I am so grateful to you.”

Please share our content if it is helpful