perf: navigation blocked on a chunk fetch because prefetch was off

[fas89]

Reported symptom: switching between pages feels slow. Confirmed, with a cause.

The cause

shouldPrefetch and shouldPreload both default to true in VuePress. This repo set both to false in the initial commit, in April, with no comment explaining why.

The cost is paid on every navigation. With prefetch off the built site carries zero <link rel="prefetch"> across 213 pages, so clicking a link blocks on fetching that page's chunk — a full network round trip before anything renders.

prefetch links in dist: 0
js chunks in assets/:   310

My first hypothesis was wrong and worth recording: I assumed it was disabled to stop Monaco being prefetched. git log -S shouldPrefetch shows it predates the playground entirely. There was never a reason.

Why turning it back on would have been worse

Of 19 MB of chunks, 12.4 MB is Monaco — the ts / css / html / json workers plus editor.api and vs — reachable only from /playground/. shouldPrefetch: true would prefetch all of it for every visitor, trading one problem for a worse one.

The fix

The documented function form, (file, type) => boolean: prefetch script chunks, skip the editor. 299 of the 310 chunks are under 100 KB and are exactly the route chunks that make navigation feel instant.

	before	after
prefetch links per page	0	214
Monaco chunks prefetched	—	0
prefetched weight	—	4.87 MB, cached after the first page

That is strictly less than the framework default, not more aggressive than it.

shouldPreload returns to true. Preload only covers files the current page needs, so the default is correct everywhere — including /playground/, where Monaco genuinely is required.

Verification

• Build green; 213 of 219 HTML files carry prefetch links (the 6 without are static reels/*.html assets, not VuePress pages)
• /playground/ still references its own chunk and not Monaco's in HTML; both worker bundles still exist for on-demand load
• Monaco exclusion checked by parsing every <link rel="prefetch"> href on a deep page: 0 matches against ts.worker, css.worker, html.worker, json.worker, editor.api, vs-

One honest limit

I could not reproduce the latency locally — served from localhost there is no round trip to pay. The mechanism is certain from the built HTML; the felt improvement needs a real network, which is where it was reported. Worth confirming once this deploys.

Considered and rejected

quicklink (viewport + idle) and instant.page (65 ms hover) both solve this well, but they add a runtime dependency to do what the framework already exposes natively — and neither can see chunk names, so neither could have excluded Monaco, which is the entire difficulty here.