I’ve been able to get my Sage/Tailwind based theme setup so that I’m generating page and component-specific CSS from sass, however, I’m running into a problem attempting to compile/purge Tailwind at a page-specific level, i.e. app.css for all tailwind styles (fallback if no page-specific detected), app-home.css for all home page tailwind styles, app-category.css for category page and so on.
In my previous build system I was able to get this done by following a specific file/folder naming structure and using Gulp to dynamically generate the content configuration based on the name of the sass file being saved.
I’ve been trying to get something working using both the bud/tailwindcss package and the bud/purgecss package, but nothing seems to want to work other than placing the content configuration in the tailwind.config.cjs file.
I’ve seen a few similar posts on the forum regarding page-specific CSS but nothing really in regards to this type of use case. Was hoping the community might have some ideas before I end up throwing too much time at it in the wrong direction.
2 Likes
Hi @Adam_Hodson,
This is an interesting idea. You may want to take a look at running multiple Bud instances, and specifying content configuration for each page and instance.
Is Tailwind CSS splitting required / good value for effort though? Remember that Tailwind tree-shakes without PurgeCSS, and minifies well. But perhaps your project has other nuances that I’m not aware of.
Lots of extra complexity is added when using Tailwind with a preprocessor like SASS, and is not recommended.
If, for some reason, your project has a lot of page specific non-Tailwind styling, running separate Bud instances without Tailwind could be a solution.
My feeling is that page splitting Tailwind styles is a bit of a ‘code-smell’, and is worth reconsidering the approach, but I may have misunderstood your use case (apologies in advance).
1 Like
Thanks for the response i’ll check out the multiple bud instances to see if that might work.
PurgeCSS works great for purging the global styles, but as a site grows and the number of templates grow, so do the number of tailwind classes being used.
Some pages use little to no tailwind, and others use quite a bit, it really just depends on the use page in question and how extensive the designs are. When it’s a page that’s only loading a few tailwind classes, i.e. a simple contact page, even a compressed, minified, and purged Tailwind CSS file may have an extra 20kb+ of CSS that just isn’t necessary.
I’m still pretty sure the solution lies in the bud file itself and somehow building those content configurations on the fly like I have with Gulp. I’m not seeing any documentation on setting the content config from within the Bud-Tailwind docs, do you know if something like that is feasible?
There isn’t any provision to override or redirect the tailwind.config.* file from within Bud. But that is by design; Bud is just loading the Tailwind PostCSS extension. Tailwind’s resolveConfig helper is then resolving the configuration file, which contains your content configuration.
One possible solution is to use multiple Bud instances, and a generator function in tailwind.config.cjs for the content prop.
>20KiB minified and compressed unused CSS sounds like something is wrong. I can see why you want to shed those bytes!
That makes sense, I’ll keep digging and report back with anything I come up with.
And it’s not that the 20kb is unused, just that it may not be used on a specific page. Consider this scenario:
Tailwind is being used to create various global blocks - think sliders, heroes, CTA sections, whatever. A page is built from a combination of the global blocks within a custom template, so a page with 6-8 sections could potentially include more tailwind classes than one with a single section, i.e. a contact page.
So if the tailwind file for a really big page like a home page creates 10kb of CSS, a how it works page may add an additional 5kb, and so on as the number of templates grow, it can stand to reason that a site that generates one singular tailwind file could have 20kb of unused CSS in it when loaded on the contact page in this scenario.
One thing I’m thinking of experimenting with is generating these files on the fly when pages are saved in WP. Libraries like Yarn can be run in the browser, so doing something like hooking into the post save action then
- parsing out the HTML
- extracting the CSS files in questions
- running it through DropCSS
- Saving a new page-specific CSS file based on the rendered HTML (so folder structure wouldn’t really matter).
I think this could also be a good solution for using tailwind in Gutenberg/ACF blocks, and based on the documentation, the processing time should be negligible on post/page save.
1 Like
Ah, I see what you mean. I suppose perceived efficiency is based on user behaviour, and how many distinct pages are typically accessed per ‘session’.
Your approach certainly sounds interesting, and with FSE / Gutenberg I guess processing the actual rendered content is the only way to accurately be able to purge rules on a per-page basis. I imagine this would sit as a layer above the theme build pipeline, and not be specific to Sage / Bud.
Looking forward to see what you come up with!