Debugging astro dev performance problems | Astro Lounge | Page 1

meager kettle Apr 15, 2026, 12:24 PM

#

astro dev

[vite] connected.
14:23:54 [types] Generated 3ms
[vite] connected.
14:23:55 [content] Syncing content
14:23:55 [content] Synced content
astro v6.1.6 ready in 13979 ms
┃ Local http://localhost:4321/
┃ Network use --host to expose
14:23:55 watching for file changes...
/*! 🌼 daisyUI 5.5.19 */
14:24:59 [200] / 6070ms
14:24:59 [200] / 168ms

How to best debug that?

fossil zodiacBOT Apr 15, 2026, 12:24 PM

#

Hi @meager kettle. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

Looking at your output, there are two performance concerns:

Slow startup — ready in 13979 ms (~14 seconds)
Slow first page render — [200] / 6070ms on the first request (the second is fast at 168ms, likely cached)

Here are the debugging approaches supported by the available documentation:

1. Enable verbose logging

Run the dev server with the --verbose flag to get more detailed output about what Astro is doing during startup and rendering:

npx astro dev --verbose

This can help pinpoint where time is being spent. [--verbose flag]

2. Use `console.log()` to profile slow data fetching

If you have data fetching (e.g., fetch() calls or database queries) in your page frontmatter, add console.log() with timestamps around them. Output from Astro frontmatter appears in the terminal, not the browser:

---
const start = Date.now();
const data = await fetch('...');
console.log(`Fetch took ${Date.now() - start}ms`);
---

[Debugging with console.log()]

3. Use the Dev Toolbar's Audit app

While the dev server is running, the Audit app in the Astro dev toolbar automatically checks for common performance issues on the current page and highlights problematic elements directly in the browser. [Dev toolbar]

4. Analyze your bundle size

If the slowness is related to large JavaScript bundles, use rollup-plugin-visualizer to identify heavy modules:

// astro.config.mjs
import { visualizer } from "rollup-plugin-visualizer";

export default defineConfig({
  vite: {
    plugins: [visualizer({ emitFile: true, filename: "stats.html" })]
  }
});

#

Run npm run build and inspect the generated stats.html. [Analyze bundle size]

Note: The 6-second first render followed by a fast 168ms second render strongly suggests a slow server-side data fetch or computation on the first request (not a bundle issue). I'd focus on profiling your frontmatter data fetching first with `console.log()` timestamps.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@meager kettle Kapa.ai is still learning and improving, please let me know how I did by reacting below.

meager kettle Apr 15, 2026, 12:26 PM

#

Its all local on file (one request is 1k of yaml files) howevrer, this also happens on multiple starts after each other... How to debug this? Verbose output is very large (multiple Megabytes)

This happens on every start / restart even if no file is changed @fossil zodiac

#

Its all local on file (one request is 1k of yaml files) howevrer, this also happens on multiple starts after each other... How to debug this? Verbose output is very large (multiple Megabytes)

This happens on every start / restart even if no file is changed @fossil zodiac

fossil zodiacBOT Apr 15, 2026, 12:30 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

Based on the knowledge sources available, I can offer some targeted suggestions for your specific situation (slow startup/render from many local YAML files, reproducible on every start).

Content Layer Watcher

Since you're loading ~1,000 YAML files, this is almost certainly going through Astro's content layer. The content layer syncs on every start. If you're using a custom loader, you can check how the file watcher and sync logic behaves — the watcher in the loader context is what triggers re-syncs on file changes. [LoaderContext.watcher]

Experimental: Queued Rendering

If the slowness is during page rendering (the 6s request), you could try enabling the experimental queued rendering feature, which is described as more memory-efficient and performant, especially for large projects:

// astro.config.mjs
import { defineConfig } from "astro/config";

export default defineConfig({
  experimental: {
    queuedRendering: {
      enabled: true,
      contentCache: true // may help with large content collections
    }
  }
});

[Experimental queued rendering]

Streaming to Improve Render Time

If your page awaits data in the frontmatter, moving fetches into smaller components allows Astro to stream HTML progressively rather than blocking the entire page render. [Using streaming]

