Tailwind Memory Spike with Tauri with Vue with Vite in Dev Mode

[CyberNeo1337]

Tailwind v4 utilities causing extreme memory usage in Vite dev mode

Hello. Hope you are all doing well.
I'm seeing a reproducible memory issue with Tailwind CSS v4 when using Vite in development mode.

Environment:

• Tailwind CSS 4.x
• @tailwindcss/vite same version
• Vue + Vite
• Node 24.11.1
• pnpm 11.11.0

I isolated the issue to the utilities import:

@import "tailwindcss/theme.css";

works normally.

@import "tailwindcss/preflight.css";

works normally.

@import "tailwindcss/utilities.css";

causes memory usage to rapidly increase, reaching around 90% system memory or significant increase in memory usage.

This happens with pnpm dev when the application is opened in a normal browser, so it is not specific to Tauri.

pnpm tauri dev also exhibits the memory spike, while pnpm tauri build does not.

I also tested Tailwind 4.2.x and 4.3.3, with the same behavior.

I'm wondering whether this is a known issue with the Tailwind v4 Vite development pipeline/utilities generation.

[VivensB]

I think this is source detection rather than utilities generation, and the way you isolated it is the strongest clue.

If you look in node_modules/tailwindcss, theme.css is a static @theme block and preflight.css is a static reset. utilities.css is a single line, @tailwind utilities;, and that is the only layer generated from the candidates found by scanning your project. So "swapping that one import changes memory" points at the scan set being large, not at utility generation being slow.

Two minute check. Pin the sources explicitly and see if it goes away:

@import "tailwindcss" source(none);
@source "./src";

If memory returns to normal, it is automatic source detection, and the fix is to keep that or exclude whatever tree is being walked. If it does not change, then it is something else, and that is worth saying here too.

For a Tauri project specifically, check whether anything large sits outside your ignore rules. src-tauri/target is the obvious candidate. Auto detection honors .gitignore, and it honors it even with no .git directory present, so a tree not covered by an ignore rule gets walked.

Measurements. Minimal Vite plus Tailwind project with one large un-ignored directory (1500 files, about 22 MB). Tailwind 4.3.3, Vite 6.3.5, Node 22, Linux x64, peak RSS of vite build:

source config	large dir	peak RSS
@import "tailwindcss";	present	1212 MB
@import "tailwindcss";	absent	145 MB
source(none) + @source "./src"	present	137 MB

Same shape on 4.1.7 (1331 MB against 177 MB). Cold and warm Vite caches measured the same, 1331 and 1344 MB, so this is not dependency pre-bundling.

One thing I could not explain, in case it helps whoever picks this up. An explicit @source glob covering the exact same files costs about 189 MB, while automatic detection over those files costs about 1331 MB. So it is not file contents, not extensions (.d and .ts measured identically), and not recursion depth. It looks specific to automatic detection, but I did not isolate why.

The repro is small if it is useful, happy to post it.

[CyberNeo1337]

Progress update

I've done some additional testing to narrow down possibly where the memory increase is coming from.

Environment

• Tauri application
• Vue frontend
• Tailwind CSS 4.x
• WebKitGTK
• Tested both development and production builds

Findings so far

I first compared the Tauri application using normal CSS versus Tailwind CSS.

With normal CSS only, I do not observe the memory spike. I observed this by initiating another project where styling is fully css as i was having the tailwind memory spike issue

But one good news is that your suggestion to use the below

@import "tailwindcss" source(none);
@source "./src";

With Tailwind CSS and the above suggestion (yours @VivensB), I consistently see the behavior :

Initial memory:       ~58%
During/after startup: ~80%
After settling:       ~70%

So there is roughly a 20 percentage-point peak increase, followed by a gradual decrease of around 10% instead of a straight up memory crash and system crash.

The behavior is reproducible in both:

pnpm tauri dev

and the production application built with:

pnpm tauri build

Tailwind investigation

I narrowed the behavior down further to Tailwind's generated utilities.

I tested the source(none) configuration as suggested:

@import "tailwindcss" source(none);

@source "./";

with style.css located directly under:

src/style.css

At this point, the behavior appears to be related to the interaction between Tailwind-generated utility CSS and WebKitGTK, rather than Tailwind source scanning itself.

Current hypothesis

I'm currently investigating whether WebKitGTK is allocating a significant amount of temporary memory while parsing, resolving, laying out, or rendering the Tailwind-generated utility CSS.

I have not confirmed a memory leak yet, since the memory does partially decrease after the initial spike.

If you have faced any similar incidents, please let me know about it, or if any additional details are to be provided from my side,please let me know
.
Thank you.

[VivensB]

Before you chase WebKitGTK, please check one thing, because I think I sent you down a wrong path and the numbers above may not mean what they look like.

@source resolves relative to the CSS file, not the project root. Your stylesheet is at src/style.css, and I suggested @source "./src". From inside src/, that points at src/src, which does not exist. Measured on 4.3.3, with a stylesheet at src/probe.css and markup at src/app.html:

  CSS file at src/probe.css:
    @source "./src"    -> resolves to src/src      0 utilities
    @source "./"       -> resolves to src/         7 utilities
    @source "../src"   -> resolves to src/         7 utilities

  CSS file at project root:
    @source "./src"    -> resolves to src/         7 utilities

So with source(none) plus @source "./src" from src/style.css, Tailwind generates no utilities at all. The output is about 4.5 KB of preflight and theme and nothing else. If that is the configuration the "58 to 80 to 70" numbers came from, then the improvement is not source scanning being fixed, it is Tailwind having been switched off.

