Extremely long time to first page interactivity in dev

[hermann-p]

Starting with deno task dev will, upon first request to the server, take multiple minutes until the page is shown and interactive. During that time, deno run --ext=js -A ... vite.js is constantly at 100% CPU usage on one processor core. After that is done, the app and hot reloading work mostly normal, but some changes (e.g. new routes) will restart that process.

The project was created with deno run -Ar jsr:@fresh/init. We then added the following modules:

• tailwindcss
• daisyui
• hono
• zod & zod-openapi

[bartlomieju]

Thanks for the report! I tried reproducing this on macOS but couldn't — with a fresh jsr:@fresh/init project plus daisyui, hono, zod, and @hono/zod-openapi added, the first request to / returns in ~1.6s on a cold start (no node_modules, no vite cache). Subsequent requests are instant, and I don't see the deno run --ext=js -A … vite.js subprocess pegged at 100% CPU.

To narrow this down, could you share:

1. OS and Deno version (deno --version). The "subprocess at 100% CPU for minutes" pattern often points at a platform-specific issue (e.g. Windows file watching).
2. Your deno.json — specifically the resolved versions of @fresh/core, @fresh/plugin-vite, vite, and tailwindcss.
3. Project size — roughly how many routes, islands, and static assets? Anything unusual like a large static/ tree or generated files?
4. A vite --debug log from deno task dev up through the first request. You can capture it with:

   DEBUG=vite:* deno task dev 2>&1 | tee vite-debug.log
   

   then make one request to / and attach the log (or the last ~200 lines from when the request comes in).
5. Does the slowness still happen if you remove daisyui, hono, zod, and zod-openapi one at a time to see which one triggers it? That would help isolate whether it's dep pre-bundling for a specific package.

If it's faster to share a repo that reproduces it, even better.

[hermann-p]

Thanks for your quick response. I can't share my repo for that, although I'm sure it would help.

OS and deno: I'm running on Fedora linux with a kernel of 7.0.9-105.fc43.x86_64

deno 2.7.12 (stable, release, x86_64-unknown-linux-gnu)
v8 14.7.173.7-rusty
typescript 5.9.2

deno.json I see there have been a few more deps added, but the problem started when the first few were installed.

deno.json

Details

{ "title": "", "description": "", "version": "0.0.1", "nodeModulesDir": "manual", "tasks": { "lint": "deno lint .", "lint:fix": "deno lint . --fix", "format": "deno fmt --check .", "format:fix": "deno fmt .", "check": "deno task lint && deno check && deno task format",

"dev": "vite",
"build": "vite build",
"create-system-info": "./scripts/create-system-info.sh",
"start": "deno run -A server.ts",
"update": "deno run -A -r jsr:@fresh/update .",

"test": "mkdir -p ./reports && deno test --env-file=.env-test --allow-all --doc --reporter=junit > ./reports/results.xml",
"test:pretty": "deno test --env-file=.env-test --allow-all --doc --reporter=pretty"

},
"lint": {
"rules": {
"tags": ["fresh", "recommended"]
}
},
"exclude": ["**/_fresh/*", "server.ts"],
"imports": {
"@/": "./",
"@std/dotenv": "jsr:@std/dotenv@^0.225.6",
"@std/path": "jsr:@std/path@^1.1.4",
"@tailwindcss/typography": "npm:@tailwindcss/typography@^0.5.19",
"daisyui": "npm:daisyui@^5.5.19",
"fresh": "jsr:@fresh/core@^2.3.3",
"preact": "npm:preact@^10.29.1",
"@preact/signals": "npm:@preact/signals@^2.9.0",
"@fresh/plugin-vite": "jsr:@fresh/plugin-vite@^1.1.2",
"vite": "npm:vite@^7.1.3",
"@types/babel__core": "npm:@types/babel__core@^7.20.5",
"tailwindcss": "npm:tailwindcss@^4.1.10",
"@tailwindcss/vite": "npm:@tailwindcss/vite@^4.1.12",
"@std/http": "jsr:@std/http@^1.1.0",

"@hono/swagger-ui": "npm:@hono/swagger-ui@^0.6.1",
"@hono/zod-openapi": "npm:@hono/zod-openapi@^1.2.2",
"@scalar/hono-api-reference": "npm:@scalar/hono-api-reference@^0.10.2",
"@std/assert": "jsr:@std/assert@^1.0.19",
"@std/cli": "jsr:@std/cli@^1.0.23",
"@std/expect": "jsr:@std/expect@^1.0.19",
"@std/fs": "jsr:@std/fs@^1.0.20",
"@std/io": "jsr:@std/io@^0.225.2",
"@std/jsonc": "jsr:@std/jsonc@^1.0.2",
"@std/testing": "jsr:@std/testing@^1.0.18",
"hono": "npm:hono@^4.12.5",
"jose": "npm:jose@^6.2.2",
"pino": "npm:pino@^10.3.1",
"stoker": "npm:stoker@^2.0.1",
"ts-pattern": "npm:ts-pattern@^5.9.0",
"zod": "npm:zod@^4.3.6"

},
"compilerOptions": {
"lib": ["dom", "dom.asynciterable", "dom.iterable", "deno.ns"],
"jsx": "precompile",
"jsxImportSource": "preact",
"jsxPrecompileSkipElements": [
"a",
"img",
"source",
"body",
"html",
"head",
"title",
"meta",
"script",
"link",
"style",
"base",
"noscript",
"template"
],
"types": ["vite/client"]
},
"fmt": {
"useTabs": false,
"lineWidth": 120,
"indentWidth": 2,
"semiColons": true,
"singleQuote": false,
"proseWrap": "preserve",
"exclude": ["static", "**/*results.xml", ".github"]
}
}


