Improve production build performance for the case of many small non-tailwind stylesheets #4644
Conversation
In layers mode, skip `purgecss` completely if source stylesheet does not have any tailwind layers. For the legacy codebases with a lot of non-tailwind stylesheets, it dratically improves the performance of the production build.
|
@adamwathan is there anything I can do to get this PR merged? This is quite an important issue for us and I'd be happy to do any changes you deem necessary. |
|
Unsubscribe me from this I am not understanding anything.
…On Thu, Jun 24, 2021, 15:48 Sergey Tatarintsev ***@***.***> wrote:
@adamwathan <https://github.com/adamwathan> is there anything I can do to
get this PR merged? This is quite an important and important issue for us
and I'd be happy to do any changes you deem necessary.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4644 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AQLGT3767W4IO6XORUMBMX3TUL7GBANCNFSM46VCACMQ>
.
|
|
Just haven't had time to review, have higher priorities unfortunately. Will try to look soon, have to be really careful with changes like this though so it takes a bit of a commitment to get through it. Hopefully soon, can you use your own fork though in the mean time? |
|
Hey @SevInf. Comparing this to PurgeCSS itself, are we missing these few lines? if (this.options.variables) {
this.variablesStructure.safelist = safelist.variables || [];
} |
|
@bradlc this code is taken from |
|
Hey @bradlic, so I am back with the fix. You were right, those lines were missing and were breaking |
|
@SevInf thanks man will put this out in the next patch! |
Hi there!
We decided to use tailwind as a base of our design system. Our codebase is legacy-ish Vue 2 SPA with pretty liberal use of
<style>blocks in our components, built with webpack (this info will be important later). Tailwind worked great and was delightful to work with. That is, until we got to production build part.Turns out, just adding tailwind to our postcss plugins list added a couple of minutes to our build times. Actual usage did not seem to matter: commenting out every
@applyand@tailwindrule did not seem to change anything: build with tailwind plugin included still was couple of minutes slower than without it. Further investigation pointed out atpurgeoption as the culprit. Removing it seemed to bring out build times in line with what we expected, but we'd very much like to keep it. Of course, purging unused styles takes time, but minutes still seemed excessive, especially considering thattailwind-cliwith the same config successfully generates the stylesheet in a couple of seconds.As it turns out, tailwind plugin runs purgecss on every source stylesheet. Which, in case of legacy-ish code base with a lot of tiny stylesheets, is quite a lot. Sure, if said file does not have
@tailwinddirective, it will get wrapped inpurgecss ignoreblock, but extraction of used rules from html and js will still be done from scratch for every one of those tiny stylesheets.This PR changes the plugin to completely skip
purgecssinlayersmode if the source file did not include any tailwind layers. For that, I had to switch frompostcss-purgecssplugin to callingpurgecssmanually — it does not seem like there is a way to decoratepostcss-purgecssplugin to call it conditionally for both PostCSS 7 and 8. I guess, the upside of this is that latest purgecss could also be used in compat build.Some benchmarks of this PR on our codebase:
Before:
pnpm build 421.86s user 29.51s system 169% cpu 4:25.98 totalAfter:
pnpm build 285.95s user 16.38s system 214% cpu 2:21.21 totalAs you can see, it saves 2 minutes for us. It might be also very useful for other people in similar situations: integrating tailwind into existing codebase with modularized css.