[Emotion migration] Caching issue causing performance problems

[tsullivan]

Performance bug

As Kibana devs migrate SCSS code into Emotion (meta issue), folks have begun to notice performance issues at runtime.

When a component renders with Emotion styles, a new <style> tag is added to the head. The effect is that style tags accumulate as we navigate Kibana.

Quote from @mbondyra:

Over time, this can result in thousands of redundant <style> tags, which resembles a memory leak and can impact runtime performance. The more we adopt the rewrite, the more this issue scales—more style tags keep getting added but never removed when navigating between pages. It also means other teams can unintentionally slow down our apps just by adding styles to theirs, since styles persist across navigation.

The investigation is still early at the time of this writing. In production, we're seeing styles being added with each plugin, not removed on unmount, but not being duplicated. Memoized components have their emotion style tags persisted. We're still looking into whether any styles are being duplicated. While going through several views we can reproduce 6900 style tags locally and the tab memory usage increased to 1.1GB.

Additional notes

• A resource which may help: https://engineering.deptagency.com/optimizing-emotion-in-react
• A live expression in devtools with document.querySelectorAll('style').length and switching between views is a nice way to see what could inject duplicated style tags

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[Dosant]

I wanted to summarize the thread that we had as I see it

In production, we're seeing styles being added with each plugin, not removed on unmount

This is expected behavior for emotion. Styles aren't removed because it might be too costly to recalculate and reinsert them. I created a quick proof of concept at #218404, where we have a separate cache for each React tree. The main downside is that even the shared components' cache isn't shared between different apps. For example, EUI components have to recalculate their styles when moving between apps.

• We can look into this more if we can at least share the cache for the EUI components.
• We can find smarter ways to clean up. For example, instead of cleaning up after unmounting, we can use a heuristic to decide when the number of cached styles is too large.

As Kibana devs migrate SCSS code into Emotion (https://github.com/elastic/kibana-team/issues/1417), folks have begun to notice performance issues at runtime.

I don't think it's clear that the performance issues mentioned come from Emotion. While indefinite growth looks like a memory leak, @tkajtoch investigated and found that after using Kibana for a while, only 17MB out of 1GB seems to be related to CSS. It's more likely that we have more serious memory leaks from other sources.

Memoized components have their emotion style tags persisted.

It seems that memoization shouldn't play a role in this. Memoized components and useMemo can be helpful if building the Emotion CSS string is expensive, but the main caching happens inside Emotion.

We're still looking into whether any styles are being duplicated

We've learned about two scenarios that may resemble duplication:

1. Dynamic variables used inside css string:

kibana/src/platform/plugins/shared/unified_search/public/typeahead/suggestions_component.tsx

Lines 177 to 187 in de213f6

	const verticalListPosition = isSuggestionsListFittable
	? `top: ${pageYOffset + containerRect.bottom - SUGGESTIONS_LIST_REQUIRED_TOP_OFFSET}px;`
	: `bottom: ${documentHeight - (pageYOffset + containerRect.top)}px;`;
	const divPosition = css`
	position: absolute;
	z-index: 4001;
	left: ${containerRect.left}px;
	width: ${containerRect.width}px;
	${verticalListPosition}
	`;

In this case, each time the suggestions popover appears, it will show up at a slightly different vertical position. Because of ${verticalListPosition}, the styles are set up in a way that Emotion considers this a different version of the same component. As a result, it adds it to the cache and injects it into the DOM with each render

The best practice is to use style prop or css variables.

I added this to EUI/Kibana Emotion guide: elastic/eui#6828 (comment)

2. Styles for shared components are separated when used from different plugins

I think this duplication comes from our global issue with how packages work. Each plugin gets its own instance of an imported package unless the package is added to a shared UI bundle. So when the same component from a regular package is used by Lens and Dashboard, from an Emotion perspective, those are two different components, and the styles aren’t reused between them (same for scss)

[tsullivan]

I don't think it's clear that the performance issues mentioned come from Emotion. While indefinite growth looks like a memory leak, @tkajtoch investigated and found that after using Kibana for a while, only 17MB out of 1GB seems to be related to CSS. It's more likely that we have more serious memory leaks from other sources.

Based on this, I think we should not ask for folks to put another pause on SCSS removal for now.

Thanks so much for this, @Dosant! The addition to the EUI guide is a great read!

[tsullivan]

I announced this investigation and knowledge share to the Kibana contributors: https://groups.google.com/a/elastic.co/g/kibana-contributors/c/hH-xcaGLOm8/m/CjhR5rV5DQAJ

The only part I see could need more followup are these suggestions:

• We can look into this more if we can at least share the cache for the EUI components.
• We can find smarter ways to clean up. For example, instead of cleaning up after unmounting, we can use a heuristic to decide when the number of cached styles is too large.

We can also wait and see if folks are OK with tacking the issue just by sticking to the best practice of separating static and dynamic styles.

[tsullivan]

We should investigate the possibility of collecting benchmark data with telemetry. This would help us know the current standard numbers of style tags in the DOM. If we do this, we would probably also want to know the size of memory loaded for the browser tab, and how the size of CSS code compares with that.

[elasticmachine]

Pinging @elastic/eui-team (EUI)

[tsullivan]

We should investigate the possibility of collecting benchmark data with telemetry. This would help us know the current standard numbers of style tags in the DOM. If we do this, we would probably also want to know the size of memory loaded for the browser tab, and how the size of CSS code compares with that.

Right now, our telemetry service is only intended to be used to collect product usage data, not benchmarks or performance data. We would want something like APM RUM to collect this type of information.

[tsullivan]

From @rudolf in Slack

I wouldn't say you should "measure it using RUM" but report it as a trace using RUM

Ideally you could report just an Otel metric from the client-side but that's not possible yet...

[tsullivan]

Related: emotion-js/emotion#3332

[mbondyra]

I've done some additional testing and turns out it's not a problem. In dev, Emotion injects a separate <style> tag for each rule. In prod, it doesn't use it, it instead uses insertRule, which avoids DOM mutation and is significantly faster (even faster than static stylesheets!). Here's a piece of code from the emotion codebase responsible for it. Why doesn't it use insertRule for dev environment? Because it kills dev experience — styles added via insertRule aren't visible in DOM and can’t be edited in devtools.

➡️ Example (checking clean Lens app):

Dev: ~1200 <style> tags
Prod: ~45 <style> tags

Why didn’t we notice this earlier?
Bit of human error — I raised the issue based on dev behavior, someone else confirmed it happened in prod too (probably a misread), and we didn’t double-check 🤷‍♀️

✅ Conclusion: No perf issue in production, @tsullivan we can close this issue 🎉