top of page
  • Writer's pictureMordy Oberstein

The Benefits of & Problems with Core Web Vitals

A Developer's Perspective on Core Web Vitals: A Conversation with Dan Shappir

The SEO Rant Podcast Banner: Dan Shappir & Mordy Oberstein

Wix's own Performance Tech Lead, Dan Shappir, joins the podcast to share his take on Core Web Vitals from a developer's perspective:

  • The Value of Core Web Vitals

  • Collaborating with Google on Core Web Vitals

  • The shortcomings of Core Web Vitals

Go deep into Core Web Vitals from the perspective of a world-class developer who sits on the Chrome Advisory Board. We jump into a bit of what goes on behind the scenes when working with Google to improve Core Web Vitals as well as what benefits and problems Core Web Vitals bring to the web and to SEO.


Are Core Web Vitals a Good Thing?

Core Web Vitals are a good thing. Core Web Vitals provide a standardized way to measure a page's performance. Moreover, Google is doing so with a relatively small number of metrics. This makes it easier for SEOs and developers to hone in on specific ways to improve a page's performance.

Very often, we go from a situation of having no metrics to provide structure to having too many. When that happens the vitality of these metrics becomes diluted. However, with Core Web Vitals you have only three metrics to focus on.

Moreover, Core Web Vitals was actually based on real user interactions. Google loaded pages for users and asked their test subjects to press a button once they thought the page loaded. It turns out users thought the page loaded when the largest element was finished... this is how LCP came to be one of the vitals.

This is just an example of Core Web Vitals being very much aligned to real expectations and real user behavior. The relationship of Core Web Vitals to actual user behavior only makes them more substantial and beneficial.

On Developer's Working with Google on Core Web Vitals

Dan, as a developer for Wix, has had many conversations with Google about Core Web Vitals. Google has been very transparent with developers about Core Web Vitals and has been quite open to taking feedback and making improvements.

For example, Google is reevaluating CLS and looking at ways to improve it as developers have voiced some complaints.

As with anything new, Google has partnered up with the industry and is taking formal feedback from developers. Core Web Vitals is a relatively new construct and it will take time for Google to deal with all of the challenges presented by the new metrics. The important thing is that Google is very eager to improve the metrics.

What Problems Are There With Core Web Vitals?

One major problem with Core Web Vitals is that there are only three of them (though, as mentioned, there is a benefit to that). For a more holistic picture of performance, Google will need to consider other metrics. There are talks for Google to include a fourth metric, FCP (First Contentful Paint) sometime in the future.

Google has said that each year they will evaluate the state of the web in the context of Core Web Vitals in order to see if adjustments need to be made, if new metrics should be added, or if current metrics should be deprecated.

There are, however, real issues with Core Web Vitals. For example, Core Web Vitals does not always jive with single-page applications. Specifically, there are issues with single-page applications and CLS. CLS, as it says, is cumulative. Since there is no separate server request with these kinds of sites, as the user moves from page to page CLS will continue to be assessed all the way through.

Even FID has potential issues. It turns out that FID performance across the web is good. In fact it's a bit too good. Suspiciously so. One reason for this is interaction serviced by JavaScript. So say you have a button supported by JavaScript (JS). If you click the button after the JS has loaded, you'll get a good FID score. If you click while the button is still loading, you'll get a poor FID score. This should incentivize you to create less code bloat so everything loads faster. However, let's say you click the button really quickly before the JS even finished downloading... you'll get a great FID score! Now, of course, the button did nothing and the user got nothing, but you would get a great FID score.

Things like this bring up all sorts of questionable practices. In our case here, why not hide the button until it the JavaScript finished loading? This is really the problem with metrics. They can encourage 'hacks' to manipulate the system. However, that's not unique to Core Web Vitals.

Even with LCP, there are some problems with the way Google calculates the metric. For example, Google discounts images that take up the entire viewport for LCP. Google considers this a background image and not related to the goals of LCP from a user behavior perspective. But let's say you have a small menu that pushes the image down just a bit? Now the image, though a background, does not occupy the entire viewport and counts as your LCP!

The Real Impact of Core Web Vitals

Performance, when you get down to it, is really about bounce rate. More than anything it's important to have a page that loads quickly so users don't do things like abandoning their carts on your site.

With Core Web Vitals, performance becomes a bigger part of the SEO equation. This gives Google buy-in to create a faster web. Now, a new "market" (i.e., SEOs) are pushing the performance of sites to a greater degree. This, from a strategic point of view, makes a lot of sense. It makes sense for Google to create a dynamic where SEOs are pushing for better performance.

But still, at the end of the day, and despite the increased relevance on rank, performance is a conversion-oriented problem first and foremost.


bottom of page