Quick way to tell which you measured: build, then grep the emitted CSS for a class you actually use.

grep -c '^\s*\.flex' dist/assets/*.css     # or any utility you know is in your markup

Zero means the source set is empty and the page is unstyled, which would also show visually.

You did mention trying @source "./" as well, and from src/style.css that one is correct, so if the spike persisted under that form, then the WebKitGTK line of inquiry stands and this note only rules out the other variant.

One thing that would separate the two cleanly, since you already have the comparison set up: build once with the working @source and once with plain @import "tailwindcss";, and compare the emitted CSS sizes rather than memory. If the sizes are close, source detection is not the variable and the difference you originally measured was somewhere else. If the auto-detected build is much larger, it is worth finding what is inflating the source set.

Sorry for the detour. The relative-path behaviour is easy to miss and I should have flagged it when I suggested the line.

[Pleo2]

The split imports provide a useful diagnostic, but the source directive must be attached to the utilities import and every explicit @source path is relative to the stylesheet.

For a stylesheet at src/style.css, a bounded test configuration is:

@layer theme, base, components, utilities;

@import "tailwindcss/theme.css" layer(theme);
@import "tailwindcss/preflight.css" layer(base);
@import "tailwindcss/utilities.css" layer(utilities) source(none);

@source "./";

Here ./ means the existing src/ directory. @source "./src" from that file means src/src, which can make memory look fixed simply because no application sources are being scanned.

I would compare three facts for each run:

1. Vite process RSS after the page is opened.
2. Emitted CSS byte size.
3. Presence of one known utility used by the application.

If source(none) plus the correct source path keeps the generated utilities intact and removes the spike, automatic detection or a watched tree is the variable. If memory still grows with the bounded source set, capture a heap snapshot and a minimal reproduction because the issue is then more likely in repeated dev invalidation than initial scanning.

Tailwind documents both the stylesheet-relative rule and source(none) here: https://tailwindcss.com/docs/detecting-classes-in-source-files#disabling-automatic-detection

Since this is a Tauri repository, also make sure generated directories such as src-tauri/target are excluded from automatic detection, or keep the explicit source set so those trees never become candidates.

[nhannm-vn]

1. Switch to @tailwindcss/postcss (Recommended)
   PostCSS handles memory cleanup much better in dev mode.

Install: pnpm add -D @tailwindcss/postcss postcss

Add to postcss.config.js:

export default {
plugins: {
'@tailwindcss/postcss': {},
},
}

Remove @tailwindcss/vite from vite.config.ts.

2. Limit scanning scope
   Add @source to your CSS to prevent scanning non-essential files:

@import "tailwindcss";
@source "../src/**/*.{vue,js,ts,jsx,tsx}";

[Dani-8]

@CyberNeo1337 Since you are using Vite + Tauri + WebKitGTK, this memory behavior is caused by a double-invalidation feedback loop between Vite's HMR file watcher and WebKitGTK's dev inspector.

Here is the exact breakdown of why this happens and how to permanently resolve it:

1. Root Cause: Vite Watcher + Tauri Target Directory
   • Tailwind v4's @tailwindcss/vite plugin hooks directly into Vite's module graph to perform dynamic source scanning.
   • In Tauri applications, Rust compilation outputs and temporary artifacts are generated inside src-tauri/target/. If src-tauri/ is not explicitly ignored in vite.config.ts, Vite's watcher attempts to re-index hundreds of compiled binary/intermediate files whenever WebKitGTK initializes or updates the dev webview.
   • This triggers massive memory spikes in Node.js/Vite RSS during dev mode, which settles slightly after garbage collection runs.

2. Permanent Fix (Vite Configuration)
   In your vite.config.ts, explicitly exclude the src-tauri build artifacts from Vite's watcher:

   import { defineConfig } from 'vite';
   import vue from '@vitejs/plugin-vue';
   import tailwindcss from '@tailwindcss/vite';

   export default defineConfig({
   plugins: [vue(), tailwindcss()],
   server: {
   watch: {
   ignored: ['/src-tauri/target/']
   }
   }
   });

3. Correct Relative @source Path in src/style.css
   Because @source paths resolve relative to the stylesheet location, ensure your src/style.css bounds the scanning to your frontend files without walking parent folders:

   @import "tailwindcss" source(none);
   @source "./**/*.{vue,js,ts,jsx,tsx,html}";

Applying the server.watch.ignored rule prevents Vite from feeding Tauri's Rust build artifacts into Tailwind's scanner, keeping memory usage stable during both pnpm tauri dev and normal browser testing.

[nisargpatel7042lva]

Why this happens

In a Tauri application, the Rust backend lives inside the src-tauri/ directory. During development builds, Cargo creates a massive target/ directory filled with tens of thousands of temporary object files, build artifacts, and caches.

By default, Tailwind v4's automatic source scanner and Vite's file watcher attempt to index the entire project workspace. Crawling through the heavy Cargo build directory consumes a huge amount of memory and causes severe dev-server memory spikes.

---

How to Fix

1. Pin your CSS source explicitly

Turn off automatic workspace scanning in Tailwind v4 and point it exclusively at your frontend source directory:

@import "tailwindcss" source(none);
@source "./src";

2. Exclude src-tauri in vite.config.ts

Prevent Vite's file watcher from inspecting the Tauri backend and Cargo cache:

import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';

export default defineConfig({
  plugins: [vue()],
  server: {
    watch: {
      ignored: ['**/src-tauri/**']
    }
  }
});

Restart your Vite dev server after updating the config, and memory usage will return to normal.