Styled props are ~30% slower at render than cva or css

[kris-ellery]

Hello friends!

As we refactor our design system components to use TS and Panda, we are also running performance benchmarks. Recently, I tested the 100 Button components and noticed poor render results. After some investigation, I found the culprit: the styled props.

Panda offers two ways to create styled props: either via styled.button or via the splitCssProps hook that separates styled props from the rest.

// via styled.button
export const Button: FC<ButtonProps> = (props) => {
  return <styled.button {...props} />;
};

// via splitCssProps
export const Button: FC<ButtonProps> = (props) => {
  const [cssProps, restProps] = splitCssProps(props);
  const { css: cssProp, ...styleProps } = cssProps;
  return <button className={css(styleProps, cssProp)} {...restProps} />;
};

Both examples allow consumers to pass styled props that generate atomic utility class names.

<Button marginBottom="30px" marginTop={{ base: '10px', lg: '30px' }} />
<Flex display="flex" gap="10px" flexDirection={{ base: 'column', lg: 'row' }} />
<Text textAlign={{ base: 'center', lg: 'left' }} />

Both approaches use the same splitProps method. This operation is costly and, for our performance test of 100 Buttons, it has increased the mount time by 30% and re-render by 40% in a Next 14 and React 18 environment.

Clearly, we're not happy about this and wonder if leveraging the css prop and skipping splitCssProps altogether is the way to go.

Here is an example of using the css prop rather than individual styled props from the previous example:

<Button css={{ marginBottom: '30px', marginTop: { base: '10px', lg: '30px' } }} />
<Flex css={{ display: 'flex', gap: '10px', flexDirection: { base: 'column', lg: 'row' } }} />
<Text css={{ textAlign: { base: 'center', lg: 'left' } }} />

This issue does not seem specific to Panda; it's something every static CSS library deals with — the mapping of props and their values to the correct class names.

So the question is, can we make styled props faster or do we have to use css prop to maximize performance? Note, we had zero success with unplugging and removing Panda's runtime in our setup.

[mverissimo]

How do you measure this benchmark? Could share some reproduction?

[kris-ellery]

I run a Next.js app with 100 buttons, each with random variants (size, tone, disabled, etc), then measure render times with React Profiler for mount and update. I do this in dev and prod environments.

Here is an example comparing Button, SplitCssButton, and StyledButton. See console log for mount and re-render metrics.

https://codesandbox.io/p/devbox/panda-button-render-performance-forked-vydk8r

The differences in this example aren't as significant due to low complexity. However, once you start adding Button.Label and Button.Icon subcomponents things start to add up.

[kris-ellery]

I might try automated testing next with https://github.com/callstack/reassure

[omridevk]

@kris-ellery I personally use the CSS prop to use less runtime as possible

[kris-ellery]

Thats what my team is leaning to as well. I've refactored our codebase and a render test of 100 random buttons went from 10-12ms to 7-8ms in production. We're happy to sacrifice some DX of styled-props for a better runtime performance. Plus it shaved off 13KB from styled-system/jsx/is-valid-prop.mjs file.

[astahmer]

exactly ! note that you can set jsxStyleProps to minimal (or none) to disable those (almost) completly

as you mentioned, there are trade-offs to using JSX style props:

• more work has to be done at runtime inside the styled factory like splitting props
• the runtime needs to know which component property should be split & passed to the css function (to return the matching CSS class)

---

👀 unless using a bundler plugin like this which can inline those to their resulting classes

⚠️ but then you introduce another trade-off: composability is now limited to what the static analysis sees at compile-time (so you can't do css(props.css, { ...stuff }) anymore

✅ which, again, can be solved by selectively opting in with the import attribute like import { css } from "../styled-system" with { type: "macro" }) and then you get the best of both worlds: nice DX + small JS size & fast perfs

[astahmer]

So the question is, can we make styled props faster or do we have to use css prop to maximize performance?

I think it's quite fast already, given the constraints (if it can be improved we'd be happy to merge that in)
but yes I totally agree, in perf sensitive cases (rendering hundreds of times a component, it shouldnt matter in most cases), a super simple solution is to:

• either use css(xxx) instead of styled
• or if that happens with css(xxx), extract the css(xxx) call outside of the component render cycle so that it doesnt have to re-compute the same thing over and over

---

Note, we had zero success with unplugging and removing Panda's runtime in our setup.

I didnt understand this part, can you explain ?

[kris-ellery]

We have tried to add additional PostCSS plugins, like postcss-prune-var or postcss-css-variables, but there is no difference in static CSS output. Tried before and after Panda plugin in postcss.config.js

We have also tried the pandabox plugins with mixed results. We have not been able to inline class names at build time. I think certain conditions had to be met between design system, consuming app, etc.

Side note, we have noticed issues with hashing. When design system builds a manifest file panda.buildinfo.json with hashing turned off, and the consuming app turns on the hashing, the styles in CSS are hashed, but not in DOM.

I love using Panda, but the integrations and custom build solutions are a bottleneck.