perf(platform-browser): disable styles of removed components instead of removing by mattlewis92 · Pull Request #64524 · angular/angular

mattlewis92 · 2025-10-19T16:47:27Z

This commit changes the behaviour of REMOVE_STYLES_ON_COMPONENT_DESTROY.

Now, style and link nodes are disabled instead of removed from DOM which avoiding the browser having to reparse the stylesheet when the stylesheet is re-enabled.

This was previously reverted in 1640743 but it seems like the observed perf regression in chromium has since been fixed in https://issues.chromium.org/issues/40911913, so it should be possible to reland this perf improvement

PR Checklist

Please check if your PR fulfills the following requirements:

The commit message follows our guidelines: https://github.com/angular/angular/blob/main/contributing-docs/commit-message-guidelines.md
Tests for the changes have been added (for bug fixes / features)
Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

Bugfix
Feature
Code style update (formatting, local variables)
Refactoring (no functional changes, no api changes)
Build related changes
CI related changes
Documentation content changes
angular.dev application / infrastructure changes
Other... Please describe:

What is the current behavior?

When all components using a stylesheet are destroyed, the stylesheet is removed from the DOM

Issue Number: 59651

What is the new behavior?

The stylesheet is now marked as disabled, which improves performance the next time the stylesheet is enabled, as the browser will not have to incur the cost of reparsing the stylesheet when enabling it (although it will still trigger style recalculations)

Does this PR introduce a breaking change?

Yes
No

When a component is destroyed, its associated <style> elements are now
disabled in the DOM rather than removed. When the same component is recreated, the styles
are re-enabled at their original position instead of being re-appended to the end of
<head>. This may change the CSS cascade order of component stylesheets, which could
affect styling if your application relies on the order in which component styles appear
in the DOM.

To migrate, avoid depending on the insertion order of Angular component stylesheets in
<head>. If you have styles that must take precedence over component styles, use more
specific CSS selectors or increase specificity rather than relying on source order.
Applications that do not rely on stylesheet ordering in <head> are not affected.

Other information

alan-agius4 · 2025-10-20T07:08:05Z

