Rewriting Storefront's CSS in Tailwind: What It Saves, and What a Trim Saves Instead

By FlexPlat. November 6, 2026.

Rewriting WooCommerce Storefront's catalogue CSS in Tailwind cut the CSS a first-time visitor downloads by 77–83%, from about 44–48 KB to 8–11 KB compressed. A much cheaper tool that removes unused rules cut it by 65–68%, to 15 KB, and works without Flx at all.

Neither changes the page much overall. CSS is 10–14% of these pages: the rewrite saved 36–38 KB out of 322–486 KB, and largest contentful paint (LCP) moved by about 0.5 s at best. All of this comes from one sample store in a lab, on a simulated phone.

We make Flx, which renders WordPress pages in Node.js, and our other demo uses Tailwind, so we had a reason to want the rewrite to win. It did come out smallest. The rewrite's lead over the trim was small, and the trim on plain WordPress beat every Flx version on LCP once we added the delay Flx has on a live site. LCP is the time until the largest piece of content appears.

Why we ran it

Our Twenty Twenty-Five demo is styled by the renderer's own Tailwind CSS, and its pages got much lighter when that went in. So the obvious question for our Storefront demo was whether doing the same would shrink its CSS. We could see three ways to answer it, and we wanted numbers before choosing one:

• rewrite Storefront's look in Tailwind and remove its CSS;
• keep the CSS and remove the rules the pages don't use;
• leave the CSS alone, and let developers write their own themes in Tailwind on top of it.

Why Twenty Twenty-Five uses Tailwind

We built and measured two options for that demo.

• WordPress's styles in every page. The renderer put WordPress's global styles, about 175 KB, inside each page's HTML.
• The renderer's own Tailwind stylesheet. Only the theme's preset variables stay in the page, about 4 KB. The rest moves to one stylesheet (52 KB, 10 KB compressed when we switched) that the browser can keep between pages.

We kept the first as a one-setting rollback and switched the default to the second, for these reasons:

• It looked the same. Both scored 94.2% desktop and 90.9% phone against native pages. Before and after the switch, the live site was pixel-identical on the 5 routes and 2 widths we checked.
• Pages got far smaller. Page HTML went from about 187 KB to 17 KB, or 26 KB to 4 KB compressed.
• A site's own choices survived. Palette, font and size presets still apply, because Tailwind's tokens read WordPress's variables.
• The risk was low. It took two days of a six-day limit we had set, and it can be undone with one setting.

We accepted one loss: a site's Additional CSS and Global Styles edits other than presets no longer apply.

We did not test a trim on that demo, so it was never one of the options we rejected. Most of the page gain came from taking CSS out of each page, and a cached stylesheet written another way might have done the same. So we don't credit Tailwind for the speed result there. On our Twenty Twenty-Five demo, Flx pages are about 40% lighter than the same pages served by WordPress (121–123 KB vs 189–223 KB), and the main content appears about 0.3–0.6 s sooner on a simulated phone (Lighthouse, median of 3). Results on your site depend on its theme and plugins; we measure before and after for every conversion.

Storefront starts from a different place, for two reasons:

• Its CSS is already outside the page. Inline CSS is only 6–7 KB compressed, and page HTML is 13–21 KB, so there is no 175 KB block to remove.
• WooCommerce prints much of the markup. Twenty Twenty-Five's renderer builds its own markup. WooCommerce's scripts depend on the markup it prints, so a Storefront version has to style that markup as it comes.

How we tested

We compared seven versions of the same store on one GitHub runner: WordPress 7.1.3, WooCommerce 11.2.1, Storefront 4.6.2 and WooCommerce's sample products, served over HTTP/2 through nginx.

Cart, Checkout and My account kept their original CSS and native rendering in every version.

1. Trim. A tool collects the CSS the catalogue pages load, removes rules that match nothing in their HTML, keeps classes that scripts add later, and minifies the result. We wrote that keep-list from reading the scripts, before running the state tests, so the tests could catch what it missed.
2. Full Tailwind. Tailwind utilities on the header, footer and product cards, which the theme owns. @apply rules on the classes WooCommerce prints. Colours are fixed to Storefront's defaults.
3. Measure. Lighthouse 12.6.1 on a phone profile, over HTTP/2 with outside network blocked, on home, shop and a variable product. Simulated throttling (median of 5) is the main result, and DevTools throttling (median of 3) is a check on it. Runs went round the versions in turn, so a slow spell on the runner would not land on one version.
4. Check the pages. Screenshot comparison with native on 11 catalogue pages at desktop and phone width. In a real browser: add to cart, mini-cart, variation choice, lightbox, tabs, sticky bar, phone menu, phone search, notices and search results.
5. Follow a shopper. Shop, then product, then cart, in one browser with its cache, counting what each step downloads.

We set these rules before seeing results, and committed them to version control before the first run:

• A version is faster than Flx only if its LCP is at least 0.3 s sooner on at least 2 of 3 pages, and by more than the spread between Flx's own runs.
• A version has smaller CSS only if a first-time visitor's compressed CSS is at least 50% less on all 3 pages.
• The trim must match native at 95% or more on every page and width. Full Tailwind must average at least 90% with no page under 85%.
• Every state must work, and a failure is reported as broken.
• If full Tailwind is within 0.2 s of LCP and 5 KB of CSS of the trim on at least 2 of 3 pages, the rewrite has no size or speed case of its own.
• When comparing Flx with native, add the 260 ms worst case we measured on our live demo. The Flx rows below use a renderer on the same machine, so they don't include it.

