With all the factors involved in making a website successful as a marketing tool, I’ve been asked recently where page speed falls on the importance spectrum? Is it as big of an issue as it used to be? Can a slower site still get the same ROI from search and advertising as a faster one?
Ben is our Mad Fish technical SEO expert so I thought I would pick his brain on the subject.
So when you discuss ‘page speed’ with someone, what are you talking about?
When I use the term page speed I am talking about the time that it takes for a given web page to load in a browser. It’s typically measured in seconds or milliseconds. I’m not talking about the Google tool that gives you basic information on how to speed up a webpage.
I use ‘load time’, ‘page speed’ and ‘page load time interchangeably. Google has a tool called “PageSpeed”, and also has a “page speed” component to their algorithm. I would point out that the Google “PageSpeed” tool provides some good reporting on opportunities to making a page faster, however it’s not so great at telling you a page’s actual load time in seconds or microseconds.
What tools would you recommend for testing a page’s speed or load time?
One free tool that I really like using is the website speed test offered by Pingdom. http://tools.pingdom.com. You can set your testing location to one of three cities that’s closest to you in proximity so you can get the most accurate read.
Of course, if you are a Mad Fish client, we monitor your website speed constantly using our analytics platform, Mad Fish Elements.
So at what speed should a company be worried?
Well, if your web page takes longer than a minute, then you’re probably not going to rank for anything. So stop reading this and call us to fix your load time now <You would think Herman would laugh here but he has an ‘I’m dead serious’ look on his face>.
In my experience 2-3 seconds is OK; under a second is outstanding.
I know waiting for a page to load is obnoxious from a user’s perspective but what do you see as the ranking and traffic implications of slow page speed?
You see a lot of professionals talking about how they think page speed does or doesn’t matter, and in the end they all cite Google’s Webmaster Guidelines or lyrics from a few Matt Cutts videos. We’ve all read lengthy blog posts where an analysis shows that most web pages on the first page are within a certain range of load time.
But really, the conclusion inevitably is that if your page loads quickly, the load time is a minimal factor that doesn’t make a huge ranking difference, but if your page loads slowly, your rankings can drop. Really, Fast doesn’t matter but Slow can kill you.
From observing client websites and accidental experimentation, our rule of thumb is that in order for your site to have the potential to rank on first page of Google you need your site to load under 5 seconds. From what we’ve observed on the sites that we work with, any site that comes in slower than five seconds tends to drop like a stone from the first page.
And there are several ways to improve site speed, correct?
Yes, we can typically make 2-3 changes to a website right off the bat to improve site speed. Optimizing databases, implementing caching, improving hosting and getting rid of bulky plug-ins or tracking scripts are easy places to start. The team can pretty quickly identify these opportunities during our initial site evaluation and boost performance for 80% of sites right away. There are always the outliers of course that require a more robust solution.
What kind of solutions are we talking?
Well, a CDN is a great solution for image heavy websites. High-res showcase photography of landscapes or five star meals look beautiful but they can really bog down a site. You have to consider that your customers may not be using the most robust connections to browse your site. You don’t want a user to hit the back button because the site is running too slow. A large percentage of visitors hitting the back button will hurt your rankings FAR MORE than just having a slow website load time.
So how does a CDN work?
Well, CDN stands for Content Delivery Network and it is true to its name. A CDN is a way to leave copies of your site in multiple server locations around the world so that it takes a user the same amount of time to access your site whether they are searching from their home in Portland or their hotel room in London. It allows all that data to travel shorter distances when necessary. It’s a pretty slick setup for improving site load time when dealing with large files. But I don’t recommend it for every website.
And you’ve seen a CDN help a client’s site rank better?
Yes, we had a client who implemented a new site with over 30Mb of images to load per page. Our internal test servers loaded the site without a problem but when the site went live, the rankings started to drop and we had to identify why. We quickly identified that the page speed jumped to an average of 12 seconds per page. That absolutely sucked. Once we implemented the CDN, page speed returned to 2.5 seconds. Rankings returned about 3 weeks after everything was in place.
You want to give everyone a quick snapshot of how to put a CDN in place for a situation like this?
Sure, when it comes to a basic mid to small business website, it’s actually not too complicated if you know what you are doing. There are many CDN services out there, but for a quick and cost effective setup, we use Amazon Cloudfront for basic set. For enterprise level websites (i.e. 10k visitors per day and higher), it takes some additional upfront planning. Here’s an example of how an average business owner/webmaster could implement a basic CDN from Amazon/AWS in a matter of minutes.
Create a new Cloudfront instance on your account
Set the cache time to 20 days (or whatever length makes sense)
We used our main server as the source server, as this is where all of the images were stored
Create a subdomain named “cdn”, and map it to the cloudfront DNS (i.e. cdn.yoursite.com)
Update all image, CSS, and JS file paths to use the cdn subdomain, (i.e. “cdn.yoursite.com”)
That’s it. Git push, Git pull. You should see site speed improvements immediately.
The caveat to this approach is that you’re using your main/existing webserver as the source server for the CDN. This way you can continue to upload images and files to your current site without reprogramming your current CMS, or changing your internal processes. This solution gets the job done, but if you’re big, or looking to go big, we’d need to alter the solution to not use your existing webserver as the source.
Well, thanks Ben. I think this is helpful.
You’re welcome Corrie. Can I eat my lunch now?
