A Latência que Você Não Sabia que Estava Pagando

Cada milissegundo que seu servidor passa esperando um fetch terminar antes de iniciar outro é latência que chega ao usuário. Uma página que faz três chamadas de API sequenciais, cada uma levando 100ms, tem um atraso mínimo de 300ms entre servidor e navegador antes que um único byte de HTML seja enviado. A mesma página com as três chamadas em paralelo entrega seu primeiro byte em aproximadamente 100ms. Essa diferença não é teórica. É visível em uma conexão moderada, pronunciada em uma lenta, e se acumula em cada página da sua aplicação.

O SvelteKit é construído com paralelismo como padrão para seu modelo de execução de funções load. As funções load de layouts ao longo da hierarquia de rotas são executadas concorrentemente sempre que possível. O framework faz a coisa certa automaticamente, desde que você não introduza sequenciamento acidentalmente. As formas de introduzi-lo são específicas e reconhecíveis. Entendê-las faz a diferença entre uma aplicação rápida e uma que é silenciosamente lenta de maneiras que sua máquina de desenvolvimento jamais vai expor.

Este artigo aborda como a execução concorrente de load functions do SvelteKit funciona, o que é um waterfall de requisição e onde ele tende a se esconder, os mecanismos que criam sequenciamento não intencional incluindo a armadilha do await parent(), estratégias para preservar o paralelismo quando os dados do parent são genuinamente necessários, e um exemplo completo de dashboard paralelo demonstrando tudo isso.

O Que um Waterfall de Requisição Realmente Custa

Waterfalls de requisição são um dos problemas de performance mais comuns e menos visíveis em aplicações web. Um waterfall ocorre quando a requisição B não pode começar até que a requisição A tenha sido concluída, e a requisição C não pode começar até que B termine, e assim por diante. O tempo total é a soma de todas as durações das requisições, e não o máximo de qualquer uma individualmente.

Em um navegador, waterfalls geralmente são visíveis na aba de rede como uma cascata de requisições, cada uma iniciando somente após a anterior terminar. No servidor, dentro de uma função load, eles são invisíveis do lado de fora. O usuário vê uma página lenta. O desenvolvedor vê uma função load lenta. A causa raiz — três fetches sequenciais que poderiam ter sido paralelos — está enterrada em um código que parece razoável à primeira vista.

O desafio específico com o SvelteKit é que waterfalls podem existir em dois níveis distintos: dentro de uma única função load, e através da hierarquia de funções load. Uma página com um load de root layout, um load de section layout, e um load de page tem três contextos de execução separados. Se qualquer um deles cria uma dependência de outro que força a execução sequencial, a latência total se acumula ao longo da cadeia.

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

A diferença entre 350ms e 150ms é puramente arquitetural. As APIs não ficaram mais rápidas. A rede não melhorou. A única mudança é a estrutura de dependência entre as funções load.

Como o SvelteKit Executa Funções Load Concorrentemente

O SvelteKit inicia todas as funções load de uma determinada rota o mais cedo possível. Para uma rota como /dashboard, que pode envolver um load de root layout, um load de section layout do dashboard e o próprio load da página, o SvelteKit inicia os três simultaneamente quando uma requisição chega.

Nenhuma dessas funções load aguarda as outras por padrão. Elas são independentes. Cada uma faz suas próprias chamadas de API, e o SvelteKit mescla todos os valores de retorno em um único objeto data que o componente de página recebe.

Esse padrão é o que você deseja. O framework está trabalhando a seu favor desde que você não o substitua. Os mecanismos que o substituem são todas formas de dependência explícita ou implícita: uma função load expressando que precisa da saída de outra antes de poder prosseguir.

A única maneira de uma função load expressar uma dependência na saída de outra função load é através da função parent(). Chamar await parent() é o contrato explícito que diz: "Não posso prosseguir até que todos os meus loads de layout ancestrais tenham sido concluídos." Isso às vezes é necessário. O problema é quando é chamado desnecessariamente, ou chamado em um ponto da função onde bloqueia um trabalho que não precisava esperar.

