What are the limitations of Core Web Vitals?

by | Jul 21, 2021 | Application Performance, Articles

A lot of attention is paid to Core Web Vitals these days, but few articles cover their limitations. I thought useful to share some thoughts about this.

Boris Rogier

Boris Rogier

Co-founder

Core Web Vitals: what are the limitations?

Core Web Vitals are under the spotlight of web performance since Google’s web dev team introduced it as a new scheme to evaluate user experience on a website. Google announced in November 2020 that the Core Web Vitals would influence the SEO page ranking from May 2021. This has a major impact on many businesses who depend on their website to conduct their operations and generate revenue. A lot of discussion around web performance has exclusively focused on optimizing Core Web Vitals for that reason. 

But Core Web Vitals have limitations:

  • they do not reflect all aspects of user experience
  • they are not meaningful for all websites.

Let’s take a close look and identify the gaps and the situations where that experience monitoring framework is adapted or not. 

What are Core Web Vitals’ main gaps? 

Core Web Vitals is structured around 3 metrics which reflect 3 aspects of the user experience: 

  • LCP (Largest Contentful Paint) reflects the speed at which a user will start seeing “something large” (any object, be it an image, text, video, …) appearing on the screen
  • FID (First Input Delay) measures interactivity or the speed at which the browser will be busy at the first  user interaction
  • CLS (Cumulative Layout Shift)measures visual stability and whether the user may be disturbed or not by content being shifted away on the screen by the rendering of another content. 

For the sake of clarity, Core Web Vitals bring massive improvements compared to older metric sets (like page load times, TTFB, FCP). 

Where are the limitations of Core Web Vitals then? 

Loading speed / LCP 

This metric makes sense if most of the user experience is driven by pages being loaded fast. Nowadays this is not always the case for web applications (like SaaS apps) and also for a growing number of websites (like social networks).  Page loads represent a very small portion of the experience of users. Progressive or single page applications initially load a bundle (containing a set of stylesheets and javascripts), but then most user interactions do not consist in additional pages being loaded but in javascript executions and web API calls to render additional contents and execute functions. 

There are two consequences to that: 

  • Page load and LCP measurements are exceptional. A user may load a page only a limited number of times a day while using a website full time. 
  • From a user perspective, the operation measured by the LCP is relatively meaningless. In most cases, visually it consists of loading a logo or a progress bar. 

This is what LCP measures for a website like www.linkedin.com:

LCP example with Linkedin

This means that the actual user experience which is measured by LCP is the appearance of the Linkedin logo on the initial load of the page. If that operation was slow, LCP would bring some info (but is it really a web performance challenge to render a logo within a short timeframe?).

First Input Delay – measuring interactivity

FID aims at measuring interactivity and the responsiveness your users experience. Technically speaking it measures the time interval between the first user interaction (e.g. a mouse click) and the time by which the browser is able to react to it (for more details on the FID, please read this article). 

This is a good starting point but again for progressive web sites and single page applications, that very first interaction is too small a sample of the user’s activities to be meaningful. 

As an example, the table hereunder represents the number of calls made by a user on linkedin.com by initiator type.

  • There cannot be more “first user inputs” that the number of page loads (here Navigation = 377 items).
  • While the number of XHR (XmlHTTPRequests), scripts and fetch calls that generated requests over the network (e.g. API calls to render data in all forms) sums up to more 3.1k operations.

At best FID represents 10% of the user’s interactions. 

How many interactions does FID measure

When should you rely on Core Web Vitals… or not? 

Core Web Vitals are great for some sites… but inadequate for others. 

You should rely on Core Web Vitals when most of the user’s interactions consist in loading additional pages. 

In case your web platforms consist of: 

  • Progressive web apps
  • Single Page Applications

You may care about Core Web Vitals because of its SEO ranking influence. Nevertheless Core Web Vitals will be very insufficient to make sure you keep your user experience under control. 

If this corresponds to your situation, I recommend that you take a close look at this article on “How to monitor user experience for Single Page Applications”.  

Share this post

Newsletter

All our latest network monitoring and user experience stories and insights straight to your inbox.

Resources

Kadiska is now part of Netskope
This is default text for notification bar