LCP poor due to cookies banner acceptance policy

144 views
Skip to first unread message

Armando Ruiz

unread,
Feb 9, 2024, 5:56:34 AMFeb 9
to web-vitals-feedback
We are registering a very poor LCP inmobiles due to our cookie management interface.
 
This interface is mandatory to be shown to users and is displayed after the page has finished loading. 
This, despite having asked for recommendations to our cookie consent manager provider, who suggested us to move their script to the top of the head and even to add some prefetch scripts of their DNS to speed up its loading.

But the problem is that Search Console always makes its measurements as if it were a user on their first visit. This way, the cookie acceptance interface will always be shown and this always happens by the end of the page load, slowing down our LCP.


Barry Pollard

unread,
Feb 9, 2024, 6:01:15 AMFeb 9
to Armando Ruiz, web-vitals-feedback
The data in Search Console is based on real user measurement in CrUX so I disagree it will always be based on their first visit.

You can refer to this article for best practices for cookie notices:

--
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/b540d4c0-cd7d-4db6-88b0-08d1c9bd13abn%40googlegroups.com.

Armando Ruiz

unread,
Feb 9, 2024, 7:55:43 AMFeb 9
to web-vitals-feedback
Hi, Barry. Thx for your soon reply.

The way our cookies consent interface works is:
- the interface occupies the whole window in order to make sure the user can´t navegate in our web until he/she takes a decission by clicking one of only three buttons accesible for accepts/discards/costumizes the cookies
- after the user takes one of this possible actions, the interfaze doesn´t show covering the window in further visits, but only a button is appears at the bottom of the screen to make accesible the interface if the user wants to change cookies settings
Search Console always measures LCP with the interface covering the window, as if it were the first time visiting our web (as it does not click anywhere, everytime it meassures)

Barry Pollard

unread,
Feb 9, 2024, 7:56:46 AMFeb 9
to Armando Ruiz, web-vitals-feedback
How do you know what Search Console measures?

Armando Ruiz

unread,
Feb 9, 2024, 8:05:54 AMFeb 9
to web-vitals-feedback
Sorry!! I got confused. I intended to say Page Speed Insights.

It can be seen in the images of progression of charge it offers and it always shows the cookies interface.

Aymen Loukil

unread,
Feb 9, 2024, 8:07:53 AMFeb 9
to Armando Ruiz, web-vitals-feedback
PagespeedInsights offers 2 type of data:

- Real users data coming from CrUX
- Synthetic data coming from an on-demand run of Google Lighthouse. 

What you see in Lighthouse result isn't what is reported in Search Console.

Aymen,

Barry Pollard

unread,
Feb 9, 2024, 8:31:02 AMFeb 9
to Aymen Loukil, Armando Ruiz, web-vitals-feedback
Exactly, the bottom part of PageSpeed Insights is a simple cold page load of your site and so it will assume it's the first visit. It is intended as an auditing tool to suggest improvements to your website. As it is unable to know all the different cookies or interactions your site can set and do, it does a simple page load. As a result it may or may not be reflective of your real users page experience depending how many of them are effectively new visitors, and if they have similar devices and speeds as the PSI Lighthouse test. But the test does surface some suggestions and best practices which, if followed, will in many cases result in improved performance for all visitors.

The CrUX data (at the top of the PSI, and in GSC) is based on real users.

But it may well be enough of your visitors are effectively first time visitors and are getting a slow LCP because of your cookie consent banner. If you have enough repeat visitors to offset the slow LCP of your first time visitors then that will be reflected in the aggregate CrUX data, but similarly (and perhaps more likely) if you do not,  then that will also be reflected in the aggregate CrUX data.

It seems LCP is measuring that load time accurately here and the cookie banner is shown late. This is a common problem for cookie consent widgets. But it does reflect the user experience - they did not see the "main content" until it loaded later (and further they didn't see what they actually came to the site to see, until they interacted with that cookie banner).

If you want to improve your LCP in these cases, you have a number of choices:
  • Optimise the cookie consent banner as much as possible. The advice the cookie consent provider has given sounds like good initial advice to help with that, but it may not be sufficient.
  • Look at alternatives that do have as much of a performance impact (including self-hosted options that can be faster - though there are often good reasons for using third-parties here).
  • Do not occupy the whole window forcing the user to choose, so this late-loading cookie banner is not the LCP element. I'm not a lawyer so don't want to get into this too much, but forcing the user to deal with the cookie consent banner is a choice. As far as I understand it, you could have the user be able to see (and even use!) the site without the requirement of consent (and obviously not use cookies or anything that would require that consent until they have consented), and have a smaller cookie banner that is not the LCP element, and then load further functionality (or not) after they have made that choice.
Either way it sounds like the metric is measuring this accurately. So, while we appreciate that there are legal requirements to be had, and business choices to be made in how those legal requirements are met and whether to block access until a choice is made, and also appreciate the problems that optimising third-party resources like consent managers is complex, that does not alter the fact that LCP is supposed to measure how the user experienced the site and appears to do that here.

So, other than offering that "cookie notices best practice" guidance which I linked to, I'm not sure what further action there is here.

But happy to answer any other questions or take on suggestions on how this should be dealt with.

Thanks,
Barry

Armando Ruiz

unread,
Feb 9, 2024, 8:51:07 AMFeb 9
to web-vitals-feedback
Thanks a lot for your —almost— essay. It does help.
Reply all
Reply to author
Forward
0 new messages