How I added $77,548.80 in additional traffic to a Plastic Surgeon’s Site Doing Nothing But On Page Technical Speed Tweaks [CASE STUDY]

Introduction

This post will go over a case study of a plastic surgeon client I had and how I was able to double its organic traffic by (really more) than 2x. The focus – or theme – of this case study is speed optimisation.

As you are (hopefully) aware – your page speed is a ranking factor for Google – and where it places your site. However many people do not know exactly what it takes to have a fast website.

Many think that a fast website involves nothing more than installing a WordPress speed plugin – perhaps tweaking some options and Bob’s your uncle.

However this is not always the case – and this particular client is a perfect example of how someone can have a very well designed, professional site – pay $10K+ for it – and yet still not have it optimised and fast.

The reason is because many times a client will test a web design’s company on their computers – which are normally extremely fast – and will not notice any speed issues – and will then sign off on the project – and there really isn’t a big incentive for the web design company to put any work into really optimizing the site for speed since the client isn’t even aware of the issue to ask about it.

Then the client could go to an SEO company – which can focus on various SEO factors like buying backlinks – but will not look at the underlying site structure as they (may) not be equipped to handle such technical undertakings.

Rather than creating a generic ‘How to make your WordPress site faster’ article – of which you can find many online – I instead wanted to show you a case study of a client who not only had a professionally created website – but also had a speed plugin installed – and how I optimized the site to its fullest potential – and allowed the site to perform to its greatest potential online.

Keep in mind – that this client’s site was not only professionally developed but also had a page speed plugin all ready – it was not “slow” per se.

This Case Study will go over the specific technical issues I had to fix – and may give you some ideas on how to squeeze some extra juice out of your site.

Good luck!

Let’s Start with The Results

Before we start let’s quickly look at the results that were achieved on this campaign (and when I say campaign I’m really only referring to the work done on site with speed fixes which will be outlined in this guide).

Please note the calculations used to come up with the total number in the title ($77,548.80) was done using my SEO Agency Audit method which you can find here.

First the overview graph

Here you can see a sharp increase in impressions and clicks – which were hovering around 35-60 clicks p/day.

To show you how you could quantify the results of this campaign on a financial level let’s look a bit deeper into the numbers. Below is the comparison traffic report of the 2 months before the traffic upswing and after the traffic upswing:

https://d3vv6lp55qjaqc.cloudfront.net/items/1N0U1a1t0f2q3M3e1t1b/Image%202019-07-08%20at%201.32.07%20PM.png?X-CloudApp-Visitor-Id=3150368&v=2b22f2ab
As you can see it’s 6.63 (6,630 clicks) vs. 2.72K clicks in the previous period. The impressions have pretty much quadrupled

The traffic only tells part of the story – luckily the client had tracked conversions through a long period of time on Analytics – so let’s look at how many enquiries were received over the same comparison period

https://d3vv6lp55qjaqc.cloudfront.net/items/3X2U0y0P452l2E3s453p/Image%202019-07-08%20at%201.03.47%20PM.png?X-CloudApp-Visitor-Id=3150368&v=d3d97cd7
Number of goal completions (contact form filled out) between the 2 periods

You can see a 38% difference – or an extra 157 leads in 2 months – which is significant. Keep in mind that this is a high ticket industry – with a starting price of $10,000 for the smallest surgical operation.

To quantify this further we can look at CPC on individual keywords. Let’s give a couple of examples and add those up:

https://d3vv6lp55qjaqc.cloudfront.net/items/440B2o2I400w0C2V1P3H/Image%202019-07-08%20at%201.29.13%20PM.png?X-CloudApp-Visitor-Id=3150368&v=2b22f2ab

Here we see hairline lowering surgery has gone from 1 click in 2 months to 83 clicks every 2 months. Taking this one example – and using the Keywords Everywhere Chrome plugin you can see the CPC (cost per click) for this keyword below:

