What You Need to Know About A New Core Web Vitals Metric Google Is Creating
In recent months, Core Web Vitals may be the single most discussed change in the Search Engine Optimization (SEO) world. These new metrics mostly continued to promote Google’s insistence on pages delivering an excellent user experience. However, they also provided new benchmarks for webmasters to adhere to and inform their choices, and also hinted at massive SEO implications. Now, only a few months since their initial rollout on mobile devices, one is already set to be replaced. So, let us explore this new Core Web Vitals metric Google is creating and how it may affect web development.
Core Web Vitals, summarized
To contextualize this change, let us first briefly summarize Core Web Vitals themselves.
Web Vitals, as well as their Core subset, serve to help webmasters gauge their websites’ User Experience (UX) and performance. However, only the Core subset informs Page Experience – along with some other metrics, one of which was later removed. It was likely this initial state of affairs that caused some confusion in the SEO world early on. Thankfully, web development experts can help with this distinction now and inform your course.
Still, for context and clarity, let us briefly outline this distinction ourselves.
#1 Web Vitals
Initially, the larger Web Vitals group includes the following, as Google’s aforelinked article explains:
- Time to First Byte (TTFB)
- First Contentful Paint (FCP)
- Largest Contentful Paint (LCP)
- Total Blocking Time (TBT)
- Time To Interactive (TTI)
- First Input Delay (FID)
- Cumulative Layout Shift (CLS)
Each of these metrics gauges a different aspect of a user’s interaction with a website, from the first click to the first input and visual cohesion. Addy Osmani’s following illustration explains this very well:
However, not all of these are equally impactful or equally within webmasters’ direct control. That’s arguably why, as we’ll discuss below, they don’t all affect Page Experience.
#2 Core Web Vitals
Unlike their broader group, Core Web Vitals do – along with some other metrics. These measure specific, highly perceivable aspects of users’ experience, not peripheral factors like TTFB or TBT. In brief, they are the following.
Largest Contentful Paint (LCP)
LCP measures the time between when a page first starts loading and when the largest image or block of text becomes visible to the user. Google explains that it effectively gauges perceived loading speed.
First Input Delay (FID)
FID measures how long it takes for a page to first become able to process user input, such as a click or tap. Google explains it effectively gauges perceived responsiveness – and it’s the way it does so that informs the new Core Web Vitals metric Google is creating.
Cumulative Layout Shift (CLS)
Finally, CLS measures a page’s visual stability by assessing how many layout shifts occur within the user’s viewpoint as the page loads. This is the most technical one among Core Web Vitals to gauge, as its score comes from a formula, not a static time measurement.
#3 Page Experience
Lastly, Page Experience takes Core Web Vitals into account, as well as mobile-friendliness, HTTPS, and interstitials. “Safe browsing” used to be among them, but has since been removed.
It is this effect on Page Experience that, arguably, fueled many concerns. That is, either adding another metric or replacing one would immediately domino into Page Experience and, in turn, SEO.
The new Core Web Vitals metric Google is creating is replacing FID
With all this in mind, the new Core Web Vitals metric Google is creating is set to replace FID specifically. Initial speculation included a simple addition instead of a replacement, but Google had already been considering replacing FID since June.
To better grasp the reasons behind this and inform our predictions on this new metric, we may take a closer look at Google’s own reasoning behind this over time.
Why FID was chosen over the alternatives
Google explains why FID was chosen as part of Core Web Vitals in similar terms to ours. Put simply, FID was the closest approximation to the actual user experience, while the other adjacent Web Vitals were not. Specifically, they say:
“We believe it is important to measure actual user experience in order to ensure that improvements on the metric result in real benefits to the user. We chose to measure FID because it represents the part of the user experience when the user decides to interact with a site that has just been loaded.” That is not to say the others could not inform website improvements, only that FID was seemingly the best for the job.
What FID lacks
However, FID proved to be lacking in this department. It did measure perceived loading speed, but it faced two distinct challenges:
- Its scope was too limited, and
- Most Content Management Systems (CMSs) already yielded near-perfect FID scores.
WeAreUV and SearchEngineJournal, among others, cite an HTTP Archive Almanac writer who explains the latter:
“FID is very good for most CMSs on desktop, with all platforms scoring a perfect 100%. Most CMSs also deliver a good mobile FID of over 90%, except Bitrix and Joomla with only 83% and 85% of origins having a good FID.”
This, WeAreUV correctly argues, presented a crucial issue. Namely, that this state of affairs made FID largely meaningless:
“It has become a competition where everybody wins and thus nobody wins and nobody gets credit for sharing the gold medal. […]If 99% of content management systems are awarded top scores, what separates them? What is the use of a metric that cannot distinguish anything?”
It is this combination, then, that likely led Google to replace FID with a new metric “that extends what FID measures today yet still retains its strong connection to user experience”. It could neither fully reflect the user’s experience, nor distinguish good pages from bad ones. It evaluated a metric that everyone could ace, in turn measuring nothing of significant substance.
So what is this new metric?
All that said, we cannot fully know what this new Core Web Vitals metric Google is creating will be. We do know they intend to replace FID with it, however. We also now know what they intend to achieve, via their above article, and may extrapolate meaningful conclusions that way.
Their explicit goals with this new metric are the following:
- “Consider the responsiveness of all user inputs (not just the first one).”
- “Capture each event’s full duration (not just the delay).”
- “Group events together that occur as part of the same logical user interaction and define that interaction’s latency as the max duration of all its events.”
- “Create an aggregate score for all interactions that occur on a page, throughout its full lifecycle.”
This narrower scope of FID seems to be the primary drive behind this new metric. It only measured input delay specifically, not “broader end-to-end latency of an event”. As such, it could not accurately capture the exact perceived loading speed, as it failed to account for the “various stages in the lifecycle of an event”:
As such, we may reasonably expect a more holistic speed and responsiveness metric. It should still be one that measures input delay, but it should seek to do so more expansively.
The progress of the new Core Web Vitals metric Google is creating
Thankfully, Google has remained notably transparent about this new metric’s progress. In November, they published an article that outlines said progress and the alternative approaches they’re considering.
We may consolidate the information within it down to the two distinct fronts that follow.
#1 Measuring interaction latency
On this front, Google has pinpointed two approaches; maximum event duration and total event duration. The former will gauge the maximum duration within a group of events, while the latter will sum up all event durations.
#2 Aggregating all interactions per page
Next, Google is considering the following strategies to aggregate interactions and delay therein:
- Worst interaction latency; measuring the single largest latency that occurred on a page after any type of input.
- Budgets strategies; citing research that highlights user perceptions, FID’s primary goal, Google is also considering delay thresholds. This, they argue, may help filter out insignificant delays that users will not perceive as negative./li>
- Measurements over budget; should budgets be established, Google is then considering alternative methods of delay measurement. These are worst interaction latency, total interaction latency, and average interaction latency – all over budget./li>
- High quantile approximation; then, as an alternative to largest interaction latency over budget, Google is considering this method which “should be fairer to web pages that have a lot of interactions and may be more likely to have large outliers”. Here, too, they are considering two alternatives, both based on latencies over budget./li>
Evidently, lots of careful deliberation has gone into this new metric. While it is still being calibrated, it seems to be explicitly addressing FID’s shortcomings and building on its strengths.
Google is looking for your feedback
Finally, Google is actively looking for webmasters’ feedback on this developing metric and their current alternatives – including through Twitter. Should you be interested, they offer the option to do so in their above article as well, with very simple instructions:
“We want to encourage developers to try out these new responsiveness metrics on their sites, and let us know if you discover any issue.
Please also email any general feedback on the approaches outlined here to the web-vitals-feedback Google group with “[Responsiveness Metrics]” in the subject line.”
In summary, the new Core Web Vitals metric Google is creating did come at a rather challenging time, as SEOs were still adjusting to the recent rollout’s changes. Still, all the available information, including Google’s explicit goals and progress reports, establishes it as a replacement for FID. It should thus continue in the direction of the current Core Web Vitals, while expanding on FID’s intended purpose. It may be too early to gauge the impact it will likely have across SEO and web development alike. But, thankfully, we know that it will specifically spearhead responsiveness and speed – the qualities webmasters already strive for.