Klaro significantly adds to anonymous visitor page weight

Note I didn't originally find this via the page weight, I was looking at PHP performance and noticed hook_js_settings_alter() was taking quite a lot of time (well 16ms but with a hot cache) even on render cached pages, and noticed Klaro puts a very large amount of information in settings, then this reminded me to check the front end for where the js in the performance test was coming from.

Thanks, yes this should definitely be solved in the Klaro JS lib.

More lightweight solution can in the meantime be found in https://www.drupal.org/project/cookies/ → 2.x (Lib rewrite, because we had similar issues in 1.x) but we already discussed with @jurgenhaas that switching the solutions won't make sense at this point of time anymore. Klaro should solve it or maybe the lib should be forked for Drupal?

COOKiES 2.x Lib was rewritten in Svelte and has 12kb (34kb uncompressed) JS, 3kb (12kb uncompressed) CSS. Functionality is very very similar, both have some minor features which the other module doesn't have.

If it can't be fixed in Klaro lib, we could merge both projects and take the best parts from each and use the smaller JS lib from COOKiES.

Please have a look into the ADR which explains the decision on why the privacy track went with Klaro: https://git.drupalcode.org/project/drupal_cms/-/wikis/Architecture-Decis...

We've been working hard months ago and did consider the COOKiES module back then. But as described in the ADR, there have been licensing issue with the external library back then and maintainers have not been available for discussions despite the fact that we really tried hard. The fact that they now decided to go for a rewrite makes it a completely new module and it's not the time to consider a major change now that Drupal CMS is in RC phase.

As for the IS about the size of the JS library, I agree that we need to push for an optimisation there.

Sorry if my comment could be understood wrong. I did never want to propose COOKiES over klaro, just wanted to give an alternative, if anyone needs a quickfix. I edited my comment to highlight the key point, which was meant to be:

• Let's get this fixed in Klaro lib
• We could combine both solutions if needed
• Switching to COOKiES isn't an alternative here anymore

Hope that's clearer now.

We already discussed with @jurgenhaas that COOKiES is planned to be deprecated in favour of Klaro in the future, once feature-parity is reached, and we have an upgrade path to Klaro!

Let's focus on getting the Klaro lib smaller and all will be fine? :)

PS (technical detail FYI): COOKiES 2.x is just a replacement of the JS Lib (now smaller by using Svelte), module-wise it's identical to 1.x)

Let's postpone this on 🐛 Klaro library seems way too large? Active but there might be config or other changes required in Drupal CMS to take advantage of any improvements in the module.

In issue #3493540, we ensured that the JavaScript files are only loaded if services are also activated. This minimizes the standard footprint for the moment.

In issue #3491681 we changed the library from klaro-no-css.js to klaro-no-translations-no-css.js and thus reduced it from 208K to 164K.

During the work on #3491681 we also realized that the Klaro library is built with compatibility options for very old browsers. We have reduced these to the Drupal browser defaults and thus reduced the library to 64K. We are in contact with the maintainer and will adopt the new lean library.

In #3493822 we discuss whether the library can be integrated with `defer` or even `async`. However, due to the way the library is used, I am rather pessimistic about finding a solution here.

There is 📌 Update performance tests when Klaro tags a new release Postponed open which updates the performance test coverage - it shows that out of the box Drupal CMS will have 0 js or css from Klaro loaded now which is great.

What we don't have tests for is the impact once an app is enabled, that would be good to add especially once 🐛 Klaro library seems way too large? Active is in a tagged release.

I think this issue can probably be marked fixed/duplicate once the above issues are all in a tagged release. Really nice to see this come together.