By default, don't aggregate jquery.js

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 C

if 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.

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.

Here's a follow-up to try to handle this generically. 📌 Aggregate 'only ancestor' libraries in their own groups Active .

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.

looks good to me.

we do the same with the main ckeditor script for similar reasons

NW for the comment

Added the comment.

Test failures on the test only job show the improvement:

Asserting ScriptBytes 249765 is greater or equal to 170000 and is smaller or equal to 171000
Failed asserting that 249765 ( is equal to 170000 or is greater than 170000 ) and ( is equal to 171000 or is less than 171000 ).
/builds/project/drupal/core/tests/Drupal/Tests/PerformanceTestTrait.php:623
/builds/project/drupal/core/tests/Drupal/Tests/PerformanceTestTrait.php:672
/builds/project/drupal/core/profiles/demo_umami/tests/src/FunctionalJavascript/AssetAggregationAcrossPagesTest.php:54
2) Drupal\Tests\demo_umami\FunctionalJavascript\AssetAggregationAcrossPagesTest::testFrontAndRecipesPagesEditor
Asserting ScriptBytes 417181 is greater or equal to 337700 and is smaller or equal to 338700
Failed asserting that 417181 ( is equal to 337700 or is greater than 337700 ) and ( is equal to 338700 or is less than 338700 ).
/builds/project/drupal/core/tests/Drupal/Tests/PerformanceTestTrait.php:623
/builds/project/drupal/core/tests/Drupal/Tests/PerformanceTestTrait.php:672
/builds/project/drupal/core/profiles/demo_umami/tests/src/FunctionalJavascript/AssetAggregationAcrossPagesTest.php:76
FAILURES!

https://git.drupalcode.org/project/drupal/-/jobs/4641371

So about 80kb reduction in bytes downloaded across a couple of pages and reproducible with stock Umami.

Feedback appears to be addressed

I think that's worth a release note

Committed 784effb and pushed to 11.x. Thanks!

nod_ → closed merge request !10811

There's nothing really for site owners to respond to, so I don't think a release note is right here, but added a change record.

Tagging for release highlights not because we should add the details here, but we can talk about the end result in combination with other issues that should also improve aggregate hit rates in 11.2

Automatically closed - issue fixed for 2 weeks with no activity.