#

Honest limitation: The knowledge sources don't contain specific guidance for profiling content layer sync performance with large numbers of local files, or for filtering/summarizing verbose logs. For deeper investigation, I'd recommend checking the Astro Discord or filing an issue with a minimal reproduction, as the Astro team may have more targeted advice for this specific bottleneck. [Creating minimal reproductions]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@meager kettle Kapa.ai is still learning and improving, please let me know how I did by reacting below.

meager kettle Apr 15, 2026, 12:31 PM

#

@fossil zodiac

Why do I have so many reloads on first render?

📎 message.txt

fossil zodiacBOT Apr 15, 2026, 12:31 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

Looking at your terminal output from the conversation history:

[vite] connected.
[vite] connected.

You can see two "connected" messages, which suggests the dev server is restarting or reconnecting during startup. This is a known behavior when Astro's dev server restarts — for example, when astro.config.mjs is detected as changed or when the content layer finishes syncing and triggers a reload. [isRestart]

The astro dev server uses Hot Module Replacement (HMR) via Vite to update the browser as changes are detected. [astro dev] If the content layer sync (your ~1,000 YAML files) completes after the initial server start, it can trigger a reload, which would explain:

The double [vite] connected. — a reconnect after a reload
The slow first [200] / 6070ms — the page rendering after the reload, while content is still being processed or freshly loaded into memory

The knowledge sources don't contain more specific detail about why multiple HMR reloads occur during content sync with large file sets. For a deeper diagnosis of this specific behavior, I'd recommend asking on the Astro Discord, as this appears to be a content layer + large dataset interaction that isn't covered in detail in the available documentation.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@meager kettle Kapa.ai is still learning and improving, please let me know how I did by reacting below.

meager kettle Apr 15, 2026, 12:34 PM

#

@fossil zodiac

E:\astro-reisinger.pictures>npx astro dev --verbose 2> ../log.txt
[vite] connected.
14:33:39 [types] Generated 3ms
[vite] connected.
14:33:40 [content] Syncing content
14:33:40 [content] Synced content
astro v6.1.6 ready in 9706 ms
┃ Local http://localhost:4321/
┃ Network use --host to expose
14:33:40 watching for file changes...
/*! 🌼 daisyUI 5.5.19 */
14:33:53 [200] / 5898ms

Do you see anything in the verbose output?

📎 log.txt

fossil zodiacBOT Apr 15, 2026, 12:34 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

The user is asking me to analyze their verbose log output, but they've redirected the verbose output to a file (2> ../log.txt) and only shared the same standard terminal output we've already seen — not the actual verbose log contents. The --verbose flag output went to the log file, not to the terminal display shown here.

I can only see the same non-verbose output as before. Without the actual contents of ../log.txt, I can't analyze the verbose output.

A few observations from what is visible:

The double [vite] connected. is still present, confirming the reconnect behavior discussed earlier.
Startup is 9706ms (slightly faster than the previous 13979ms run).
First page render is still slow at 5898ms.
Content sync (Syncing content → Synced content) appears to complete quickly in the log, but the 13-second gap between server ready (14:33:40) and the first request (14:33:53) suggests you waited before opening the browser — the 5898ms is the actual render time.

To actually see the verbose output, you need to redirect stdout as well, not just stderr:

npx astro dev --verbose > ../log.txt 2>&1

Or to see it in the terminal while also saving it:

npx astro dev --verbose 2>&1 | tee ../log.txt

Once you have the actual verbose log contents, that would be the data needed to diagnose the bottleneck. The knowledge sources don't provide guidance on interpreting specific verbose log entries beyond what the `--verbose` flag enables. [`--verbose` flag]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@meager kettle Kapa.ai is still learning and improving, please let me know how I did by reacting below.

meager kettle Apr 15, 2026, 12:35 PM

#

@fossil zodiac : Here are the logs

📎 log.txt

fossil zodiacBOT Apr 15, 2026, 12:35 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

