Speed is a killer.
Amid all the design, copy, testing and strategy talk it’s easy to forget that there’s a nuts and bolts issue that can make or break your site’s performance. I’m talking about load speed.
Load speed matters a lot more than you’d think.
It’s a ranking factor:
Here’s what the effect of load speed looks like in terms of search result placement:
Slower site = lower position. Ideal load speed is as near to zero as you can get it: The top 10 SERPs load in less than a second.
And it matters a lot to visitors too.
‘Globally, slow loading times are considered the biggest frustration of modern mobile users,’ said Episerve in its 2015 report. And mobile users are now the majority of web traffic.
The effect on conversions is even more drastic than what we can observe for SERPs, and much more stark:
Conversion rate peaks at 2.4 seconds; add two seconds and it halves. Add one second and it falls by 27%.
Why is this still an issue? With faster broadband more widely distributed than ever before, and smartphones getting faster and more powerful, why haven’t web pages kept up?
Mainly because we’re using that additional bandwidth to pack sites with gimmicks, tracking cookies and huge images.
Images are the main culprit, growing 3X since 2011, but scripts have made a big jump too. If you had a pure HTML site it would be the same size now as in 2011, when average internet speeds in the USA were 3X slower.
But instead, page load speed is not just bad.
It’s getting worse.
Web performance in ecommerce slows by an average of 23% yearly, according to data from 2014: ecommerce sites then took 6.5 seconds to render their primary content – nearly twice that to fully load.
The average top ranking website now takes around 9 seconds to load.
(These are whole sites, not individual pages.)
Who does this affect?
Everyone. Bounce is pretty high across all industries, and so is failure to perform the actions we want users to do, aka, lack of conversion.
Ecommerce websites in particular suffer high bounce and cart abandonment.
Cart abandonment is down from a 2012 peak of nearly 72% – but only to 69.23%, a pretty small drop. The large majority of ecommerce website visitors abandon.
It’s directly correlated with load time.
What about bounce?
Ecommerce bounce rate is correlated to load speed too. This ecommerce site’s users bounced at a rate of 44% – on average. Split them by load speed experience and there’s a clear difference:
Bear in mind, fast loaders were defined here as ‘under 4 seconds’! There’s a 24% jump in bounce for desktop between the fast and slow load groups.
Content websites suffer from high bounce, and that’s load speed related.
So do lead generation sites for services.
Ultimately, the relationship between bounce and load speed looks more or less like this across industries:
Are you affected by slow load speeds?
How can you know if your website is affected by slow load speed? Start by checking your basic load speed. You can use Google’s PageSpeed Insights tool to find out how well your site is performing.
Run your URL through Google’s tool and you get data on how quickly your site is loading, and advice on which elements could be improved to accelerate it.
Note that the outcome can be substantially different for desktop vs mobile:
But while Google’s tool isn’t a bad one-stop shop for covering the basics, there’s a lot going on under the hood that it doesn’t show you.
So here are five great tools for diving deep into exactly what’s happening with your site.
Offers you a list of your site’s issues rated by priority.
You can shift your server around to see what your site looks like around the world, and get both an overview and an actionable list graded from A to F.
Wondering what to tackle first? Start here.
Pingdom gives you grades too. It also offers a waterfall analysis so you can see exactly what’s going on.
It’s not free though, unlike the majority of tools on this list.
Offering waterfall analysis and a range of different servers, letting you see how the two interact.
Rather than moving your server around, Dotcom-monitor uses a variety of servers simultaneously.
4: Load Impact
Load Impact offers browsing scenarios and analyses your content too.
It’s free, but you have to create an account, and compared to the other tools on this list, it’s a lot more complicated.
I saved the best til last. Webpagetest is what I mostly use.
The interface is kind of 1996 in a bad way, but the functionality is fast, easy to access and gives just the right amount of detail.
Waterfalls, content breakdown and a couple of other tools let you go from ‘my site is too slow’ and see visually which elements are sucking up loading time.
So we’ve seen a bunch of different load speed metrics. The question is, which ones are really important?
The vital load speed metrics are the ones that really matter to your customers:
- Time to the page being visible
- Time to being able to find what they want
- Time to being able to do what they want
This is one reason that ecommerce sites are so load speed sensitive. A bunch of images and buttons loading slowly and with glitches and jumps is much more frustrating than a single, ill-advised supergiant image that takes too long to load. And people come to ecommerce sites to make decisions about that they want – that’s all three of the ticklist above, happening at once.
How do we fix a slow-loading site?
How to accelerate a slow website
1: Minimize HTTP requests
Each time a file loads on your website, an HTTP request is sent to your server from the browser. While the two computers are talking, things slow down. Yahoo says this can account for up to 80% of load time.
To see the request report in Websitespeedtest, go to Test Result>Details and scroll down; it’s the third report.
(This is a very simplified explanation: if you’d like to get more under the hood, check out this post by Yoast’s Jimmy Comack.)
The more off-page resources that are stored elsewhere your web page has to load, the more HTTP requests it must send and the slower it will load.
This is made worse because HTTP was originally configured to only begin a new request when the old one was finished. To speed things up, it’s now possible to make asynchronous requests (all happening on top of each other.) It’s faster – but runs the risk of your page loading in a messy, confusing way. Remember, we’re not chasing abstract load speed metrics. We want visitors to orient themselves and act quickly without bouncing.
How do we cut down on the number of HTTP requests? We cut down on the number of resources that are being loaded.
Start with images. Get rid of any images that aren’t directly doing something useful on the page. Having plenty of images is a good thing, but if they’re just there for the sake of it, consider removing them.
Video is up next. Some sites with extensive video can add one or two seconds to site load time: that’s the whole time that most people are willing to wait, spent on one asset. Is it really worth it?
Finally, CSS. Each CSS file is its own separate request. But a single CSS file can usually do for all your CSS needs, so combine them into one to cut down on the number of requests.
2: Enable compression
Large pages take a long time to load. But it’s possible to compress them, with the open source Gzip tool.
Most web servers can use Gzip to compress files into .zip files before sending them. You might have the same number of files being downloaded (if you didn’t get around to cutting down your request numbers yet) but you won’t have the same quantity of information, so your pages will load faster.
Yahoo says Gzip can cut 70% off your load time.
To enable Gzip, drop this code into your .htaccess file:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
# Or, compress certain file types by extension:
3: Enable browser caching
Browser caching lets a visitor store a version of your website on their browser. Then, when they return to your site, they only have to open the majority of the files that make up your site, not download them.
Sounds good, right?
Take a look in your Google Analytics Overview report, at your returning vs new visitors.
The new visitors will have empty caches. You can’t accelerate their experience of your site with browser caching. But the returning visitors are another story: you can shave the majority of site load time for these visitors.
If you have a high proportion of returning visitors, or you’d like to get caching dialled in for your site, here’s a great resource.
4: Minify resources
Many ‘website builders’ that don’t rely on trad developer skills – or any at all – can make great looking websites. But snoop under the hood, and the code doesn’t look so great. Bloated and sloppy, it can be this that’s slowing your site down.
What’s to do?
You can tidy the code up yourself. Removing unnecessary line breaks, indentation and spaces in your code can accelerate it.
But minifying it is even more effective.
Here’s what that looks like:
In this example, a simple section of HTML has been automatically shrunk to the smallest and leanest it will go and still work. In the process, 11% of the code has been shaved away.
Minifying these CSS elements alone could make significant data savings.
You can use tools like Minifycode.com to minify your code, then replace the offending code in your HTML, CSS or Java with the minified version.
If you’re running WordPress, there’s an Auto-optimize plugin that minifies all your code, though it does take a little setting up.
5: Optimize images
Images are the most bandwidth-sucking elements of most websites. Typical errors are leaving images in bandwidth-hungry formats or in enormous sizes. Check out how long these images took to load:
The purple lines are images. The largest took 2.09 seconds. Big problem.
The three things you need to concentrate on when you’re optimizing images are size, format and the src attribute.
Big images soak up bandwidth. If your page is 500px wide, why are your images 2500px wide?
That additional size is an unnecessary burden on your site load time.
Sure, that image will be resized on the site when it renders – but the whole massive file will be loaded each time too. Don’t resize images: crop them to fit your site’s maximal dimensions, in an image editing tool.
(If you don’t have Photoshop, try Pixlr – browser-based and free.)
The best image format is .jpg, with .png second. (Not all browsers will render .png images.) BMPs, TIFFs and Gifs all suck up bandwidth like crazy.
The src attribute
The src attribute tells the browser where to look for the image. In HTML, it looks like this:
Don’t have ones that look like this:
That means there’s no defined source for the image. When that happens, the browser will start looking for it by sending requests to the page itself, adding to the data burden of loading the page – plus, your image won’t load.
6: Optimize CSS delivery
CSS tells browsers what each element of your page is supposed to look like. You can do it two ways, externally or inline.
External CSS is found in the header of your page, looking like this:
<link href=”https://static.hsstatic.net/content_shared_assets/static-1.4043/css/public_common.css” rel=”stylesheet”>
All the information needed to render your page (Hubspot’s page, in this case) is in the CSS stylesheet.
This is way better than doing it with inline CSS, where you drop CSS in between your HTML. Using a stylesheet reduces the size of your code, while using only one stylesheet reduces the number of requests and thus cuts down load time.
To find out how many external CSS sheets your page is using, use a tool like Varvy’s CSS Delivery Tool or GiftofSpeed.
GiftofSpeed helps you optimize CSS delivery, but if you’d prefer to do it yourself, Varvy has instructions.
A final thought:
What about AMP?
AMP is supposed to make everything super fast. And it does. But it works by forcing you to use a stripped-down version of CSS, HTML and Java, with not much room for choice. It forces you to rely on Google’s content delivery network, which is lightning fast but which changes all your URLs to Google ones. And you have to get pretty hacky to even get simple stuff like forms on an AMP page.
If you regularly publish news, this could be a good choice, and some people recommend using it for landing pages. But as a way to speed up your core website, it’s the wrong tool for the job.
Slow website load speed can crush your SEO and your conversions alike. The solution lies in trimming down and tidying up the basic code of your website, and a lot of the fixes aren’t even that complex. When fractions of a second can be measured in higher bounce, fewer sales and leads, and even affect SERPs, it makes sense to address them now.
If I left out your favorite load speed fix or you want to add something, get in touch in the comments!