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 hace tres llamadas secuenciales a una API, cada una tardando 100ms, tiene un retraso mínimo de 300ms entre el servidor y el navegador 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 valor 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 siempre que sea posible. El framework hace lo correcto automáticamente, siempre que no introduzcas secuenciación accidentalmente. Las formas en que puedes introducirla son específicas y reconocibles. Comprenderlas marca la diferencia entre una aplicación rápida y una que es silenciosamente lenta de formas que tu máquina de desarrollo nunca expondrá.

Este artículo cubre cómo funciona la ejecución concurrente de load en SvelteKit, qué es un waterfall de solicitudes y dónde suele esconderse, los mecanismos que crean secuenciación no deseada 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 un Waterfall de Solicitudes

Los waterfalls de solicitudes son uno de los problemas de rendimiento más comunes y menos visibles en las aplicaciones web. Un waterfall ocurre cuando la solicitud B no puede comenzar hasta que la solicitud A haya completado, y la solicitud C no puede comenzar 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, los waterfalls son frecuentemente visibles en la pestaña de red como una cascada 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. Un 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 simple vista.

El desafío específico con SvelteKit es que los waterfalls 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 un layout raíz con load, un layout de sección con load y un load de página 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 brecha entre 350ms y 150ms es completamente arquitectural. 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 de una ruta dada lo antes posible. Para una ruta como /dashboard, que puede involucrar un load de layout raíz, un load de layout de sección de dashboard y el load de la página en sí, SvelteKit inicia los tres simultáneamente cuando llega una solicitud.

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

Este comportamiento predeterminado es el que deseas. El framework está trabajando 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 forma 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 todos mis loads de layouts ancestros hayan completado." Eso a veces es necesario. El problema es cuando se llama innecesariamente, o cuando se llama en un punto de la función donde bloquea trabajo que no necesitaba esperar.

Identificando un Waterfall

El diagnóstico más simple para un waterfall es medir el tiempo total de carga de la página contra lo que teóricamente debería ser dado las duraciones individuales de las llamadas a la API. Si tu página hace tres llamadas independientes a la API cada una tomando 80ms y el tiempo total del servidor es 240ms, esas llamadas son secuenciales. Si el total es aproximadamente 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, añadir 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 se ve 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. Solucionarlo 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 waterfall es la 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 resuelve cuando todas ellas han resuelto. El valor de resolución es un array de los valores resueltos individuales, en el mismo orden que el array de entrada. Si alguna Promise rechaza, Promise.all rechaza inmediatamente con ese motivo de rechazo — todos los demás resultados son descartados, incluso los que ya 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 respuesta 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 a 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 demás. Para esos casos, usa Promise.allSettled en su lugar.

Promise.allSettled espera por 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 — prefieres datos parciales en lugar de una página de error cuando los fetches no críticos fallan.
Nunca uses Promise.all sin procesar en un fan-out (teamMembers.map(...)) donde se esperan fallos individuales de ítems y deben manejarse por ítem, 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 resuelve.

// +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 de carga pendiente — típicamente con {#await} — hasta que resuelvan.

Usa Promise.all (espera todo) cuando:

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

Usa retornar Promises (streaming) cuando:

Los datos son secundarios o no críticos — paneles de análisis, 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 con {#await} en el componente.

En la práctica, Promise.all es el valor 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 con {#await} en el componente se tratan en detalle en Transmisión de Datos con Promises.

Cuándo 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 la secuenciación 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 }
}

Este es un waterfall legítimo. No puedes obtener el autor sin conocer el ID del autor, y no puedes conocer el ID del autor sin obtener el post. La respuesta correcta es aceptar el costo secuencial y minimizar todo lo demás. Si necesitas datos independientes adicionales (digamos, posts relacionados y configuración del sitio), obtén esos 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 (post antes que author) se respeta. La secuenciación innecesaria (related después de author) se elimina.

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

Usar 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 comienzo de una función load bloquea cada fetch que viene después hasta que todos los loads de layouts ancestros completen, incluso si esos fetches no tienen dependencia con 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() resuelva, es probable que esos fetches ya estén completos.

// 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
	}
}

Cuándo parent() debe preceder al fetch

Cuando la URL de un fetch depende de datos del padre — un ID de usuario, identificador de tenant o token de acceso — la dependencia es real y la secuenciación es inevitable. Usar 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() resuelve.

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

Las funciones load individuales no son el único lugar donde aparecen los waterfalls. Un patrón común es una jerarquía de layouts donde cada nivel espera datos del padre antes de hacer su propio trabajo, creando una cadena que serializa cada load 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() }
}

El cronograma 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 operación más lenta por sí sola, 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 usaba los datos del padre en su fetch en absoluto. Los datos del padre solo eran necesarios como paso intermedio 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 él.

Midiendo el Grafo de Dependencias

Al depurar el rendimiento en una jerarquía de layouts de múltiples 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 resuelve.

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 a los 200ms.

Promise.all para Fetches Independientes Dentro de un Load

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

Fetches paralelos de 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 arreglo:

// 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 arreglo muy grande crea una gran cantidad de solicitudes simultáneas contra la API de destino. Un arreglo 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 esta carga. Para colecciones grandes, considera usar lotes: divide el arreglo en grupos y usa 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)
)

Combinando Promise.all con fetches condicionales

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

// 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 arreglo 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 arreglo se mantiene, por lo que la asignación por desestructuración permanece correcta.

Ejemplo Práctico: Un Dashboard 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 app: 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 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 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 app layout

<!-- 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 al mismo tiempo que éste. Los tres fetches de la carga de página se completan antes de que parent() se resuelva, por lo que no agregan latencia adicional.

Errores Comunes y Anti-Patrones

Llamar a parent() al inicio sin verificar si bloquea 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 insignificante, 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 re-retornar valores ancestros para que los componentes descendientes 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 de los ancestros. 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 al eliminar las cascadas escalan con el tráfico. En un servidor con poca carga, una carga secuencial de 200ms versus una carga paralela de 90ms representa 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 rendimiento del servidor aumenta como consecuencia directa de duraciones de solicitud más cortas.

Vale la pena considerar explícitamente la relación entre el paralelismo y la carga en las APIs de destino. Paralelizar fetches dentro de una función load significa que las APIs de destino reciben solicitudes en ráfaga en lugar de secuencialmente. Para un solo usuario, esto está bien. Para una página de alto tráfico donde la misma función load se ejecuta miles de veces por segundo, cada instancia que paraleliza tres fetches contra la misma API de destino significa que esa API recibe el triple de la tasa de solicitudes comparada con una versión secuencial. Asegúrate de que los servicios de destino estén dimensionados para el tráfico en ráfaga de tus funciones load paralelas.

El uso de Promise.all para fetches mapeados sobre arreglos (el ejemplo de actividad de miembros del equipo) requiere especial atención. Obtener actividad para 50 miembros del equipo envía 50 solicitudes simultáneas contra la API de actividad. Considera si la API de actividad está diseñada para ese patrón de acceso. Los servicios internos diseñados para acceso de registro único no siempre manejan bien el fan-out. Los endpoints por lotes, donde envías una lista de IDs y recibes una lista de resultados, son preferibles para este patrón cuando el servicio de destino los soporta.

Próximos Pasos

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 la navegación, y cómo usar invalidate(), invalidateAll(), depends() y untrack() para mantener los datos actualizados sin refetching innecesario.

Ver también

Uso de datos padre en funciones Load — el artículo técnico sobre parent(): qué retorna, la diferencia exacta de alcance entre las cargas de servidor y universales, y el patrón fetch-first con análisis detallado de tiempos
Transmisión de datos con Promises — complementa este artículo al cubrir cómo diferir datos secundarios mediante Promises no resueltas en lugar de bloquear el HTML inicial por 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