Tailwind 2.0 poor performance as part of a webpack PostCSS build system

[khalwat]

Description of the problem

Tailwind CSS 2.0 builds slowly as part of a HMR webpack build system. It is slower than the release, but that could just be due to the amount of CSS generated increasing.

I filed a very similar issue a month ago #2544 and worked around the problem by splitting the CSS up into separate chunks. Global @apply still worked, and everything was great.

It's all written up in the article Speeding Up Tailwind CSS Builds

However with Tailwind CSS 2.0, the technique described in the article breaks.

Desired solution

I'm hoping to have the DX of working with Tailwind CSS 2.0 be improved from a HMR build time perspective.

I realize that you can only optimize your generation of CSS so much, and a PR is in the works to do just that with esbuild. I also realize that part of the slowness here is simply webpack and the surrounding ecosystem being slow when dealing with massive amounts of CSS (though I've optimized that quite a bit here).

However, the paradigm that Tailwind CSS is using is what generates a massive amount of CSS, and webpack is a very widely used tool that many things are built upon.

Some way to address the DX here would be great; huge gains can be made using the CSS splitting technique described in the article, maybe there could be a way to restore that functionality to Tailwind 2.x?

Link to a minimal reproduction:

I made a new branch with Tailwind 2.0, webpack 5, PostCSS 8, and all the goodness:

https://github.com/nystudio107/tailwind-css-performance/tree/problem-tailwind-2.x

webpack_1  | ℹ ｢wdm｣: Compiled successfully.
webpack_1  | ℹ ｢wdm｣: Compiling...
webpack_1  | ℹ ｢wdm｣: assets by status 72.8 KiB [cached] 2 assets
webpack_1  | assets by status 9.21 MiB [emitted]
webpack_1  |   assets by info 3.62 MiB [immutable]
webpack_1  |     asset app.53801fed2ee43ce850f5.hot-update.js 3.62 MiB [emitted] [immutable] [hmr] (name: app)
webpack_1  |     asset runtime.53801fed2ee43ce850f5.hot-update.js 881 bytes [emitted] [immutable] [hmr] (name: runtime)
webpack_1  |     asset 53801fed2ee43ce850f5.hot-update.json 37 bytes [emitted] [immutable] [hmr]
webpack_1  |   assets by path js/*.js 5.6 MiB
webpack_1  |     asset js/app.js 5.55 MiB [emitted] (name: app)
webpack_1  |     asset js/runtime.js 43.9 KiB [emitted] (name: runtime)
webpack_1  |   asset manifest.json 303 bytes [emitted]
webpack_1  | Entrypoint app 9.21 MiB = js/runtime.js 43.9 KiB runtime.53801fed2ee43ce850f5.hot-update.js 881 bytes js/app.js 5.55 MiB app.53801fed2ee43ce850f5.hot-update.js 3.62 MiB
webpack_1  | cached modules 711 KiB [cached] 61 modules
webpack_1  | runtime modules 28.9 KiB 14 modules
webpack_1  | ./node_modules/css-loader/dist/cjs.js??clonedRuleSet-4.use[1]!./node_modules/postcss-loader/dist/cjs.js??clonedRuleSet-4.use[2]!../src/css/app.pcss 3.61 MiB [built] [code generated]
webpack_1  | example-project (webpack 5.4.0) compiled successfully in 2527 ms

While 2.5s isn't awful, this is in a pretty minimal CSS setup, where I was getting about 1.2s for the equivalent builds in Tailwind 1.x, and using the technique described in the article, the builds were around 182ms

[adamwathan]

However with Tailwind CSS 2.0, the technique described in the article breaks.

Can you explain specifically what you mean by this? Does the build fail with an error or something? I'm surprised anything is different here as there were basically no internal changes between 1.9 and 2.0.

[khalwat]

Ah yes, sorry, I pushed up a new branch that demonstrates the problem: https://github.com/nystudio107/tailwind-css-performance/tree/broken-tailwind-2.x

So if I try to do this in global.pcss:

.my-cool-class {
  @apply pt-4 mb-2 text-lg
}

body {
  background-color: orange;
  @apply my-cool-class
}

I end up with this:

webpack_1  | ERROR in ../src/css/app-components.pcss (./node_modules/css-loader/dist/cjs.js??clonedRuleSet-4.use[1]!./node_modules/postcss-loader/dist/cjs.js??clonedRuleSet-4.use[2]!../src/css/app-components.pcss)
webpack_1  | Module build failed (from ./node_modules/postcss-loader/dist/cjs.js):
webpack_1  | SyntaxError
webpack_1  |
webpack_1  | (9:10) /var/www/project/src/css/components/global.pcss The `pt-4` class does not exist. If you're sure that `pt-4` exists, make sure that any `@import` statements are being properly processed before Tailwind CSS sees your CSS, as `@apply` can only be used for classes in the same CSS tree.
webpack_1  |
webpack_1  |    7 |
webpack_1  |    8 | .my-cool-class {
webpack_1  | >  9 |   @apply pt-4 mb-2 text-lg
webpack_1  |      |          ^
webpack_1  |   10 | }
webpack_1  |   11 |
webpack_1  |
webpack_1  |  @ ../src/css/app-components.pcss 47:4-60:5 2:12-216 9:17-24 13:7-21 45:20-34 49:6-59:7 50:38-52 56:26-40 58:21-28 68:15-29
webpack_1  |
webpack_1  | example-project (webpack 5.4.0) compiled with 1 error in 207 ms

The above works fine when using Tailwind 1.x, despite being broken up into separately imported files.

I assumed this was a result of the various internal @apply changes that were made.

[khalwat]

I made a branch that shows the same code working in Tailwind 1.x: https://github.com/nystudio107/tailwind-css-performance/tree/works-tailwind-1.x

Here's the diff between the two branches:

nystudio107/tailwind-css-performance@broken-tailwind-2.x...works-tailwind-1.x

It's just changing the Tailwind CSS semver from ^2.0.0 to ^1.0.0, and then the changes in the package-lock.json as a result of the npm install but that's it.

It works with Tailwind CSS 1.x, and it breaks with Tailwind CSS 2.x, with the aforementioned error:

webpack_1  | (9:10) /var/www/project/src/css/components/global.pcss The `pt-4` class does not exist. If you're sure that `pt-4` exists, make sure that any `@import` statements are being properly processed before Tailwind CSS sees your CSS, as `@apply` can only be used for classes in the same CSS tree.

[acoyfellow]

I'm not sure if it's related, I have a hunch it might be.. But upgradng a Sapper/Svelte (using postcss with rollup though, not webpack) project to Tailwind 2.0 has brought me a new headache. Sapper's compile time has 10-100x'd, and I can't make changes on the fly. I get "Killed 137" messages. Trying to debug now, I'll update this comment with any findings.

Edit: I found that

1. It's seems something related to Tailwind 2.0, or one of it's dependencies. At least in my case (sapper project using svelte preprocessor)
2. Simply doubling the CPU on my dev machine did nothing. still crashing.
3. Removing the preprocessor entirely bypasses the crashing
4. Removing the preprocessor build step from rollup in the server section, but leavign it in the client (this is the "trick" i'm unsure about. my project seems to be working as expected still, and it compiles). I question if we need the svelte preprocessor in both client/server? The same project, but simply updating deps, brought my dev experience to a screetching hault. Edit2: this isn't a real solution. I've introduced a flicker on ssr load while the css is loading from the client, I think.

[ambethia]

I'm going to add to this. I just upgraded to tailwind 2.0 and I'm getting brief beach-balling on my browser whenever HMR happens in a svelte app on snowpacker. PostCSS plugins are just tailwind, postcss-nested, and autoprefixer.

[acoyfellow]

Autoprefixer was my problem, I think. Still investigating. I had to roll it back to an older version than what TW 2 uses. My dev experience and build times are back to “normal”. TW has^10.0.2, and i rolled back to ^9.8.6.

[Cherry]

We're also experiencing very slow build times with our setup. Here's another reproduction repo which I hope will help resolve the problem:

https://github.com/Cherry/postcss-tailwind-slowdown

In this stripped down repo, we have a very basic PostCSS workflow setup, with postcss-preset-env, a simple JS workflow with just babel-loader (defaults for example sake), and 2 entrypoints, both requiring tailwind. On my Ryzen 3700x system, the npm run dev step takes almost 50 seconds for the first build, and then if I alter the tailwind.config.js file, the rebuild takes another 50s. For some members on my team with older systems, this rebuild process can take multiple minutes, which is as you can imagine quite disruptive to their workflow.

Other system info:

OS: Windows 10.0.19041 Build 19041
Node: v14.15.1 LTS

If we can provide any more information to make debugging this easier, please let me know and I'd be happy to do so.

[RobinMalfait]

Hi!

I've tested your setup @Cherry and when I run webpack --progress it takes about 1min20s for me.
But using that same setup, when I run yarn add postcss@latest and then webpack --progress again, it takes 15s. (essentially upgrading to postcss 8 instead of postcss 7)

Is it possible to migrate to postcss 8?

I'll keep doing some research to see if I can find other culprits.

[Cherry]

Hi!

I've tested your setup @Cherry and when I run webpack --progress it takes about 1min20s for me.
But using that same setup, when I run yarn add postcss@latest and then webpack --progress again, it takes 15s. (essentially upgrading to postcss 8 instead of postcss 7)

Is it possible to migrate to postcss 8?

I'll keep doing some research to see if I can find other culprits.

Thanks so much for taking a look @RobinMalfait. Unfortunately we're not able to upgrade just yet. postcss-preset-env is a key component in our build process today, so we're stuck on PostCSS 7 until that sees an update. A jump from 1m20s to 15s is definitely significant, though 15s still seems like a rather long time for a simple development build.

[iuscare]

I can confirm, that the switch from tailwind 1.9.6 to 2.0.1 with postCSS8 in place increased our compilation time during development no less than 33% and sadly breaks the workaround by @khalwat

Please let us know, if additional information can be helpful to classify or to debug the issue.

[michtio]

I can confirm the same thing as what @khalwat mentioned, we reverted back to 1.9, I hope this issue gets some priority, as TW2.0 slow down our dev environment a lot, HMR takes much too long, and our compilation time ( after changing out postcss-preset-env , to leverage autoprefixer directly, and abandoning nested postcss ) still increases depending on machines by 35-55%, which brings in a rather complicated ( but necessary ) setup build times to ~2.8s.