O Context Tem Custo de Desempenho?

Você aprendeu a usar context—fornecendo valores, consumindo-os, tornando-os reativos. Mas como o context realmente se comporta em termos de desempenho? Você deve se preocupar com o custo de providers profundamente aninhados? Centenas de consumidores de context vão deixar sua aplicação mais lenta?

Este artigo responde a essas perguntas de forma definitiva. Vamos examinar a implementação de context do Svelte, entender o que realmente aciona re-renders, aprender a identificar code smells arquiteturais que se disfarçam de problemas de desempenho, e desenvolver técnicas para fazer profiling de aplicações com uso intenso de context.

A resposta curta: context é essencialmente gratuito. A resposta mais longa revela por que a abordagem do Svelte difere fundamentalmente de outros frameworks, e como aproveitar essa diferença em aplicações de grande escala.

Context É Barato

Um dos melhores aspectos da API de context do Svelte: ela praticamente não tem overhead de desempenho. Ao contrário de alguns frameworks onde o context aciona re-renders em cascata, o context do Svelte é essencialmente gratuito.

Por Que o Context É Gratuito

O context no Svelte é apenas uma busca em um Map. Quando você chama getContext('key'), o Svelte:

Busca a chave no Map de context do componente atual
Se não encontrar, verifica o Map do pai
Continua subindo até encontrar ou chegar à raiz
Retorna o valor (ou undefined)

É só isso. Sem assinaturas. Sem observers. Sem diffing de Virtual DOM. Apenas uma simples travessia de Map que acontece uma única vez durante a inicialização do componente.

Performance Model:
══════════════════

setContext('key', value)
  └── Map.set('key', value)  ← O(1) operation

getContext('key')
  └── Walk up tree checking Maps  ← O(depth) but only at init
  └── Return value               ← O(1)

Cost: Essentially zero at runtime

O Que Realmente Causa Re-renders

O context em si não causa re-renders. Os valores dentro do context podem causar—mas é o estado reativo fazendo seu trabalho, não o overhead do context.

Os Gatilhos Reais de Re-render

<script>
	import { setContext } from 'svelte'

	let count = $state(0)

	setContext('counter', {
		get value() {
			return count
		} // Getter reads $state
	})
</script>

Quando você acessa counter.value no template ou efeito de um componente:

O Svelte rastreia que o componente depende de count
Quando count muda, o Svelte sabe que deve re-executar aquele bloco reativo específico
Apenas as partes que realmente leem count são re-renderizadas

Isso é reatividade de granularidade fina—o mesmo sistema que alimenta toda a reatividade do Svelte. O context é apenas o mecanismo de entrega.

O Que Não Causa Re-renders

<script>
	import { getContext } from 'svelte'

	const counter = getContext('counter')

	// This component captures the context reference once
	// It does NOT re-run when counter.value changes
	// unless we actually USE counter.value somewhere
</script>

<p>I don't read counter.value, so I never re-render</p>

Simplesmente obter o context não cria uma assinatura. Apenas a leitura de estado reativo (via getters que acessam $state) cria dependências.

A Vantagem da Granularidade

A reatividade do Svelte é no nível de propriedade, não no nível de objeto. Isso significa:

<script>
  const settings = getContext('settings');
  // settings = { theme: $state, locale: $state, debug: $state }
</script>

<!-- Only re-renders when theme changes -->
<div class={settings.theme}>

<!-- Only re-renders when locale changes -->
<p>{settings.locale}</p>

<!-- Never re-renders (debug not used in template) -->

Cada acesso a uma propriedade cria sua própria assinatura. Se locale mudar mas você usa apenas theme, seu componente não é re-renderizado.

No React, atualizar qualquer parte de um valor de context re-renderiza TODOS os consumidores. Soluções alternativas como useMemo e divisão de contexts são necessárias. A reatividade de granularidade fina do Svelte resolve isso por design.

Quando o Context Se Torna um Smell

Embora o context seja tecnicamente barato, usá-lo em excesso pode indicar problemas arquiteturais:

Smell 1: Muitas Chaves de Context

<script>
	setContext('user', user)
	setContext('userPreferences', preferences)
	setContext('userPermissions', permissions)
	setContext('userNotifications', notifications)
	setContext('userSettings', settings)
	setContext('userSubscription', subscription)
	// 🤔 This is getting out of hand