Results

Simulated phone, median of 5 runs. Lower is better in every column except Score. CSS is compressed, external plus inline.

The DevTools check gave smaller gaps, and on the home page a different order.

What the rules say

A whole visit

The savings shrink when a shopper reaches the cart, because that page still needs Storefront's original files.

The trim and the rewrite save about 40 KB while browsing. A visitor who goes on to the cart then downloads the original CSS as well, so they use more CSS over the whole visit than with Flx as released. We did not try trimming or rewriting the Cart page.

What caused the difference

CSS is a small part of these pages. On the product page, images are 242 KB, JavaScript 101 KB and fonts 78 KB, against 48 KB of CSS. That limits what any CSS option can save.

Fewer blocking bytes help first paint a little. First paint improved by about 0.15–0.35 s on trim and full Tailwind, because the page has less to download before it can draw. The same gain appears on native + trim, so it does not come from Flx or from Tailwind.

Tailwind's size advantage comes partly from covering less. The full Tailwind file is 38 KB raw and the trim is 87 KB. The trim keeps many rules for states a page might reach, and its keep-list is deliberately cautious. The Tailwind file covers only what we ported for this sample store. We did not test how far a stricter keep-list could shrink the trim.

A Tailwind theme on top of Storefront adds a little. Its CSS came to about 0.7 KB more than the handwritten theme's, and it doesn't reduce anything, because Storefront's CSS stays. Its value is for developers who prefer writing Tailwind.

The themed home page's simulated LCP is probably a modelling effect. Both themes lose 0.23–0.43 s there under simulated throttling, but only 0.04–0.06 s under DevTools throttling. We would not rely on it.

The work differs a lot.

Problems this test found in our own product

Looking at the pages found three problems in what we already shipped. We fixed all three in release 1.8.1. The numbers in this article were measured before that release, on 1.8.0.

• The sticky add-to-cart bar doesn't appear on Flx product pages. The script loads, but its settings don't reach the page, so it stops quietly. With the settings supplied, the bar works in every version, so the CSS options aren't the cause.
• Our theme helper makes every product card image lazy-loaded, including the first, which WooCommerce gives high priority. That added about 1.1 s of LCP on the shop page under DevTools throttling in a single run.
• Our handwritten theme hides its phone footer icons and the menu label, with white on white. The Tailwind theme copied that design and has the same fault. Our state tests pass anyway, because they check whether something can be tapped and not whether it can be seen.

A fourth finding limits one option. Our safety check for themes on Cart, Checkout and My account refuses CSS containing backslashes. Tailwind's class names for arbitrary values and breakpoints contain them, such as .bg-\[\#16161d\]. So a Tailwind theme works on catalogue pages today, and those three pages would stay native without its header and footer until we change that check.

Mistakes we made, and fixed

The first two fixes changed the numbers. The rules above did not change.

What this test cannot tell you

This is one sample store in a lab, tested for loading. Treat the numbers as a direction, not a promise for any store.

• The store is simple. It has one theme, sample products, default colours and no other plugins. Both the trim and the rewrite removed all WordPress styles from catalogue pages, which on a real store would include plugins' styles. Each would need work to keep them.
• Both prototypes are lab versions. Neither is in Flx. We built them for this test with an AI coding agent in part of a working day. That says little about the cost of a real store, or of keeping one working.
• The rewrite isn't finished. Its home page drifts by up to about 100 px in section spacing, and its menu sits 16 px off. It still scored 95%, so the pixel score is lenient on mostly white pages. We looked at it and did not polish it further.
• The score misses colour faults. See the phone footer above.
• LCP understates the product page. On every version it measured the site title, because WooCommerce hides the gallery until its script runs. It doesn't tell you when the photo appears.
• The cost of Flx is an estimate here. The renderer ran on the same machine, adding about 10 ms. The 260 ms comes from our live demo, and we measured that before this test.
• Scores vary. Two identical pages, native and Flx on the product page, differed by 0.15 s of simulated LCP, so the 0.305 s result is close to noise. Outside network was blocked, so Google Fonts isn't counted in any version.
• Repeat visits weren't measured beyond the single journey above.

What it means

If smaller CSS is the goal on a Storefront catalogue page, each option gives this:

• Trim: most of the saving (65–68%), the same look, little code, and no need for Flx. It needs regenerating when the store changes, and it's the first thing to try on a store that only wants less CSS.
• Full Tailwind: the smallest CSS (77–83%), about 7 KB better than the trim on most pages, for far more code and upkeep. Its speed gain did not hold up under the DevTools check. Size alone is a weak reason to do it.
• Tailwind theme: no saving at all. It adds a little CSS, and it's a choice about how developers work.

For a store that wants speed, CSS is unlikely to be the first place to look. Images, scripts and fonts are much larger on these pages, and a visitor who reaches the cart loses most of the CSS saving.

The case for Flx on a store remains what it was: JavaScript developers building WordPress and WooCommerce pages. This test does not change that, and it gives no speed reason to choose Flx.

What we decided

We are not rewriting Storefront's CSS in Tailwind. About 7 KB less CSS doesn't justify the code and upkeep, and the speed gain did not hold up under our check.

• Tailwind for theme authors stays possible. It works on catalogue pages today. Cart, Checkout and My account would stay native with such a theme until we change our safety check, and we have not made that change.
• Trimming stays optional. We have not built it into Flx, because a store can trim its CSS without Flx.