It looks like your message came through without the actual log file attached or pasted. Could you share the contents of the verbose log (either paste the text directly or attach the file)? Once I can see the actual verbose output, I can try to help identify what's taking so long during startup and the first page render.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@meager kettle Kapa.ai is still learning and improving, please let me know how I did by reacting below.

meager kettle Apr 15, 2026, 12:37 PM

#

@fossil zodiac : Can you see the 2MB large file? I fear not

Based on your verbose logs, the nearly 10-second startup delay is caused by massive file system overhead and slow module loading by Vite.

ROOT CAUSES:

Massive Image Resolution Overhead:
Vite is individually resolving hundreds of raw .jpg images in your src/content/einblicke/ directory (e.g., sport, beauty, events). Each resolve operation takes ~140-145ms, creating a massive disk I/O bottleneck.
Exceptionally Slow Module Loading:
- astro/dist/i18n/index.js: Took an abnormally long 5.17 seconds (5173ms) to load.
- Pre-bundled Vite chunk (chunk-TQTGZ74W.js): Took ~2.5 seconds (2501ms) at the end of the log.

RECOMMENDED FIXES:

Relocate Images:
If Astro doesn't need to process these images through Zod schemas or content collections, move large image galleries out of src/content/ to the public/ folder or an external CDN. This stops Vite from parsing them during startup and drastically cuts I/O overhead.
Check Antivirus/Disk Performance:
Since you are on Windows, the 5.17s load time for a single built-in file is a huge red flag. Check if Windows Defender or another antivirus is actively scanning and throttling Node.js file reads. You may need to add an exclusion for your project folder (E:\astro-reisinger.pictures).
Warm Up Vite Cache:
The 2.5s delay for dependency chunking happens when Vite discovers and caches new dependencies. Simply restarting the dev server (without modifying package.json) usually skips this step and speeds up subsequent starts.

fossil zodiacBOT Apr 15, 2026, 12:37 PM

#

Let me check the knowledge base for you again. One moment! :books:

#

You're right — I cannot see the attached file. Only the text of your message came through, not the 2MB log file.

The analysis you've pasted appears to have been generated by another tool or AI that had access to your verbose log. I'm not able to verify or validate those findings, as I don't have access to the log contents myself, and the knowledge sources available to me don't contain specific guidance on interpreting Vite verbose logs or diagnosing the specific issues mentioned (antivirus interference, i18n module load times, etc.).

What I can confirm from the knowledge sources:

The --verbose flag is intended to help debug issues like this. [--verbose flag]
Astro's asset caching stores processed images in ./node_modules/.astro by default. If images in src/content/ are being repeatedly processed, preserving this cache between builds/restarts can help. [Asset Caching]

For the specific diagnosis in your pasted analysis (Vite module resolution times, antivirus interference, Windows-specific I/O bottlenecks), I'd recommend bringing those findings directly to the Astro Discord `#support` channel, where the team can review your actual log file and provide authoritative guidance. [Need more?]

#Debugging astro dev performance problems

1. Enable verbose logging

2. Use console.log() to profile slow data fetching

3. Use the Dev Toolbar's Audit app

4. Analyze your bundle size

Note: The 6-second first render followed by a fast 168ms second render strongly suggests a slow server-side data fetch or computation on the first request (not a bundle issue). I'd focus on profiling your frontmatter data fetching first with console.log() timestamps.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

Content Layer Watcher

Experimental: Queued Rendering

Streaming to Improve Render Time

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

Once you have the actual verbose log contents, that would be the data needed to diagnose the bottleneck. The knowledge sources don't provide guidance on interpreting specific verbose log entries beyond what the --verbose flag enables. [--verbose flag]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

2. Use `console.log()` to profile slow data fetching

Note: The 6-second first render followed by a fast 168ms second render strongly suggests a slow server-side data fetch or computation on the first request (not a bundle issue). I'd focus on profiling your frontmatter data fetching first with `console.log()` timestamps.

Once you have the actual verbose log contents, that would be the data needed to diagnose the bottleneck. The knowledge sources don't provide guidance on interpreting specific verbose log entries beyond what the `--verbose` flag enables. [`--verbose` flag]