Very slow render when using Tailwind

[lukevella]

I noticed that when using the Tailwind component, email renders are much slower. Usually a render takes a couple of milliseconds but when using tailwind it takes over 1 second (5 - 10 times slower).

Is this expected behavior or could I be doing something wrong?

[EyMaddis]

I avoided Tailwind unfortunately. Looking at the code, you can see that it is actually rendering the whole children tree of the component every time: https://github.com/resendlabs/react-email/blob/main/packages/tailwind/src/tailwind.tsx (search for renderToStaticMarkup).

renderToStaticMarkup is also use during the render() function. If you are then also use plainText generation, you are rendering the same template at least 4 times!
render() (renderToStaticMarkup) -> tailwind (renderToStaticMarkup), then it replaces stuff in the HTML code and parses tailwind code every time. Also the tailwind-to-css stuff is setup every time. There is a lot of potential for optimization here but the main issue with rendering twice is not a low hanging fruit.
It gets worse of course, if you have more than one rendered.

I noticed that I do not need most of tailwinds functionality, so this is what I did:

import { tailwindToCSS, TailwindConfig } from "tw-to-css";
 const { twj } = tailwindToCSS({
    config, // my config
  });

const textStyle = twj('text-bold ... ') // only parsed once but does not support anything that uses @media query

function MyTemplate() [
 return <Text style={textStyle}>...</Text>
]

[lukevella]

Thanks for explaining @EyMaddis, makes sense now. I wish I knew this earlier cause it was quite a pain trying to figure out why my requests were so slow and having to update all my email templates.

[EyMaddis]

"HB" posted this in the react-email discord. Maybe this solves the headache for you (even if it is a bit annoying to do copy and paste: https://tailwind-to-css.vercel.app/

[gabrielmfern]

This has actually been fixed as of the latest version for @react-email/tailwind. See https://resend.com/blog/improved-performance-for-tailwind-emails

[lukevella]

@gabrielmfern It might be worth mentioning that rendering templates with tailwind is still much slower than rendering without. I'm seeing 10x difference.

In my case, these renders are blocking requests so the difference is very significant and noticeable. So even though the latest update is a big improvement, it's still too slow for anyone who wants to render emails on demand.

[larrysharette]

Just adding this for future reference for anyone else running into slow down issues: Try not using plugins in the tailwind config you're using for React Email. Our tailwind config was using the @tailwindcss/forms plugin and by removing that plugin from the config being used for react email, rendering time went from >3sec to <1sec. Which this definitely fell within usable range for us.

[christopherliedtke]

Thanks for sharing this tip! For me, removing the @tailwindcss/forms plugin made a difference between rendering within 2s and rendering times of more than 40s. I think that should be put into the docs..

[jd-carroll]

For anyone else finding this, I still see dramatic differences between Tailwind and non-Tailwind emails. I am sure it is better than it was before, but I don't know that the issue is completely resolved.

When using Tailwind, we are seeing render times around 5311.666ms whereas non-Tailwind render times are around 932.44ms.

Additionally, the @react-email/tailwind component alone is 3.6mb when bundled.

Taken in combination, I don't see a path forward for us using the Tailwind component.

Note: Those performance numbers are from ARM Lambdas with 512mb of memory

[gabrielmfern]

A few notes on this.

I still see dramatic differences between Tailwind and non-Tailwind emails. I am sure it is better than it was before, but I don't know that the issue is completely resolved.

The difference between both is still dramatical, but the most important thing is that it is not exponential as it was before. Before
the rendering time would increase exponentially based on the amount of components/classes. This was unbearable and has a come
a long way since.

When using Tailwind, we are seeing render times around 5311.666ms whereas non-Tailwind render times are around 932.44ms.

There's not so much to do to avoid the slowness here with the current architecture we have,
this is because every time the email is re-rendered we run Tailwind again on the classes, this would allow for something like
dynamic classes of course, which usually Tailwind does not, but this is unnecessary tbh. For some time I've been thinking of a new
architecture for us to have to still allow for using Tailwind, but in a more common fashion. Not sure how to approach this yet, would love comments from anyone here.

Additionally, the @react-email/tailwind component alone is 3.6mb when bundled.

This has been sort of solved through another PR we have still to get merged (#1124), it should end being about 900kb which is still not small but a big improvement nonetheless.

[jd-carroll]

Makes sense and agreed on your points (but still needed something faster for our transactional emails), looking forward to testing once available.

Additionally, for those in serverless space trying to use this, memory size (aka CPU size) makes a dramatic difference. Halving the memory to 256mb lead to performance times at 12s+

[gabrielmfern]

@jd-carroll Wonder if you are still having the same performance issues when running on low RAM with Tailwind. I benchmarked the latest (i.e., 0.0.15) version, and it got, on average, 77ms when running with --max-old-space-size=256. This isn't accounting for the startup time, though, so not sure if the latest would also help on serverless.