Identificando um Waterfall

O diagnóstico mais simples para um waterfall é medir o tempo total de carregamento da página em relação ao que deveria ser teoricamente, dadas as durações individuais das chamadas de API. Se sua página faz três chamadas de API independentes, cada uma levando 80ms, e o tempo total no servidor é de 240ms, essas chamadas são sequenciais. Se o total gira em torno de 80ms, elas são paralelas.

Em desenvolvimento, o log detalhado do SvelteKit é a primeira ferramenta. Em produção, uma configuração de rastreamento distribuído anexada ao seu servidor permite ver os tempos individuais de fetch dentro de uma requisição. Sem rastreamento, adicionar timestamps manualmente dentro das suas funções load fornece os dados:

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

Se a saída do log se parecer com isto, as chamadas são sequenciais:

[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 inicia somente após o anterior ser concluído. O await antes de cada chamada fetch() é o culpado. A correção é uma questão de reestruturar para iniciar todos os fetches como Promises e então aguardá-los 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

Os três fetches são concluídos em poucos milissegundos um do outro porque foram executados em paralelo.

Fetches Sequenciais Dentro de uma Única Função Load

A forma mais direta de waterfall é aquela que você mesmo escreve: usar await antes de chamar o próximo fetch. Cada chamada await fetch(...) bloqueia a execução até que aquele fetch seja concluído. A próxima linha não é executada até que a primeira termine.

// 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 recebe um array de Promises e retorna uma única Promise que é resolvida quando todas elas forem resolvidas. O valor de resolução é um array dos valores individuais resolvidos, na mesma ordem do array de entrada. Se qualquer Promise rejeitar, Promise.all rejeita imediatamente com aquela razão de rejeição — todos os outros resultados são descartados, mesmo os que já foram resolvidos. Esse comportamento de falha rápida é a origem da crítica que você pode ter ouvido.

O Promise.all em dois estágios no exemplo preferido acima é deliberado. O primeiro estágio inicia os três fetches HTTP simultaneamente. O segundo estágio lê os corpos das respostas em paralelo. Ambos os estágios se beneficiam do paralelismo.

O padrão também torna a estrutura do código mais honesta sobre a intenção. Uma cadeia sequencial de await fetch implica que cada chamada depende da anterior. Uma chamada Promise.all torna a independência das operações explícita.

Promise.all vs Promise.allSettled

A crítica ao Promise.all é válida em um cenário específico: quando alguns dos fetches são não críticos e uma falha em um não deve descartar os resultados dos outros. Para esses casos, use Promise.allSettled em vez disso.

Promise.allSettled aguarda cada Promise independentemente do resultado e retorna um array de objetos de resultado, cada um com um status de "fulfilled" ou "rejected" e o value ou reason correspondente.

// 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 : []
	}
}

A regra prática:

Use Promise.all quando cada fetch do grupo é necessário para renderizar a página — uma falha deve produzir uma página de erro.
Use Promise.allSettled quando o grupo contém uma mistura de fetches críticos e opcionais — você quer dados parciais em vez de uma página de erro quando fetches não críticos falham.
Nunca use Promise.all puro em um fan-out (teamMembers.map(...)) onde falhas individuais de itens são esperadas e devem ser tratadas por item, não como um erro em nível de página.

Uma alternativa: retornar Promises não resolvidas (streaming)

Há uma segunda maneira de iniciar fetches em paralelo: retornar as Promises diretamente da função load sem aguardá-las. O SvelteKit aceita Promises não resolvidas no valor de retorno e transmite dados para o componente à medida que cada uma é resolvida.

// +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 os fetches são iniciados no momento em que o valor de retorno é avaliado. A função load retorna imediatamente. O HTML da página é enviado ao navegador antes que qualquer fetch seja concluído. O componente recebe as Promises e deve lidar com um estado pendente — tipicamente com {#await} - até que sejam resolvidas.

