Auditing Your CSS Output

Even with Tailwind's JIT engine removing unused styles, your production CSS bundle can grow unexpectedly. Auditing your CSS output means inspecting the final compiled file to understand what made it in, how large it is, and whether anything unnecessary slipped through. A lean stylesheet loads faster, parses faster, and improves Core Web Vitals scores.

The simplest audit starts with measuring file size. After building your project, check the size of the generated CSS file. Gzip size is the number that matters for real-world performance because browsers decompress on the fly. A well-tuned Tailwind output is typically 5–15 KB gzipped for most projects.

During development, run Tailwind in watch mode to rebuild the stylesheet on every file change. This gives you real-time feedback on how your class additions affect output size. Use the --minify flag when measuring size to get production-accurate numbers rather than the development build.

Open the compiled CSS file and search for class names you suspect might be unnecessary. If you see hundreds of animation keyframes you never use, or an entire color palette for a color you only reference once, those are candidates for pruning. Text search for your content globs to verify they match the right files.

The most common source of bloat is misconfigured content paths. If your content array is too broad, Tailwind scans files it should not, picking up class-like strings from build artifacts, test fixtures, or third-party libraries. If it is too narrow, real classes get purged from production. Audit the content array first.

PurgeCSS can run as a standalone tool to analyze which selectors in your stylesheet are matched by your HTML files and which are not. While Tailwind has its own purging built in, running PurgeCSS separately gives you a detailed rejection report that highlights exactly which classes survived and which were removed.

Tools like Statoscope, webpack-bundle-analyzer, or Next.js's built-in ANALYZE=true mode visualize your entire bundle including CSS files. They show a treemap of what takes up space, which makes it easy to spot unexpected Tailwind class groups consuming a disproportionate share of bytes.

A subtle source of bloat is dynamically constructed class names that JIT detects as strings and includes even though they are never used at runtime. For example, building a class from a variable like 'text-' + color forces you to safelist many permutations. Prefer full class names in your markup instead.

If you have added a safelist in your config, periodically audit those entries. Safelist items are always included regardless of whether they appear in scanned content. Over time, safe-listed classes from old features accumulate, adding bytes to every production build even after the feature is removed.

Treat CSS output size as a tracked metric in your CI pipeline. After each build, log the gzip size to a file or a dashboard. When the size spikes unexpectedly between commits, bisect the recent changes to find the culprit. Many teams set a size budget and fail the build when it is exceeded.

Official Tailwind plugins like @tailwindcss/typography and @tailwindcss/forms add hundreds of rules when enabled. If you are not using Prose content or styled form elements, remove the plugin from your config. Every plugin you remove is a meaningful chunk of bytes saved from the final bundle.

Test your understanding of Tailwind CSS Mastery concepts from this lesson.

In this lesson you learned: measuring gzip size as the key production metric, auditing content paths to prevent over-scanning or under-scanning files, and removing unused plugins and safelist entries to keep the bundle lean. Next up we explore class sorting with the Prettier plugin.