Why Unused CSS Happens in Tailwind & Next.js

And How to Remove It Safely

Why "unused CSS" appears even on modern projects

Seeing a warning about unused CSS on a Tailwind + Next.js project often feels counter-intuitive. Tailwind promotes utility-first, purge-friendly CSS, and Next.js encourages modular architectures - so why is there still so much unused code?

The answer is simple: unused CSS is not a bug, it's a side effect of flexibility and scale.

As projects grow, styles accumulate faster than they are removed - especially in component-driven systems.

---

What "unused CSS" actually means

Unused CSS refers to styles that:

• are included in the CSS bundle,
• but are not applied on a given page,
• or are not applied anywhere at all.

Important nuance:

• CSS can be unused per page, yet valid globally.
• Tools often flag "unused" without understanding runtime states, breakpoints, or conditional rendering.

This is why blind cleanup is risky.

---

Why Tailwind projects still accumulate unused CSS

In real-world audits, the most common causes are:

1. Global utility availability Tailwind generates a wide range of utilities to support flexible layouts. Even with purging enabled, many utilities remain because they are referenced dynamically or indirectly.
2. Conditional rendering and state-based UI Classes applied only:

• on hover,
• on interaction,
• on certain breakpoints,
• after hydration, may be flagged as unused by static analyzers.

3. Shared components across many pages A component may use styles on one page but not another - yet its CSS is shipped globally.
4. Legacy and refactored components Old components are removed, but their styles remain referenced somewhere in the build chain.
5. Overly broad safelists Aggressive safelisting patterns keep more CSS than necessary.

---

Why unused CSS matters (and when it doesn't)

Unused CSS does not directly affect SEO rankings.

However, it can:

• increase CSS bundle size,
• slow down rendering,
• delay LCP,
• increase layout recalculation cost.

On large or mobile-heavy sites, this becomes noticeable.

That said, removing CSS that is:

• critical for responsiveness,
• required for edge cases,
• or used conditionally, can break layouts in subtle ways.

---

Common mistakes when "cleaning" CSS

We often see teams:

• delete utilities because a tool says "unused",
• remove global styles without understanding scope,
• aggressively tree-shake styles used at runtime,
• optimize CSS before addressing larger JS or layout issues.

This often leads to regressions that are hard to debug.

---

How we approach unused CSS safely

Our process is conservative and structured.

Step 1: Identify real impact

We first measure:

• CSS bundle size,
• contribution to LCP,
• render-blocking behavior.

If CSS is not a bottleneck, we deprioritize it.

---

Step 2: Separate global vs page-specific styles

We review:

• truly global styles (base, layout, typography),
• component-level styles,
• page-specific styles.

Only the latter two are candidates for reduction.

---

Step 3: Scope styles aggressively

Where possible:

• move styles into component-level CSS modules,
• reduce global utility usage for complex components,
• avoid "one-size-fits-all" styling patterns.

---

Step 4: Review Tailwind configuration

We audit:

• content paths,
• safelist rules,
• dynamic class usage,
• legacy config remnants.

Small config changes often yield large gains.

---

Step 5: Validate visually and functionally

Every cleanup step is validated across:

• breakpoints,
• interaction states,
• browsers,
• real pages.

No CSS optimization is considered done without visual QA.

---

What usually delivers the best results

In practice, the biggest wins come from:

• reducing global CSS scope,
• splitting heavy components,
• simplifying design systems,
• removing unused third-party styles.

Not from chasing "0 unused CSS".

---

Key takeaway

Unused CSS is normal in modern Tailwind + Next.js projects.

The goal is not elimination - it is control. Safe CSS optimization focuses on:

• reducing critical-path weight,
• preserving layout stability,
• avoiding regressions.

Performance improves when architecture improves - not when warnings are blindly fixed.