Significant performance penalty when using "space-" space between class

[longzheng]

We noticed in a React app that using the "space between" utility classes (e.g. space-y-2) in a layout that has a lot of child nodes introduces a significant performance penalty that makes it almost unusable.

For example

<div class="space-x-1">
    <div>
        <div>test 0</div>
        ...
        <div>test 9999</div>
    </div>
</div>

The bizarre thing about this is that the child nodes are not direct descendants of the container that has the space- class.

I created a repro test case that illustrates this issue https://codesandbox.io/p/sandbox/sharp-faraday-hw99dy?file=%2Fsrc%2FApp.tsx%3A35%2C13 with 10,000 child nodes (two levels inside the container with the space-x-1 classname)

To repro

• click "hide content" and "show content"
• rendering of the 10,000 nodes should be almost instant
• check the "apply space-x-1 class" checkbox
• click "hide content" and "show content"
• when showing content, the rendering will be noticeably slower

The generated CSS output of the space-x-1 utility is as follows

.space-x-1 > :not([hidden]) ~ :not([hidden]) {
  --tw-space-x-reverse: 0;
  margin-right: calc(0.25rem * var(--tw-space-x-reverse));
  margin-left: calc(0.25rem * calc(1 - var(--tw-space-x-reverse)));
}

I'm assuming the > :not([hidden]) ~ :not([hidden]) part of the selector is complex and causes the rendering delays.

I'm not sure if there's any reasonable workarounds except to not use space between and switch to gap instead, but I'm keen to hear if anyone else has run into this problem.

[adamwathan]

Thanks for sharing this, I saw a tweet about something similar to this the other day so it's nice to have a reproduction! You're right, it looks like the :not([hidden]) ~ :not([hidden]) part is the source of the slowdown. If you swap that to * + * which is a slightly less powerful way to achieve the same idea, the performance is almost instant.

We originally used space-x-x > * + * but switched to space-x-4 > :not([hidden]) ~ :not([hidden]) because of so many complaints from people that hidden elements were still being affected by the selector. This performance issue is a strong case for switching back for v4, and just telling people to solve that hidden element issue a different way.

Not sure if we can change this in v3, maybe with a feature flag that you can opt in to if your project is impacted by this (I think it's only really an issue when you have a lot of child nodes).

[longzheng]

Thanks for confirming.

My team also concluded that the simpler selector > * + * is a reasonable workaround.

We proposed writing a plugin to generate alternate space-y-fast- utility classes using the simpler selector which we can use in layouts we know for sure that are not going to contain hidden elements (which is reasonable since we usually conditionally render elements in React rather than just hide them).

[longzheng]

We came across this CSS selector performance debugging tool in Microsoft Edge which was super handy https://blogs.windows.com/msedgedev/2023/01/17/the-truth-about-css-selector-performance/

From that tool we were able to verify with metrics that :not([hidden]) ~ :not([hidden]) was significantly slow

As expected * + * was much faster

[longzheng]

Just making a note it also affects divide-y since it uses the same :not([hidden]) ~ :not([hidden]) selector.

Repro https://codesandbox.io/p/sandbox/sharp-faraday-forked-5zf57f

[longzheng]

For divide-y we ended up doing a workaround by manually applying border-t to items in a loop, for example in React

                    {items.map((item, rowIndex) => {
                        return (
                            <div
                                ...
                                className={clsx([
                                    rowIndex > 0 ? 'border-t border-grey-200' : undefined,
                                ])}
                            >

[adamwathan]

Here’s the PR to switch to a faster implementation for v4: #13459

[bmakan]

I was just dealing with this issue myself. I found a workaround that helped tremendously in my case. I was using the "important": "#root" in my tailwind.config.js. When I removed it, the performance improved greatly. So far, haven't noticed any side effects, but this will depend on everyone's project.

The culprit was the divide-* class. After the change above, the timing went from ~200ms down to a few ms per rule (I was using a few variations of those, e.g., color, width, etc.).

Before:

After:


etc.

[Eazash]

I was just dealing with this same issue. I've found that the issues from the v3 style selector manifested in long element render delays that significantly impacted our project's FCP scores. Since my project can't yet migrate to tailwind v4, I've written up a postcss plugin that transforms the selectors to the more performant variant. Sharing it here as it might be helpful to others

[wongjn]

Thank you for sharing that! Here's that version as a Tailwind Plugin.