react-email: Huge performance degradation introduced with @react-email/components 0.0.8 and higher 🐢

Describe the Bug

Context: I’m developing an AWS Lambda with SES and react-email, so execution time is critical. After upgrading @react-email/components to 0.0.8 or higher, the average execution time has increased tenfold.

To emulate an environment with limited resources, I ran my lambda in a Docker container with memory and CPU settings configured in docker-compose.yml.

Findings:

The issue seems related to how @react-email/components handles Tailwind styles.
The more Tailwind styles you incorporate, the more noticeable the performance degradation.

Below are some performance measurements. (code base can be found here):

0.0.7 0 0 7

0.0.7 + tailwind (+31 % to execution time which is totally fine) 0 0 7 + tailwind

0.0.11 0 0 11

0.0.11 + tailwind (+11k % to execution time 🐢) 0 0 11 + tailwind

Which package is affected (leave empty if unsure)

@react-email/components

Link to the code that reproduces this issue

https://github.com/nikita-resh/react-email-performance-issue

To Reproduce

Pre-requirements:

docker installed

I’ve prepared a public GitHub repo with everything needed to reproduce the issue. You can find four commits in the main branch corresponding to each state from the attached images.

Here’s how you can measure execution time on your own:

Checkout commit with
Execute docker-compose build --no-cache in root folder
Execute docker-compose up in root folder
Find performance-issue-container | EXECUTION: <x>s in logs

Note: don’t forget to add --no-cache flag after checkout a different commit

Expected Behavior

Expect that the execution time will not increase after upgrading to @react-email/components 0.0.8 or higher.

What’s your node version? (if relevant)

18.17.1

About this issue

Original URL
State: closed
Created 8 months ago
Reactions: 11
Comments: 16 (3 by maintainers)

Most upvoted comments

We released a @react-email/tailwind@0.0.13-canary.1 that should fix that issue. You can install the @react-email/components@0.0.12-canary.0 as well. Please, let me know if the performance issue still persist

bukinoshita on Nov 19, 2023

“@react-email/components”: “0.0.7”, is still best performance

sysmat on Nov 4, 2023

@bodinsamuel Great that if fixes your issues! But now we already have these changes on latest and they are more stable than on that development version, so you can update to @react-email/tailwind@0.0.13.

gabrielmfern on Dec 4, 2023

Yeah, this is something we are aware of. The Tailwind component is pretty slow atm and we are planning some perf improvements soon.

gabrielmfern on Nov 3, 2023

Hey, tried to use the canary version but got this error. I guess it’s because I use type: module, can you advice?
file:///node_modules/@react-email/tailwind/dist/index.mjs:78594
     var _fs = /* @__PURE__ */ _interop_require_default(__require("fs"));
                                                       ^
 Error: Dynamic require of "fs" is not supported
     at file:///node_modules/@react-email/tailwind/dist/index.mjs:12:9
you should render the HTML only once and not every time the function runs to get the best performance possible.

As a side note, there is no tutorial on how to achieve that, especially on monorepo. emails exports only output the raw code without types and does not follow tsconfig.json which creates incompatibilities. Right now to compile react-email I already need a two step compilation tsc -p tsconfig.json && tsup that is not working well with turbo repo.

Can you try out @react-email/tailwind@0.0.13-dev.user-build-problems.0?

email export should generate HTML files that you can use directly when sending the email, if it generates js files it means there was an error and the export command gives some shallow feedback Also, are you compiling react-email yourself I couldn’t follow?

gabrielmfern on Nov 30, 2023

Because of this performance issue , the render function takes long time to execute and on Vercel , the max duration on a hobby plan is 10 sec , and this results in 504 error being thrown while taking long time to render to html

Yeah, as I said before, on environments that you want this to run fast, best case scenario is you pre-render the HTML and send it. But besides this somewhat of a workaround, I am working on some perf improvements to the component right now.

gabrielmfern on Nov 6, 2023

Because of this performance issue , the render function takes long time to execute and on Vercel , the max duration on a hobby plan is 10 sec , and this results in 504 error being thrown while taking long time to render to html

viperxeyes on Nov 6, 2023