Core Web Vitals: Will Google Give Breaks for Slow Plugins and Apps?

Google’s Martin Splitt answered a question about what to do about third party must-have functionalities in the form of apps and plugins and whether Google would give publishers a Core Web Vitals break since those apps were made by a third party.

Loren Baker asked a question that discussed the issue of publishers who need marketing and sales related functionalities on their sites that tend to slow down the web page and contribute to poor core web vitals scoring.

The example used was of a Shopify site incorporating email list, review and chatbox functionalities contributing to exceedingly bad core web vitals performance.

But the question applied equally to all third party apps, themes and plugins, regardless of platform, including WordPress.

This is an important question because the problem with publishers being judged on Core Web Vitals performance is that the performance issues do not generally rise through the fault of the publishers.

The fault for the poor performance lies with the makers of the apps, themes, and plugins.

So it feels like it’s not fair for Google to give a low score to a site for using a third party plugin or app that delivers a necessary functionality that users or the publishers need.

Loren Baker asked:

“Is the Core Web Vitals Update going to give people a break, so to speak, if they’re using a third party app which is leading to their site having lower scores than if they would if they had no apps on the page?”

Why Good Core Web Vitals Scores Should be the Focus

Martin Splitt answered by first focusing on Google’s goals for Core Web Vitals, trying to get the publisher to look at it from t that perspective.


“I understand where they’re coming from. The answer for all of these questions is pretty much the same.

Think about what are we trying to do with the page experience signal.

What we are trying to do there is we try to quantify what makes the user have a good experience with a page.

And it doesn’t matter what tools are being used, what libraries, frameworks are being used, if there’s JavaScript on the site, if there’s no JavaScript on the site, if there’s apps on the site, if there’s all first party on the site, if it’s using Google analytics or Google Ads or Google Tag Manager- none of that matters.

If it slows down the page, it’s detrimental to the experience of the user. It doesn’t matter where the reason is coming from if it’s… like bad first party code or bad third party code, everything is possible to do with less impact on the core web vitals than it is probably done right now out of not being like aware of that being a problem or a lack of care or other technical reasons that need to be addressed at some point. As developers we’d like to speak of that as technical depth.

So if they make things slower, that reflects in the core web vitals and that’s what matters in the end.”

Which User Experience Matters Most?

Martin acknowledged that many of the functionalities that slow down a site also improve user experience by doing things like helping them accomplish their goals, like contacting the business through chat.

Martin Splitt explained:

“Sure, I’m seeing comments saying like these apps might actually make the experience better for users, but do they?

Because if it’s like oh yeah this app gives us a chat experience, yes. But a chat can be implemented in a way that does not make the page slower for everyone who does not interact with the chat or even those who want to interact with the chat.”

Martin is referring to the fact that there are ways to minimize the impact of chatbox JavaScript and CSS files by adding element attributes that allows the code to not interfere in the rendering.

For every thing that negatively impacts core web vitals score there is a solution, even for third party advertising code.

The problem that isn’t addressed is that those solutions tend to be outside the scope of many web publishers.

Martin continued:

“It’s not a measure of should we have a chat on our page, yes or no. Yes, if it makes the experience for the user, have a chat.
Just don’t build it in a way that it actually makes the page worse. And that’s the thing.”

In a way, Martin is missing a point about functionalities. Most publishers and ecommerce companies do not have have their own in-house programmers building chat boxes.

Publishers are at the mercy of the content management ecosystem.

Core Web Vitals Aren’t Perfect

Martin next admitted that the core web vitals metrics aren’t the best but pragmatically insisted that it’s the best we have for now.

Martin explained:

“And we can argue about if the core web vitals are …really completely modeling that. I would say they don’t. But it’s the best approximation that we have right now.

And actually measuring performance and measuring experience for users is really, really hard. And we will see an evolving set of metrics as part of the core web vitals evolving over time.”

Give Users a Good Page Experience

Martin next encouraged publishers to focus on the page experience.

Martin Splitt on giving a good user experience:

“But …generally speaking the idea is to give pages that are giving a good experience to users a boost.

And I don’t think a good experience is if I am reading something about the article I’m going to potentially going to buy and then whatever I’m reading is shifted down because there’s some review stars popping in on the top.

Does that mean you shouldn’t have review stars? No.

Have review stars but make space for them so that when they pop in nothing else moves on the page.”

Good Web Vitals Scores Are Possible

It can seem overwhelming to solve core web vitals issues but Martin encourages publishers to keep trying by stating that it’s not an impossible problem to solve. He said that good scores can be within reach.

Martin Splitt:

“It’s not that it’s impossible to do this. I get this question a lot with cookie consent banners. So, is a cookie consent banner that I have to have for legal reasons, is that going to drag down my CLS?

Probably yes if it’s implemented in a way that is disruptive to the user it might actually cause cumulative layout shift.

If it’s only causing a little bit of it, that’s not even a problem. We’re not saying zero is what you need to target.

You’re needing to target something that is reasonable, which I think is 0.1, which is the percentage of the effective viewport and the amount of shifting that happens.

So there is a certain amount of shifting that can happen without basically falling under the threshold of what core web vitals consider a good experience.

But if you implement it, let’s call it lazily and just go yeah it’s going to be fine, yes it’s going to move everything below once it pops in then that’s not a great way of implementing it and you might want to reconsider the way that you implement it.”

Ask APP/Plugin Developers to Improve their Products

Martin Splitt now offers useful information about must-use apps that deliver a poor user experience.

Martin said:

“If you’re not implementing it because it’s coming from a third party, let them know, tell them, Hey by the way we noticed that your solution does this. We really like your solution but we really don’t like how it kind of treats our users. So would you consider fixing that?

And there are ways of doing it, it just needs to be done.”

Screenshot of Loren Baker Interviewing Google’s Martin Splitt

Screenshot of Loren Baker interviewing Martin Splitt about Core Web Vitals for

Three Core Web Vitals Insights

Martin shared a lot and perhaps a general way to characterize them is with three points.

The three points below isn’t all you need to know. Martin shared a lot of details.

These are three points that summarize what he said:

  1. Review whether an app or functionality is truly needed and if it does provide a must-need user experience. If it’s somewhat superfluous, consider getting rid of it.
  2. Implement site functionality in a way that doesn’t interfere with page rendering. This may mean editing the code to add additional element attributes (like the lazy load image attribute or link rel=”preload”). Until template and plugin makers get on the ball about this it’s unfortunately in the site publisher’s lane to fix it, whether they like it or not.
  3. Contact the app, plugin and theme developers and ask them to create better implementations.


Watch the SEJ interview with Martin Splitt, starting at the 8:00 minute mark: