La Latencia que No Sabías que Estabas Pagando

Cada milisegundo que tu servidor pasa esperando un fetch antes de iniciar otro es latencia que llega al usuario. Una página que realiza tres llamadas a APIs de forma secuencial, cada una tomando 100ms, tiene un retraso de servidor a navegador de mínimo 300ms antes de que se envíe un solo byte de HTML. La misma página con las tres llamadas en paralelo entrega su primer byte en aproximadamente 100ms. Esa diferencia no es teórica. Es visible en una conexión moderada, pronunciada en una lenta, y se acumula en cada página de tu aplicación.

SvelteKit está construido con el paralelismo como comportamiento predeterminado para su modelo de ejecución de funciones load. Las funciones load de los layouts a lo largo de la jerarquía de rutas se ejecutan de forma concurrente donde sea posible. El framework hace lo correcto automáticamente siempre que no introduzcas secuenciamiento accidentalmente. Las formas en que puedes introducirlo son específicas y reconocibles. Entenderlas marca la diferencia entre una aplicación rápida y una que es silenciosamente lenta de maneras que tu máquina de desarrollo nunca expondrá.

Este artículo cubre cómo funciona la ejecución concurrente de loads en SvelteKit, qué es una cascada de solicitudes y dónde suele ocultarse, los mecanismos que crean secuenciamiento no intencionado incluyendo la trampa de await parent(), estrategias para preservar el paralelismo cuando los datos del padre son genuinamente necesarios, y un ejemplo completo de dashboard paralelo que demuestra todo lo anterior.

El Costo Real de una Cascada de Solicitudes

Las cascadas de solicitudes son uno de los problemas de rendimiento más comunes y menos visibles en las aplicaciones web. Una cascada ocurre cuando la solicitud B no puede iniciarse hasta que la solicitud A haya completado, y la solicitud C no puede iniciarse hasta que B haya completado, y así sucesivamente. El tiempo total es la suma de todas las duraciones de las solicitudes en lugar del máximo de cualquier solicitud individual.

En un navegador, las cascadas son frecuentemente visibles en la pestaña de red como una serie de solicitudes donde cada una comienza solo después de que la anterior termina. En el servidor, dentro de una función load, son invisibles desde el exterior. El usuario ve una página lenta. El desarrollador ve una función load lenta. La causa raíz, tres fetches secuenciales que podrían haber sido paralelos, está enterrada en código que parece razonable a primera vista.

El desafío específico con SvelteKit es que las cascadas pueden existir en dos niveles distintos: dentro de una única función load, y a través de la jerarquía de funciones load. Una página con una carga de root layout, una carga de section layout y una carga de page tiene tres contextos de ejecución separados. Si alguno de ellos crea una dependencia con otro que fuerza la ejecución secuencial, la latencia total se acumula a lo largo de la cadena.

