There isn’t a hard and fast rule for how to audit Core Web Vitals, especially with a variety of third party tools to consider. We breakdown some of our speed auditing top tips to incorporate into your workflows, which will cover:
When auditing a website for site speed and Core Web Vitals issues, we recommend always start the troubleshooting process by reviewing the ‘Experience’ section within Search Console – provided access is available. Search console aggregates real user (field) data from the Chrome UX report, so this is an easy way of understanding which of LCP, CLS or FID issues are affecting your user experience, and ultimately the site’s ranking potential.
Navigate to ‘Page Experience’ > ‘Core Web Vitals’, and the graph displayed will show the number of URLs that are classified as either ‘Good’, ‘Need Improvement’ or ‘Poor’ for the website property. For example:
See the chart below on timings and metrics from Google on the above Core Web Vitals thresholds.
From here, we can assess whether or not the majority of URLs are classed as Good’, therefore passing all 3 Core Web Vitals metrics, or if most pages are ‘Poor’ or ‘Need improvement’, indicating that there are some outstanding technical issues that need to be resolved in order for them to pass.
Helpful Tip: Pages need to pass all three web vitals in order to move into the ‘Good’ status, and it’s not enough for the majority of a site URLs to be in the ‘Need improvement’ range.
You can then drill down into each section to discover the specific URLs that are being affected by speed issues and need auditing. These are grouped by those that are similar on a template level. So, instead of trying to audit all different types of URLs that a site may have – e.g. homepage, category pages, product pages, blog posts, etc, the issues that real users face when visiting the website may only be centred around 1 or 2 of these, meaning that you can focus your efforts solely on these templates, which can be a great time saver.
Although PageSpeed Insights (PSI) is a useful free tool by Google that gives a top level overview of potential opportunities to fix issues, it’s really a lazy way to audit site speed if used in isolation. We’ve seen many SEOs take the recommendations, sometimes word for word, and present these back to the clients developers or technical team without really understanding the why or any context behind them.
Unfortunately, this can often lead to more questions being fired back at you, especially if you’re not delving further into the opportunities and recommendations that the tool will spit out.
For example, we’ve all heard of the recommendation to ‘Eliminate render blocking resources’ to speed up the load of the LCP element, but what happens when this resource is critical to have in place on first paint, such as a cookie banner script or the affected assets are 3rd party resources? Developers are likely to knock this one straight back, as there won’t be much they’ll be able to do – so it’s really important that any technical recommendations taken from PSI are taken with a pinch of salt and investigated further before relaying back to developers.
It’s also useful to know that PSI uses a set emulated device (Moto G4) with Lighthouse, but issues can vary considerably depending on the device real users utilise most frequently, as is the case with ‘lab’ testing. It can often mean that PSI will not return issues or opportunities for testing on that specific device, even though you know there’s an issue for the site’s real users from the Chrome UX report.
We’d therefore always recommend using PSI in conjunction with other speed testing tools where device and connection configuration can be adjusted accordingly.
WebPageTest has a range of useful features and configuration options that aid speed testing at the page level. The advanced configuration allows you to adjust important test settings, like the browser and device type, as well as test location. This allows you to fine-tune your auditing, especially if you know where the majority of the site’s users are located, as well as their device type, meaning you’re not just relying on Google’s preset simulated device.
Here,you can also adjust the connection settings from the default 3G Fast connection, as well as block certain URLs if you want to test performance increases for troublesome scripts. There’s plenty of other configuration options we haven’t listed to explore but the above are the ones that we found most helpful when auditing core web vitals.
Once a test has been run, navigate to the Core Web Vitals tab to get a detailed breakdown of performance for each metric including filmstrips, video timelines, waterfall charts, as well as a granular breakdown of the element that triggered the event – all of which are exportable in a range of formats, and best of all, free!
The filmstrip view is particularly useful in understanding at what point in the page load certain elements visually appear, which can help prioritise which assets could potentially be loaded quicker. It will display very clearly if there are significant visual shifts to help pinpoint the elements causing it.
GTMetrix has similar features to WebPageTest, however, a lot of the advanced options that are free in WPT are only available in the paid for packages.
In basic terms, a waterfall chart is a timeline of when files or assets are requested, how long they took to download and when they are visible on the page.
Looking at a waterfall chart can seem a bit daunting from the offset, as there’s lots of different rows, bar lengths and colours that mean different things – but don’t be put off! Spending time learning about and understanding waterfall charts is the single most important skill a technical SEO should have for speed auditing.
If you’re used to using WebPageTest for web vitals auditing, we find their waterfall charts the most user- friendly. WebPageTest providesa colour coded key above the chart denoting connection information, resource types being requested, and other events such as JS execution. It also visually displays render blocking resources, as well as highlighting requested resources that have a 3xx or 4xx response.
Helpful Tip: Pay attention to the light and dark shade of the horizontal bars on the waterfall, the light shade indicates that the resource has been requested by the browser, whilst the dark shade indicates the resource is being downloaded.
All in all, this helps in gaining a deeper understanding of performance issues on the site and, in turn, makes your recommendations to fix them more actionable. We recommend Matt Hobbs’ in depth article on how to read a waterfall chart to learn more.