Use Promise.all (aguarde tudo) quando:

Os dados são necessários para renderizar a página de forma alguma — o título de um post, um nome de usuário, qualquer coisa que deixaria uma UI em branco ou quebrada se ausente na primeira renderização.
Você está em um +page.server.ts — funções load do servidor não suportam streaming; apenas loads universais +page.ts podem retornar Promises não resolvidas.
O componente não tem um estado de carregamento significativo para mostrar — um spinner para cada campo é uma UX pior do que uma curta espera por dados completos.

Use retornar Promises (streaming) quando:

Os dados são secundários ou não críticos — painéis de analytics, conteúdo relacionado, contagens de comentários — coisas que o usuário não precisa para começar a ler a página.
O conteúdo principal fica pronto rapidamente e os dados secundários são mais lentos; segurar a resposta pelo fetch lento atrasaria tudo desnecessariamente.
Você está disposto a escrever e manter os estados de carregamento {#await} no componente.

Na prática, Promise.all é o padrão correto para a maioria das funções load. Streaming é um progressive enhancement deliberado para dados específicos lentos e não críticos que, de outra forma, bloqueariam uma página que seria rápida. Recorrer ao streaming para evitar pensar sobre Promise.all é a motivação errada — ambos os padrões iniciam fetches em paralelo; a única diferença é quando o navegador recebe o HTML.

O padrão de streaming e o tratamento {#await} do lado do componente são abordados em detalhes em Streaming de Dados com Promises.

Quando fetches sequenciais são genuinamente necessários

Nem todos os fetches sequenciais são evitáveis. Quando a URL ou os parâmetros de um segundo fetch dependem do resultado do primeiro, a dependência é real e o sequenciamento é inevitável.

// 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 é um waterfall legítimo. Você não pode buscar o autor sem saber o ID do autor, e não pode saber o ID do autor sem buscar o post. A resposta correta é aceitar o custo sequencial e minimizar todo o resto. Se você precisar de dados independentes adicionais (digamos, posts relacionados e configuração do site), busque-os em paralelo com o segundo fetch, não depois dele:

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

O tempo total agora é post_fetch + max(author_fetch, related_fetch) em vez de post_fetch + author_fetch + related_fetch. A dependência genuína (post antes de author) é respeitada. O sequenciamento desnecessário (related após author) é eliminado.

A Armadilha do await parent() na Hierarquia de Load

Usando Dados do Parent em Funções Load aborda a mecânica, os diagramas de tempo e a correção para essa armadilha em profundidade. A versão resumida: chamar await parent() no topo de uma função load bloqueia cada fetch abaixo dele até que todos os loads de layout ancestrais sejam concluídos, mesmo que esses fetches não tenham dependência dos dados ancestrais. O tempo total da página se torna ancestor_duration + page_fetch_duration em vez de max(ancestor_duration, page_fetch_duration).

A correção: inicie seus fetches antes de aguardar o parent

Inicie cada fetch que não requer dados do parent antes de chamar await parent(). Quando parent() for resolvido, esses fetches provavelmente já estarão concluídos.

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

Quando parent() deve preceder o fetch

Quando uma URL de fetch depende de dados do parent — um ID de usuário, identificador de tenant ou token de acesso — a dependência é real e o sequenciamento é inevitável. Usando Dados do Parent em Funções Load aborda esse padrão em detalhes, incluindo como minimizar o custo paralelizando tudo que não compartilha a dependência assim que parent() for resolvido.

Padrões de Waterfall Através da Hierarquia de Layout

Funções load individuais não são o único lugar onde waterfalls aparecem. Um padrão comum é uma hierarquia de layout onde cada nível aguarda dados do parent antes de fazer seu próprio trabalho, criando uma cadeia que serializa cada load do root até a página.

Considere uma hierarquia de três níveis:

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

A linha do tempo de execução para esta hierarquia:

Waterfall across all three levels:

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

  Total: 200 + 90 + 110 = 400ms

A correção requer examinar cada nível e perguntar: esta função load realmente precisa dos dados do parent antes de iniciar seu próprio trabalho?

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

A linha do tempo de execução para a hierarquia corrigida:

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

O tempo total caiu de 400ms para 200ms. O gargalo agora é a única operação mais lenta, que é o resultado correto.

O principal aprendizado dessa comparação é que remover o parent() do layout da aplicação foi a mudança de maior valor. Aquele layout estava chamando await parent() no topo e depois não usava os dados do pai em seu fetch. Os dados do pai eram necessários apenas como repasse ao componente. Como o SvelteKit mescla automaticamente todas as saídas de load, o componente de página recebe siteConfig sem que o layout da aplicação precise fazer nada com isso.

Medindo o Grafo de Dependências

Ao depurar desempenho em uma hierarquia de layouts com múltiplos níveis, construir um modelo mental do grafo de dependências ajuda a identificar onde o paralelismo está sendo sacrificado. As regras são:

Uma função de load que não chama parent() é executada em paralelo com todas as outras funções de load para a mesma rota. Uma função de load que chama await parent() no topo é executada sequencialmente após todos os loads de layouts ancestrais. Uma função de load que chama await parent() após iniciar seus próprios fetches é executada de forma concorrente com os loads ancestrais, mas bloqueia a etapa de mesclagem até que parent() seja resolvido.

A etapa de mesclagem aguarda o último parent() ser resolvido e os dados do load da página estarem prontos. Neste grafo, esses são o mesmo evento em 200ms.

Promise.all para Fetches Independentes Dentro de um Load

O padrão Promise.all dentro de uma única função de load merece tratamento dedicado porque abrange mais casos do que o simples exemplo de "paralelizar três fetches". Qualquer grupo de operações que sejam independentes entre si e produzam resultados necessários antes do retorno deve ser combinado em um Promise.all.

Fetches paralelos em múltiplos estágios

Quando uma função de load busca múltiplas coleções e cada item nessas coleções requer um fetch de detalhe, os fetches internos podem ser paralelizados usando Promise.all mapeado sobre um 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 }
}

