Percorsi dei contenuti e rimozione delle classi inutilizzate

Tailwind CSS generates utility classes for every combination of your theme values — potentially hundreds of thousands of classes. Without pruning, the raw CSS output would be several megabytes. The purging process (officially called content scanning or tree-shaking) removes every class that does not appear in your source files, shrinking the production CSS to typically just 5–50 KB. Getting your content configuration right is essential for a lean build.

Tailwind scans the files you list in the content array and searches for string patterns that look like Tailwind class names. It does not execute your code — it does a simple text search. Any string that matches a known utility class is included in the output. This is why you must never construct class names dynamically by concatenating strings; the scanner won't find the full class name.

Glob patterns in the content array use standard glob syntax. The double-star ** matches any number of directory levels. Curly braces {} match multiple extensions. Be as specific as possible — avoid patterns that are too broad (like ./**/*) as they will slow down scanning by including files like images and JSON that cannot contain class names.

Different frameworks organize their files differently. Here are the correct content patterns for the most popular setups. Next.js needs app/ and pages/ directories. Vue projects typically use .vue files. Laravel's Blade templates live in resources/views/. Always check that your entry files (like index.html or layout files) are included explicitly if they sit outside your glob patterns.

Sometimes classes are constructed at runtime and cannot be detected by static scanning — for example, class names built from CMS content, user input, or API responses. Use the safelist option to force-include specific classes or patterns, ensuring they are always in the output regardless of whether the scanner finds them. You can safelist individual strings or regex patterns.

The blocklist option is the opposite of safelist — it prevents specific classes from being included in the output even if the scanner finds them in your source. This is useful for enforcing team conventions (preventing use of deprecated utility names) or reducing output size by explicitly excluding utilities you know you will never use, like certain font size or animation classes.

For files that need preprocessing before scanning — like .pug templates, .md files, or custom template engines — Tailwind's content.transform option lets you provide a function that transforms the raw file content into a string of class names. This is rarely needed but powerful for edge cases where the file format hides class names in a non-obvious way.

If your project uses a third-party component library that ships pre-built JavaScript with embedded Tailwind classes, you need to include the library's dist files in your content array. Many popular Tailwind component libraries (like Flowbite, daisyUI, or custom internal libraries) work this way. Add the path to their built JavaScript output so the scanner can detect which classes they use.

To confirm that your content configuration is working correctly, run npx tailwindcss build and check the output file size. A well-configured production build should be under 50 KB (often much less). You can also run the Tailwind CLI with the --watch flag during development to see real-time compilation and verify that adding a new class immediately appears in the output.

Tailwind v3 uses a Just-In-Time (JIT) engine by default. Unlike the old PurgeCSS approach, JIT generates classes on demand as you write them, scanning your content files in real time during development. This means your development CSS is already small and matches production exactly — there is no separate purging step in v3. The content array serves both development scanning and production optimization.

The most common mistake is missing files from the content array — classes from those files get purged in production. Another mistake is dynamic class construction where the full class name never appears as a string. A third issue is forgetting template files in non-JS frameworks. Always test your production build locally with NODE_ENV=production to catch purging issues before deploying.

Test your understanding of Tailwind's content paths and class purging.

In this lesson you learned: the content array tells Tailwind which files to scan for class names, full class names must always appear as literal strings for the scanner to detect them, and the safelist option force-includes classes that cannot be statically detected. Next up we explore the difference between extending and overriding the Tailwind theme.