If your business relies on organic traffic, it’s imperative that your website is optimised for Google’s upcoming Core Web Vitals (CWV) update. Originally due to be released in May, this ranking update has been pushed back and is now set to begin rollout in mid-June and be fully embedded by August – giving organisations valuable extra time to prepare.

Image of Google Analytics on a monitor

As we’ve covered in more detail in our on-demand webinar, the Core Web Vitals update is a major change to the search engine’s ranking algorithm, that puts increased focus on page performance signals to reward those sites that deliver a fast and smooth browsing experience. In contrast, sites that aren’t optimised risk losing visibility in the search rankings, as well as a negative impact on conversion rates, overall user experience and even the environment (with higher demands on the CPU requiring higher levels of energy usage).

At Box UK we receive much of our online traffic (and subsequent enquiries) from organic sources, and wanted to do everything we could to ensure our site was prepared for the Core Web Vitals update, in line with our agile approach that promotes continuous iteration and improvement at every level of the organisation.

In just a few days we had taken the site’s scores against key performance metrics from the 20s and 30s up to 90+. In this post I’ll take you through the key points of this journey, explaining some of the major activities we undertook that you can apply to improve your own CWV scores and how our approach helped ensure maximum impact and value was delivered, as quickly as possible.

How to improve your Core Web Vitals scores

1. Look at your typography setup

Our first action was to look at how the fonts were being loaded across the site, as this is managed by a third-party service and some of the default decisions were negatively impacting performance. We made a number of changes to optimise how the fonts are configured, which Harry Roberts has written about in more detail on the CSS Wizardry site (where you can also find lots of useful advice on a range of other specific performance issues).

Large and small letter 'A' characters

This optimisation work included the installation of a ‘fallback’ font, which displays a standard web font while the third-party option is loaded, to improve time to First Contentful Paint (FCP) – one of the key page experience signals that make up the Core Web Vitals update. This did however introduce a slight ‘step’ as the fallback font was swapped out, causing a small increase in Cumulative Layout Shift (CLS), another of Google’s page experience signals. We’re currently doing some additional work to mitigate against this by ensuring the fallback and final fonts are as closely matched as possible, which will minimise the shift and improve the visual experience for users.

2. Review any unused elements

Next up, we had to remove any elements across the site that were adding to load times, without delivering value. For the Box UK site this included elements such as scripts to render emojis, unnecessary block styles and libraries, and default stylesheets, although this will differ across sites. Another high-impact change was making our use of Bootstrap much leaner, selecting what items should load rather than having everything load by default (reducing Bootstrap to around half the size in the process).

We also conducted a review of active plugins across the site to understand the performance impact each was having, in order to weigh up this cost against the value being delivered. In some cases the plugins could simply be removed with minimal impact to functionality, while in other cases it was necessary that they stay, and the associated performance impact would have to be tolerated. The review also highlighted opportunities to improve what was already there, and explore alternative solutions that may provide a better balance of performance and functionality (something we’re currently investigating to deliver live chat capabilities, for example).

3. Optimise images/animations

Images play a major role in many modern websites – communicating brand identity and delivering visual interest and impact – but they also have one of the most significant performance footprints.

View of a person's arms working on laptop, on wooden desk

To reduce page load and improve performance without compromising the images that are already on the Box UK site, we implemented a number of changes such as preloading the hero banner images across the site and setting up a ‘smart’ preload which renders a small image by default, and then resizes it according to the specific dimensions of the viewport. To improve the visual experience the images were also configured to display a blurred version while the full image is loading, rather than the grey block that is the standard.

To target improvements to the First Contentful Paint scores, optimising specifically above the fold was a priority area of focus. We did a lot of work here including implementing lazy loading images so that they only load when visible, and disabling animation above the fold. We also updated the default settings of our WordPress VIP installation, which concatenates JavaScript but doesn’t defer the script. Turning deferred JavaScript on ensures that it isn’t loaded before it’s needed, further boosting performance.

4. Optimise videos

In a similar way to images, videos can really help communicate messages to website visitors and encourage engagement and interaction – but this often comes at the cost of page speed. The Box UK site includes both Vimeo and YouTube videos, and on investigation we found that scripts for both of these services were loading on any page that contained a video – our first step was to change this to only load the specific script needed to play the video on the page.

YouTube and Vimeo

We also swapped the existing full video player scripts with ‘lite’ versions to reduce load requirements and to behave like a facade. This did mean that some advanced features – such as allowing users to reopen the video popup at the point they’d paused it – were no longer supported, but it was felt that the performance gains delivered made this compromise worthwhile.

More about our process

As you can see, the improvements made targeted a wide range of elements across the site, but just as important as what we did was how we approached the process.

Optimising for performance is much an art as it is a science, and the activities that deliver greatest performance will be different for everyone, but you should always start your project by capturing baseline metrics against which you can measure the impact of your activities. We used the WebPage Test tool to do this, which assesses the site against a range of criteria including Google’s Core Web Vitals page experience signals, and insights from its Lighthouse tool.

In addition to running the home page through the tool we also tested a range of page types to get a representative picture of the site, covering service and insight pages, about us, and vacancies (we also focused on mobile scores over desktop, as Google will be prioritising these as part of the CWV update).

One we had a baseline in place we then took an iterative approach to making improvements, reviewing after each deployment to measure the impact on performance. Initially we took our measurements from the vacancy page, as while it’s less important that these pages rank in organic search they are perhaps the least complex pages on the site, so we could be confident that any improvements seen here would be reflected across the other pages. When the vacancy page was ranking well we then moved our focus to optimising specific components found elsewhere on the site.

Close-up of laptop and person's hand

The iterative approach taken additionally facilitated ongoing discussion with the site owners (in this case, the marketing team), so that we could make informed decisions about development activities, to balance expected performance gains with any potential negative impact on functionality or the customer experience. Changes were also rolled out responsibly to minimise risk throughout the process, using feature flags to streamline the deployment process and enable any new features to be quickly and safely rolled back if needed.

Summary

So that was our performance optimisation journey, but what did the work deliver? Well, the results have been pretty impressive – we’ve taken the site from scores of 27 (for the home page) and 32 (for a representative service page) to 95 and 97 respectively. We’re now well-prepared for next month’s Core Web Vitals update, and there are signs that Google is already viewing the changes favourably, as we’re seeing a steady growth in search visibility and organic traffic.

If you’re worried that your site is underperforming and are considering making changes to protect your organic traffic, a good first step is to plug your URL into the WebPage Test tool or Google’s own PageSpeed Insights tool to check your current scores. And if you’re not sure what changes to make or how to manage progress, get in touch with a member of our team for clear and practical recommendations, targeted at where they’ll make the most difference.

About the Author

Ian Jenkins

Ian Jenkins is a Principal Developer at Box UK. He has wide range of development experience in various platforms and languages, in particular PHP and Symfony. Ian has worked on and delivered a number of successful projects and is currently most interested in maintaining and transforming troublesome legacy projects into well-tested, high-performance web applications.