</script>

O que indica: Você está tratando o context como um depósito de dados em vez de projetar fronteiras de funcionalidade coesas.

Solução: Agrupe dados relacionados em um único context com uma API bem projetada:

<script>
	setContext('user', {
		get profile() {
			return user
		},
		get preferences() {
			return preferences
		},
		get permissions() {
			return permissions
		}
		// ... methods for mutations
	})
</script>

Smell 2: Context Substituindo Todas as Props

<!-- Every component reads from context instead of accepting props -->
<UserAvatar />
<!-- reads getContext('user').avatar -->
<UserName />
<!-- reads getContext('user').name -->
<UserBio />
<!-- reads getContext('user').bio -->

O que indica: Você tornou os componentes implicitamente dependentes do context, tornando-os mais difíceis de reutilizar e testar.

Solução: Use props para dependências explícitas, context para dados ambientais:

<!-- Props for direct data, context for ambient things like theme -->
<UserAvatar src={user.avatar} size="medium" />
<UserName name={user.name} />

Smell 3: Context para Tudo

<!-- Using context even for direct parent-child -->
<script>
	setContext('buttonColor', 'blue')
</script>

<Button /> <!-- reads context for color -->

O que indica: Você está usando context onde uma prop seria mais simples e explícita.

Solução: Props para relacionamentos diretos:

<Button color="blue" />

Smell 4: Providers Profundamente Aninhados

<AuthProvider>
	<ThemeProvider>
		<LocaleProvider>
			<FeatureFlagsProvider>
				<AnalyticsProvider>
					<NotificationsProvider>
						<ToastProvider>
							<ModalProvider>
								<App />
							</ModalProvider>
						</ToastProvider>
					</NotificationsProvider>
				</AnalyticsProvider>
			</FeatureFlagsProvider>
		</LocaleProvider>
	</ThemeProvider>
</AuthProvider>

O que indica: Cada provider é um conceito separado, o que é válido—mas o aninhamento é visualmente avassalador e sugere que você pode consolidá-los.

Solução: Considere um único componente AppProviders que define todos os contexts:

<!-- AppProviders.svelte -->
<script>
	import { setContext } from 'svelte'

	let { children } = $props()

	// Set up all app-level contexts
	setContext('auth', createAuthContext())
	setContext('theme', createThemeContext())
	setContext('locale', createLocaleContext())
	// ...
</script>

{@render children()}

Considerações de Memória

Os valores de context persistem durante o tempo de vida do componente provider. Entender as implicações de memória ajuda a evitar vazamentos sutis em aplicações de longa execução.

Context e Ciclos de Vida de Componentes

Quando um provider é desmontado, seu context se torna inacessível para novos consumidores. No entanto, quaisquer closures ou callbacks que capturaram valores de context continuam mantendo referências:

<!-- PotentialLeak.svelte -->
<script>
	import { getContext } from 'svelte'

	const data = getContext('largeDataset') // Captures reference

	$effect(() => {
		// This closure holds 'data' reference
		const handler = () => {
			console.log(data.items.length)
		}

		window.addEventListener('scroll', handler)

		// Always clean up to release references!
		return () => {
			window.removeEventListener('scroll', handler)
		}
	})
</script>

A função de limpeza é fundamental. Sem ela, data permanece referenciado mesmo após a desmontagem do componente, impedindo a coleta de lixo de objetos potencialmente grandes.

Objetos Grandes no Contexto

Para grandes conjuntos de dados, considere se o objeto inteiro precisa estar no contexto:

<script>
	import { setContext } from 'svelte'

	let { children } = $props()

	let allProducts = $state([
		/* thousands of items */
	])

	// ❌ Entire dataset exposed—every consumer holds reference to all data
	setContext('products-bad', {
		get all() {
			return allProducts
		}
	})

	// ✅ Provide access methods—consumers get only what they need
	setContext('products-good', {
		getById(id) {
			return allProducts.find((p) => p.id === id)
		},
		getPage(page, size = 20) {
			return allProducts.slice(page * size, (page + 1) * size)
		},
		get count() {
			return allProducts.length
		},
		search(query) {
			return allProducts.filter((p) => p.name.toLowerCase().includes(query.toLowerCase()))
		}
	})
</script>

{@render children()}

A segunda abordagem permite que os consumidores acessem o que precisam sem manter referências ao conjunto de dados inteiro. Isso se torna significativo com milhares de itens ou quando os consumidores montam e desmontam com frequência.

Detectando Problemas de Memória

Use a aba Memory do Chrome DevTools para identificar vazamentos relacionados ao contexto:

Tire um snapshot do heap antes de montar os componentes
Execute ações que montam/desmontam consumidores de contexto
Force a coleta de lixo (clique no ícone de lixeira)
Tire outro snapshot do heap
Compare os snapshots para encontrar objetos retidos

Procure por objetos que deveriam ter sido coletados pelo garbage collector, mas permanecem devido a referências de contexto em closures ou manipuladores de eventos.

Considerações de Performance no SSR

O contexto se comporta de forma diferente no servidor. Entender essas diferenças evita surpresas de performance em produção.

Isolamento de Contexto por Requisição

No servidor, cada requisição HTTP cria sua própria árvore de componentes com contexto isolado. Isso é essencial para a segurança dos dados — você não quer que os dados do Usuário A vazem para o Usuário B — mas tem implicações de performance:

<!-- +layout.svelte -->
<script>
	import { setContext } from 'svelte'

	let { data, children } = $props()

	// This runs for EVERY request on the server
	// Keep initialization fast!

	// ❌ Expensive computation on every request
	function createExpensiveContext() {
		const processed = heavyComputation(data.rawItems) // Runs per request!
		return {
			get items() {
				return processed
			}
		}
	}

	// ✅ Accept pre-computed data from load function
	function createEfficientContext() {
		return {
			get items() {
				return data.processedItems
			} // Already computed in load
		}
	}

	setContext('items', createEfficientContext())
</script>

{@render children()}

Mova computações custosas para as funções de carregamento +page.server.ts ou +layout.server.ts, onde os resultados podem ser cacheados.

Correspondência na Hidratação

Os valores de contexto devem produzir saída idêntica no servidor e no cliente durante a hidratação:

<script>
	import { setContext } from 'svelte'
	import { browser } from '$app/environment'

	let { data, children } = $props()

	// ❌ Different values cause hydration mismatch
	setContext('env-bad', {
		get timestamp() {
			return Date.now()
		}, // Different on server vs client!
		get isBrowser() {
			return browser
		} // false on server, true on client
	})

	// ✅ Stable values from load function
	setContext('env-good', {
		get timestamp() {
			return data.serverTimestamp
		}, // Same value
		get isBrowser() {
			return browser
		} // OK if not used during initial render
	})
</script>

{@render children()}

Incompatibilidades na hidratação fazem com que o cliente descarte o HTML do servidor e renderize novamente, anulando os benefícios de performance do SSR.

Contexto vs. Dados de Função de Carregamento

Às vezes você não precisa de contexto — as funções de carregamento do SvelteKit podem ser suficientes:

// +layout.server.ts
export const load = async ({ locals }) => {
	return {
		user: locals.user,
		theme: locals.preferences.theme
	}
}

<!-- +layout.svelte -->
<script>
	let { data, children } = $props()
	// data.user and data.theme available to all child routes
	// No context needed for simple data passing!
</script>

{@render children()}

Use contexto quando precisar de atualizações reativas ou métodos. Use dados de função de carregamento para informações estáticas por requisição.

Benchmarking de Performance do Contexto

Quando você precisa verificar que o contexto não é um gargalo, meça com precisão em vez de adivinhar.

Medindo o Tempo de Busca no Contexto

Buscas no contexto são operações de Map. Veja como quantificar o custo:

<script>
	import { getContext } from 'svelte'

	// Measure raw lookup cost (do this in a test, not production)
	if (import.meta.env.DEV) {
		const iterations = 10000

		console.time('context-lookups')
		for (let i = 0; i < iterations; i++) {
			getContext('app')
		}
		console.timeEnd('context-lookups')

		// Typical result: < 1ms for 10,000 lookups
		// If you see more, the issue is elsewhere
	}
</script>

Nota: Isso mede apenas o tempo de busca, não as atualizações reativas disparadas pela leitura dos valores de contexto.

Medindo a Frequência de Atualizações Reativas

Rastreie com que frequência os componentes re-renderizam devido a mudanças no contexto:

