COOKiES increases LCP a lot (Google pagespeed)

We're currently using defer in libraries.yml.
According to https://dev.to/fidalmathew/async-vs-defer-in-javascript-which-is-better-...

I think we should use async instead? Do we need to wait for the DOM?

But anyway it seems it has no effect on the LCP value, maybe because LCP is not only loading order, but also UI changes timing?

Cookiebot also uses async for example: https://www.cookiebot.com/de/manuelle-implementierung/

But anyway it seems it has no effect on the LCP value, maybe because LCP is not only loading order, but also UI changes timing?

So that might just be part of the solution...

FYI: It's mainly because of the long text in our case. Let's set this minor for further investigations, but I currently don't think COOKiES is the root cause.

We found out, that async breaks the COOKiES UI display.

Let us try a shorter text for the banner.

"Please agree to the use of cookies on this website, which serve to collect personal data and pass it on to third-party service partners. You can revoke your consent at any time under "Cookie settings"."

I also created a new issue for the Svelte library to reduce the banner size.
https://github.com/jfeltkamp/cookiesjsr/issues/38

This will also help to let the banner not be the largest content element.

For Drupal libraries async and defer are almost meaningless, because - unless you are setting header: true - Drupal libraries are at the end of the page anyways. Async can be even dangerous, because it would crash with Drupal's built in weighting / ordering of dependencies. Especially for Cookies, which is designed to be a dependency of other modules, I'd explicitly advise against async: This could break Drupal JS behaviors, and devs could no longer relyably use the well-known once('my_behavior', '.my_selector').doStuff() pattern.

Generally I think this is topic a misunderstanding of (or maybe a general flaw in) Lighthouse. If you enable a Cookie Banner, then by design AND intention you'll have a late large contentful paint. If a site owner doesn't want the "paywall" style of the Cookie Banner, the admin has the option to show the banner after page scroll. This works well in 1.x on all our sites for LCP. In 1.x our problem was mostly FID (which was now replaced by INP, and where I have high hopes thanks to the Svelte rewrite. Really excited to try v2.x, thanks for all your work!).

Other similar tools simply use a small floating icon, which avoids the Lighthouse message by basically removing the largest from the contentful paint problem. (I personally find those even more annoying and distracting, especially on small screens. A banner at least is gone after declining.)

Maybe changing the default `lib_scroll_limit` config setting to 1 pixel would be a sensible default for most users?

Thanks @hudri. Yes these are separate topics. Using defer is generally fine for this lib, while it won't have large effects. Async would indeed be wrong.

I also dislike the LCP idea in Lighthouse and had similar thoughts.

Maybe changing the default lib_scroll_limit config setting to 1 pixel would be a sensible default for most users?

Yes I agree that might fix the LCP issue, not a bad idea! :) Any negative side effects? Cookies (non-required) are still blocked until the user scrolls and accepts them?

Anyway improving the default text is also a good idea.

Have not noticed any negative side effects. Cookies are of course still blocked until accepted.

From a user journey perspective I also like this behavior more than the instant banner: don't instantly nag the user, ask for permission after the user really interacts with the site.

There might be an odd edge case though: On a very small site without basically any content, paired with a very large screen, there might be no scroll bar, so the scroll event can not even be triggered and the banner will never be shown. But IMHO this is not a real world problem, improving the LCP for all users simply outweights this edge case. (And if necessary it can be easily fixed inside the admin UI.)