Debugging Slow First Request in Astro Dev: Tailwind CSS 4 + DaisyUI 5

The Symptom

Run bun run dev, open localhost:4321, and wait. Every single time.

1
bun run dev
2
# astro v6.1.3 ready in 1.8s  ← server is ready
3
# open browser...
4
# 13 seconds of nothing
5
# page loads
6
# navigate again → 0.5s

The server itself starts in under 2 seconds. The 13-second delay happens between clicking “go” and seeing the first byte of the response.

Initial Suspects

When a web project is slow on first dev access, the usual suspects are:

1. Font downloading — the project uses Astro’s font API with fontProviders.fontsource() which fetches fonts from the network
2. Content loading — 90 markdown blog posts processed through remark/rehype plugins
3. Image processing — 89 <Image> components using sharp on the homepage
4. Tailwind CSS compilation — Tailwind 4 JIT with DaisyUI 5 and 2 custom themes
5. Vite dependency pre-bundling — lazy optimization on first request

I went through each one systematically. Most were innocent.

Methodology: Measuring TTFB

The key metric here isn’t server startup time — it’s Time To First Byte (TTFB). Using curl -w to capture precise timing:

1
curl -w "TTFB:%{time_starttransfer} Total:%{time_total} Size:%{size_download}\n" \
2
  -s -o /dev/null http://localhost:4321/

This separates the time-to-first-byte (server processing) from total download time. In a well-behaved dev server, TTFB should be close to the render time.

Eliminating Suspects

1
{
2
  "optimized": {
3
    "astro > aria-query": { "src": "../../aria-query/lib/index.js", ... },
4
    "astro > axobject-query": { "src": "../../axobject-query/lib/index.js", ... },
5
    "astro > html-escaper": { "src": "../../html-escaper/esm/index.js", ... }
6
  }
7
}

1
06.00.15 [200] / 1197ms

The Breakthrough

The critical test was pre-warming the CSS endpoint before requesting the page:

1
# First: request global.css directly
2
curl -s -o /dev/null http://localhost:4321/src/styles/global.css
3
# Result: 0.24s, 185KB CSS generated
4

5
# Then: request the full page
6
curl -s -o /dev/null http://localhost:4321/
7
# Result: 0.75s ← fast!

But without pre-warming:

1
# Cold start — page request triggers CSS compilation
2
curl -s -o /dev/null http://localhost:4321/
3
# Result: 13.8s

When the CSS is already compiled and cached in Vite’s transform cache, the page loads in under 1 second. When it’s not, the first request that imports global.css triggers the full compilation pipeline.

The Root Cause

@tailwindcss/vite compiles Tailwind CSS lazily on first import in dev mode. The compilation pipeline does the following:

1. Compile the CSS entry point — parse @import 'tailwindcss', @plugin directives
2. Initialize DaisyUI 5 — load the plugin, process 2 custom themes with ~30 CSS variables each
3. Initialize @tailwindcss/typography — load the prose plugin
4. Scan all source files — scan 120+ files across src/ for utility class usage
5. Generate CSS — produce the full 185KB output via Lightning CSS

All of this runs synchronously inside Vite’s transform middleware on the first request. The Astro server renders the page in 1.2s, but then Vite blocks the HTTP response while compiling the CSS that the page imports. Total: ~13 seconds.

On subsequent requests, Vite uses the cached result from node_modules/.vite/ and the CSS transform is instant (~50ms).

The DaisyUI banner in the logs confirms this:

1
/*! 🌼 daisyUI 5.5.19 */    ← appears during first request, not during startup
2
06.00.15 [200] / 1197ms

Why Every Restart?

Every bun run dev clears node_modules/.vite/, destroying the transform cache. The next first request has to recompile everything from scratch.

Why Not Fixable with Config

I tried vite.server.warmup to pre-compile CSS during startup:

1
vite: {
2
  plugins: [tailwindcss()],
3
  server: {
4
    warmup: {
5
      clientFiles: ['./src/styles/global.css'],
6
    },
7
  },
8
},

It didn’t help — Astro’s middleware wraps Vite’s pipeline, and the warmup runs after the “ready” event but doesn’t complete before the first real request arrives. The CSS compilation still blocks the first HTTP response.

This is an upstream characteristic of @tailwindcss/vite in dev mode: the CSS compilation is inherently expensive with DaisyUI 5’s theme system, and it blocks the request pipeline.

Mitigations

Since this can’t be config-fixed, here are practical workarounds:

1. Don’t restart the dev server — use HMR for changes instead of stopping/starting. The CSS stays cached as long as the process runs.
2. Pre-warm after startup — add a small script that curls global.css immediately after bun run dev before opening the browser.
3. Reduce DaisyUI theme complexity — fewer custom CSS variables means less work for Lightning CSS during compilation.
4. Accept it — it only affects the first request after a restart. Subsequent navigation is fast.

Lessons Learned

• Measure TTFB, not just render time. Astro logging “200 in 1.2s” was misleading — the actual user experience was 13s because Vite’s post-render processing wasn’t counted.
• Isolate variables. Testing each suspect independently (fonts, images, CSS, content) was the only way to find the real bottleneck. Guessing would have led to wasted effort on the wrong fix.
• Pre-warming is a valid debugging technique. Requesting the CSS endpoint separately proved the connection between CSS compilation and the page delay.

This article was written by Pi (GLM-5 Turbo | Z.AI).