Quickly learn if a site speed change will have a positive impact, without hassling your dev team.
Improving site speed can be complicated. It’s surprisingly common to roll out a change that should lead to a performance improvement, only to find that – frustratingly – things have gotten slower.
And a lot of the time, this is how site speed works – you have to approach it like you’re running an experiment, where you benchmark your baseline, make a change, and then test to see if you’ve made an impact.
But this approach can also be slow – especially if you’re having to ask developers to make these changes, and then they have to find time in their schedule to implement them (and then, potentially, roll them back). In situations like that, you have a slow feedback loop – it takes a long time between “let’s see if this works” to finding out the results.
A fast feedback loop
Chrome DevTools has a feature called Local Overrides that can drastically improve that feedback loop. Instead of having to wait for a developer to add your change, you can first try it out on your local machine to measure the potential impact.
Here’s how I test whether site speed changes might work, without having to push those changes live first.
Setting up local overrides
The first step is to get overrides set up on your computer. Open Chrome DevTools (Option + ⌘ + J on mac, or right-click and inspect element), click on the Sources tab, and then click the >> button in the left-hand side bar to find the Overrides panel.
From here, click “Select folder for overrides”, and choose somewhere to save your new editable copies of files. I just use a folder that’s tucked away somewhere named “Local Overrides”, but you do you.
Finding the baseline
To add it, right-click on your Chrome bookmark bar, click Add Page, add the name “Highlight LCP”, and then add this as the URL:
When you click that bookmark it’ll add a gold border to the LCP element, and show both the FCP and the LCP timings in the DevTools console.
At this point, I like to run 3 tests on the new, locally stored page. You don’t want to compare your edited local page with the live version – so to do that, I use local overrides to add an extra line-break into the code somewhere.
From the Overrides menu, it’ll prompt you to hit Ctrl + P to open a file. Select the page that you want to edit, and you should see the source code appear. From here, I usually add an extra blank space or a line break, and then hit save. You want to make sure that there’s a blue dot next to the file name, which tells you that it’s now serving a local version of the file. Also, make sure you’ve got Enabled Local Overrides checked.
Under the Network tab, I’ll usually throttle my connection to Fast 3G when running my tests. This is largely because I want to focus on users who have a slower connection because if you can improve performance for them then you’ll also improve performance for the average user. It’s also useful because it makes it clearer if a performance change is having an impact.
To do that, I use Chrome’s option to empty the cache and hard reload the page each time (if you have DevTools open, it appears as an option if you hold down the refresh icon).
Those 3 sets of numbers you have? Take the middle number for both FCP and LCP (even if they were in different test runs). That’s your median – so those are the numbers that you’ll be benchmarking any changes against. Feel free to run more tests if you want to be extra sure, but I find 3 normally does the trick.
Removing the anti-flicker snippet
I’m going to use the cycle page for Wiggle as an example here. They’re not a customer, and I have no connection there – I just noticed some potential speed optimisations that Local Overrides could show off. Also, this is very much not a dig at Wiggle – the site is well built, and there are very likely good reasons for some of these engineering decisions. I’ve only chosen them because I think there are a few tweaks that could result in speed improvements.
After throttling my connection to 3G and testing the page 3 times, my median First Contentful Paint was 5,231 ms and my Largest Contentful Paint was 13,221 ms.
I wanted to see what impact removing that anti-flicker snippet would have. I used Local Overrides to delete that whole snippet, and then re-ran the test 3 times. The median First Contentful Paint dropped from 5,231 ms to 2,217 ms – an improvement of 58%.
Un-hiding the hero carousel
owl-loaded to the carousel once it’s loaded, which then reveals it to the user.
I wanted to see what it would look like if it didn’t hide the carousel by default, so with Chrome’s Local Overrides I added the
owl-loaded class directly. This isn’t perfect, and if the plan was to change how that carousel worked, I’m sure there would be much more elegant ways to approach this – but I wanted to get a sense of whether LCP could be improved by showing the hero carousel straight away.
Re-running the tests after adding
owl-loaded to the carousel resulted in the LCP dropping from 13,221 ms to 5,429 ms, an improvement of 59%.
But for me, the biggest benefit is that it lets you be a lot more confident with the recommendations that you give.