2 misunderstandings of Google’s Core Web Vitals

Timothy Bednar
Nov 20, 2020 · 4 min read

This post assumes that you have been working to improve Core Web Vitals and need clarity on how Google uses the metrics. Please visit Waterfaller.dev to fix page speed and core web vital issues on your web site.

I have been working on making pages faster for over a decade and have seen all kinds of shenanigans when it comes to page speed. Way back in the day, we mistakenly used server response times which were soon replaced by time-to-first byte. Oh and then we got fancy.

Image for post
Image for post

We started measuring “page load” (or specifically the window.load event which corresponds to when the browser stops “spinning”). But soon it was clear that we could cheat that metric to look good on internal reports without any real-world improvement. (Oddly enough Google Analytics still uses this metric in its Site Speed report.)

How fast is fast enough?

Starting in May 2021, Google announced that Core Web Vitals are becoming the metrics used to determine search rankings. And for many businesses, this is the answer on what to measure and how fast is fast enough. But even with that clarity, two common misunderstandings might keep us from fixing our issues. Today, I will focus on first input delay as measured by Google in their Search Console.

Misunderstanding #1 — field metrics

As an application, I want to improve the FID so that it is less than 300ms.

Instead, you can use a “lab metric” called total blocking time (TBT) as a proxy for the first input delay. TBT measures how long the main thread is blocked from the first contentful paint until time to interactive (TTI). The idea is that if we reduce TBT, then the probability of a user getting a delay goes down. So you could write something more testable,

As an application, I want to reduce the Total Blocking Time of our landing page so that it is less than 600ms.

I have recently found that while this is testable. Depending on our situation, the scope of the fix could make this story unsuccessful. TBT adds up the blocking time of “long tasks” or tasks long take longer than 50ms. So a more testable story might be,

As an application, I want to reduce the number of long tasks that occur on our landing page to improve total blocking time.

The above story forces us to inventory all the long tasks on the page, find the scripts responsible, and then target specific solutions. Depending on what we discover, we might create user stories for each task addressed. This specificity allows us to create stories that are testable.

Misunderstanding #2 — percentiles

The issues identified in the Search Console are based on percentiles. Every day, Google rolls up all the URLs for our domain then it calculates the 75th percentile for first input delay. It then applies its rubric to that number: 0–300ms is fast, 300–600ms gets labeled “needs improvement” and everything slower is “poor”. If a page is visited 48 times and the FID is “poor”, it means that 36 visitors experience an input delay over 600ms.

So to make sure that our FID is fixed, we will need to make sure that our testing describes how to test focused on those 36 visitors. For example, we discovered that users getting poor FID were mobile users visiting from India. This insight now informs our acceptance criteria for our story.

Story: As a mobile visitor, I want my browser to process fewer long tasks so that I can quickly interact with the call to action.

Scenario: mobile visitor from India visits landing page
Given that I’m located in India
and using a Moto g4 on a slow 3G connection
When I visit on the landing page
Then my browser processes fewer long tasks
and I can quickly interact with the call to action

For this story, we can test by comparing the before and after values for the number of long tasks and then also use the Chrome Web Vitals plugin to measure FID when interacting with the call to action.

If Web Vitals and Google ranking is critical to our business, we would do well to avoid these common misunderstandings which also will apply to largest contentful paint and cumulative layout shift.

I’m daily working to improve page speed, and as a side hustle, I created Waterfaller. I appreciate your comments.

Waterfaller.dev

Let’s fix your page speed and core web vital issues

Sign up for Waterfaller

By Waterfaller.dev

Resources for page speed nerd from Waterfaller.dev Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Timothy Bednar

Written by

Married, father of five, web developer, and creator of Waterfaller.dev

Waterfaller.dev

Waterfaller.dev is a publication and newsletter on Medium and “not another” page speed application (https://waterfaller.dev) that pinpoints page speed issues, suggests user-stories and acceptance criteria and points to technical solutions.

Timothy Bednar

Written by

Married, father of five, web developer, and creator of Waterfaller.dev

Waterfaller.dev

Waterfaller.dev is a publication and newsletter on Medium and “not another” page speed application (https://waterfaller.dev) that pinpoints page speed issues, suggests user-stories and acceptance criteria and points to technical solutions.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store