twMerge performance compared to clsx

[samadadi]

Hi. Is there any benchmark that compares twMerge and clsx? Honestly I want to use this library but I want to know how much I am giving up in regard to performance.

[dcastil]

Hey @samadadi! 👋

The TLDR is: Generally I'd say tailwind-merge is definitely fast enough for common use cases, but I wouldn't consider it free performance-wise and only use it when I specifically want to merge Tailwind CSS classes. E.g. I wouldn't just replace all my clsx calls with it without testing the impact of that.

I think if I find some time, I'll create a benchmark for it. But since tailwind-merge relies on caching, it isn't easy to create a test that resembles real-world use. Maybe I'll find an open-source project using it extensively and run the benchmark on that.

---

twMerge is definitely slower than clsx because of the additional merging deduplication which clsx doesn't do. I didn't do a benchmark of this yet, so can't compare both precisely at this moment. I used tailwind-merge in 4 production apps already and didn't run into performance issues so far. Even if twMerge was called 1000 times at app startup (in an actual app rendering a large table, not a test scenario), its cumulative execution time didn't exceed 16 ms on a somewhat low-end desktop computer.

tailwind-merge puts most of the stress on the CPU when a lot of components are rendered for the first time (twMerge gets called a lot of times with different inputs), i.e. when the app is loaded or when navigating to a new page that wasn't visited since last app load. Subsequent updates are negligible in performance impact. Calling twMerge a few times, e.g. when a component updates or many calls with the same inputs, e.g. when rendering a list of things has a low performance impact.

I just tested this on my computer in the app of https://risecalendar.com where we use twMerge a lot, especially in design system components. Here is the code I used:

// Using tailwind-merge v1.13.0
import { extendTailwindMerge } from 'tailwind-merge'


// This is originally exported as `twMerge`, but I renamed it for this test
export const twMergeInternal = extendTailwindMerge({
    // tailwind-merge config
})

let calls = 0
let time = 0

export function twMerge() {
    calls += 1
    const start = performance.now()
    const result = twMergeInternal.apply(null, arguments)
    time += performance.now() - start
    return result
}

window.setInterval(() => {
    console.log('twMerge calls:', calls, 'time:', time)
}, 5000)

Results of reloading the app running this code in development mode with Vite on a MacBook Pro 16" with a M1 Pro chip (from 2021) in the Chrome browser with devtools open:

349 calls to twMerge with a total of 5.1 ms execution time.

[samadadi]

Thank you so much for the response.

[dcastil]

I added an issue to add a performance test to tailwind-merge → #253

[Grsmto]

I think the runtime involvement should be stated somewhere in the doc especially when there is a a when to not use it section here but runtime is not stated.
One of the reason Tailwind got so successful in the first place was because of no-runtime. Before that it was Styled-Components dominating. I'm sure runtime libraries for Tailwind are faster than SC anyway but still people should be aware of this when taking their decision on a stack.

[dcastil]

What would you want there to be stated about the runtime? Shouldn't it be obvious that it has a runtime when you call a JS function? E.g. same like calling a lodash function.

[Grsmto]

Shouldn't it be obvious that it has a runtime when you call a JS function? E.g. same like calling a lodash function.

It is far from obvious in an era where you have server-side rendering, React Server Components or other "islands" frameworks like Astro. You can call JS functions in many scenario these days without it having runtime overhead. And I think that's what confuses people.

I get it that it's not your responsibility to educate people on that and maybe my comment here is enough already.

[dcastil]

Hmmm yeah tailwind-merge can be and is used in many environments: in the browser, in server-side rendering on a CI server, in the runtime of an app backend server, in an edge compute runtime, etc. The library is essentially a JS function without any opinions on those things, so I don't think its docs would be the right place to discuss or educate on those topics.