FID en INP

[Andreas van Beek]

Dear team just some concerns from this site, i already know for a long time the change from FID to INP, my coire vitals are always oke, but with the new metric i can see that i just score over 200 ms in INP its 219. I have tried all things to reduce photos etc, i even called my webhoster and they say probably it has no negative effect. I am not so sure. What can i do to reduce further because all the items belong to the webhoster (The big data) I am a small business can not effort loosing my position because of the new metrics. Bit worry here. My website https://www.houseofcrete.nl

thankx in advance

--

Andreas van Beek
CEO House of Crete

 

tel: 0639856800
tel: 0617399856

mail:    in...@houseofcrete.nl

website: www.houseofcrete.nl

website  http://www.houseofcrete.nl

[Gilberto Cocchi]

Hi Andreas, thanks for your feedback.

I suggest you look at your CMP UI implementation, you may find some of the guidance explained here useful to optimize this user flow.

By yielding on the CMP UI Button Click Event Handlers you will make your CMP UI more responsive and reduce the negative impact on INP by those interactions. 

--
You received this message because you are subscribed to the Google Groups "web-vitals-feedback" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web-vitals-feed...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/ccb211e7b57e9f870edda79ca8b04ec0%40houseofcrete.nl.

--

gTech Up

Gilberto Cocchi Web Ecosystem Consultant gilb...@google.com +39 02 3661 8337

Google Italy | Via Federico Confalonieri 4 | Porta Nuova Isola | Building C | Milan 20124

Registered in Milan, Italy

This email may be confidential and privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

The above terms reflect a potential business arrangement, are provided solely as a basis for further discussion, and are not intended to be and do not constitute a legally binding obligation. No legally binding obligations will be created, implied, or inferred until an agreement in final form is executed in writing by all parties involved.

[Inspired Taste]

It has been a full year since I first posted about Google failing their own INP metric. Now we are failing INP and Google still is. We average 230ms and the main culprit is still Google GPT.js causing latency in the ad pipeline. The only way we can pass is to completely defer ad loading for multiple seconds which is absurdly unsustainable. Google.com is also still failing. (See screenshot) I pointed this out to Danny Sullivan and John Mueller on X. They both publicly responded that Google needs to do better. Google updated the docs to say that it is a ranking signal, system or factor. I am still confused. The bottom line is the fact that there is a warning for a ridiculous threshold which Google can’t even pass. Google should be extremely embarrassed about how INP is being handled. The threshold is unfair to place onto publishers and even Google themselves. 

[Barry Pollard]

I understand your frustration with this but spamming multiple old issues with this is NOT acceptable. If this is done again this account will be blocked from this group.

A large number of sites (68% on mobile, 98% on desktop) do pass INP and we believe it is a tough, but achievable metric. The thresholds, like all Core Web Vitals thresholds, were chosen based on a combination of UX research and achievability. No exception was made for Google sites. Site that fail (including our own) are indicative of sites that could be improved.

Thanks,

Barry

[Inspired Taste]

I apologize for the multiple threads. It was not intended to be spammy at all. Each one was on topic and had recent discussions. I went ahead and deleted one of them. We are just extremely frustrated to wake up one morning with tons of warnings and Google is still failing, it seems very unfair to independent publishers who are working extremely hard. We extensively tested to pass INP for over a year now and we boiled the problem down to Google’s GAM ad code. That is the worst part. We can’t fix it. Then to find out that CWV’s is still in the documentation as a ranking signal, as publishers we are very concerned with how Google is handling this. 

Again I apologize for multiple threads. As mentioned, I went ahead and deleted one. I want to work with Google to work on things but it is increasingly difficult to be heard and publishers keep getting in trouble for things out of our control. 

Please pass this frustration on to your team. 