Project size The project was freshly created. It has one route page and three hono routes, no asset files are used except the styles.css.

vite log This is a log from start until the page became interactive (I dumped the whole ~6k lines). vite-debug-public.log

disabling dependencies This is a bit tricky, removing deps and still keeping the project able to start.
Simply creating a new project, copying over the deno.json and starting dev mode would still stay fast and snappy.
If there's nothing suspicious in the logs I will go over and try to remove dependencies one by one.

[hermann-p]

I worked through the log file and noticed that the whole dependency chain of the hono-app would get processed by vite's WASM compiler for every single request.

Thus I changed

import apiApp from './api/app.ts';
app.use(ctx => {
  const url = new URL(ctx.req.url)
  return url.pathname.startsWith('/api/') ?
    apiApp.fetch(ctx.req) :
    ctx.next()
})

to

const getApiApp = memoize((_: void) => import('./api/app.ts').then(m => m.default)
app.use(async ctx =>
  const url = new Url(ctx.req.url)
  return url.pathname.startsWith('/api/) ?
    (await getApiApp()).fetch(ctx.req) :
    ctx.next()
})

This would cache the import and vite's processing results, fixing the loading time.

Is there a more ideomatic solution?

I also noted that the .devenv/-directory (cache for nix devenv) would get included in the filewatcher, so I added that to the exclude directive in vite.config.ts just to be sure.

[bartlomieju]

Thanks for digging into the log — that's really useful.

I can explain the cold-start cost and have a guess about the per-request part, but I want to verify before pointing at a fix.

Why the first request is so slow. The Fresh vite plugin currently sets noExternal: true and optimizeDeps.noDiscovery: true for the SSR environment (packages/plugin-vite/src/mod.ts around the ssr config). That combination means:

• Every npm dependency reachable from a route — including hono, @hono/zod-openapi, zod, all of stoker, all of @scalar/hono-api-reference, etc. — is pulled through vite's SSR transform pipeline as raw source instead of being externalized to Deno's loader.
• Dep pre-bundling (esbuild) is disabled, so there's no cached bundle for that graph.

So on the first request that touches your api/app.ts, vite has to transform the entire hono + zod-openapi + scalar tree from source using the Deno-bundled esbuild-wasm. On a large openapi/scalar tree that genuinely can take minutes of single-core CPU. The settings exist for correctness reasons (the comments mention duplicate preact copies between npm:preact@* and the bare preact specifier), but the cost is real and I think we can do better here — at minimum by externalizing packages we know are safe (anything that doesn't touch preact).

The "every request" part is the surprising one. With a static top-level import apiApp from './api/app.ts', the SSR module cache should hold across requests and you should pay that cost once per dev session, not per request. Your memoize workaround pushing it into a dynamic import shouldn't change that — both end up in the same module graph.

A couple of things that could be invalidating the SSR module cache between requests:

1. File watcher false positives. You mentioned .devenv/ was being watched — was it also triggering reloads (look for [vite] page reload or hmr update lines in the log right before slow requests)? If so, that alone would explain per-request reprocessing, because any change invalidates downstream modules.
2. Something in the deno cache or node_modules dir (you have nodeModulesDir: "manual") getting touched and tripping the watcher.

Could you check the debug log for two specific things:

• Is there an hmr / page reload / file changed event between requests 1 and 2?
• After your memoize fix, does the second request to /api/... actually hit vite:resolve / vite:transform for hono files again, or is it quiet? (Grep for hono in the vite:transform lines around the second request.)

That'll tell us whether the per-request reprocessing is a watcher-invalidation bug (fixable in Fresh by tightening the ignore patterns / not watching .devenv etc.) or whether it's something inherent to how the SSR graph is being walked. The cold-start cost is a separate issue we should track regardless — noExternal: true is pretty aggressive and likely the bigger win to revisit.

For now, your dynamic-import + memoize is a reasonable workaround; there isn't a more idiomatic Fresh API for it yet.

[hermann-p]

Those are interesting insights.

I can't see any reload- or invalidating events between the first two requests.
The .devenv HMR events all show [no modules matched] - I think that's just noise.

You're right, there's no vite:transform for hono after the initial request either, so it's really just a cold start phenomenon, not per request (as confirmed due to the app working normally after first interactivity, including HMR).

I first feared I had just shifted the loading time into the background as the module build is now a promise inside the /api/-handler, but that's not happening either. It takes a tad longer, but only a few seconds as expected.