packages/platform-browser/src/dom/shared_styles_host.ts

 */
 interface UsageRecord<T> {
-  elements: T[];
+  elements: Map</** Host */ Node, /** Style Node */ T>;


Why do we need a Map here?

It was the data structure that was ported from the original commit that was reverted:

angular/packages/platform-browser/src/dom/shared_styles_host.ts

Line 19 in b63354e

elements: Map</** Host */ Node, /** Style Node */ HTMLStyleElement>;

What would you propose instead, just a plain object?

This code has been refactored greatly over the past year or so, and from what I am seeing elements: T[]; can be retained as the data structure as mostly I am seeing elements.values() which makes using a Map redundant here.

What about here when we remove the host?

angular/packages/platform-browser/src/dom/shared_styles_host.ts

Lines 259 to 261 in 39bb013

for (const {elements} of [...this.inline.values(), ...this.external.values()]) {

elements.delete(hostNode);

}

the removeHost is used used only in the ShadowDomRenderer, and in this case both this.inline and this.external will not be populated for the host that was added via addHostas addStyles and removeStyles are not used for shadow dom.

Makes sense, thank you! Fixed in 035ae4a (#64524)

thePunderWoman · 2025-10-20T17:18:39Z

@mattlewis92 This will likely have an impact on the new animate.enter and animate.leave APIs. We have issues where style sheets were getting prematurely pruned before when elements were removed. Unfortunately this is not the type of behavior that's easy to unit test. Can you verify this has no impact on that use case? We don't want styles disabled for elements that are in the process of animating away.

mattlewis92 · 2025-10-21T07:47:27Z

@mattlewis92 This will likely have an impact on the new animate.enter and animate.leave APIs. We have issues where style sheets were getting prematurely pruned before when elements were removed. Unfortunately this is not the type of behavior that's easy to unit test. Can you verify this has no impact on that use case? We don't want styles disabled for elements that are in the process of animating away.

Sure I can test that - do you have any kind of animations playground setup / reproduction of the previous issue where I can test it against?

thePunderWoman

This looks good to me. I think since you're re-using existing codepaths, this shouldn't have any impact on the animations use case. So we should be good.

JeanMeche · 2025-10-24T20:28:44Z

I'll take care of running a TGP over the weekend.

JeanMeche · 2025-10-27T00:36:06Z

TGP is failing. removeStyles has some usages, because even though ɵSharedStylesHost is private its pulled by at least one project.

mattlewis92 · 2025-10-27T10:21:24Z

TGP is failing. removeStyles has some usages, because even though ɵSharedStylesHost is private its pulled by at least one project.

Would it make sense to rename disableStyles back to removeStyles, or are you able to easily clean this up internally?

thePunderWoman · 2026-01-09T17:16:08Z

Heads up that this is likely to end up conflicting with #66048 which is being implemented by @dgp1130.

mattlewis92 · 2026-01-09T17:42:19Z

@thePunderWoman was the internal usage of the addStyles api cleaned up yet to unblock this PR? Looks like the signature of addStyles is changing in #66048 as well, so I guess it will need to be cleaned up to unblock both PRs

thePunderWoman · 2026-01-09T17:54:09Z

@mattlewis92 I'm unaware of the addStyles cleanup issue. Is there an open issue associated?

mattlewis92 · 2026-01-09T17:55:20Z

@mattlewis92 I'm unaware of the addStyles cleanup issue. Is there an open issue associated?

Just basing it on this comment from above:

TGP is failing. removeStyles has some usages, because even though ɵSharedStylesHost is private its pulled by at least one project.

thePunderWoman · 2026-01-09T17:58:21Z

@mattlewis92 Ah, I see. No, to my knowledge that has not changed.

mattlewis92 · 2026-03-06T12:19:05Z

@JeanMeche ah I see the issue, on HMR it's leaving the old style element disabled and creating a new one

JeanMeche · 2026-03-06T12:22:26Z

It was raised by an internal test, I haven't dug too much into it but I looks like to me it was reproducing what happened at runtime.

That might be what you were able to reproduce.

mattlewis92 · 2026-03-06T13:14:16Z

@JeanMeche OK this looks like it fixes it (verified in a real app): 9156d36

Please can you kick off the G3 tests again and let me know if the test passes now?

JeanMeche · 2026-03-06T13:17:03Z

Thx, I'll keep you updated.

mattlewis92 · 2026-03-06T13:30:36Z

All failing tests in CI pass locally, so I guess they're just flakes?

JeanMeche · 2026-03-06T13:38:56Z

You might have only run the node test targets and the not browser test targets ?
pnpm bazel test //packages/core/test/acceptance:acceptance_web_chromium should pass locally (the firefox are always broken locally), It fails for me.

mattlewis92 · 2026-03-06T14:47:37Z

OK I think it's fixed now - the remaining test passes on my local machine, so I guess it's flakey?

Starting local Bazel server (8.6.0) and connecting to it...
INFO: Analyzed target //devtools/projects/ng-devtools-backend/src/lib/component-tree:test_firefox (1054 packages loaded, 47300 targets configured).
INFO: Found 1 test target...
Target //devtools/projects/ng-devtools-backend/src/lib/component-tree:test_firefox up-to-date:
  dist/bin/devtools/projects/ng-devtools-backend/src/lib/component-tree/test_firefox_/test_firefox
INFO: Elapsed time: 147.040s, Critical Path: 40.79s
INFO: 7703 processes: 2400 internal, 1466 darwin-sandbox, 3548 local, 289 worker.
INFO: Build completed successfully, 7703 total actions
//devtools/projects/ng-devtools-backend/src/lib/component-tree:test_firefox PASSED in 8.8s

Executed 1 out of 1 test: 1 test passes.

JeanMeche · 2026-03-06T14:48:49Z

This one is flakey yes.

mattlewis92 · 2026-03-06T15:59:57Z

Looks like the presubmit passed! 🚀

JeanMeche · 2026-03-06T16:14:25Z

I'm seeing some slight changes on some screenshot tests but I wouldn't consider them minor. No sure they're flakey.

mattlewis92 · 2026-03-06T17:08:39Z

Anything you're able to share to help me debug it? (I'm in the angular slack if you want to DM it to keep it private)

JeanMeche · 2026-03-09T10:43:21Z

Had a quick chat with Matt, this is probably a breaking change as the order of the styles elements might be different with this change.

Can you update the commit and the PR to reflect that Matt ? Thanks

mattlewis92 · 2026-03-09T11:56:17Z

Done!

mattlewis92 · 2026-03-09T15:22:40Z

The CI failure looks unrelated to this change, it wasn't failing on Friday, and I don't think this PR added more than 5kb of code to exceed the bundle budget threshold

…of removing This commit changes the behaviour of `REMOVE_STYLES_ON_COMPONENT_DESTROY`. Now, `style` and `link` nodes are disabled instead of removed from DOM which avoiding the browser having to reparse the stylesheet when the stylesheet is re-enabled. This was previously reverted in 1640743 but it seems like the observed perf regression in chromium has since been fixed in https://issues.chromium.org/issues/40911913, so it should be possible to reland this perf improvement BREAKING CHANGE: When a component is destroyed, its associated `<style>` elements are now disabled in the DOM rather than removed. When the same component is recreated, the styles are re-enabled at their original position instead of being re-appended to the end of `<head>`. This may change the CSS cascade order of component stylesheets, which could affect styling if your application relies on the order in which component styles appear in the DOM. To migrate, avoid depending on the insertion order of Angular component stylesheets in `<head>`. If you have styles that must take precedence over component styles, use more specific CSS selectors or increase specificity rather than relying on source order. Applications that do not rely on stylesheet ordering in `<head>` are not affected.

…nstead of removing

…nstead of removing Clean up stale disabled stylesheets during HMR when component styles change.

…nstead of removing

…nstead of removing Prevent deferred animation renderer destroy from disabling replacement styles during HMR.

pullapprove bot requested a review from crisbeto October 19, 2025 16:47

angular-robot bot added area: performance Issues related to performance area: core Issues related to the framework runtime labels Oct 19, 2025

ngbot bot added this to the Backlog milestone Oct 19, 2025

JeanMeche requested a review from alan-agius4 October 19, 2025 17:25

alan-agius4 added the requires: TGP This PR requires a passing TGP before merging is allowed label Oct 19, 2025

pullapprove bot removed the requires: TGP This PR requires a passing TGP before merging is allowed label Oct 19, 2025

alan-agius4 reviewed Oct 20, 2025

View reviewed changes

crisbeto removed their request for review October 20, 2025 07:17

pullapprove bot requested a review from crisbeto October 20, 2025 07:17

mattlewis92 force-pushed the issue-59651 branch 2 times, most recently from 9ee205d to 035ae4a Compare October 20, 2025 15:15

alan-agius4 requested a review from thePunderWoman October 24, 2025 19:32

thePunderWoman approved these changes Oct 24, 2025

View reviewed changes

JeanMeche added the action: global presubmit The PR is in need of a google3 global presubmit label Oct 24, 2025

JeanMeche added state: blocked on G3 cleanup This change requires a G3 cleanup state: blocked and removed state: blocked on G3 cleanup This change requires a G3 cleanup labels Oct 27, 2025

mattlewis92 force-pushed the issue-59651 branch from 035ae4a to 637603b Compare January 9, 2026 17:50

mattlewis92 force-pushed the issue-59651 branch from 637603b to 62118f1 Compare January 19, 2026 11:30

mattlewis92 force-pushed the issue-59651 branch from ada0081 to 03fa85c Compare March 6, 2026 11:14

mattlewis92 force-pushed the issue-59651 branch from 777a13d to 9156d36 Compare March 6, 2026 13:12

mattlewis92 force-pushed the issue-59651 branch from 9156d36 to 2fa3ff9 Compare March 6, 2026 14:23

JeanMeche added the breaking changes label Mar 9, 2026

mattlewis92 force-pushed the issue-59651 branch from 2fa3ff9 to 345a027 Compare March 9, 2026 11:55

angular-robot bot added the detected: breaking change PR contains a commit with a breaking change label Mar 9, 2026

mattlewis92 force-pushed the issue-59651 branch from 345a027 to 145abab Compare March 9, 2026 15:18

mattlewis92 force-pushed the issue-59651 branch from 145abab to b973f10 Compare March 17, 2026 18:35

mattlewis92 added 7 commits March 18, 2026 10:31

fixup! perf(platform-browser): disable styles of removed components i…

d8608b4

…nstead of removing

fixup! perf(platform-browser): disable styles of removed components i…

c12334b

…nstead of removing

fixup! perf(platform-browser): disable styles of removed components i…

b3d8f97

…nstead of removing

fixup! perf(platform-browser): disable styles of removed components i…

054e526

…nstead of removing Clean up stale disabled stylesheets during HMR when component styles change.

fixup! perf(platform-browser): disable styles of removed components i…

950bfba

…nstead of removing

fixup! perf(platform-browser): disable styles of removed components i…

a84a102

…nstead of removing Prevent deferred animation renderer destroy from disabling replacement styles during HMR.

mattlewis92 force-pushed the issue-59651 branch from b973f10 to a84a102 Compare March 18, 2026 10:38

	for (const {elements} of [...this.inline.values(), ...this.external.values()]) {
	elements.delete(hostNode);
	}

Conversation

mattlewis92 commented Oct 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Checklist

PR Type

What is the current behavior?

What is the new behavior?

Does this PR introduce a breaking change?

Other information

Uh oh!

alan-agius4 Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

mattlewis92 Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

alan-agius4 Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

mattlewis92 Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

alan-agius4 Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

mattlewis92 Oct 20, 2025

Choose a reason for hiding this comment

Uh oh!

thePunderWoman commented Oct 20, 2025

Uh oh!

mattlewis92 commented Oct 21, 2025

Uh oh!

thePunderWoman left a comment

Choose a reason for hiding this comment

Uh oh!

JeanMeche commented Oct 24, 2025

Uh oh!

JeanMeche commented Oct 27, 2025

Uh oh!

mattlewis92 commented Oct 27, 2025

Uh oh!

thePunderWoman commented Jan 9, 2026

Uh oh!

mattlewis92 commented Jan 9, 2026

Uh oh!

thePunderWoman commented Jan 9, 2026

Uh oh!

mattlewis92 commented Jan 9, 2026

Uh oh!

thePunderWoman commented Jan 9, 2026

Uh oh!

mattlewis92 commented Mar 6, 2026

Uh oh!

JeanMeche commented Mar 6, 2026

Uh oh!

mattlewis92 commented Mar 6, 2026

Uh oh!

JeanMeche commented Mar 6, 2026

Uh oh!

mattlewis92 commented Mar 6, 2026

Uh oh!

JeanMeche commented Mar 6, 2026

Uh oh!

mattlewis92 commented Mar 6, 2026

Uh oh!

JeanMeche commented Mar 6, 2026

Uh oh!

mattlewis92 commented Mar 6, 2026

Uh oh!

JeanMeche commented Mar 6, 2026

Uh oh!

mattlewis92 commented Mar 6, 2026

Uh oh!

JeanMeche commented Mar 9, 2026

Uh oh!

mattlewis92 commented Mar 9, 2026

Uh oh!

mattlewis92 commented Mar 9, 2026

Uh oh!

Reviewers

mattlewis92 commented Oct 19, 2025 •

edited

Loading