> Because every new class name that you introduce could have potentially hundreds of property-value combinations, and that translates to more compiled CSS—which, of course, means a larger network request, and potentially slower performance.
After PurgeCSS you can end up with a 15kb CSS bundled payload even before gzip for a decently sized site. That's so much smaller than most other CSS libraries because Tailwind is very purge friendly.
Unlike other methods I’ve seen Tailwind based projects result in very small CSS payloads that tend to grow asymptotically over time instead of getting bigger and more bloated over time as people keep adding new “semantic” classes.
And purge css is not some "other thing" you have to go get to use tailwind effectively, it's built in! You don't need webpack in the mix or whatever, you just need a couple of lines in your tailwind config.
In real life, tailwind produces the smallest dist files of anything I've used just because the built in treeshaking thing is just effortless and works so well.
(Clearly this is my least favorite "I don't like tailwind" gripe lol)
Came looking for this comment. 100% agreed, and it seems like the author didn't even try?
My site https://www.listenaddict.com/ is 5.6kg for all the core/layout, and then another 1.6kg for the color theme (I have 12x themes and they're all separate, so the user only has to load one of them).
OP wrote:
> Because every new class name that you introduce could have potentially hundreds of property-value combinations, and that translates to more compiled CSS—which, of course, means a larger network request, and potentially slower performance.
After PurgeCSS you can end up with a 15kb CSS bundled payload even before gzip for a decently sized site. That's so much smaller than most other CSS libraries because Tailwind is very purge friendly.