- π¬π§United Kingdom catch
Going to re-open this, didn't realise it was from so long ago.
A lot of things have changed in the intervening years, but we still create multiple aggregates with similar files in them.
e.g.
Page 1, library A, depends on drupal/jquery
Page 2, library B, depends on drupal/jquery
This will result in two aggregates, both of which include the full jquery library.
We could try to do something like 'separate out libraries that are dependencies of other libraries vs. ones that aren't, but that also doesn't necessarily work.
e.g.
Page 1, library A, depends on library C, which depends on drupal/jquery
Page 2, library B, depends on drupal/jquery
Page 3, library D depends on library Cif library C is bundled with drupal/jquery, then jquery gets duplicated. If library C gets bundled with library A, then library C gets duplicated.
Even if library A and library B were put in their own separate aggregate, library C and jquery would be together. Or if library A and library C were put together instead, that will then duplicate library C if library D depends on it too on a different page again.
I've got issues like π Create placeholders for more things Active and π Consider adding back the 'every page' concept to libraries Active open to try to add heuristics about aggregate grouping, which are all tackling the original problems with hook_init()/every_page discussed here in different ways. But full deduplication didn't happen in the 15 years since this issue was opened, and it's very unlikely to get done this year either.
There is another way that pulling jQuery out of the aggregate would help.
Let's say:
- anonymous users never load jQuery
- authenticated users load it on some pages
- admins load it on every page.If authenticated users and admins end up with jQuery in different aggregates, then while this will rarely or never affect browser caching (it might with masquerade module), it will affect varnish/cdn efficiency a bit.
- Merge request !10811Add preprocess: false to the jquery library definition. β (Open) created by catch
- π¬π§United Kingdom catch
Had to add new test coverage to pick this up - just hitting two non-admin pages from Umami as an editor is enough.
Reduction of 80kb of JavaScript downloaded between the two pages which is pretty much what you'd expect given jquery.min.js is 75k uncompressed.
- π¬π§United Kingdom catch
Here's a follow-up to try to handle this generically. π Aggregate 'only ancestor' libraries in their own groups Active .
- π¬π§United Kingdom catch
This is quite a significant improvement for very little effort, and at least in its current state, π Aggregate 'only ancestor' libraries in their own groups Active is not, bumping to major.
The Needs Review Queue Bot β tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide β to find step-by-step guides for working with issues.
- π«π·France nod_ Lille
looks good to me.
we do the same with the main ckeditor script for similar reasons