O tempo total para este padrão é teamList_fetch + max(all_member_activity_fetches) em vez de teamList_fetch + sum(all_member_activity_fetches). Para uma equipe de dez membros, cada um com um endpoint de atividade de 60ms, isso equivale a 60ms versus 600ms para o segundo estágio.

Este padrão tem uma consideração de escala: Promise.all com um array muito grande cria um grande número de requisições simultâneas contra a API downstream. Um array de 200 membros iniciaria 200 chamadas de fetch concorrentes. A maioria das APIs e serviços internos tem limites de taxa ou de pool de conexões que rejeitarão ou enfileirarão essa carga. Para coleções grandes, considere o uso de lotes: divida o array em grupos e use Promise.all dentro de cada grupo, sequenciando os 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 com fetches condicionais

Às vezes um fetch deve ocorrer apenas se uma condição for atendida. Combinar fetches condicionais com Promise.all requer cuidado para manter o alinhamento correto dos índices do 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) é uma Promise que resolve imediatamente para null. Ela pode ser colocada em um array de Promise.all junto com Promises de fetch reais sem afetar o tempo. O fetch ignorado não contribui com latência alguma. O alinhamento dos índices do array é mantido, portanto a atribuição por desestruturação permanece correta.

Exemplo Prático: Um Dashboard Paralelo

O exemplo completo a seguir demonstra todos os padrões deste artigo em um contexto realista. A rota do dashboard tem três níveis de função de load. Cada um é otimizado para paralelismo. Nenhum nível aguarda dados do pai que não necessite. O load da página adia sua chamada a parent() até que seus próprios fetches independentes estejam em andamento.

Definições 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
}

O layout raiz: configuração do site

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

O layout da seção app: navegação

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

O load da página do dashboard: usuário, posts e analytics em 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
	}
}

O componente do 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. -->

O componente do layout app

<!-- 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>

Linha do tempo de execução anotada para o 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

