Poor performance as part of a webpack PostCSS build system

[khalwat]

Using the latest Tailwind CSS (1.8.13 as of this writing), I'm seeing slowness very similar to #1620 & also #443, the performance of using HMR with webpack-dev-server and webpack 4 or 5 is quite slow.

It takes about 10 seconds on my MacBook Pro 2019 just changing a single color in a .pcss file, and it appears externally that it's rebuilding everything each time. The building of Tailwind CSS seems to have gotten slower and slower as the amount of utilities it includes have gone up.

I'm not sure what the caching implemented in 1.7.2 does, but in a long running process (and maybe it's already doing this but) what if all of the Tailwind-specific imports like:

@import "tailwindcss/base";

...were cached in a long running process, so it just returns the pre-generated blob? I'd imagine you're probably already doing this, but have any instrumentation or profiling been hooked up to the build to determine where the bottlenecks are?

My postcss.config.js looks like this:

module.exports = {
    plugins: [
        require('postcss-import')({
            plugins: [
            ],
            path: ['./node_modules'],
        }),
        require('tailwindcss')('./tailwind.config.js'),
        require('postcss-preset-env')({
            autoprefixer: { },
            features: {
                'nesting-rules': true
            }
        })
    ]
};

...and the whole setup is essentially what's here: https://nystudio107.com/blog/an-annotated-webpack-4-config-for-frontend-web-development#tailwind-css-post-css-config

It's not doing anything fancy re: the PostCSS part of the build, but its extremely slow compared to the HRM of JavaScript modules, etc.

I tried removing postcss-preset-env to see if it made a difference, but it doesn't seem to.

Related: https://stackoverflow.com/questions/63718438/webpack-dev-server-slow-compile-on-css-change-with-tailwind

[adamwathan]

Can you create a GitHub repo that we can use to test and benchmark? Setting it up myself means I'm just gonna put this off for months and months unfortunately, hah.

[khalwat]

Here ya go, all packaged up in a Docker container:

https://github.com/nystudio107/tailwind-css-performance

[khalwat]

I did a little more research on this tonight, and removing Tailwind CSS entirely from the project resulted in instantaneous HMR'd CSS.

Narrowing it down further, my .pcss has the following lines:

@import 'tailwindcss/base';
@import 'tailwindcss/components';
@import 'tailwindcss/utilities';

Removing @import 'tailwindcss/utilities'; results in the compilation being extremely fast; which I suppose makes sense, because it is generating the most CSS.

If we're just doing a raw import of a pre-generated file here, I'm guessing that it's just due to the massive side of the CSS file, and there may not be room for optimizations here.

Going on this, and some other various issues filed here, I refactored it to split off the .pcss into 4 separate files which I import individually in my app.ts:

import '../css/tailwind-before.pcss';
import '../css/app-before.pcss';
import '../css/tailwind-after.pcss';
import '../css/app-after.pcss';

tailwind-before.pcss has ->

/**
 * This injects Tailwind's base styles, which is a combination of
 * Normalize.css and some additional base styles.
 */
@tailwind base;

/**
 * This injects any component classes registered by plugins.
 *
 */
@tailwind components;

app-before.pcss has ->

/**
 * Here we add custom component classes; stuff we want loaded
 * *before* the utilities so that the utilities can still
 * override them.
 *
 */
@import './components/global.pcss';
@import './components/typography.pcss';
@import './components/webfonts.pcss';

tailwind-after.pcss has ->

/**
 * This injects all of Tailwind's utility classes, generated based on your
 * config file.
 *
 */
@tailwind utilities;

app-after.pcss has ->

/**
 * Include styles for individual pages
 *
 */
@import './pages/homepage.pcss';

/**
 * Include vendor css.
 *
 */
 @import 'vendor.pcss';

So all we've done here is taken one large .pcss bundle and chopped it up into 4 separate ones that can be individually recompiled, and thus also individually HMR'd.

This results in near instantaneous rebuilds for any of my .pcss that I may be writing, while also allowing me to use Tailwind CSS utilities, etc. that are generated dynamically as a result of config file changes..

All of the CSS is still imported in the right order, and they all also build into one combined CSS file for a production build.

I'll likely write this up for others who may run into it.

[khalwat]

Wrote the article up in:

Speeding Up Tailwind CSS Builds

[michtio]

@adamwathan this could be nice to be added in the documentation

Also props Andrew! This will help tons of people.

[adamwathan]

I am surprised splitting up the files makes a difference — to me that points to the build process not doing what it should because it means each file is being processed independently which can have surprising side effects in your CSS. The CSS should be fully concatenated into a single file before being processed by PostCSS for everything to work properly. Otherwise you can't use @apply across files for example.

If someone can put together a super minimal simple example that demonstrates the issue that would be helpful, the provided project with the Docker container looks super complicated.

Tailwind builds everything from scratch in < 4s for me so I wonder if something in the configuration is causing Tailwind to run multiple times.

[khalwat]

@adamwathan did you see the part about the postcss-import plugin? It looks to me like it might end up parsing each statement in the imported CSS files, looking for other @import statements.

I haven't tried taking postcss-import out of the mix to confirm its impact on this (if any) but it certainly could be a factor.

I realize that we can't @apply across multiple files, but since I'm lumping all component CSS together, I assumed it'd be fine (that's where my @applys would likely be coming from). I've noted this in the article. I haven't run into any other side-effects, but I'll definitely note them if I do.

As for the bare minimum repo, I'll have to leave that for someone else, or me when I have more time to devote to this.

[adamwathan]

Ahh you are doing JS imports for each file rather than PostCSS imports, that makes sense that it would speed things up in that way but comes with the consequence I mentioned of your files being processed in isolation from each other.

[khalwat]

mmm yeah I removed the postcss-import plugin entirely from postcss.config.js:

module.exports = {
    plugins: [
        require('tailwindcss')('./tailwind.config.js'),
    ]
};

...and reduced by app.pcss to just:

body {
 background-color: blue;
}

@tailwind base;
@tailwind components;
@tailwind utilities;

...and the rebuild times are still as slow as mentioned previously, so it's either Tailwind-related or build system-related (or more likely a mix of both).

[jan-dh]

Can only confirm that we're having similar issues. Our build itself is pretty quick but HMR with css being imported through js is very slow. So much it sometimes crashes Chrome 😅

[khalwat]

If the floor here is 3.6s on a modern MacBook Pro, raw execution, no tooling, no build system, no VM/Docker, etc. in real-world situations it's only going to get worse.

When using HMR, especially iteratively, this can slow down the developer experience significantly.

I don't know enough about Tailwind's internals, but perhaps something like a static cache that just returns the utilities rather than regenerating them if the config hasn’t changed would be ideal.

Or perhaps other shortcuts/caching layers could be implemented if process.node_env is development, similar to how WDS does in-memory compilation and takes other shortcuts in development.

Other moonshots: rewrite the core in Rust or the like and bundle it up via WASM. Yeah, I know, it'd need PostCSS and a whole bunch of other things to be also similarly ported over... just seeing the gains from esbuild, and figured I'd put it out there.

[adamwathan]

Yep something we can continue to work on when we’re able to prioritize it. In the mean time I’m 100% open to pull requests that improve performance if you have any ideas you’d like to try 👍🏻

[khalwat]

I hear ya @adamwathan -- I think to do this effectively, the person would need to know Tailwind's internals really well, which unfortunately I'm not able to delve into currently. So I'll use my hack for now, until it can get addressed in core. Thx!