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.
It works by saving a copy of the page you're working on (or any other resource, like a JavaScript or CSS file), letting you edit that, and then serving that file instead of the live version.
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
You need to know what your baseline is before you can see if a change improves or harms performance. Most of the time, the metric I'm trying to improve is Largest Contentful Paint, so I built a JavaScript snippet that's heavily inspired by Tim Kadlec's perf-diagnostics.css.
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:
javascript:(function(){var paintEntries = performance.getEntriesByType("paint");var entries = [];new PerformanceObserver((entryList) => {for (const entry of entryList.getEntries()) {entries.push(entry);}var element = entries[entries.length - 1];var lcp = entries[entries.length - 1]["loadTime"];var fcp = paintEntries[1]["startTime"];console.log("FCP is " + Math.round((fcp + Number.EPSILON) * 100) / 100 + " ms");console.log("LCP is " + lcp + " ms");element["element"].style.border="4px solid gold";}).observe({type: 'largest-contentful-paint', buffered: true});})();
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.
Now that's all set up - I normally run 3 tests, making a note of the First Contentful Paint and Largest Contentful Paint values using the JavaScript bookmarklet.
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 noticed that Wiggle were using the anti-flicker snippet from Google Optimize. A/B testing software sometimes suggests this - it effectively hides the page completely until either the Optimize JavaScript has loaded and run, or 4 seconds have passed - whichever is soonest. 4 seconds is a long time to hide content, and could explain why slower connections are seeing an FCP of over 5 seconds. Andy Davies' has a really useful post on anti-flicker snippets, which is worth checking out if you'd like to know more.
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
With the JavaScript bookmarklet, I was able to see that the LCP element was the hero header image. Wiggle seem to use a carousel for this, but they only show the first slide. In either case - the approach seems to hide the carousel by default, and then unhide it with JavaScript. It looks like it adds a CSS class named 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%.
Wrapping up
Local Overrides allow you to experiment with site speed fixes on your local machine, so you have a really fast feedback loop. It's useful for helping you debug, spot issues, and test whether things like deferring JavaScript will break the page layout.
But for me, the biggest benefit is that it lets you be a lot more confident with the recommendations that you give.