How to audit & optimise for Core Web Vitals
Core Web Vitals Explained, Audited & Optimised
This post covers Core Web Vitals, and explains what the new Page Experience update is, and how to optimise for it along with an auditing exercise.
If you are at the stage where you wish to proceed with a core web vitals audit then don't hesitate to get in touch, I can provide a full auditing service along with recommendations and all enhancement implementations.
Coping with Core Web Vitals
We know it will hit some time over the summer (took me awhile to upload this blog, apologies it’s now Autumn… What a year!), and this insight came from Google, not an ego-centric self-proclaimed SEO expert. And it took me so long to complete this blog post, due to ongoing work, the Page Experience update has landed and is(has) rolling/rolled out…
Core Web Vitals has stemmed from a Google update which they have named the ‘Page Experience update’. Web Core Vitals is a leading factor in assessing the quality of how Google judge your visitors page experience.
In a nutshell the Core Web Vitals are a standard set of metrics provided to developers and SEO’s to help understand how a user engages with our web pages.
What are the metrics that determine a visitor’s web page experience?
So far, we know they comprise of the following:
- Page Load Time
- Mobile-Friendly
- HTTPS
- Intrusive ads
All the above points have further detail and for now we know these elements are judged in determining the quality of a user’s web page experience.
So, what of the Core Web Vitals?
Is your content bumping around as the page loads (CLS), and is the content, along with the on-page objects, shifting about as the page loads? Ideally, you want the page to look and appear solid as soon as the page loads into the browser.
The metrics that make up Core Web Vitals assess the website’s loading time, how it interacts with the viewer on load and visual stability.
These three metrics – loading time (LCP) - the page loading performance, time to interact - (FID), the ease of interaction and visual stability - (CLS), are closely related to a website’s speed and all three metrics impact performance for both the search engine and the visitor to your website.
Google has given us a strong heads up regarding this algorithm update. They have also provided us with these three metrics which we can measure and improve. These three Web Core Vital metrics comprise of the following detail:
(Loading) LCP: Largest Contentful Paint
LCP: Measures loading performance, which is essentially how long it takes for the largest item in the viewport to load. LCP accounts for what is visible in the visible screen and considers nothing that is happening below the fold. Key factors to consider include images, background images, block-level content text and video poster images.
Ideally, we want to hit below 2.5 seconds, even if it is below 4 seconds it will still need improving. Anything above 4 seconds and we will be in the negative zone.
Fast loading pages are more likely to rank higher in Google than slower pages, a fast-loading page is key to a positive user experience. Fast page load times also benefit conversion rates and engagement factors.
(Interactivity) FID: First Input Delay
FID: This measures the time it takes for the website to be in a state to respond when a user clicks on something. It’s a measure of the website’s page being in a state of idleness within the viewers browser.
FID is measured in milliseconds, the ideal here is to hit below 100 milliseconds, to avoid the poor score ranking it needs to be below 300 milliseconds.
The FID measures the time taken for the web page to be in a state where it can register a first interaction point (click being made) and be able to act upon the click. So, it’s the processing time from the first click to when the page is set to engage with the click being made. This is where FID differs from the Time to Interactive metric, which measures the time it takes a page to become fully interactive only.
(Visual stability) CLS: Cumulative Layout Shift
CLS: This is the measure of visual stability when the page is loading. Content blocks, images or other content assets that shift on load will need optimising so to ensure that the movements are minimised. Examples of this occurring include; when a page loads and you go to click on a link, but it then suddenly shifts, or images swap around before eventually settling down into their holding space.
Google’s algorithm uses a calculation to produce a score for your web pages. To be in the green CLS must be less than 0.1, or a minimum of 0.25 to avoid going into the negative region.
We are provided with a traffic light measurement and the target is to hit good, or green! Factors measured by CLS include - Impact fraction, layout shift and distance fraction.
The Site Speed Audit
So, the above are the main metrics, now how to audit the website to assess speed performance. We will focus on the ‘poor’ score areas but note how this can be adjusted to include ‘needs improvement’ pages.
To perform this Web Core Vitals audit you will need a paid subsciption account for Screaming Frog and a Page Speed Insights API key.
How to extract the relevant data from Screaming Frog:
In the top navigation bar select the ‘Page Speed’ tab followed by Export.
Once the data is extracted from Screaming Frog find the following columns and filter out accordingly:
Largest Contentful Paint Time (ms)
- Filter this column to an LCP of equal to and more than 4000ms
Total Blocking time (ms)
- Filter all pages with a TBT of equal and more than 300ms
Cumulative Layout Shift
- Filter all pages to equal to or more than 0.25
Select and copy this data over to a new sheet.
All the details on this new sheet display pages that fail each Core Web Vital metric.
This list is a starting point for developers as it points directly to pages with issues, check for patterns to shed light on areas that maybe a point of failure.
Fixing Speed Issues
Firstly, let’s investigate if there any common render blocks, relevant to these pages that the pages may not require.
This is easily done in Screaming Frog, within the Overview tab simply scroll down to Page Speed and you will find a list of common issues that affect the speed of any page load.
Improving the LCP
If you see lots of pages with the ‘Eliminate Render-Blocking resources’ issue, then select and export it. The Render Blocking issues impact LCP performance, and you can see each URL that is affected within this tab in Screaming Frog.
Analyse the page and decide as to whether the pages affected require all the current calls that are being made, and whether aspects can be in-line to the source code of the page, and can anything be deferred on load?
LCP measures the length it takes for the largest element in the viewport to render, essentially the user must see something meaningful within a reasonable amount of time (less than 2.5 seconds for mobile).
Element types that are measured for this metric comprise of:
- Block-level elements with inline text, or just plain text
- Img
- Image inside an SVG
- Post image of a video element
- Element with a background image loaded via a URL from within a separate CSS file
Applying optimisation methods to these elements on a page will improve overall rendering.
A good improvement, that applies to a lot of websites we come across, is to inline all the CSS in the head section of the page you are working with.
This can save a lot of page loading time; some sites need just 5% of the CSS that loads for a page. Streamlining this by isolating the CSS required and only applying that to the one call on a page will make a significant cut into LCP times.
Another good tip is to look at implementing lazy loading, for offscreen images. And keep the images light, high resolution images are not always necessary. And ensure the main banner, or hero image, is served early in the page load process.
CLS improvement tips
Apply a CSS aspect-ratio so to reserve areas of space or apply aspect ratio boxes. And ensure that you include size attributes on video as well as image elements. This means the browser allocates the correct amount of space in the document while the image is loading.
Apply set dimensions to your image holders, in the CSS or inline too. This will prevent image holders from shifting around upon page load. This achieved by populating img elements with the width and height attributes. Responsive images can be handled using source set (srcset) in the CSS which defines the images you allow the browser to select.
Use local fonts if possible and they are acceptable, calling web fonts can lead to layout shifts. This is due to the browser recalculating font space after the web font is called and then downloaded.
Specifically, we need to ensure that when a visitor to your web page scrolls downward, minimal shifts, if any, are occurring. Design aspects that incorporate natural shifts should be ok, provided that relevant CSS calls are used, such as – transform, scale and other related properties that relate to animations and transitions.
Improve the First Input Delay
We need the web page to be ready to go as soon as it gets a visitor, they need to be able to use buttons, links, or whatever other clickable elements you have placed on the web page.
A good approach is to avoid having images being loaded that may get in the way of critical resources being called such calls to CSS and JS files.
Fixing, or improving, a poor FID score is often achieved by focusing on optimising both CSS and JS files. The goal is to get these files downloaded and parsed as quickly as possible. This enables the web page to be rendered, in terms of page layout, quickly.
Optimising CSS files involves simply deleting calls from the page to CSS that are not required for the page or deleting out old CSS code that is no longer used from within the CSS file.
JS files may prevent engagement on a page to be instant from a first click, due to them creating a long input delay caused by their shear size or server location.
Speed Optimisation techniques.
Along with optimising for the Web Core Vital components that make up the major factors of the Page Experience update. There are several other things you can do that will aid a web pages performance and these include:
- Enable GZip compression and HTTP/2 from your web server. Delete old files that are not in use and if possible, use a CDN to deliver content globally faster.
- Resize images to fit mobile screens and use the correct file format for images. Keep them light where possible and try not to lose too much of the image’s quality where it’s needed.
- Use CSS for borders or background colours, use CSS instead of background images.
- Do away with using Google Fonts or add styles to the call.
- Do not use the @import tag for CSS calls, just place link tags to unique CSS files where necessary.
- Avoid older CSS layout techniques like float and use flexbox and the CSS grid instead.
- Avoid inline CSS and minify CSS files into other files where possible.
- Use CSS animation techniques instead of JS powered effects.
- Use an SVG wherever possible instead of usual image formats like jpeg or png.
Concluding
In conclusion, the three most important aspects of Web Core Vitals which we can optimise for include FID, which tracks the websites responsiveness, CLS which tracks the stability of the web page on load, and LCP that tracks overall page load speed.
Hitting green for all these aspects depends on the complexities of the web page. Some web pages may require several calls to function in a manner so it’s reaching the objectives set. It’s a duty to improve what we have using the above optimisation techniques. Understanding the aspects that enhance the Core Web Vitals metrics is a step in the right direction. Working on web pages to improve these factors will benefit all aspects of the website, from search engine ranking to user-engagement, and so make the objectives of the website easier to attain.