The Only World-Standard SEO Software


Download Now
SEO PowerSuite
SEO PowerSuite Hot-new version
Supported OS

Speeding Up Your Websites: Quick On-Site Changes That’ll Reduce Bounce Rate

Link-Assistant.Com | Posted in category GuestBox On Page SEO

guest post by Luke Marchie

According to some co-workers, obsessively shaving down load times is becoming a bit of a bad habit for me.

While most site's I've worked with arrive on my desk with a fairly decent load time there is always work that can be done to help bring these up to speed which has become a vital part of our standard on-site clean up we perform for new clients.

Not only is site speed surmised to be a growing factor in your search engine rankings, but you almost always notice a reduction in your bounce rate once you've spent some time optimizing your load times.

A good rule of thumb is the more often you shout obscenities at your computer screen while a site loads the more benefit you'll get once it's been optimized.  Of course, this test might depend entirely on the demeanor of the user.

Even on a "good day" our client was still seeing load times as high as 5 seconds.

While my screenshot of the 11 second load time is missing, even on a "good day" our client was still seeing load times as high as 5 seconds from Pingdom's load time checker.

One horror story turned fairytale was the case of a recent website I had the pleasure of working with.  While I won't be divulging any domains, I can say at first glance the site looked fairly normal - good design, decent content, slight on-page issues to fix - but what shook me to my core was the load time.

On a good day we were seeing around a 5 second load time, but on a bad day...and boy there were some bad ones...our load times skyrocketed up as high as 11-12 seconds.

Identifying Your Site's Load Time Issues

Now this is where things get tricky.  I have yet to come across 2 websites that share the same exact same load time issues - there's a number of factors that affect load time but I can do my best to compile some of the most common issues:

  • bad/slow hosting
  • unnecessary javascript/infinite loops
  • sloppy/invalidated code
  • un-optimized images
  • poorly coded wordpress themes

My first go-to test is the Pingdom Site Speed Checker. This tool will allow you to get a read on how long the page will load for an average visitor. and I use it throughout my entire process to help me benchmark how much progress I've made so far.  Be sure to make sure you're testing from a location similar to where you expect your target visitors will be navigating from.

Once I have an idea of how long the page is taking to load it's time to look at some details.  For this I almost exclusively use Chrome's Developer Tool.  Right click anywhere on your site in Chrome and select "Inspect Element".  This will bring up the developer window - from there select "Network" on the top of the dev toolbar and reload your site.

You should see a nice layout of the individual load times of the images, javascript, and any other files your site is using to load.  Here's where you can dive in and see whether you can identify any issues.

Screen shot 2013-03-29 at 1.44.32 PM

Now in this example you can see the initial "GET" request is getting help up for almost 3 seconds!

The example above is from a site already partially through the cleanup process, but already you can spot a few problem points - the jQuery and initial GET request for the site both have a suspiciously long waiting times.  As you scroll down you would also be able to spot what kind of images are taking the longest to load, as well as any include files that may be loading spottily.

Validating Your Code with WC3

Using WC3's code validator should be one of your first steps.  As anyone who's worked with this tool knows - your errors most likely will be bountiful and sometimes it can take an hour or so to clean everything up.  While you may not see a huge drop in your page load speed it entirely depends on how great (or how poorly) the site was coded out when you inherited it.

This process also forces you to take a really good look at the source code.  This is invaluable as it allows you to keep an eye out for anything fishy looking and gets you familiar with what you'll be working with for the next few hours.  In the example I'm using here I quickly found a couple issues:

  • javascript tags left over from a now unused contact form implemented by a previously used SEO company
  • PHP based validation for said contact form in each footer.
  • 88 lines of commented out code loading in the header
  • MASSIVELY large images being loaded
  • multiple unused (yet active) WordPress plugins

Having removed the code-based issues I mentioned above (and correcting no less than 23 errors) my code was finally able to validate!

Victory!

Victory!

Now it's time to move onto optimizing the various media types you use across your site.

Giving Your Slow Loading Images the 'Smush'

