Optimizing

[jackmcdade]

What do you guys to do optimize the final output? Even after trimming down a lot of unused vars (colors, etc), the generated base output is 13k lines at 180kb+. Just curious if there's a way to turn off helpers I know wouldn't end up using as a place to start.

Update: There are now docs on how to do this. Lots of control. https://tailwindcss.com/docs/controlling-file-size/

[syropian]

Have you tried using something like https://github.com/purifycss/purifycss ? It scans your input and completely removes any unused selectors from the output.

[jackmcdade]

That's in my "things to try" list, but there's a bit of complication involved in bootstrapping it, and there's always a risk of Purify missing something and stripped out required selectors and rules.

[adamwathan]

If you're using Laravel Mix, you can enable purifycss with a quick option:

mix.whatever()
    .options({ purifyCss: true })

As long as you aren't doing anything really out of the ordinary, it's surprisingly smart about checking the right files. Works with Blade, single file Vue components, etc.

THAT SAID, it has a pretty significant bug in that it doesn't strip CSS classes that contain non-standard characters (like our colons everywhere) and it also doesn't strip classes that end in numbers, so in my experience it wasn't that useful with Tailwind. Hopefully they fix that.

The main strategy we have right now is just simplifying your config. The biggest wins you'll get are in removing unused colors, spacing utilities, and using fewer breakpoints if you don't need 5 like we offer out of the box.

You can control which colors are available per utility as well, so you don't need to have your entire color palette available as backgrounds, borders, AND text colors.

Same deal with spacing; there's a good chance you can remove a bunch of negative margin utilities for example.

In the near future, we plan to modularize the utilities a lot more, so that instead of just doing @tailwind utilities, you could do this sort of thing:

@tailwind utilities/background-colors;
@tailwind utilities/border-widths;
@tailwind utilities/flex-wrapping;
// etc.

This would make it easy to straight up exclude any categories of utilities you aren't using.

In addition to that, those individual imports would never apply hover or responsive variants, so you could instead have fine grained control over what utilities have those variants and which don't:

@responsive {
    @hoverable {
        @tailwind utilities/background-colors;
    }

    @tailwind utilities/border-widths;
}

@tailwind utilities/flex-wrapping;
@tailwind utilities/z-index;

@responsive {
    @tailwind utilities/text-sizes;
}
// etc.

This would give you really fine control over the size of the generated file, at the cost of a lot of manual work of course. It would also let you make utilities hoverable (and focusable soon) that we opted not to make hoverable by default.

I don't think we will ever provide the degree of customization to do things like "only create these padding sizes for the left side and not the right side" or "only make these 2 padding sizes responsive".

Now all of that said, I don't think even the default configuration's output file size is actually a huge deal in practice. Even with the bazillion colors and breakpoints we provide, Tailwind is only 27kb minified and gzipped.

Compare that to a random site you use every day like for example GitHub, whose minified and gzipped CSS is 95.6kb, or DigitalOcean which comes in at 76.2kb, or Dribbble which is 75.3kb (I didn't even cherry pick these, just literally the first three sites in my bookmarks bar that I tried.)

Basically any image you ever serve is gonna be bigger than Tailwind's output, and users are only ever going to download it once until you deploy a new version, so personally I don't think it's worth sweating too much.

We are still committed to providing more ways to optimize the output size and it's something I check every time we change the framework in any way, so it's never going to get out of hand (ask @reinink, he is sick of hearing me talk about file size) but I do recommend trying not to sweat it too much. In my experience from a workflow perspective, it's way better to have more utilities than you need than it is to prematurely optimize and find yourself dicking around in the config file all the time basically writing new CSS because you deleted classes you weren't using yet but find yourself needing two weeks later.

[reinink]

ask @reinink, he is sick of hearing me talk about file size

It's true. While I very much value keeping the file size as small as possible, I'd hate to limit the framework as a whole because we think 25kb (minified) is too big, when in reality it isn't (or we simply don't know).

Maybe a good next step is to do some research into what impact a 25kb file will have, compared to a 15kb file, compared to a 40kb file. And then compare this to the average filesizes being used by most websites today.

I just don't want to burn pointless time and energy chasing something that doesn't matter. Micro optimizations are a productively killer.

[adamwathan]

I just did some tests where I removed breakpoints and reduced the color palette, here's what I got:

	5 screen sizes	4 screen sizes	3 screen sizes	2 screen sizes	1 screen size
Full color palette (83 colors)	27.6kb	22.1kb (80%)	16.6kb (60%)	11kb (40%)	6.8kb (25%)
Half color palette (42 colors)	17.3kb (63%)	14.5kb (53%)	11.6kb (42%)	8.7kb (32%)	5.7kb (21%)

So if you can get away with fewer breakpoints or colors, that will definitely make a big difference.

We try to ship with an extremely generous amount of values in the default config just because we don't want you to have to edit it for prototyping purposes. Much better to trim the fat after your site is built and design has stabilized than to optimize prematurely I think, and even then 27.6kb doesn't worry me too much personally.

[jackmcdade]

Totes! I agree with you. This was way more info than I expected :) nice work.

On Nov 2, 2017, at 7:05 PM, Adam Wathan notifications@github.com wrote:

I just did some tests where I removed breakpoints and reduced the color palette, here's what I got:

5 screen sizes 4 screen sizes 3 screen sizes 2 screen sizes 1 screen size Full color palette (83 colors) 27.6kb 22.1kb (80%) 16.6kb (60%) 11kb (40%) 6.8kb (25%) Half color palette (42 colors) 17.3kb (63%) 14.5kb (53%) 11.6kb (42%) 8.7kb (32%) 5.7kb (21%) So if you can get away with fewer breakpoints or colors, that will definitely make a big difference.

We try to ship with an extremely generous amount of values in the default config just because we don't want you to have to edit it for prototyping purposes. Much better to trim the fat after your site is built and design has stabilized than to optimize prematurely I think, and even then 27.6kb doesn't worry me too much personally.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[syropian]

@adamwathan One thing I noticed is if I want to use @apply in a Vue component I have to include @tailwind utilities; in every component I want to use it in. I noticed this would increase the css build size with every component that imported the Tailwind utilities. Any ideas how I could mitigate that?

[dstrunk]

@syropian, looks like a solid bug report, actually—I think the expectation is that @tailwind utilities; should only ever only import once, but after trying it myself, with each new @tailwind utilities; call, CSS jumps in line count by around 14,713 (based on a vanilla tailwind install, v. 0.1.0, your mileage may vary).

Although, thinking about it I'm not sure exactly how one would mitigate that. If your JS is compiling after CSS and you still need to rely on postCSS directives, something like tree shaking would be needed to truly get rid of duplicate CSS. Might be wrong on this, but confirming the bug at least.

[HellPat]

@syropian @dstrunk I'm not sure if this is a common usecase. But do you really need the full utilities in your JS-Component?

I always place the minimal amount of CSS needed for a component to work in the component itself. The rest of the styles goes into a boring old css-file on a project level.

If you add the utility-classes to the components html directly that no problem. You have them in one place and do not need to adjust them many times for the same component. So I'd not use @apply at all and just drop the utility-classes in my html.

If you want to change the style => just change the html (you need to do that only at the one place) and you're good to go.

[syropian]

@psren Yeah, it's not a huge issue, I could of course extract anything I'd use @apply on into a separate component, sometimes I'm just lazy 😅

[adamwathan]

@syropian Yeah the issue is of course Tailwind can't @apply classes that it can't find, and it only knows to look in the current set of styles for classes to mix in.

I really don't know much about how style tags in Vue components work so I'm not sure what options there are for making it work the way you'd want.

One idea that comes to mind is writing some sort of PostCSS plugin for marking a section of CSS to be deleted and throwing that very late in your PostCSS chain:

<style>
@strip {
  @tailwind utilities;
}

.foo { @apply .bg-purple; }
</style>

Something like that could make the utilities available in the CSS at the time Tailwind is looking for them, and then strip them later.

I don't want to commit to taking this on as a Tailwind feature, but that would be an extremely easy PostCSS plugin to write if you wanted to get your feet wet with it 😊

[syropian]

@adamwathan That's a pretty cool idea! I can survive being more diligent about extracting things into Vue components for now, but I'll definitely consider a custom PostCSS plugin if it ends up becoming a pain point for me.

[HellPat]

@adamwathan the @strip is not that easy because it has to search the HTML-Template of the component for used classes, too.

[OwenMelbz]

Just had another thought - has anybody tried yet exporting critical css yet for above/fold content?

[zackkrida]

It looks like a tailwind user has forked purifycss to make it work with tailwind's "special characters" in classes : / etc.: https://github.com/tailwindcss/tailwindcss/issues/137#issuecomment-342668417

[andrewdelprete]

Checkout PurgeCSS

The author recently made changes to work with Tailwind syntax. It has a webpack plugin and works well with Laravel Mix.

I have a few gist examples on a Medium post here: https://medium.com/@AndrewDelPrete/using-purifycss-to-remove-unused-tailwind-css-classes-173b3ee8ee01

[pxwee5]

At a time where all developers are optimizing content delivery for mobile, I think getting PurgeCSS or PurifyCSS to work with TailwindCSS is a must, especially for small to medium websites.

The framework at 27KB alone (gzipped without styling the site yet) is bigger than most small to medium website's gzipped CSS file (by quite a margin).

Tailwind is a really nice concept and it's been nice testing stuff on it. But it is really hard to justify using TailwindCSS when the gzipped size is still so big. I feel the documentation should push users to implement PurgeCSS and PurifyCSS (or even a built in implementation) to filter all unused css classes in the final output.

[adamwathan]

@pxwee5 It's a lot smaller once you change the default color palette to be the colors you are actually using. We provide a lot out of the box to make it a nice getting started experience, but personally I don't think measuring the framework based on the intentionally bloated version we put on CDNs for prototyping is super fair.

If you reduce the number of breakpoints and colors to match what a framework like Tachyons provides for example, now you are down to under 15kb.

I recommend measuring the size of your own Tailwind generated CSS, not the default. You'll find it's probably smaller than Bootstrap when you use your own color palette instead of the big one we provide as an example.

It's also worth keeping in mind that your CSS isn't going to grow if you use a framework like Tailwind, at least not in the way it would with a traditional approach.

This post is a great example of how your CSS size will change over time on a project using a utility-approach:

https://medium.com/@johnpolacek/by-the-numbers-a-year-and-half-with-atomic-css-39d75b1263b4

All that said, 0.3 will be out this week that provides even more control over what's generated, and of course people are free and encouraged to use PurgeCSS to make things even smaller. We'll add documentation about that when we have time. This is a free open source project so no one is getting paid to work on this full time.

[adamwathan]

Added some documentation around this yesterday:

https://tailwindcss.com/docs/controlling-file-size/