<script>
	import { getContext } from 'svelte'

	const data = getContext('data')
	let renderCount = $state(0)

	// Track renders in development
	$effect(() => {
		const _ = data.value // Access reactive property
		renderCount++

		if (import.meta.env.DEV) {
			console.log(`Component render #${renderCount}`)
		}
	})
</script>

<p>Render count: {renderCount}</p>

Se renderCount aumentar inesperadamente, investigue quais mudanças de propriedade do contexto estão disparando atualizações.

Usando APIs de Performance

Para medições precisas, use a API de Performance do navegador:

<script>
	import { getContext } from 'svelte'

	const ctx = getContext('heavy')

	function measureContextAccess() {
		performance.mark('ctx-start')
		const value = ctx.expensiveComputed
		performance.mark('ctx-end')
		performance.measure('context-access', 'ctx-start', 'ctx-end')

		const measure = performance.getEntriesByName('context-access')[0]
		console.log(`Context access took ${measure.duration.toFixed(3)}ms`)
		performance.clearMeasures('context-access')
		performance.clearMarks()
	}
</script>

<button onclick={measureContextAccess}>Measure</button>

Profiling com DevTools

Para uma análise de performance holística:

Abra o DevTools → aba Performance
Clique em Record
Interaja com seu app (dispare atualizações de contexto)
Pare a gravação
Examine o flame chart em busca de tarefas longas

Procure por:

Atualizações pequenas e frequentes (pode indicar contexto excessivamente reativo)
Atualizações únicas longas (pode indicar computações custosas em getters)
Atualizações inesperadas de componentes (pode indicar dependências reativas não intencionais)

Criando um Budget de Performance

Para aplicações grandes, estabeleça benchmarks:

// lib/performance/context-budget.ts
export const CONTEXT_BUDGETS = {
	lookupTime: 0.1, // ms per lookup
	updateBatch: 16, // ms for update cycle (60fps budget)
	maxConsumers: 100 // per context key
}

export function checkBudget(metric: string, value: number, budget: number) {
	if (value > budget) {
		console.warn(
			`Context performance budget exceeded: ${metric} = ${value}ms (budget: ${budget}ms)`
		)
	}
}

Integre verificações de budget ao seu fluxo de desenvolvimento para detectar regressões de performance cedo.

Dicas de Performance

Esses padrões abordam preocupações específicas de performance. Entender por que cada um importa ajuda você a aplicá-los adequadamente.

Dica 1: Evite Criar Objetos em Getters

Quando um getter retorna um objeto recém-criado, cada leitura cria uma nova referência. Isso tem duas consequências: alocação desnecessária de memória e possíveis problemas com verificações de igualdade por referência.

<script>
	import { setContext } from 'svelte'

	let userName = $state('Alice')
	let userEmail = $state('alice@example.com')

	// ❌ Creates a new object every time profile is accessed
	setContext('user-bad', {
		get profile() {
			return { name: userName, email: userEmail }
		}
	})

	// ✅ Return the reactive state directly
	let profile = $state({ name: 'Alice', email: 'alice@example.com' })
	setContext('user-good', {
		get profile() {
			return profile
		}
	})
</script>

No primeiro exemplo, chamar ctx.profile === ctx.profile retorna false porque cada acesso cria um novo objeto. Isso quebra a memoização, causa trabalho desnecessário em effects que comparam referências e gera lixo para o GC coletar.

O segundo exemplo retorna a mesma referência de objeto toda vez. Mutações em profile.name ou profile.email são rastreadas pelo sistema de reatividade do Svelte, e a igualdade por referência funciona conforme esperado.

Dica 2: Mantenha os Valores de Contexto Estáveis

O contexto é definido uma vez durante a inicialização do componente. Se você criar o objeto de contexto inline, funciona — mas entender o momento de inicialização ajuda a evitar bugs sutis.

<script>
	import { setContext } from 'svelte'

	let { children } = $props()

	// ❌ Works, but the object is created fresh each time this component mounts
	// If this component remounts frequently, you're creating many identical objects
	setContext('config', {
		apiUrl: '/api',
		timeout: 5000
	})

	// ✅ Stable reference - also clearer that this is static configuration
	const config = {
		apiUrl: '/api',
		timeout: 5000
	}
	setContext('config', config)
