Hacker News new | past | comments | ask | show | jobs | submit login

The full Tailwind without PurgeCSS is definitely huge (about 2MB uncompressed), but the more recent versions have PurgeCSS integrated directly, without needed to set it up separately.

The suggested use case is building one stylesheet that covers all your pages, with the idea that a site with a reasonably consistent design is likely to use only a very narrow sliver of the available classes. In practice I've found my styles when using Tailwind to hover around the 30KB mark uncompressed (single digit KBs actually going over the wire).

It's definitely added complexity, but it's not too bad imo.




30KB is still absolutely massive in terms of raw CSS


Like I say though, that's prior to gzip/Brotli. It's usually < 10KB actually being downloaded.


I don't see that as an issue. It will get cached and it's the same difference as having a medium sized, well compressed image. Almost inconsequential when you consider you'll never have to write any more lines of CSS.

Don't get so hung up on the size of the CSS when it's relatively tiny compared to images.


> Don't get so hung up on the size of the CSS when it's relatively tiny compared to images.

It's an issue when you have to make the user wait for the top of the page to render (so they might leave if it takes too long to see anything), especially on mobile on a slow connection.

That's why APM for example makes you inline the CSS at the top of the HTML file and won't allow more than 75KB of uncompressed CSS.

CSS might be smaller than most images but it's critical to the initial page experience whereas image loading can be delayed.


Good job you can combine approaches by inlining the functional classes you've used and serving the remainder normally then.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: