layout.server.ts called multiple times

[nevil2]

I have layout.server.ts set with prerender = true. It is collecting data from the headless CMS.

As I have components using this data, in layout.svelte I have setContext('layoutData', data) and in the components getContext('layoutData').

This is resulting in layout.server.ts collecting data from the CMS multiple times during build. How do I stop this?

[Maxaubert]

This is expected behaviour, not a bug: setContext/getContext has nothing to do with it, so that part of your setup is a red herring.

Why it happens: when you prerender, SvelteKit's crawler treats every page as its own isolated request. For each route it discovers, it builds a Request and calls the server's respond() function on it (see prerender.js), which runs the entire load chain for that URL, including every ancestor +layout.server.ts. There's no caching of load results between pages, so if you have 50 prerendered pages under that root layout, layout.server.ts's load runs 50 times, hitting your CMS 50 times.

This is consistent with how prerendering is documented to work: each prerendered route is generated by exercising your app as if it were a normal request (see the prerender docs).

The fix: cache the CMS call yourself at module scope in +layout.server.ts, so the actual fetch only happens once no matter how many pages get prerendered:

// src/routes/+layout.server.ts
let cache: Promise<LayoutData> | undefined;

export const load: LayoutServerLoad = () => {
	cache ??= fetchFromCms();
	return cache;
};

async function fetchFromCms() {
	// your existing CMS call
}

Caching the promise (not just the resolved value) matters if you ever raise config.prerender.concurrency above its default of 1, since it dedupes in-flight requests instead of firing off several separate CMS calls. All prerendered pages for a given build are visited from the same worker (see queue.js and the default concurrency: 1), so a module-level variable like this really is shared across every page during the build.

One caveat: only do this for data that's the same for everyone (which CMS content usually is). Don't use module-level caching like this for anything user-specific in a normal (non-prerendered) SSR route, since the module stays alive across real requests from different users on a live server and you'd leak data between them.