</script>

{@render children()}

Para configuração estática, a diferença é pequena. Mas extrair o objeto torna a intenção do código mais clara: essa configuração não muda. Também permite reutilização caso você precise referenciar config em outro lugar no componente.

Para constantes de nível de módulo que realmente nunca mudam, considere defini-las fora do componente completamente:

// lib/config.ts
export const APP_CONFIG = {
	apiUrl: '/api',
	timeout: 5000
} as const

Então importe e use diretamente — nenhum contexto é necessário para valores verdadeiramente estáticos.

Dica 3: Use $derived para Valores Computados

Valores computados devem ser calculados uma vez e armazenados em cache, não recalculados a cada acesso. A rune $derived lida com isso automaticamente.

<script>
	import { setContext } from 'svelte'

	let { children } = $props()

	let items = $state([])

	// ❌ Recalculates on every access
	setContext('cart-bad', {
		get items() {
			return items
		},
		get total() {
			return items.reduce((sum, i) => sum + i.price * i.quantity, 0)
		},
		get count() {
			return items.reduce((sum, i) => sum + i.quantity, 0)
		}
	})

	// ✅ Computed once via $derived, cached until items changes
	let total = $derived(items.reduce((sum, i) => sum + i.price * i.quantity, 0))
	let count = $derived(items.reduce((sum, i) => sum + i.quantity, 0))

	setContext('cart-good', {
		get items() {
			return items
		},
		get total() {
			return total
		},
		get count() {
			return count
		}
	})
</script>

{@render children()}

No primeiro exemplo, se cinco componentes leem cart.total, o reduce é executado cinco vezes. Se esses componentes renderizarem novamente, o reduce é executado novamente para cada um.

Com $derived, o reduce é executado uma vez quando items muda. Todas as leituras subsequentes retornam o valor em cache. Para arrays simples isso pode não importar, mas para computações custosas ou grandes conjuntos de dados, a diferença é significativa.

Dica 4: Não Coloque Tudo em Contexto

Nem tudo pertence ao contexto. Informações de estilo, em particular, possuem mecanismos de entrega melhores.

<script>
	import { setContext } from 'svelte'

	// ❌ Using context for styling values
	setContext('buttonPrimaryColor', '#3b82f6')
	setContext('buttonSecondaryColor', '#64748b')
	setContext('buttonBorderRadius', '0.375rem')
	setContext('buttonDisabledOpacity', 0.5)
</script>

Essa abordagem tem vários problemas:

Cada componente deve chamar getContext para acessar esses valores
Sem cascata CSS — você perde a herança natural do CSS
Sem suporte a DevTools — não é possível inspecionar ou modificar no navegador
Verboso — cada valor precisa de sua própria chave de contexto

As propriedades customizadas do CSS resolvem isso de forma elegante:

<script>
	let { children } = $props()
</script>

<div class="theme-wrapper">
	{@render children()}
</div>

<style>
	.theme-wrapper {
		--button-primary: #3b82f6;
		--button-secondary: #64748b;
		--button-radius: 0.375rem;
		--button-disabled-opacity: 0.5;
	}
</style>

Os componentes as utilizam via var(--button-primary). Os valores cascateiam naturalmente pelo DOM, podem ser inspecionados no DevTools e podem ser substituídos em qualquer nível sem JavaScript.

Use contexto para:

Estado reativo que muda em tempo de execução
Métodos e ações
Dados com escopo de funcionalidade (conteúdo do carrinho, estado de autenticação)
Configurações que afetam o comportamento, não a aparência

Use propriedades customizadas do CSS para:

Cores, espaçamento, tipografia
Temas visuais
Qualquer coisa puramente apresentacional

Dica 5: Agrupe Estados Relacionados

Quando múltiplos valores de estado sempre mudam juntos, considere se eles deveriam ser um único objeto.

