Start: generated preloads should default to fetchpriority="low", with production before/after data

[quanglam2807]

TL;DR: Start fetches every generated route preload at High priority, where it competes with the stylesheet, font and LCP image, even on server-rendered pages that don't need that JS to paint. We shipped fetchpriority="low" on those preloads on two production sites. Mobile FCP dropped from 5.5–6.9 s to 3.1–3.5 s on every page we measured, and desktop FCP from 1.3–2.6 s to 0.6–0.8 s, with no measurable cost to hydration or click latency. React and Next.js already do this for their own bootstrap scripts. I think it should be Start's default: tracked in #8546, implemented in draft PR #8212.

Production before/after

webcatalog.io: Start 1.168, React 19.3, Vite 8, 71–79 preloads per page (about 445 KB of JS). The only change was fetchpriority="low" on the generated preloads. Lighthouse 13.5 medians:

Page	Form	Perf	FCP	Speed Index
/en/desktop	mobile	47 → 66	6.9 s → 3.5 s	6.9 s → 4.2 s
/en/desktop	desktop	71 → 90	2.6 s → 674 ms	2.6 s → 951 ms
/en/apps/ometv	mobile	35 → 67	6.8 s → 3.5 s	6.8 s → 4.2 s
/en/apps/ometv	desktop	66 → 83	2.6 s → 641 ms	2.7 s → 1.0 s
/en/apps/country/us	mobile	59 → 65	6.4 s → 3.5 s	6.4 s → 5.1 s
/en/apps/country/us	desktop	80 → 80	1.3 s → 633 ms	1.3 s → 924 ms

A second production site, lexibird.com (same stack, 43 preloads), with the same change, 5 runs each:

Page	Form	Perf	FCP	Speed Index
/en/desktop	mobile	61 → 67	5.5 s → 3.1 s	5.5 s → 4.7 s
/en/desktop	desktop	84 → 93	1.7 s → 817 ms	1.7 s → 929 ms

TBT, TTI and hydration are unchanged within noise on both sites, and neither site showed hydration errors in production.

Isn't this just Lighthouse?

No. Lighthouse's simulation does exaggerate priority effects (see @TiagoGranelli's explanation in #8212), so we also measured real Chrome under applied throttling, 5 interleaved runs:

	default (High)	fetchpriority="low"
Mobile FCP (= LCP)	4.44 s	2.87 s
Mobile hydrated	6.71 s	6.58 s
Mobile first successful menu click	7.23 s	7.03 s
Mobile slowest click (Event Timing)	96 ms	112 ms
Desktop FCP	660 ms	388 ms
Desktop hydrated	917 ms	933 ms

Hydration doesn't move: the connection is the bottleneck, so the last chunk arrives at the same time; low just lets CSS, font and images go first. Full methodology: #8212 (comment)

Why default, not opt-in

• Big win when preloads are large, near zero when they're small (the PR author's and Tiago's apps). We found no case where SSR-rendered content got slower.
• It's what the rest of the stack already does: React's bootstrap preloads are fetchPriority: 'low', and Next.js inherits that. Start is the outlier.
• An opt-in only reaches teams who already know to look. The cost is invisible in code and only shows up in field metrics.

Where it shouldn't apply

• ssr: false matches and SPA mode: the JS is the content, so keep today's priority. Start knows which matches were server-rendered, so the default can be scoped to them.
• Pages whose LCP element is rendered by client JS after hydration. We saw one: on a page where the LCP element is a client-fetched card, Lighthouse's simulated desktop LCP went from 2.9 s to 3.6 s, although observed LCP improved. That argues for an escape hatch (a HeadContent prop or transformAssets field), not against the default.
• Early Hints need to forward fetchPriority, or the HTML attribute arrives too late wherever hints are sent.

Try it today

useTags and Asset are exported from @tanstack/react-router, so you can render your own HeadContent that adds fetchPriority: 'low' to link[rel=modulepreload] tags. That's how the production numbers above were produced.

If you run a Start app, especially one with a large preload set, please share your before/after numbers, ideally field data (CrUX or RUM) for FCP, LCP and INP. And if you have a case where low makes things worse, that's exactly what's needed to get the default right.

Related: #8546 (issue), #8212 (draft PR), #6749, #8511.

Edited 2026-09-28: added lexibird.com as a second production site; added production before/after data, and changed the proposal from an opt-in to a default (scoped to server-rendered matches) with an escape hatch.