It’s no big secret that site speed is important, particularly for ecommerce sites. It’s been proven again and again that the faster the page load time, the better the conversion rate and the higher the average order value. And it’s also a search ranking factor across both desktop and mobile so the faster your site loads for users, the better your chance of being able to rank well in Google.
Third-party code like this is pretty common and is used for all sorts of reasons – including for analytics, social sharing functionality, A/B testing software, and for serving ads.
Using PageSpeed Insights
Using Chrome DevTools
Chrome DevTools is incredibly powerful and has a ton of useful information about any site that you want to audit. It can be a little daunting looking through the data at first, but when you know what to look for it can give you an incredibly useful view of what the browser is actually doing, and how much time it spends doing what.
You can bring up Chrome DevTools by right-clicking and clicking “Inspect”, or pressing Command + Option + J on Mac, or Control + Shift + J on Windows. I do this in an incognito window when I’m auditing site performance so that Chrome extensions don’t affect page load times.
The Performance Report
This isn’t to criticise any of the third-party code listed there, by the way – it’s very likely that large amounts of this code is useful. It’s just worth knowing how much load time they add to the page so you can determine if the code’s usefulness is worth the performance trade off.
Network Request Blocking
Firstly, I load the page 3 times in an incognito window, making a note of the reported load time for each one – the median page load time (i.e. ordering the load times fastest to slowest, the median is the middle one) becomes our benchmark. Using the UK homepage of Nike.com as an example, the median load time for me at the time of testing was 7.26 seconds.
Use defer or async where you can
<script async src=”…”>
Adding the async attribute is pretty straightforward – it involves adding “async” to the script tag like this:
<script async src="/your-file.js" />
<script defer src=”…”>
<script defer src="/your-file.js" />
Importantly though, this shouldn’t be used for scripts that are absolutely critical to the loading of the page and that need to be executed early. Libraries like jQuery can be critical as they’re often used for layout and so it’s not recommended that those are deferred – but you might see some performance benefits from deferring the load of things like analytics or ad tracking.
Using preconnect and dns-prefetch resource hints
It’s fairly common for browsers to discover third-party assets at various points throughout page load – which means these connections can happen throughout the render of the page. In most cases, it would be better for those connections to be made up-front, in parallel. And that’s what the preconnect resource hint does.
For your critical assets (such as images from a CDN), you can see performance gains by telling the browser to preconnect to the third-party domains that you’re going to request the assets from, by including a preconnect link tag in the head:
<link rel="preconnect" href="https://cdn.example.com">
For less critical third-party assets that aren’t required for the page to render, such as analytics, you can use dns-prefetch to get the browser to do the initial DNS setup:
<link rel="dns-prefetch" href="//www.googletagmanager.com"> <link rel="dns-prefetch" href="//www.google-analytics.com">
The setup time for domain name resolution can often be between 20-100ms, so being able to do this all upfront in parallel, instead of staggered throughout the page load can help.
As with lots of things, it’s important to test this to ensure it really is having a performance improvement on your site. If you use a Real User Monitoring tool, then make sure to check the impact when the change has gone live. Andy Davies has also written a guide on how to test the impact of preconnect before changes go live, using WebPageTest, and this is a really useful method to see whether it’s worth trying this out on your site before you get the dev team involved.
Regularly audit Google Tag Manager
Tag managers (the most popular being Google Tag Manager) are great for allowing people to add tracking tags to the site without having to rely on a developer to include it. But the drawback in making it easy to add tags is that it becomes easy to add lots of tags, and often people aren’t aware of the performance cost they can have.
In many cases, this results in loads of out-of-date tracking tags, or tags for products that nobody uses, but are still being loaded on the site.
It’s well worth reviewing your tag manager regularly to check which tags are being loaded in. If there are tags for marketing platforms that nobody uses anymore, then you can potentially make performance improvements to the site by simply removing (or pausing) those tags.
We provide a range of analytics support for our clients (including auditing Google Tag Manager), and you can find some of the things we can help you with here.
Measuring site speed