<script>
	import { setContext } from 'svelte'

	let { children } = $props()

	// ❌ Separate state that always updates together
	let isLoading = $state(false)
	let error = $state(null)
	let data = $state(null)

	async function fetchData() {
		isLoading = true // Triggers reactive update
		error = null // Triggers another reactive update
		try {
			data = await fetch('/api/data').then((r) => r.json()) // Another update
		} catch (e) {
			error = e // Another update
		} finally {
			isLoading = false // Another update
		}
	}

	// ✅ Grouped state - single object mutation
	let state = $state({ isLoading: false, error: null, data: null })

	async function fetchDataBetter() {
		state.isLoading = true
		state.error = null
		try {
			state.data = await fetch('/api/data').then((r) => r.json())
		} catch (e) {
			state.error = e
		} finally {
			state.isLoading = false
		}
	}

	setContext('data', {
		get isLoading() {
			return state.isLoading
		},
		get error() {
			return state.error
		},
		get data() {
			return state.data
		},
		fetch: fetchDataBetter
	})
</script>

{@render children()}

O Svelte agrupa atualizações de estado síncronas, então a diferença prática é frequentemente mínima. No entanto, agrupar estados relacionados:

Esclarece a intenção — esses valores pertencem juntos conceitualmente
Simplifica o reset — state = { isLoading: false, error: null, data: null }
Permite atualizações atômicas — Object.assign(state, { isLoading: false, data: result })

A contrapartida: consumidores que precisam apenas de data também rastrearão mudanças em isLoading e error se acessarem o objeto pai. Com estado separado, cada propriedade é rastreada de forma independente. Escolha com base nos seus padrões de acesso.

Depurando Performance de Contexto

Se você suspeita de problemas de performance relacionados ao contexto, veja como investigar:

Verifique o Que Está Re-renderizando

<script>
	import { getContext } from 'svelte'

	const data = getContext('data')

	$effect(() => {
		console.log('Component re-rendered')
	})
</script>

Inspecione as Dependências de Contexto

<script>
	const ctx = getContext('app')

	// Log when specific properties are read
	$effect(() => {
		console.log('Theme accessed:', ctx.theme)
	})
</script>

Perfile com o DevTools do Navegador

Abra o DevTools → aba Performance
Grave enquanto interage com seu aplicativo
Procure por atualizações inesperadas de componentes
Rastreie qual mudança de estado as acionou

Principais Conclusões

Contexto é barato: Apenas uma busca em Map no momento da inicialização. Sem overhead em tempo de execução.
A reatividade causa re-renderizações, não o contexto: Ler $state por meio de getters cria assinaturas. O contexto é apenas o mecanismo de entrega.
Granular por design: Apenas os componentes que leem propriedades reativas específicas re-renderizam quando essas propriedades mudam.
Fique atento aos sinais de alerta: Muitos contextos, contexto substituindo props, ou providers muito aninhados indicam problemas de design — não problemas de performance.
Mantenha os valores estáveis: Evite criar novos objetos em getters. Use $derived para valores computados.
Ferramenta certa para o trabalho: Contexto para dados ambientes e limites de funcionalidade. Props para APIs explícitas de componentes. CSS para estilização.

Conclusão

A performance de contexto no Svelte é um não-problema por design. A API é um invólucro fino em torno de operações de Map que acontecem uma vez na inicialização do componente. A história real de performance diz respeito ao estado reativo — que funciona de forma idêntica independentemente de ser entregue por contexto, props ou acesso direto.

Essa clareza arquitetural tem implicações práticas. Você nunca precisa dividir contextos para evitar re-renderizações (a reatividade refinada do Svelte cuida disso). Você não precisa de wrappers de memoização ou padrões de seletores. Você pode aninhar providers sem penalidades de performance. O sistema simplesmente funciona.

As considerações genuínas de performance são arquiteturais, não mecânicas: manter os valores de contexto estáveis, evitar computações custosas em getters, compreender o ciclo de vida da memória em aplicações de longa duração e garantir compatibilidade com SSR/hidratação. Essas são decisões de design, não técnicas de otimização.

Quando você encontrar problemas de performance em uma aplicação com muito uso de contexto, a causa quase nunca é o próprio contexto. Procure, em vez disso, no estado reativo dentro do contexto, nas computações acionadas pelo acesso a esse estado ou na estrutura do componente que o consome. Perfile com medições reais, não suposições.

Próximos Passos

Entenda quando o contexto é a escolha certa em Context vs Other Patterns, comparando contexto com props, stores, eventos e funções de carregamento com um framework claro de decisão.

Veja Também

Documentação Oficial

Svelte Context — Guia oficial de contexto
$state — Rune de estado reativo
$derived — Valores computados