A waterfall in the load hierarchy:

  Root layout load         [===150ms===]
                                        |
  Section layout load                   [===120ms===]
                                                     |
  Page load                                          [===80ms===]

  Total time: 150 + 120 + 80 = 350ms

  With no dependencies (SvelteKit's default):

  Root layout load         [===150ms===]
  Section layout load      [====120ms====]
  Page load                [==80ms==]

  Total time: max(150, 120, 80) = 150ms

La diferencia entre 350ms y 150ms es completamente arquitectónica. Las APIs no se volvieron más rápidas. La red no mejoró. El único cambio es la estructura de dependencias entre las funciones load.

Cómo SvelteKit Ejecuta las Funciones Load de Forma Concurrente

SvelteKit inicia todas las funciones load para una ruta dada tan pronto como es posible. Para una ruta como /dashboard, que podría involucrar una carga de root layout, una carga de section layout del dashboard y la carga de la página en sí, SvelteKit inicia las tres simultáneamente cuando llega una solicitud.

Ninguna de estas funciones load espera a las otras por defecto. Son independientes. Cada una hace sus propias llamadas a APIs, y SvelteKit fusiona todos sus valores de retorno en el único objeto data que recibe el componente de la página.

Este comportamiento predeterminado es el que deseas. El framework trabaja para ti siempre que no lo anules. Los mecanismos que lo anulan son todas formas de dependencia explícita o implícita: una función load que expresa que necesita la salida de otra antes de poder continuar.

La única manera en que una función load puede expresar una dependencia en la salida de otra función load es a través de la función parent(). Llamar a await parent() es el contrato explícito que dice: "No puedo continuar hasta que todas mis cargas de layout ancestrales hayan completado". Eso a veces es necesario. El problema es cuando se llama innecesariamente, o se llama en un punto de la función donde bloquea trabajo que no necesitaba esperar.

Identificando una Cascada

El diagnóstico más simple para una cascada es medir el tiempo total de carga de la página contra lo que debería ser teóricamente dado las duraciones individuales de las llamadas a APIs. Si tu página hace tres llamadas a APIs independientes cada una tomando 80ms y el tiempo total del servidor es 240ms, esas llamadas son secuenciales. Si el total es alrededor de 80ms, son paralelas.

En desarrollo, el registro detallado de SvelteKit es la primera herramienta. En producción, una configuración de rastreo distribuido adjunta a tu servidor te permite ver los tiempos individuales de fetch dentro de una solicitud. Sin rastreo, agregar marcas de tiempo manualmente dentro de tus funciones load te proporciona los datos:

// src/routes/dashboard/+page.server.ts
// Temporary diagnostic instrumentation.

import type { PageServerLoad } from './$types'

export const load: PageServerLoad = async ({ locals, fetch }) => {
	const t0 = Date.now()
	console.log('[dashboard load] started')

	const userResponse = await fetch(`/api/users/${locals.user.id}`)
	console.log(`[dashboard load] user fetched at ${Date.now() - t0}ms`)

	const postsResponse = await fetch(`/api/users/${locals.user.id}/posts`)
	console.log(`[dashboard load] posts fetched at ${Date.now() - t0}ms`)

	const analyticsResponse = await fetch(`/api/users/${locals.user.id}/analytics?period=30d`)
	console.log(`[dashboard load] analytics fetched at ${Date.now() - t0}ms`)

	console.log(`[dashboard load] total: ${Date.now() - t0}ms`)

	return {
		user: await userResponse.json(),
		posts: await postsResponse.json(),
		analytics: await analyticsResponse.json()
	}
}

Si la salida del registro luce así, las llamadas son secuenciales:

[dashboard load] started
[dashboard load] user fetched at 87ms
[dashboard load] posts fetched at 174ms
[dashboard load] analytics fetched at 261ms
[dashboard load] total: 263ms

Cada fetch comienza solo después de que el anterior completa. El await antes de cada llamada fetch() es el culpable. Corregirlo es cuestión de reestructurar para iniciar todos los fetches como Promises y luego esperarlos juntos:

[dashboard load] started
[dashboard load] user fetched at 89ms
[dashboard load] posts fetched at 91ms
[dashboard load] analytics fetched at 94ms
[dashboard load] total: 96ms

Los tres fetches completan con pocos milisegundos de diferencia entre sí porque se ejecutaron en paralelo.

Fetches Secuenciales Dentro de una Única Función Load

La forma más directa de cascada es una que escribes tú mismo: usar await antes de llamar al siguiente fetch. Cada llamada await fetch(...) bloquea la ejecución hasta que ese fetch completa. La siguiente línea no se ejecuta hasta que la primera haya terminado.

// Avoid: three sequential fetches. Total time = sum of all three.
// Each fetch waits for the previous one to complete before starting.

export const load: PageServerLoad = async ({ locals, fetch }) => {
	const userResponse = await fetch(`/api/users/${locals.user.id}`)
	const user = await userResponse.json()

	const postsResponse = await fetch(`/api/users/${locals.user.id}/posts`)
	const posts = await postsResponse.json()

	const analyticsResponse = await fetch(`/api/users/${locals.user.id}/analytics?period=30d`)
	const analytics = await analyticsResponse.json()

	return { user, posts, analytics }
}

// Preferred: start all three fetches simultaneously with Promise.all.
// Total time = max of the three durations.

export const load: PageServerLoad = async ({ locals, fetch }) => {
	const [userResponse, postsResponse, analyticsResponse] = await Promise.all([
		fetch(`/api/users/${locals.user.id}`),
		fetch(`/api/users/${locals.user.id}/posts`),
		fetch(`/api/users/${locals.user.id}/analytics?period=30d`)
	])

	const [user, posts, analytics] = await Promise.all([
		userResponse.json(),
		postsResponse.json(),
		analyticsResponse.json()
	])

	return { user, posts, analytics }
}

Promise.all toma un array de Promises y retorna una única Promise que se resuelve cuando todas ellas se han resuelto. El valor de resolución es un array de los valores individuales resueltos, en el mismo orden que el array de entrada. Si alguna Promise rechaza, Promise.all rechaza inmediatamente con esa razón de rechazo — todos los demás resultados se descartan, incluso los que ya se resolvieron. Este comportamiento de fallo rápido es la fuente de la crítica que quizás hayas escuchado.

El Promise.all en dos etapas del ejemplo preferido anterior es deliberado. La primera etapa inicia los tres fetches HTTP simultáneamente. La segunda etapa lee los cuerpos de las respuestas en paralelo. Ambas etapas se benefician del paralelismo.

El patrón también hace que la estructura del código sea más honesta sobre la intención. Una cadena secuencial de await fetch implica que cada llamada depende de la anterior. Una llamada a Promise.all hace explícita la independencia de las operaciones.

Promise.all vs Promise.allSettled

La crítica de Promise.all es válida en un escenario específico: cuando algunos de los fetches no son críticos y un fallo en uno no debería descartar los resultados de los otros. Para esos casos, usa Promise.allSettled en su lugar.

Promise.allSettled espera a cada Promise independientemente del resultado y retorna un array de objetos de resultado, cada uno con un status de "fulfilled" o "rejected" y el correspondiente value o reason.

// Promise.all — use when ALL fetches are critical.
// One failure fails the entire load function.
export const load: PageServerLoad = async ({ locals, fetch }) => {
	const [user, account] = await Promise.all([
		fetch(`/api/users/${locals.user.id}`).then((r) => r.json()),
		fetch(`/api/users/${locals.user.id}/account`).then((r) => r.json())
	])
	// If either fetch fails, the load throws and SvelteKit renders +error.svelte.
	// Correct when you cannot render the page without both values.
	return { user, account }
}

// Promise.allSettled — use when some fetches are optional.
// One failure returns partial data, not an error page.
import { error } from '@sveltejs/kit'

export const load: PageServerLoad = async ({ locals, fetch }) => {
	const [userResult, analyticsResult, recommendationsResult] = await Promise.allSettled([
		fetch(`/api/users/${locals.user.id}`).then((r) => r.json()),
		fetch(`/api/users/${locals.user.id}/analytics`).then((r) => r.json()),
		fetch(`/api/recommendations`).then((r) => r.json())
	])

	// User is critical — propagate the error if it failed.
	if (userResult.status === 'rejected') {
		error(500, 'Failed to load user profile')
	}

	// Analytics and recommendations are optional — fall back to null/empty.
	return {
		user: userResult.value,
		analytics: analyticsResult.status === 'fulfilled' ? analyticsResult.value : null,
		recommendations: recommendationsResult.status === 'fulfilled' ? recommendationsResult.value : []
	}
}

La regla práctica:

Usa Promise.all cuando cada fetch del grupo es necesario para renderizar la página — un fallo debería producir una página de error.
Usa Promise.allSettled cuando el grupo contiene una mezcla de fetches críticos y opcionales — deseas datos parciales en lugar de una página de error cuando fallan los fetches no críticos.
Nunca uses Promise.all sin procesar en un fan-out (teamMembers.map(...)) donde se esperan fallos de elementos individuales y deben manejarse por elemento, no como un error a nivel de página.

Una alternativa: retornar Promises sin resolver (streaming)

Hay una segunda forma de iniciar fetches en paralelo: retornar las Promises directamente desde la función load sin esperarlas. SvelteKit acepta Promises sin resolver en el valor de retorno y transmite datos al componente a medida que cada una se establece.

// +page.ts — return unresolved Promises to stream data as it resolves.
export const load: PageLoad = async ({ fetch }) => {
	return {
		user: fetch('/api/user').then((r) => r.json()), // Promise — not awaited
		posts: fetch('/api/posts').then((r) => r.json()) // Promise — not awaited
	}
}

Ambos fetches comienzan en el momento en que se evalúa el valor de retorno. La función load retorna inmediatamente. El HTML de la página se envía al navegador antes de que cualquiera de los fetches complete. El componente recibe las Promises y debe manejar un estado pendiente — típicamente con {#await} — hasta que se resuelvan.

Usa Promise.all (espera todo) cuando:

Los datos son necesarios para renderizar la página en absoluto — un título de publicación, un nombre de usuario, cualquier cosa que dejaría una UI en blanco o rota si falta en el primer renderizado.
Estás en un +page.server.ts — las funciones load del servidor no admiten streaming; solo las cargas universales +page.ts pueden retornar Promises sin resolver.
El componente no tiene un estado de carga significativo para mostrar — un spinner para cada campo es peor UX que una breve espera por datos completos.

Usa el retorno de Promises (streaming) cuando:

Los datos son secundarios o no críticos — paneles de analíticas, contenido relacionado, conteos de comentarios — cosas que el usuario no necesita para comenzar a leer la página.
El contenido principal está listo rápidamente y los datos secundarios son más lentos; retener la respuesta por el fetch lento retrasaría todo innecesariamente.
Estás dispuesto a escribir y mantener los estados de carga {#await} en el componente.

En la práctica, Promise.all es el predeterminado correcto para la mayoría de las funciones load. El streaming es una mejora progresiva deliberada para datos lentos y no críticos específicos que de otro modo bloquearían una página que de otro modo sería rápida. Recurrir al streaming para evitar pensar en Promise.all es la motivación incorrecta — ambos patrones inician fetches en paralelo; la única diferencia es cuándo el navegador recibe el HTML.

El patrón de streaming y su manejo del lado del componente con {#await} se cubren en detalle en Streaming de Datos con Promises.

Cuando los fetches secuenciales son genuinamente necesarios

No todos los fetches secuenciales son evitables. Cuando la URL o los parámetros de un segundo fetch dependen del resultado del primero, la dependencia es real y el secuenciamiento es inevitable.

// This sequencing is necessary. The second fetch uses data from the first.
// No restructuring eliminates this dependency.

export const load: PageServerLoad = async ({ params, fetch }) => {
	// Fetch a post to get its author's ID.
	const postResponse = await fetch(`/api/posts/${params.slug}`)
	const post = await postResponse.json()

	// Fetch the author's full profile using the ID from the post.
	// This cannot start until the post is loaded.
	const authorResponse = await fetch(`/api/users/${post.authorId}/profile`)
	const author = await authorResponse.json()

	return { post, author }
}

Esta es una cascada legítima. No puedes obtener el autor sin conocer el ID del autor, y no puedes conocer el ID del autor sin obtener la publicación. La respuesta correcta es aceptar el costo secuencial y minimizar todo lo demás. Si necesitas datos independientes adicionales (digamos, publicaciones relacionadas y configuración del sitio), obtenlos en paralelo con el segundo fetch, no después de él:

// Minimize the waterfall cost by parallelizing independent work
// at each stage of the dependency chain.

export const load: PageServerLoad = async ({ params, fetch }) => {
	// Stage 1: Fetch the post. This must complete before stage 2 can start.
	const postResponse = await fetch(`/api/posts/${params.slug}`)
	const post = await postResponse.json()

	// Stage 2: Start everything that depends on the post in parallel.
	// These are independent of each other even though they depend on the post.
	const [authorResponse, relatedResponse] = await Promise.all([
		fetch(`/api/users/${post.authorId}/profile`),
		fetch(`/api/posts/${params.slug}/related?limit=3`)
	])

	const [author, related] = await Promise.all([
		authorResponse.json(),
		relatedResponse.ok ? relatedResponse.json() : Promise.resolve([])
	])

	return { post, author, related }
}

El tiempo total es ahora post_fetch + max(author_fetch, related_fetch) en lugar de post_fetch + author_fetch + related_fetch. La dependencia genuina (publicación antes de autor) se respeta. El secuenciamiento innecesario (relacionados después de autor) se elimina.

La Trampa de await parent() en la Jerarquía de Loads

Usando Datos del Padre en Funciones Load cubre la mecánica, los diagramas de tiempo y la solución para esta trampa en profundidad. La versión corta: llamar a await parent() al inicio de una función load bloquea cada fetch que le sigue hasta que todas las cargas de layout ancestrales completen, incluso si esos fetches no tienen dependencia en los datos del ancestro. El tiempo total de la página se convierte en ancestor_duration + page_fetch_duration en lugar de max(ancestor_duration, page_fetch_duration).

La solución: inicia tus fetches antes de esperar al padre

Inicia cada fetch que no requiera datos del padre antes de llamar a await parent(). Para cuando parent() se resuelva, es probable que esos fetches ya hayan completado.

// Avoid: parent() awaited at the top before any page-level work starts.
// The page load's fetches cannot begin until all ancestor loads complete.

export const load: PageServerLoad = async ({ params, parent, fetch }) => {
	const { user, siteConfig } = await parent()

	// These fetches are independent of parent data but are now blocked
	// behind the entire ancestor load chain.
	const postsResponse = await fetch(`/api/posts?tag=${params.tag}`)
	const statsResponse = await fetch('/api/stats/summary')

	return {
		posts: await postsResponse.json(),
		stats: await statsResponse.json(),
		siteName: siteConfig.siteName
	}
}

// Preferred: start independent fetches before awaiting parent().
// The page-level network work runs concurrently with ancestor loads.

export const load: PageServerLoad = async ({ params, parent, fetch }) => {
	// Start page-level fetches immediately. They do not depend on parent data.
	const postsPromise = fetch(`/api/posts?tag=${params.tag}`)
	const statsPromise = fetch('/api/stats/summary')

	// Await parent() while the fetches above are already in flight.
	// If ancestor loads are slow, the page-level fetches complete while waiting.
	const { siteConfig } = await parent()

	// Await both responses. If they completed while parent() was resolving,
	// these awaits resolve immediately at no additional cost.
	const [postsResponse, statsResponse] = await Promise.all([postsPromise, statsPromise])

	return {
		posts: postsResponse.ok ? await postsResponse.json() : [],
		stats: statsResponse.ok ? await statsResponse.json() : null,
		siteName: siteConfig.siteName
	}
}

Cuando parent() debe preceder al fetch

Cuando una URL de fetch depende de datos del padre — un ID de usuario, identificador de tenant o token de acceso — la dependencia es real y el secuenciamiento es inevitable. Usando Datos del Padre en Funciones Load cubre este patrón en detalle, incluyendo cómo minimizar el costo paralelizando todo lo que no comparte la dependencia una vez que parent() se resuelve.

Patrones de Cascada a Través de la Jerarquía de Layouts

Las funciones load individuales no son el único lugar donde aparecen las cascadas. Un patrón común es una jerarquía de layouts donde cada nivel espera los datos del padre antes de hacer su propio trabajo, creando una cadena que serializa cada carga desde la raíz hasta la página.

Considera una jerarquía de tres niveles:

// Avoid: the root layout loads slowly and everything chains behind it.

// src/routes/+layout.server.ts
export const load: LayoutServerLoad = async ({ fetch }) => {
	// Slow: 200ms
	const configResponse = await fetch('/api/site/config')
	return { siteConfig: await configResponse.json() }
}

// src/routes/app/+layout.server.ts
export const load: LayoutServerLoad = async ({ parent, fetch }) => {
	// Awaits root layout before doing anything.
	const { siteConfig } = await parent()

	// Does not use siteConfig at all in its fetch. But it waits anyway.
	const navResponse = await fetch('/api/navigation')
	return { navItems: await navResponse.json() }
}

// src/routes/app/dashboard/+page.server.ts
export const load: PageServerLoad = async ({ parent, fetch }) => {
	// Awaits the full hierarchy. By the time this starts its fetch,
	// the root and section layouts have both completed.
	const { siteConfig, navItems } = await parent()

	const dashResponse = await fetch('/api/dashboard/summary')
	return { dashboard: await dashResponse.json() }
}

La línea de tiempo de ejecución para esta jerarquía:

Waterfall across all three levels:

  Root layout (200ms)   [========200ms========]
  App layout (90ms)     waiting......[==90ms==]
  Page load (110ms)     waiting.............[===110ms===]

  Total: 200 + 90 + 110 = 400ms

La solución requiere examinar cada nivel y preguntarse: ¿esta función load realmente necesita los datos del padre antes de iniciar su propio trabajo?

// Preferred: each level starts its own work immediately.
// parent() is called only when the value is genuinely needed for a merge.

// src/routes/+layout.server.ts
export const load: LayoutServerLoad = async ({ fetch }) => {
	const configResponse = await fetch('/api/site/config')
	return { siteConfig: await configResponse.json() }
}

// src/routes/app/+layout.server.ts
export const load: LayoutServerLoad = async ({ fetch }) => {
	// This load does not need any root layout data to fetch navigation.
	// Do not call parent() at all. Navigation is independent.
	const navResponse = await fetch('/api/navigation')
	return { navItems: await navResponse.json() }
}

// src/routes/app/dashboard/+page.server.ts
export const load: PageServerLoad = async ({ parent, fetch }) => {
	// Start the dashboard fetch immediately.
	const dashPromise = fetch('/api/dashboard/summary')

	// Await parent only when needed for the return value.
	// parent() resolves when both ancestor loads are done.
	const { siteConfig } = await parent()

	const dashResponse = await dashPromise
	return {
		dashboard: dashResponse.ok ? await dashResponse.json() : null,
		analyticsKey: siteConfig.analyticsKey
	}
}

La línea de tiempo de ejecución para la jerarquía corregida:

Parallel execution with no unnecessary dependencies:

  Root layout (200ms)       [========200ms========]
  App layout (90ms)         [==90ms==]
  dashboard fetch (110ms)   [====110ms====]
  await parent()            .............. resolves at 200ms
  dashResponse.json()       resolves immediately (done at 110ms)

  Total: max(200, 90, 110) = 200ms

El tiempo total se redujo de 400ms a 200ms. El cuello de botella ahora es la única operación más lenta, que es el resultado correcto.

La conclusión clave de esta comparación es que eliminar parent() del layout de la aplicación fue el cambio de mayor valor. Ese layout llamaba a await parent() al inicio y luego no utilizaba los datos del padre en su fetch en absoluto. Los datos del padre solo eran necesarios como datos de paso hacia el componente. Dado que SvelteKit fusiona automáticamente todas las salidas de load, el componente de página recibe siteConfig sin que el layout de la aplicación tenga que hacer nada con ello.

Medir el Grafo de Dependencias

Al depurar el rendimiento en una jerarquía de layouts de varios niveles, construir un modelo mental del grafo de dependencias ayuda a identificar dónde se está sacrificando el paralelismo. Las reglas son:

Una función load que no llama a parent() se ejecuta en paralelo con todas las demás funciones load de la misma ruta. Una función load que llama a await parent() al inicio se ejecuta secuencialmente después de todas las cargas de layouts ancestros. Una función load que llama a await parent() después de iniciar sus propios fetches se ejecuta de forma concurrente con las cargas ancestras, pero bloquea el paso de fusión hasta que parent() se resuelva.

El paso de fusión espera a que el último parent() se resuelva y a que los datos propios de la carga de página estén listos. En este grafo, esos son el mismo evento en 200ms.

Promise.all para Fetches Independientes Dentro de un Load

El patrón Promise.all dentro de una única función load merece un tratamiento dedicado porque cubre más casos que el simple ejemplo de "paralelizar tres fetches". Cualquier grupo de operaciones que sean independientes entre sí y produzcan resultados que se necesiten antes de retornar deben combinarse en un Promise.all.

Fetches paralelos en múltiples etapas

Cuando una función load obtiene múltiples colecciones y cada elemento de esas colecciones requiere un fetch de detalle, los fetches internos pueden paralelizarse usando Promise.all mapeado sobre un array:

// src/routes/app/team/+page.server.ts

import type { PageServerLoad } from './$types'
import { error } from '@sveltejs/kit'

export const load: PageServerLoad = async ({ locals, fetch }) => {
	// Fetch the team member list first.
	const teamResponse = await fetch(`/api/teams/${locals.user.teamId}/members`)

	if (!teamResponse.ok) {
		error(500, 'Failed to load team members')
	}

	const teamMembers: Array<{ id: string; name: string }> = await teamResponse.json()

	// For each team member, fetch their activity summary in parallel.
	// Promise.all over an array of fetches is the idiomatic pattern.
	// All member activity fetches start simultaneously.
	const memberActivityPromises = teamMembers.map((member) =>
		fetch(`/api/users/${member.id}/activity/summary`)
			.then((r) => (r.ok ? r.json() : null))
			.catch(() => null)
	)

	const memberActivities = await Promise.all(memberActivityPromises)

	// Merge the activity data back onto each member.
	const enrichedMembers = teamMembers.map((member, index) => ({
		...member,
		activity: memberActivities[index]
	}))

	return { members: enrichedMembers }
}

El tiempo total para este patrón es teamList_fetch + max(all_member_activity_fetches) en lugar de teamList_fetch + sum(all_member_activity_fetches). Para un equipo de diez miembros, cada uno con un endpoint de actividad de 60ms, eso es 60ms versus 600ms para la segunda etapa.

Este patrón tiene una consideración de escalabilidad: Promise.all con un array muy grande crea una gran cantidad de solicitudes simultáneas contra la API downstream. Un array de 200 miembros iniciaría 200 llamadas fetch concurrentes. La mayoría de las APIs y servicios internos tienen límites de tasa o límites de pool de conexiones que rechazarán o pondrán en cola esa carga. Para colecciones grandes, considere hacer batching: divida el array en grupos y use Promise.all dentro de cada grupo, secuenciando los grupos.

// Batched parallel fetches for large collections.
// Prevents overwhelming downstream APIs with too many simultaneous requests.

async function fetchInBatches<T, R>(
	items: T[],
	batchSize: number,
	fetchFn: (item: T) => Promise<R>
): Promise<R[]> {
	const results: R[] = []

	for (let i = 0; i < items.length; i += batchSize) {
		const batch = items.slice(i, i + batchSize)
		const batchResults = await Promise.all(batch.map(fetchFn))
		results.push(...batchResults)
	}

	return results
}

// Usage in a load function with large collections.
const memberActivities = await fetchInBatches(
	teamMembers,
	10, // Process 10 members at a time
	(member) =>
		fetch(`/api/users/${member.id}/activity/summary`)
			.then((r) => (r.ok ? r.json() : null))
			.catch(() => null)
)

Combinar Promise.all con fetches condicionales

A veces un fetch solo debe realizarse si se cumple una condición. Combinar fetches condicionales con Promise.all requiere cuidado para mantener la alineación correcta de índices del array:

// src/routes/app/profile/+page.server.ts

import type { PageServerLoad } from './$types'

export const load: PageServerLoad = async ({ locals, url, fetch }) => {
	const showBilling = url.searchParams.get('tab') === 'billing'
	const showIntegrations = url.searchParams.get('tab') === 'integrations'

	// Build the array of Promises conditionally.
	// Use null as the resolved value for skipped fetches.
	const [profileResponse, billingResponse, integrationsResponse] = await Promise.all([
		fetch(`/api/users/${locals.user.id}/profile`),
		showBilling ? fetch(`/api/users/${locals.user.id}/billing`) : Promise.resolve(null),
		showIntegrations ? fetch(`/api/users/${locals.user.id}/integrations`) : Promise.resolve(null)
	])

	return {
		profile: profileResponse.ok ? await profileResponse.json() : null,
		billing: billingResponse && billingResponse.ok ? await billingResponse.json() : null,
		integrations:
			integrationsResponse && integrationsResponse.ok ? await integrationsResponse.json() : null
	}
}

Promise.resolve(null) es una Promise que se resuelve inmediatamente a null. Puede colocarse en un array de Promise.all junto a Promises de fetch reales sin afectar el tiempo. El fetch omitido no contribuye latencia. La alineación de índices del array se mantiene, por lo que la asignación por desestructuración sigue siendo correcta.

Ejemplo Práctico: Un Dashboard en Paralelo

El siguiente ejemplo completo demuestra todos los patrones de este artículo en un contexto realista. La ruta del dashboard tiene tres niveles de función load. Cada uno está optimizado para el paralelismo. Ningún nivel espera datos del padre que no necesita. La carga de la página difiere su llamada a parent() hasta después de que sus propios fetches independientes estén en curso.

Definiciones de tipos

// src/lib/types/dashboard.ts

export interface User {
	id: string
	name: string
	email: string
	plan: 'free' | 'pro' | 'enterprise'
	avatarUrl: string
}

export interface SiteConfig {
	siteName: string
	supportEmail: string
	analyticsKey: string
}

export interface Post {
	id: string
	title: string
	slug: string
	publishedAt: string
	viewCount: number
	status: 'draft' | 'published' | 'archived'
}

export interface AnalyticsSummary {
	period: string
	totalViews: number
	totalReads: number
	averageReadTime: number
	topPosts: Array<{ postId: string; title: string; views: number }>
}

export interface NavItem {
	label: string
	href: string
	icon: string
}

El layout raíz: configuración del sitio

// src/routes/+layout.server.ts
// Fetches site-wide configuration.
// No parent() call. Runs in parallel with everything else.

import type { LayoutServerLoad } from './$types'
import type { SiteConfig } from '$lib/types/dashboard'

export const load: LayoutServerLoad = async ({ fetch }) => {
	const response = await fetch('/api/site/config')

	const siteConfig: SiteConfig = response.ok
		? await response.json()
		: {
				siteName: 'The Hackpile Chronicles',
				supportEmail: 'support@hackpile.dev',
				analyticsKey: ''
			}

	return { siteConfig }
}

El layout de la sección de la aplicación: navegación

// src/routes/app/+layout.server.ts
// Fetches navigation items for the authenticated app shell.
// Validates the session via locals — no network call needed here.
// No parent() call. Runs in parallel with all other loads.

import type { LayoutServerLoad } from './$types'
import { redirect } from '@sveltejs/kit'
import type { NavItem } from '$lib/types/dashboard'

export const load: LayoutServerLoad = async ({ locals, fetch }) => {
	if (!locals.user) {
		redirect(303, '/login')
	}

	const response = await fetch('/api/navigation/app')

	const navItems: NavItem[] = response.ok ? await response.json() : []

	return { navItems }
}

La carga de la página del dashboard: usuario, posts y analíticas en paralelo

// src/routes/app/dashboard/+page.server.ts
// Loads the dashboard-specific data.
//
// Execution model:
//   - userPromise, postsPromise, analyticsPromise start at t=0
//   - parent() is awaited after the fetches are in flight
//   - parent() resolves when both ancestor layout loads complete
//   - The three fetch Promises likely resolve before or during parent()
//   - The page load's total time = max(ancestor loads, own fetch durations)

import type { PageServerLoad } from './$types'
import { error, redirect } from '@sveltejs/kit'
import type { User, Post, AnalyticsSummary } from '$lib/types/dashboard'

export const load: PageServerLoad = async ({ locals, parent, fetch }) => {
	if (!locals.user) {
		redirect(303, '/login?returnTo=/app/dashboard')
	}

	// Start all three dashboard fetches immediately.
	// None of them depend on parent() data.
	// All three are in flight before parent() is called.
	const userPromise = fetch(`/api/users/${locals.user.id}`)
	const postsPromise = fetch(`/api/users/${locals.user.id}/posts?status=published&limit=5`)
	const analyticsPromise = fetch(`/api/users/${locals.user.id}/analytics?period=30d`)

	// Await parent() while the three fetches are running.
	// This blocks here until both ancestor layout loads resolve.
	// The ancestor loads are running concurrently with the fetches above.
	const { siteConfig } = await parent()

	// Await all three fetch responses together.
	// If they completed while parent() was resolving, these await immediately.
	const [userResponse, postsResponse, analyticsResponse] = await Promise.all([
		userPromise,
		postsPromise,
		analyticsPromise
	])

	// User data is critical. If it fails, error() stops the load function.
	if (!userResponse.ok) {
		error(500, 'Failed to load user profile')
	}

	const user: User = await userResponse.json()

	// Posts and analytics are important but not critical.
	// Return empty fallbacks rather than erroring if they fail.
	const [posts, analytics]: [Post[], AnalyticsSummary | null] = await Promise.all([
		postsResponse.ok ? postsResponse.json() : Promise.resolve([]),
		analyticsResponse.ok ? analyticsResponse.json() : Promise.resolve(null)
	])

	return {
		user,
		posts,
		analytics,
		// analyticsKey from siteConfig is needed to initialise the
		// client-side analytics tracker in the component.
		analyticsKey: siteConfig.analyticsKey
	}
}

El componente del dashboard

<!-- src/routes/app/dashboard/+page.svelte -->

<script lang="ts">
	import type { PageProps } from './$types'

	let { data }: PageProps = $props()

	const publishedPostCount = $derived(data.posts.filter((p) => p.status === 'published').length)

	const topPost = $derived(data.analytics?.topPosts?.[0] ?? null)

	const formattedViews = $derived(
		data.analytics ? new Intl.NumberFormat('en-US').format(data.analytics.totalViews) : '—'
	)

	$effect(() => {
		if (data.analyticsKey) {
			;(window as Window & { __analyticsKey?: string }).__analyticsKey = data.analyticsKey
		}
	})
</script>

<div class="dashboard">
	<header class="dashboard-header">
		<img src={data.user.avatarUrl} alt={data.user.name} class="user-avatar" />
		<div class="user-info">
			<h1>Welcome back, {data.user.name}</h1>
			<p class="user-plan">{data.user.plan} plan</p>
		</div>
	</header>

	<div class="dashboard-grid">
		<section class="stat-card">
			<h2>Published Posts</h2>
			<p class="stat-value">{publishedPostCount}</p>
		</section>

		<section class="stat-card">
			<h2>Total Views (30d)</h2>
			<p class="stat-value">{formattedViews}</p>
		</section>

		{#if data.analytics}
			<section class="stat-card">
				<h2>Avg Read Time</h2>
				<p class="stat-value">{data.analytics.averageReadTime}s</p>
			</section>
		{/if}

		{#if topPost}
			<section class="stat-card highlight">
				<h2>Top Post (30d)</h2>
				<p class="stat-value truncate">{topPost.title}</p>
				<p class="stat-sub">{new Intl.NumberFormat('en-US').format(topPost.views)} views</p>
			</section>
		{/if}
	</div>

	<section class="recent-posts">
		<h2>Recent Posts</h2>
		{#if data.posts.length === 0}
			<p class="empty-state">No published posts yet.</p>
		{:else}
			<ul class="post-list">
				{#each data.posts as post (post.id)}
					<li class="post-item">
						<a href="/app/posts/{post.slug}" class="post-title">
							{post.title}
						</a>
						<span class="post-views">
							{new Intl.NumberFormat('en-US').format(post.viewCount)} views
						</span>
						<time datetime={post.publishedAt} class="post-date">
							{new Date(post.publishedAt).toLocaleDateString('en-US', {
								year: 'numeric',
								month: 'short',
								day: 'numeric'
							})}
						</time>
					</li>
				{/each}
			</ul>
		{/if}
	</section>
</div>

<!-- The analyticsKey is set on window via $effect in the script block above.
     This runs on the client after mount, using the value from siteConfig
     passed through parent() at the merge step. -->

El componente del layout de la aplicación

<!-- src/routes/app/+layout.svelte -->

<script lang="ts">
	import type { LayoutProps } from './$types'

	let { data, children }: LayoutProps = $props()
</script>

<div class="app-shell">
	<nav class="app-nav">
		<span class="app-nav-brand">{data.siteConfig.siteName}</span>

		<ul class="app-nav-links">
			{#each data.navItems as item (item.href)}
				<li>
					<a href={item.href} class="app-nav-link">
						{item.label}
					</a>
				</li>
			{/each}
		</ul>
	</nav>

	<main class="app-main">
		{@render children()}
	</main>
</div>

Línea de tiempo de ejecución anotada para el dashboard completo

Request arrives at GET /app/dashboard

t=0ms
  Root layout load starts:    fetch('/api/site/config')
  App layout load starts:     locals.user check passes, fetch('/api/navigation/app')
  Page load starts:           locals.user check passes
                              fetch('/api/users/123')           <- userPromise
                              fetch('/api/users/123/posts')     <- postsPromise
                              fetch('/api/users/123/analytics') <- analyticsPromise
                              await parent() called

t=70ms   analyticsPromise resolves (fastest fetch)
t=85ms   postsPromise resolves
t=90ms   navItems response resolves  ->  app layout load returns { navItems }
t=100ms  userPromise resolves
t=110ms  siteConfig response resolves  ->  root layout load returns { siteConfig }

t=110ms  parent() in page load resolves (both ancestor loads done)
         Promise.all([userPromise, postsPromise, analyticsPromise]) resolves immediately
         (all three were done before parent() resolved)
         user, posts, analytics parsed
         page load returns { user, posts, analytics, analyticsKey }

t=110ms  SvelteKit merges all three load outputs
         HTML rendered and sent to browser

Total server time: 110ms  (determined by root layout config fetch)
Without parallel optimization: 110 + 90 + max(100, 85, 70) = 300ms

El ahorro aquí es sustancial: 110ms versus 300ms. La ruta crítica es el fetch de configuración del sitio del layout raíz. Todo lo demás se completa antes o junto a él. Los tres fetches de la carga de página se completan todos antes de que parent() se resuelva, por lo que no añaden latencia adicional.

Errores Comunes y Anti-Patrones

Llamar a parent() al inicio sin verificar si bloquea los fetches

// Avoid: pattern where parent() is called at the top without examining
// whether any of the fetches below actually need its value.
export const load: PageServerLoad = async ({ params, parent, fetch }) => {
	const { user, siteConfig, navItems } = await parent()

	// Does this fetch actually use user, siteConfig, or navItems?
	// If not, it was unnecessarily blocked behind the ancestor chain.
	const response = await fetch(`/api/posts/${params.slug}`)
	return { post: await response.json() }
}

// Preferred: examine each fetch to determine if it truly depends on parent data.
// If none of the fetches need parent data, consider not calling parent() at all
// and relying on SvelteKit's automatic merge to provide ancestor data to the component.
export const load: PageServerLoad = async ({ params, parent, fetch }) => {
	// This fetch does not depend on parent data.
	const postPromise = fetch(`/api/posts/${params.slug}`)

	// If parent data is needed in the return value, await it after starting fetches.
	const { siteConfig } = await parent()

	const postResponse = await postPromise
	return {
		post: postResponse.ok ? await postResponse.json() : null,
		analyticsKey: siteConfig.analyticsKey
	}
}

Etapas secuenciales de Promise.all cuando pueden fusionarse

// Avoid: two separate Promise.all calls where one could serve both purposes.
// The response and the parsed body can be handled in a single chain.
export const load: PageServerLoad = async ({ locals, fetch }) => {
	const [userRes, postsRes] = await Promise.all([
		fetch(`/api/users/${locals.user.id}`),
		fetch(`/api/users/${locals.user.id}/posts`)
	])

	// This second Promise.all is necessary for the .json() calls,
	// but both .json() reads could have been chained onto the first Promise.all.
	const [user, posts] = await Promise.all([userRes.json(), postsRes.json()])

	return { user, posts }
}

// Preferred: chain the .json() parse directly into the fetch Promise.
// Both the HTTP request and the body parse run in parallel per resource,
// and the two resources run in parallel with each other.
// A single await covers both stages.
export const load: PageServerLoad = async ({ locals, fetch }) => {
	const [user, posts] = await Promise.all([
		fetch(`/api/users/${locals.user.id}`).then((r) => r.json()),
		fetch(`/api/users/${locals.user.id}/posts`).then((r) => (r.ok ? r.json() : []))
	])

	return { user, posts }
}

Esta es una optimización menor pero vale la pena entenderla. La versión con dos Promise.all introduce una pequeña brecha secuencial entre la llegada de la respuesta y el parseo del cuerpo. En la práctica la brecha es despreciable, pero la versión encadenada también es más limpia y hace que la intención sea más legible.

Llamar a parent() solo para reenviar datos que los componentes ya reciben

SvelteKit fusiona automáticamente todas las salidas de las funciones load en la prop data. Un layout no necesita llamar a parent() y devolver nuevamente los valores ancestros para que los componentes downstream puedan acceder a ellos — el componente ya los recibe. Llamar a parent() con este propósito solo crea una dependencia innecesaria en la finalización de la carga del ancestro. La explicación completa y las alternativas están en Using Parent Data in Load Functions: When NOT to Use This Pattern.

Consideraciones de Rendimiento y Escalabilidad

Las ganancias de eliminar waterfalls escalan con el tráfico. En un servidor con carga liviana, una carga secuencial de 200ms versus una carga paralela de 90ms es una mejora de 110ms por usuario. Con 1000 solicitudes concurrentes, la versión paralela maneja las solicitudes con menor latencia y mantiene menos conexiones abiertas simultáneamente, porque cada conexión se mantiene abierta por menos tiempo. El throughput del servidor aumenta como consecuencia directa de duraciones de solicitud más cortas.

La relación entre el paralelismo y la carga en la API downstream vale la pena considerarla explícitamente. Paralelizar fetches dentro de una función load significa que las APIs downstream reciben solicitudes en ráfaga en lugar de secuencialmente. Para un único usuario, esto es aceptable. Para una página de alto tráfico donde la misma función load se ejecuta miles de veces por segundo, cada instancia paralelizando tres fetches contra la misma API downstream significa que esa API recibe el triple de la tasa de solicitudes en comparación con una versión secuencial. Asegúrese de que los servicios downstream estén dimensionados para el tráfico en ráfaga de sus funciones load paralelas.

El uso de Promise.all para fetches mapeados sobre arrays (el ejemplo de actividad de miembros del equipo) requiere especial atención. Obtener la actividad de 50 miembros del equipo envía 50 solicitudes simultáneas contra la API de actividad. Considere si la API de actividad está diseñada para ese patrón de acceso. Los servicios internos diseñados para acceso a registros individuales no siempre manejan bien el fan-out. Los endpoints batch, donde se envía una lista de IDs y se recibe una lista de resultados, son preferibles para este patrón cuando el servicio downstream los soporta.

¿Qué sigue?

El siguiente artículo de esta serie cubre exactamente ese marco de decisión: Rerunning Load Functions and Dependency Tracking explica cómo SvelteKit rastrea a qué accedió cada función load, cuándo decide volver a ejecutarla después de una navegación, y cómo usar invalidate(), invalidateAll(), depends() y untrack() para mantener los datos actualizados sin refetches innecesarios.

Ver También

Usando Datos del Padre en Funciones Load — el artículo de mecánica sobre parent(): qué retorna, la diferencia de alcance exacta entre cargas de servidor y universales, y el patrón fetch-first con análisis detallado de tiempos
Transmisión de Datos con Promesas — complementa este artículo al cubrir cómo diferir datos secundarios mediante Promesas no resueltas en lugar de bloquear el HTML inicial con ellos
Fetch en Funciones Load — cubre los detalles del wrapper fetch integrado de SvelteKit, incluyendo en qué se diferencia del fetch global y por qué esa distinción importa en las funciones load de servidor
Documentación de Load de SvelteKit — referencia oficial para las funciones load, incluyendo el modelo de ejecución concurrente y las reglas de dependencia que determinan cuándo se vuelven a ejecutar las cargas