#frontend performance

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

Clean rebase, back to RTBC.

Rerolled

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.

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.

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.

nod_ → closed merge request !10811

I think that's worth a release note

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

Feedback appears to be addressed

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.

haven't manually test but all tests appear to be failing.

Added the comment.

Ah thanks. Took your advice from slack and used the revision log area to test and can confirm I can still drag the textarea up and down

OK that's not affected by this, only affects textareas (the draggable corner, when it's there).

I resized the browser window

@smustgrave did you resize the browser window or the textarea? The ckeditor textarea isn't resizable (at least not out of the box), however the revision information box should be vertically resizable.

So I tested this one on a standard install of 11.x
Went to the add Article node form
Using the browser changed size left and right, up and down and everything resized just fine.

Leaving the tag if there is additional testing that should be done, else LGTM

This is within the threshold of asset sizes in performance tests because it's a small file, meaning tests don't fail due to the improvemnet, but it allows us to lower those threshold a little bit, so have done that.

Committed e10e162 and pushed to 11.x. Thanks!

nod_ → closed merge request !11433

In that case status report page seems fine.

@smustgrave it should only affect the status report so that should be sufficient testing.

Updated the performance tests - all expected reductions in the amount of CSS we serve so that's good.

Applied the MR and went to the status report page and all seems fine, is there another thing I should be testing?

Moving to NW as the test failures I believe are legit as they are all around test performance.

This needs basic manual testing. Install the standard profile, visit admin/reports/status, apply the MR, clear caches, refresh the page - make sure it's still styled correctly.