I used to manually evaluate and optimize each image giving my site load troubles, but as you can image this task become more and more laborious as our client's site's grew larger and larger.

Luckily I found a great WordPress Plugin that automates the bulk of your image optimization. WP-Smush.it takes care of all your image optimization without having to mindlessly find and fix each image.  Smush.it takes care of the following once it's been run:

  • stripping meta data from JPEGs
  • optimizing JPEG compression
  • converting certain GIFs to indexed PNGs
  • stripping the un-used colors from indexed images

Now you can go through and Smush each media file separately  but if you're comfortable living dangerously there's also have an experimental feature called "Bulk Smush.it" which will optimize your images all in one go.  The key word here is EXPERIMENTAL!  Make sure you make a secure backup before attempting anything which even the developer labels as experimental.  Personally I've never had an issue - but it's better to play it safe.

Installing a Content Delivery Network and Caching

At this point our code should be spotless, our images should be optimized, and yet you've only shaved a few milliseconds off your load time?!  Most likely that is that case.  As we saw in the screenshot above our initial GET request was taking almost 3 seconds to process and finish loading.  A lot of time this can point to issues with your code, but since everything is validated what could the issue be?

Well unfortunately at this point you most likely will just have to point to your slow shared server and shrug. Personally I draw the limit at the server - for the most part it's not worth the time and money involved to get a site switched over to a new server but with nothing left to fix on-site is that our only option remaining?  Not on my watch!

Cloud Flare has quickly turned into one of my favorite tools to improve load times.

Cloud Flare has quickly turned into one of my favorite tools to improve load times.

A content delivery network (or CDN) sounds like a pretty complicated set up.  I was initially in awe of the process as well, but after getting my first site up and running on a CDN within 3 minutes I was impressed with how simple and effective of a tool it can be to speed up a site.  CloudFlare has been my go-to CDN for a while now - they provide basic CDN services at no-cost and have shaved upwards of 7-8 seconds off of some load times on my websites.

I find it a useful solution when it seems like updating your server is the only option left.

The process is almost automated - the only information you'll be changing is your website's nameservers.  Here's a quick run-through:

  • create a CloudFlare account
  • let it scan your DNS settings for the web property you'll be optimizing
  • select the settings for the CDN (I typically use the fastest one available)
  • login to your domain registrar and update your nameserver's with the new names provided by CloudFlare

Once the nameservers change over get ready blow your previous load-times out of the water.  Our example site dropped 7 seconds once the CDN took hold and even further once I perfected the settings.

A bonus of using CloudFlare is that they can enable minifying of code, caching, as well as a plethora of other load-time solutions normally done on their own.  Now some of their features are experimental (there's that word again...) but as long as you take the time to test out your sites once the CDN is active you can determine at what level you'll allow the CDN to run without breaking any javascript or forms.

At this point you should have made some healthy improvements to that load time without devoting more than a few hours.  Below are my final stats after tackling this 11 second loading beast:

Screen shot 2013-03-29 at 2.46.05 PM

Wait What About That Bounce Rate?!

Screen shot 2013-03-29 at 2.52.54 PMOne of my first steps after finishing my load time cleanup is to mark it in Google Analytics so I can compare traffic statistics before and after the change.

While there's a huge amount of other factors coming into play here with regards to your bounce rate, I tend to always see a fairly nice improvement in my usage statistics when comparing data before and after the site speed optimization.

Above is an example of the improvements we saw when comparing the week before and after our speed upgrade.  While we have plenty more work to do with this website before we're ready to consider it finished I can relax knowing the seconds I shaved off that load time will only compound over time. The possibly of allowing some young geniuses an extra 10 seconds in their lives gives all of our work an even greater purpose...right?

About the Author:

Luke Marchie is proud citizen of Philadelphia and when he's not writing about internet marketing for attorneys you can find him playing in poorly rehearsed cover bands, taking adult kickball way too seriously, or complaining about load times when there isn't even a computer in the room.



back to SEO blog