A economia aqui é substancial: 110ms versus 300ms. O caminho crítico é o fetch de configuração do site do layout raiz. Todo o restante é concluído antes ou junto com ele. Os três fetches do load da página são todos concluídos antes de parent() ser resolvido, portanto não adicionam latência adicional alguma.

Erros Comuns e Anti-Padrões

Chamar parent() no topo sem verificar se bloqueia 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
	}
}

Estágios sequenciais de Promise.all quando podem ser mesclados

// 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 é uma otimização menor, mas vale entender. A versão com dois Promise.all introduz uma pequena lacuna sequencial entre a chegada da resposta e o parse do corpo. Na prática, a diferença é negligenciável, mas a versão encadeada também é mais limpa e torna a intenção mais legível.

Chamar parent() apenas para repassar dados que os componentes já recebem

O SvelteKit mescla automaticamente todas as saídas das funções de load na prop data. Um layout não precisa chamar parent() e reretornar valores ancestrais para que os componentes downstream os acessem — o componente já os recebe. Chamar parent() para esse fim apenas cria uma dependência desnecessária na conclusão do load ancestral. A explicação completa e as alternativas estão em Usando Dados do Pai em Funções de Load: Quando NÃO Usar Este Padrão.

Considerações de Desempenho e Escala

Os ganhos obtidos com a eliminação de waterfalls escalam com o tráfego. Em um servidor com carga leve, um load sequencial de 200ms versus um load paralelo de 90ms representa uma melhoria de 110ms por usuário. Com 1000 requisições concorrentes, a versão paralela lida com as requisições com menor latência e mantém menos conexões abertas simultaneamente, pois cada conexão fica aberta por menos tempo. O throughput do servidor aumenta como consequência direta de durações de requisição mais curtas.

A relação entre paralelismo e carga nas APIs downstream merece consideração explícita. Paralelizar fetches dentro de uma função de load significa que as APIs downstream recebem requisições em rajada em vez de sequencialmente. Para um único usuário, isso é aceitável. Para uma página de alto tráfego onde a mesma função de load é executada milhares de vezes por segundo, cada instância paralelizando três fetches contra a mesma API downstream significa que aquela API recebe três vezes a taxa de requisições em comparação com uma versão sequencial. Certifique-se de que os serviços downstream estejam dimensionados para o tráfego em rajada proveniente de suas funções de load paralelas.

O uso de Promise.all para fetches mapeados sobre arrays (o exemplo de atividade dos membros da equipe) requer atenção especial. Buscar atividade para 50 membros da equipe envia 50 requisições simultâneas contra a API de atividade. Considere se a API de atividade foi projetada para esse padrão de acesso. Serviços internos projetados para acesso a um único registro nem sempre lidam bem com fan-out. Endpoints em lote, onde você envia uma lista de IDs e recebe uma lista de resultados, são preferíveis para este padrão quando o serviço downstream os suporta.

O Que Vem a Seguir

O próximo artigo desta série aborda exatamente esse framework de decisão: Reexecutando Funções de Load e Rastreamento de Dependências explica como o SvelteKit rastreia o que cada função de load acessou, quando decide reexecutar após a navegação, e como usar invalidate(), invalidateAll(), depends() e untrack() para manter os dados atualizados sem refetches desnecessários.

Veja Também

Usando Dados do Pai em Funções de Load — o artigo técnico sobre parent(): o que ele retorna, a diferença exata de escopo entre loads de servidor e universais, e o padrão fetch-first com análise detalhada de tempo
Transmitindo Dados com Promises — complementa este artigo abordando como adiar dados secundários por meio de Promises não resolvidas em vez de bloquear o HTML inicial neles
Fetch em Funções de Load — cobre os detalhes do wrapper fetch integrado do SvelteKit, incluindo como ele difere do fetch global e por que a distinção importa em funções de load do servidor
Documentação de Load do SvelteKit — referência oficial para funções de load, incluindo o modelo de execução concorrente e as regras de dependência que governam quando os loads são re-executados