COOKiES increases LCP (Google pagespeed)

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 updated the MR. Please check.

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!).

I see other similar tools using 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?

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/short page 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.)

Fixed scroll limit behavior.

The scroll limit was handled from the preloader to avoid loading of heavy library.
Now it moved into the main library where it is still making sense to avoid the "LCP" (largest meaningful content pain) loading slow.

Also fixed behavior for not scrollable/short pages. Recalculating the scroll limit by take the max scroll height into account.

Added to 2.x. Will be included >= 2.0.4

Now I have taken 3 measures.

1. Reduced the length of the default text shown in the banner.
2. Reduced size of the banner itself. Not shown up over the complete width of the page, but in a small dialog bottom right of the window.
3. Fixed scroll limit behavior.

Thanks for testing. Then I'll set it to fixed.