4 ms·

> TailwindCSS How big is the CSS per page? Do you have to do any per-page optimisations? I like the concept but when I look into it, the full library appears l

> TailwindCSS How big is the CSS per page? Do you have to do any per-page optimisations? I like the concept but when I look into it, the full library appears large and having to e.g. run a CSS optimiser to bring in only the CSS classes used on every page is added complexity. Generally I'm aiming to inline all the CSS into the page with less than 50KB of CSS when it's uncompressed. Bootstrap was always too large for this.

deergomoo 6y ago
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.
- nwmcsween 6y ago
  30KB is still absolutely massive in terms of raw CSS
  - rubans 6y ago
    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.
    - seanwilson 6y ago
      > 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.
      - rubans 6y ago
        Good job you can combine approaches by inlining the functional classes you've used and serving the remainder normally then.
  - deergomoo 6y ago
    Like I say though, that's prior to gzip/Brotli. It's usually < 10KB actually being downloaded.
brandoncordell 6y ago
As another poster said with PurgeCSS it isn't bad at all. I'm lucky enough that all my users are internal and we're a Chrome only business so a lot of that cruft can be left out and the speed of the page isn't a large concern. Prototyping with VueJS and Tailwind on the frontend with Rails on the backend is pretty much my ideal workflow. It's so quick to get a feature done I still surprise myself.

deergomoo 6y ago

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.

nwmcsween 6y ago
30KB is still absolutely massive in terms of raw CSS
- rubans 6y ago
  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.
  - seanwilson 6y ago
    > 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.
    - rubans 6y ago
      Good job you can combine approaches by inlining the functional classes you've used and serving the remainder normally then.
- deergomoo 6y ago
  Like I say though, that's prior to gzip/Brotli. It's usually < 10KB actually being downloaded.

brandoncordell 6y ago

As another poster said with PurgeCSS it isn't bad at all. I'm lucky enough that all my users are internal and we're a Chrome only business so a lot of that cruft can be left out and the speed of the page isn't a large concern. Prototyping with VueJS and Tailwind on the frontend with Rails on the backend is pretty much my ideal workflow. It's so quick to get a feature done I still surprise myself.