Anyone in SEO or UX type circles, or just those hanging around the Google gossip-mill of late, will have been hearing plenty of chuntering about core web vitals, the new UX performance-based signal due to roll into the Google algorithm’s big ol’ list of “things wot we grade you on when choosing who to rank.”

This was actually pre-announced all the way back in November last year, a substantial amount of notice given Google’s usual habit of just rolling things out: core web vitals will officially become ranking signals as of May 2021. This means they are joining the existing UX signals already in use by Google as considerations when ranking organic results.

Existing UX Ranking Signals

Way back since the original mobile-friendliness update (sometimes referred to mostly-playfully by SEOs as “mobilegeddon”) back in April 2015, Google has been paying more and more attention to stuff outside of content and basic speed indicators to try and ensure that search results served in high organic positions offer a nice experience to users that goes beyond “does the content match the intent.” The key (confirmed) UX ranking signals as of now-ish are

  • Mobile friendly (does the page work well on all device sizes, especially wee phone screens; is text readable, are links usable/tappable without needing a microscope, that sort of thing)
  • Secure and safe browsing (not just “does the site use HTTPS” but also is everything on the site secured, is it clean of malware and other nasties, does it not implement dodgy redirects that seem to go to nowhere useful or legitimate-looking…)
  • No intrusive interstitials (does the site let people actually land on the darn page they asked for or does it start bothering you with popups and interstitials for app installs/newsletter signups/other stuff which isn’t really functionally essential)

What Are Core Web Vitals?

There are three core web vitals to be aware of and it’s a three-letter-acronym festival on all of them!

  • LCP (largest contentful paint)
  • FID (first input delay)
  • CLS (cumulative layout shift)

LCP (Largest Contentful Paint)

This is a way of measuring what is often called “perceived load speed” – it essentially means the time that elapses until the biggest chunk of page content (i.e. the main bit of it) has loaded. Other little bits and bobs like icons and tracking scripts and ads may load afterwards, but the LCP time just measures up to when the largest image or text block visible within the viewing screen has fully rendered. So focus on mostly urgently loading your main content which is initially visible above the fold on all devices, especially mobile, and you’re on-track for a good LCP score.

The marker for a “good” LCP score is 2.5s or less. Find out more techie stuff here. Optimise by

  • Making sure your server is responding right darn quick (slow shared hosting = bad)
  • Minimise and avoid render-blocking JS and CSS
  • Minimise those resource load times (stop uploading images 10x bigger than they need to be!)
  • Make sure your client-side rendering goes snippity snap
  • Ask your site developer to have a look at these juicy tips to see what else they can improve

FID (First Input Delay)

The main thing this measures is how soon until users can start actually, you know, using the page. This might be tapping a button, clicking a link, activating a filter, or something similar. FID is measured from how long it takes between the user trying to do something and that something actually happening or the control responding. This is of course especially critical if you have a lot of rich interactive features on your page like buttons, filters or other doohickeys – nobody wants to see a page that they can’t interact with. Ever had a site where you tap and tap and tap on a button and nothing seems to happen? That means there’s an FID delay.

The threshold for a “good” FID score is 100ms or less. Find out more techie stuff here. Optimise by

  • Trimming down third party code impact (make sure you’re not loading a bunch of tracking or analytics scripts you’re no longer using, for example)
  • Reducing script execution time (make sure that JavaScript runs fast)
  • Use web workers to do “off thread” work which slows down browser activity
  • Ask your site developer to have a look at these juicy tips to see what else they can improve

CLS (Cumulative Layout Shift)

This is a bit of an oddball one to understand but in essence it means that if your site seems to load and be usable but then something else loads in (an ad, for instance) which means the page layout shifts so someone might accidentally hit the wrong thing…that’s a problem. Google’s dev documentation has an excellent example of this, which I’ve turned into a GIF below for ease of sharing.

GIF: Example Of CLS Problem

This is particularly troublesome if things are loaded in asynchronously so is especially one to watch for publishers using ad platforms!

There’s a lot of fiddly detail on how exactly CLS is calculated (and quite a bit of geometry and math) but you want to aim for a score of 0.1 or less as the bottom line. Find out more techie stuff here. Optimise by

  • Reserving layout for all the bits of your page, including ads, using size or CSS aspect ratio boxes so slower stuff loads into “parked space” rather than popping in and pushing things down
  • Just plain stop inserting things above content that has already loaded unless a user does something that warrants it
  • Use sensible transform animations that make any state changes clear and easy to understand for users on the page
  • Ask your site developer to have a look at these juicy tips to see what else they can improve

Checking Your Core Web Vitals

The good news is that a quick healthcheck on your site’s core web vitals is super-easy, as long as you’re set up on Google Search Console (and if you aren’t…well, you should be)! Just head to the new section under Enhancements and voila, there are the reports.

Core Web Vitals Report Example In Search Console

You can click into each row to see examples of URLs being affected. As most problems with these metrics will be template led (i.e. an issue on all of your product pages, not just one individual URL) this data should be enough for you to work with your developers to track down any issues and get them sorted out well in advance of May.

As of yet the strength of the new UX ranking signals (i.e. if you’ve got any problems, how hard an SEO wallop will your site take from it) has not been made clear, but in today’s hyper-competitive online world it’s worth crossing every t and dotting every i when it comes to your site’s technical setup – so even if you think your site has other strengths that might compensate for any algorithmic downgrades you get in May, you’d be mad not to get these checks on your to-do list ASAP! As a quick crib sheet, take a look at this magnificent beast put together by the fantastically talented Martina Zrzavá Libřická:

Core Web Vitals by MartiStruggling to understand what your report is telling you? Lost in the nerdy bits and the TLAs? A chat with your friendly local SEO consultant can help demystify the jargon and pin down areas for your developers to focus on. Give me a shout and let’s see how we can make your site better.