[Matheus Dal'Pizzol]

Well, as I was expecting, all of our thousands of pages are now on the yellow range at PageSpeed Insights and there's some points I'd like to address.

Barry, when you say that "A large number of sites (68% on mobile, 98% on desktop) do pass INP". Are theses pages loading Google related scripts like GPT?

I spent a year and I got our sites do a 100 score following the recommendations at web.dev. But the moment we drop GPT in, not only it destroys TBT, but because it blocks everything, it also brings LCP to the red range.
On top of that, I went on to investigate our competitor's websites and the only one passing INP was one that didn't used GPT nor Adsense as it's advertisement solution.

After the update, we got 99 on desktop, but on mobile it rarely hits 60 and the worst part is this: Despite NONE of our metrics being in the red range, the Core Web Vitals Assessment: Failed

In this case, it's not just about frustration, but it indicates that Google may not distribute our pages anymore.

I understand that Google may see it's own sites which doesn't pass the metrics as an opportunity for improvement, but in our case we CANOT afford to be ranked out until it releases some solution for GPT and it seems that there's nothing we can do to avoid this, despite having already done everything that was asked for.

[Erwin Hofman]

Just to show that it can be done with GPT & AdSense (and even top of client side rendering/hydration), these sites started focussing on INP (in order to pass before the INP date):

https://www.rumvision.com/tools/core-web-vitals-history/charlieintel.com/?path=/

https://www.rumvision.com/tools/core-web-vitals-history/www.dexerto.com/origin/mobile/?path=/

Not yet on all pages, but that just illustrates that gain can be found + addressed across different parts of the (1st & 3rd party) puzzle.

Additionally, both cases have a very healthy LCP. 

If you're seeing a sub-par LCP across your pages, it might either be something else that is impacting LCP or unfortunate prioritization of when files are executed.

---

From: web-vital...@googlegroups.com <web-vital...@googlegroups.com> on behalf of Matheus Dal'Pizzol <matheusd...@gmail.com>
Sent: Thursday, March 14, 2024 11:55:20 PM
To: web-vitals-feedback <web-vital...@googlegroups.com>
Subject: Re: [web-vitals-feedback] FID en INP

 

To view this discussion on the web visit https://groups.google.com/d/msgid/web-vitals-feedback/ee3f442c-a6d7-432b-bb03-771eb08b4f90n%40googlegroups.com.

[Inspired Taste]

In the spirit of working together here is more info from our dev team. We ran countless tests. The only way we could pass 100% of the time was to completely defer ad loading until the DOM was complete including GAM (gpt.js) for 3-4 seconds. No ad code fired for 3-4 seconds. Our site code outside of ads is extremely lean so our INP plummeted but our revenue dropped by 15-25%, sometimes more. Similar to when we experimented with AMP for a while. This wasn't sustainable so tried reducing the number of ads on our site. We could pass intermittently if we reduced to 1-2 ads with some preliminary ad code loading. Partial DOM deferring. This dropped our revenue down by 75% or more. This issue is ads and it must be the same for Google.com. 

[Inspired Taste]

This conclusion is exactly the same as us. After extensive testing, GPT was determined to be the root of our problems. It skyrockets our TBT and causes our INP to build up. We can’t fix Google’s ad code yet we and countless other publishers are now considered failing. We notifed our Google ad partner more than a year ago and they have maxed out their ad stack speed performance. GPT is the problem. We pass on desktop which is easy but most traffic these days is mobile. 68% of websites passing INP means roughly 1 out of 3 websites can’t pass. That is a lot of the internet and Google is included in the failing side. 

Again, sorry for multiple reply’s on different posts. Sometimes it feels like the independent publisher is being squeezed out and it is impossible to be heard. 

Has the Google ad team been notified to see if there is anything they could do? 

[Barry Pollard]

The feedback has been heard, and we will feed it back to the Google Ad team. We try our best to contact many teams (both inside and outside of Google) for when we spot them as having a large impact on the results of Core Web Vitals, including the ad teams. That does not always mean we can get the result back as soon as we'd like of course. Google, like many companies both large and small, is not a single entity but made up of many teams with many different priorities. I personally would love them to make web performance a much high priority of course! I suggest you continue to raise this issue with your Google ad partner to push this as well.

Also it's easy to blame a single script like GPT.js and suggest that should be fixed. However, it is the entry point for the ads themselves so any improvements to that will only have so much impact if it's the ads that are intensive. I am not an expert on the ad tech, but from a performance perspective, ads do a colossal amount of work (I'm constantly amazed that they work at all! And as fast as they do, given how much effort it is!) and it's therefore unsurprising that sites using them are flagging for this new responsive metric. But that reflects reality - ads are the often the cause of performance issues.

Our hope with this new metric is that it surfaces these issues more, and leads to improvements - from site owners considering how best to load these, to ad providers themselves (very much including Google btw!), to the Chrome browser. We have already seen this in lots of other cases, and I fully expect the ad industry to also see improvements over time.

The Core Web Vitals initiative does not differentiate by technology and does not give different thresholds to site using ads. So yes that 68% stat was for all sites. As I say, sites with ads may struggle with this metric more, but that is an accurate reflection that those sites struggle with performance more. "Needs improvement" is an accurate reflection of the reality when this is the case whether you agree with this or not.

And 68% of websites passing a metric is a good threshold to drive change. If it's 95%+ (like it was with FID) then issues will not be surfaced and so not be addressed (like we saw that this issue was ignored while FID was the responsive metric). We carefully choose the thresholds based on a balance of good UX and achievability as detailed here (note this post has not been updated for INP yet but the principals are the same).

But I fear we seem to be going round in circles, and I cannot give you the answers you want here. So unless there is any new information I will bow out of this conversation. Again, thank you for your feedback and we'll d our best to push this as much as we can with the appropriate teams.

Finally I will say that this feedback forum cannot comment on any Search Ranking impact so you will need to raise that with the Search team.

[Inspired Taste]

Hi Barry,

I really appreciate the thoughtful response here. I think you hit the nail on the head. The logic does go in a circle which is why publishers are so frustrated. 

We 100% have control of our site coding but not ad code which causes most INP so why do we get in trouble for ad tech which GAM (Google) is doing in our case. Then a failing INP feeds which negatively affects our sites ranking. This is unfair. 

Google.com can fail and be an example that we all need to fix it but their rankings won’t be affected. From a publishers point of view that is hypocracy and cruel & unusual punishment. Google.com has infinite resources and creates the rules. Meanwhile independent publishers like us have tons of work to do and are now getting in trouble for something 90% out of our control. Ad companies should be getting blamed here and GAM is serving our ads. It is a frustrating loop which is why it is so infuriating from our perspective. 

Give your position in Google it would mean a tremendous amount if you reached out to your ad team to let them know of these situations so we can work together. 

I appreciate your openness and being willing to discuss it . That will be the key for us figuring out how to fix it. 

[Matheus Dal'Pizzol]

Hey, Erwin... I was diving into charlieintel's source, and I noticed that it doesn't load the the following scripts directly.

• https://securepubads.g.doubleclick.net/tag/js/gpt.js
• https://www.googletagmanager.com/gtag/js

I also noticed that it's loading Google Tag Manager through an iframe inside a noscript tag.

Could you give us some guidance on that? For me it's very clear that the results the site is getting is related with that.

[Matheus Dal'Pizzol]

Another thing I'd like to mention is that each of our pages have it's own AMP version, and INP isn't passing even on those AMP pages.
On our own code we're already using ad lazy loading as described in the GPT docs.
So... I'm not sure what else can we do, since we already implemented every best practice documented by Google on our code and we simply can't change code from AMP.

[Erwin Hofman]

Hi Matheus,

I don't think it's related, but to answer your questions:

• GPT is loaded via a prebid file, served from a cloudfront domain owned by Aditude.com (is what the source code of that prebid JS file is saying)
• GTM is loaded via the site's own Nuxt app.js

I assume you tried searching for their GTM in the source code itself, and then ran into the <noscript> in the HTML.
However, that's just Google's recommended GTM 'fallback' for when JS is turned off by a visitor. Which means no JS will be running in the first place. 

I found/confirmed the above two bullet points just by opening DevTools network panel, search the two files and check the initiator tab/panel per file.

Op dinsdag 19 maart 2024 om 20:00:11 UTC+1 schreef matheusd...@gmail.com:

[Erwin Hofman]

Hi Matheus,

Your last message came in between writing and posting my last message.

As I'm assuming this group really is for web-vitals (heuristics) related feedback instead of per site troubleshooting, and your indication of having implemented every best practice, your best next step is to start collecting data in the field.

The new LoAF API that Google has been working on (and already shipped to Google Chrome) might turn out to be very convenient, and might even show you different INP offenders than you would expect (as I often notice when it comes to LCP and site owners thinking that there will only be one LCP candidate per template, while in reality it will be quite different due to all real life conditions and scenario's).

The real INP offenders (instead of blindly focussing on all long tasks) is likely to answer the question where to really start improving within the current setup.

In other words, it's best to start collecting real user data and combining it with LoAF insights. You could either go with:

• 'Do It Yourselves' by combining Google's official web-vitals library with the LoAF API and hooking it into GA4 to then be able to query it yourselves
• using an existing RUM SaaS/product that:
  • did the work/these steps for you (but then independent from GA4)
  • comes with LoAF data 
  • and comes with a friendly user interface to easily digest insights

Op dinsdag 19 maart 2024 om 22:23:11 UTC+1 schreef Erwin Hofman:

[Matheus Dal'Pizzol]

It's really hard for us to see another candidate than the GPT tag, because:

1. When not using Analytics and GPT, we get 99, 100 scores, with TBTs as low as 70ms on simulated slow CPU and networking.
2. In our case, Analytics is running in a separate thread, via Partytown, not blocking the main thread
3. The only thing left is GPT, leaving us with TBTs as high as 4000ms but sometimes reaching 15000ms.

I'm looking into implementing RUM via the LoAF API, just to make sure it's not anything else causing the problem.
I can do this in our code, but I have no idea on how to collect the data from AMP pages without hiring a paid solution.

[altankrk]

Hello everyone,

When it comes to Mobile Interaction to Next Paint (INP), it's crucial to maintain a smooth user experience. To achieve this, i recommend aiming for a threshold of 300 ms on mobile devices. Considering the typically slower network speeds on mobile devices, this allows sufficient time for interactions to be processed before the next paint event.

On desktops, where network speeds are generally faster, we suggest a slightly lower threshold of 200 ms. It's essential to strike a fair balance between performance optimization and user experience across different platforms.

i understand that optimizing INP can be challenging, and not everyone may have the expertise to tackle it. However, prioritizing these optimizations is vital for enhancing overall website performance and ensuring a positive user experience.

Thank you for your attention to this matter.

[Omri Ariav]

Hi -

We're using the LoAF API a lot here in Taboola - we have lab-tool we released in an open source: https://github.com/taboola/LoAF-Finder 

You can also see a case study we had with web.dev that shows LoAF API RUM usage - https://web.dev/case-studies/taboola-inp 

I am working with the team to also publish our RUM LoAF code, and then either have ppl add the GA4 reporting or use any other custom data collection platform to represent and aggregate the data. 

I hope it helps

Omri.