https://d3vv6lp55qjaqc.cloudfront.net/items/3L0G241B233f2I0Q1N1b/Image%202019-07-08%20at%201.28.24%20PM.png?X-CloudApp-Visitor-Id=3150368&v=2b22f2ab

This comes out at $357.52 every 2 months – or $2,145.12 p/year – and that was just for one keyword change.

Note: to be fair I did some on page optimisation for that keyword above but here are ones where minimal changes were done:

https://d3vv6lp55qjaqc.cloudfront.net/items/132H2529430X0o3k3S2x/Image%202019-07-08%20at%201.29.41%20PM.png?X-CloudApp-Visitor-Id=3150368&v=2b22f2ab

You can make your own calculations on these keyword variations but taking ‘coolsculpting sydney’ at 55 additional clicks per 2 months at $5.80p/click comes to $1,914 p/year in additional traffic from that one keyword

In total taking all additional traffic into account and multiplying by the CPC the total additional traffic comes in at $16,156.01 over 5 months or $77,548.80 over 24 months (expecting these results to hold over that period).

The 5 months is stretched out over 24 months to find total traffic value – all though it could be consistent for more than the next 24 months.

Now I’d love to tell you that I achieved this with some voodoo magic behind the scenes work of powerful backlinks but actually all these results were achieved without a single backlink being sent to the site.

The two results above came from fixing one header (forehead reduction) and a broken link (coolsculpting) – but the thing that really put all this together is page speed.

The reality is most people have no idea on how to make their website faster – and this includes top of the line developers – so in this case study I will break down the road blocks that made me stumble – and what I learned.

Remember that this was not:

  • A poorly built website. It was a professionally built website which cost tens of thousands of dollars (this was not a ‘broken’ or ‘slow’ site) – nor was it essentially a bad web development project. The company that created this site did a good job.
  • There was all ready a speed plugin installed on the site (and yes – just because you have a speed plugin installed on your WordPress site doesn’t mean you will automatically see results like this)

So below I’ll go through the major challenges I faced – and that you will face too – when getting a site to optimal speed. This is a case study so the changes I made relate directly to this client – as well as the specific challenges I faced – I think learning from real examples and case studies is the best way to learn. So let’s get into it.

[su_box title=”Cons” style=”default” box_color=”#F73F43″ title_color=”#FFFFFF” radius=”0″]Keep in mind that if you don’t have the right plugin you will fall!.[/su_box]

HTTPS Redirects – The Silent Killer of Page Speed

I wanted to start with HTTPS redirects because it is one of the least discussed elements of making your site fast, the least understood (and slightly technical) and also one that has the potential to really screw up your site speed.

In fact – in all honesty – this really stumped me – and I actually had a few clients that had faster sites but were not getting under the 2 second load time that I was after – and I was racking my brains out to figure out why. The host couldn’t help – and WP Rocket support couldn’t help.

The hint came when I noticed that my staging site was loading much faster than the main site – and I noticed this and sent this news to my hosting cmpany – trying to figure out why. After all – they were pretty much identical in everything – except one – the staging site was loading fast and the main site had a 3 second load time.

Here is the screenshot I sent to my hosting company – trying to figure out why the 2nd resource (with the blue dot) was taking 3 seconds to load – and notice nothing else could load until that was finished). My staging site was identical except it didn’t have the 3 second delay. Also note it’s htps://myclientsite.com.au that I was typing in – notice the 3rd resource changes to https://www.myclientsite.com.au – I’ll get to this later.

The host couldn’t help me nor could WP Rocket support themselves – until finally I figured it out.

There was no redirect setup to take a user from https://myclientsite.com.au to https://www.myclientsite.com.au. So the server was trying to create this itself – and taking a long time (not sure why it was so hard to figure out).

But here are the steps to ensure that this doesn’t happen to you and you don’t rack your brains out like I did:

You do have an HTTPS certificate right?

Before we even start – I highly recommend – just for general SEO reasons to ensure that you have an SSL certificate.

If you go to your website on a Chrome browser and see this:

[ ]
If your site is not currently secured you should see this in the address bar in Chrome (the place where you type your web address in)

You need a certificate. Get in contact with your host – “Hey, can you guys set my site up with an SSL?” or you can

If your address bar looks like this (check at the top) – then feel free to proceed to the next step:

To www or not to www – that is the question

The first site wide decision you’ll have to make is if you want your site to be in the format of www or non www.

For example – your site could be either

https://yoursite.com.au or

https://www.yoursite.com.au

Take my site – kostak4.sg-host.com for example. If type in ‘kostak4.sg-host.com’ into the address bar – you’ll see it’ll change to my site URL:

In my case I made the site be www. throughout – however I could just as easily have made it https://headstudios.com.au – it doesn’t really matter. But you must make this fateful decision.

I have set the address for this URL in my WordPress Settings > General section. This is the place to choose how you want to display your site – once you know this you can move on to the next section.

Test site speed with waterfall and HTTPS Redirect (watch the blue dots)

[su_box title=”A quick note” style=”default” box_color=”#ffd400″ title_color=”#FFFFFF” radius=”0″]If your site URL is set to https:// without the www then technically you don’t need this section – as this only seems to happen for sites of mine that are https://www.[/su_box]

The first thing you want to do is find out if this is an issue that your site is currently experiencing. You can do this with either tools.pingdom.com or gtmetrix.com – in fact you could even do this with your own browser – but let’s use tools.pingdom.com for this example.

[image of tools pingdom]

Go over to tools.pingdom.com and type in your website URL without the www and without the http/https. So if your domain is https://www.lumbercaryard.com then type in lumbercaryard.com. This will force the site to create a redirect to the proper web address – and you can see how long this takes (if the server tries to do it itself – or if an htaccess file is setup).

You might also select the area you’re closest to your hosting server from the drop down but this isn’t that important.

[ image ]

Then wait for the site to load and once it does go down to the bottom and see the time it takes for the redirect to happen. Here is an example on my own site kostak4.sg-host.com:

A waterfall chart live from kostak4.sg-host.com – look at this – the redirect from http to https is fairly quick (first row) – but the redirect from https:// to https://www takes a whole second – this is slowing down our download time.

On

Wordfence and other Plugin HTAccess Rewriters

One day my client called me to let me know the site seemed to be loading slower than usual. I didn’t know why this would be happening – we hadn’t changed anything – on the server or on the files – for the site to be slowing down.

However the culprit was soon identified (thankfully the server knew what the issue was in this case) – it was the Wordfence plugin – and some code the plugin had added to the htaccess file that was slowing down the redirect.

Wordfence is a very popular security plugin – and I use it on my sites – however just be aware of the potential for this plugin to cause issues. If it’s the case try disabling it and removing the htaccess code and see if this fixes your speed issues.

The Worfence code will look like this:

# Wordfence WAF
<IfModule mod_php7.c>
	php_value auto_prepend_file '/wordfence-waf.php'
</IfModule>
<Files ".user.ini">
<IfModule mod_authz_core.c>
	Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
	Order deny,allow
	Deny from all
</IfModule>
</Files>

# END Wordfence WAF

This makes the browser execute a file called wodfence-waf.php before the site starts – unlike other plugins who – once the cache is activated – don’t have access to any WordPress hooks and have al their actions hooked – Wordfence can be a drag. So just be aware of this. There are other plugins that can potentially cause issues so just look for any code that redirects to a .php file in the htacess file.

Firstly – you’ll want to see if this is an issue that your site is currently experiencing.

Your htaccess file is required to tell the server where to direct your URL’s.

If someone types in ‘yourwebsite.com’ and the address bar immediately changes it to ‘https://www.your…’ that is due to the work performed by the .htaccess file.

A big problem I faced was configuring the htaccess file and I will now tell you how I solved the problems and made the site lightning fast.

[su_box title=”A quick note” style=”default” box_color=”#ffd400″ title_color=”#FFFFFF” radius=”0″]This section of the guide assumes your weba ddress is https and that you have an SSL certificate installed. If you do not you can find out more info on how to install your SSL certificate here.[/su_box]

Speed Optimisation

Mobile Cache

One of the mistakes I made at first – which was slowing down the site significantly was not creating a mobile only cache with WP Rocket (please note from memory this is not enabled by default). The worst thing is – I wasn’t even aware of how much more heavy my mobile website was because of this.

Let me explain.

Whenever you come to a website – with either your phone, iPad or desktop computer – your device sends information to the server about what kind of device it is. The application (that is your website) – can then have access to that information when building your site.

To keep it simple and not make it too technical – there can be certain elements on your website – like a big video banner – that are probably un-necessary on a mobile device (nobody wants to go to a site on their mobile and see some video auto playing and draining their mobile data – leaving them fuming at you).

By creating two cached versions of the site – mobile and desktop – WP Rocket will check what device the user is on – and then serve the cached version of the site that corresponds to the device.

Let me show you an example of why this is so important.

In the video above I am on the desktop site – however the desktop site is still responsive. When I make the browser smaller it looks exactly like the mobile site – but the big video you see at the top still loads in the background – it’s just not visible.

Below you can see the ‘Network’ Dev Tools from Chrome – which tells you which elements are loading in which order and how long they take – what I discovered was that the mobile site was still loading that big 8.8MB video file.

Every.

Single.

Time.

The video loads in the background and sucks up 8MB – not good for Google crawlers – and impossible to pick up. Moral of the story – have a separate mobile cache!

In our case what was happening was that after WP Rocket was activated the mobile site actually started loading slower.

This is what was happening and dragging down the mobile download speeds (Google looks very carefully at how big your mobile site is) – so I created a separate cache for mobile to fix this issue.

Conditional Loading

One way to save on mobile speed – (by the way – I should mention that Google is switching all sites to mobile first indexing – which basically means you better have your mobile site fast otherwise good bye rankings) – is conditional loading.

This will require a slight bit of programming – but it’s well worth it.

You see – most sites will hide elements on mobile responsive sites that show on the desktop site – but will still load those elements. In other words – just because you don’t see a particular image on the mobile site – does not mean it’s being loaded.

There are many sites that serve the same site regardless of what device the user is on – and unfortunately there’s no front end way I’ve found to not load images on mobile devices when they’re not required – lucky for you I’m a WordPress developer – and can show you how to do that now.

I introduce to you the results of my research – and it is a function called [….].

But let’s take a practical example. Here is my client site’s drop down:

Note the images on the drop down – in total there are 30 images like this spread out across the top menu (for example there are 6 in ‘Procedures’ as listed here, 6 in About Us, 5 in Medispa, 5 in Patient Info etc. So that’s a lot of images!

Now as you can see image above there are 6 images being loaded – even though they’re not visible on the mobile version of the site menu.

This is the same drop down on the mobile site – note that even though on the mobile version these images are not visible – they are still being loaded in the backend. How much data do you think 30 images will suck up? All that for images that aren’t even required – and believe me no speed plugin is going to fix this issue.

You may conclude that these images are not being loaded but alas you would be wrong – there is a whole bunch of elements like this that are loaded on many sites and clog up servers.

So let’s get that speed edge over our competitors.

You are looking for 2 functions (and just a heads up this may get a bit technical – you may need a developer like me to implement) – preg_match and the $_SERVER variable.

Note: there are tools like Elementor that will allow you to hide elements on mobile screen with options – be aware that these tools do not remove the said item from the loading queue. This is the only way I could find that does this – and saves a bunch of date.

And here is how to hide images you don’t need:

Introducing the isMobile() function to your theme

In the source code of your website – in the location where your template is located – you need to edit a file called functions.php – don’t worry about all the other stuff on that file – just add the following code to the bottom:

function isMobileDevice() {
    $useragent=$_SERVER['HTTP_USER_AGENT'];
if(!preg_match('/(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino/i',$useragent)||preg_match('/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er|oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )|avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|ikom|im1k|inno|ipaq|iris|ja(t|v)a|jbro|jemu|jigs|kddi|keji|kgt( |\/)|klon|kpt |kwc\-|kyo(c|k)|le(no|xi)|lg( g|\/(k|l|u)|50|54|\-[a-w])|libw|lynx|m1\-w|m3ga|m50\/|ma(te|ui|xo)|mc(01|21|ca)|m\-cr|me(rc|ri)|mi(o8|oa|ts)|mmef|mo(01|02|bi|de|do|t(\-| |o|v)|zz)|mt(50|p1|v )|mwbp|mywa|n10[0-2]|n20[2-3]|n30(0|2)|n50(0|2|5)|n7(0(0|1)|10)|ne((c|m)\-|on|tf|wf|wg|wt)|nok(6|i)|nzph|o2im|op(ti|wv)|oran|owg1|p800|pan(a|d|t)|pdxg|pg(13|\-([1-8]|c))|phil|pire|pl(ay|uc)|pn\-2|po(ck|rt|se)|prox|psio|pt\-g|qa\-a|qc(07|12|21|32|60|\-[2-7]|i\-)|qtek|r380|r600|raks|rim9|ro(ve|zo)|s55\/|sa(ge|ma|mm|ms|ny|va)|sc(01|h\-|oo|p\-)|sdk\/|se(c(\-|0|1)|47|mc|nd|ri)|sgh\-|shar|sie(\-|m)|sk\-0|sl(45|id)|sm(al|ar|b3|it|t5)|so(ft|ny)|sp(01|h\-|v\-|v )|sy(01|mb)|t2(18|50)|t6(00|10|18)|ta(gt|lk)|tcl\-|tdg\-|tel(i|m)|tim\-|t\-mo|to(pl|sh)|ts(70|m\-|m3|m5)|tx\-9|up(\.b|g1|si)|utst|v400|v750|veri|vi(rg|te)|vk(40|5[0-3]|\-v)|vm40|voda|vulc|vx(52|53|60|61|70|80|81|83|85|98)|w3c(\-| )|webc|whit|wi(g |nc|nw)|wmlb|wonu|x700|yas\-|your|zeto|zte\-/i',substr($useragent,0,4))) {
    return true; } else { 
        
        return false; }
}

What this code will do is allow us to quickly call it by using isMobile() anywhere on the site – and then choose what we want to display (or not display). Let me show you a live example implemented from the client’s website:

if(isMobileDevice()) {
$title_enhance = '<span class="fusion-megamenu-icon"><img src="' . $this->menu_megamenu_thumbnail . '"></span>';
//echo "You are on a mobile";
} else { $title_enhance = ''; }

That’s all I added! After that change has been implemented here is how the menu looks now (using the Chrome User Agent Switcher):

This is the website viewed using Google Chrome User Agent Switcher (as mobile) – notice the images are now missing – they will be visible if switched to

The plugin that I am using here is ‘User-Agent Switcher for Chrome‘ – this allows you to fake who you are to the website – making the website believe you are a mobile user when really you are on the desktop. It’s helpful to see just how a website will react when it thinks you are on mobile – during development and testing.

Summary

That is all there is to it. Using these 4 steps above I was able to increase the traffic to my plastic surgery client by $77,548.80.

Speed is a considerable ranking factor for Google – and while this client had a professional and well put together website there were a few speed tweaks that were required to make it look perfect in the eyes of Google.

If you suspect your site may be slow follow the steps and you have tried the traditional page speed advice you may want to try the tips above and you should see ranking and traffic increases especially on a well trafficked site.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published.