¿Tiene el Contexto un Costo de Rendimiento?

Ya aprendiste a usar el contexto—proporcionando valores, consumiéndolos y haciéndolos reactivos. Pero ¿cómo se desempeña realmente el contexto? ¿Deberías preocuparte por el costo de proveedores profundamente anidados? ¿Cientos de consumidores de contexto ralentizarán tu app?

Este artículo responde estas preguntas de forma definitiva. Examinaremos la implementación del contexto en Svelte, entenderemos qué desencadena realmente los re-renders, aprenderemos a identificar code smells arquitectónicos que se disfrazan de problemas de rendimiento, y desarrollaremos técnicas para perfilar aplicaciones con uso intensivo de contexto.

La respuesta corta: el contexto es esencialmente gratuito. La respuesta larga revela por qué el enfoque de Svelte difiere fundamentalmente de otros frameworks, y cómo aprovechar esa diferencia en aplicaciones a gran escala.

El Contexto Es Económico

Una de las mejores cosas de la API de contexto de Svelte: prácticamente no tiene sobrecarga de rendimiento. A diferencia de algunos frameworks donde el contexto desencadena re-renders en cascada, el contexto de Svelte es esencialmente gratuito.

Por Qué el Contexto Es Gratuito

El contexto en Svelte es simplemente una búsqueda en un Map. Cuando llamas a getContext('key'), Svelte:

Busca la clave en el Map de contexto del componente actual
Si no la encuentra, revisa el Map del padre
Continúa hacia arriba hasta encontrarla o llegar a la raíz
Retorna el valor (o undefined)

Eso es todo. Sin suscripciones. Sin observadores. Sin diffing del DOM virtual. Solo un simple recorrido del Map que ocurre una vez durante la inicialización del 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

Qué Provoca Realmente los Re-renders

El contexto en sí no provoca re-renders. Los valores dentro del contexto pueden hacerlo—pero eso es el estado reactivo haciendo su trabajo, no la sobrecarga del contexto.

Los Verdaderos Desencadenantes de Re-render

<script>
	import { setContext } from 'svelte'

	let count = $state(0)

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

Cuando accedes a counter.value en la plantilla o el efecto de un componente:

Svelte registra que el componente depende de count
Cuando count cambia, Svelte sabe que debe re-ejecutar ese bloque reactivo específico
Solo las partes que realmente leen count se re-renderizan

Esto es reactividad de grano fino—el mismo sistema que impulsa toda la reactividad de Svelte. El contexto es simplemente el mecanismo de entrega.

Qué No Provoca 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>

Simplemente obtener el contexto no crea una suscripción. Solo leer estado reactivo (a través de getters que acceden a $state) crea dependencias.

La Ventaja de la Granularidad

La reactividad de Svelte es a nivel de propiedad, no a nivel de objeto. Esto 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 acceso a una propiedad crea su propia suscripción. Si locale cambia pero solo usas theme, tu componente no se re-renderiza.

En React, actualizar cualquier parte de un valor de contexto re-renderiza TODOS los consumidores. Los workarounds como useMemo y dividir contextos son necesarios. La reactividad de grano fino de Svelte resuelve esto por diseño.

Cuándo el Contexto Se Convierte en un Smell

Si bien el contexto es técnicamente económico, usarlo en exceso puede indicar problemas arquitectónicos:

Smell 1: Demasiadas Claves de Contexto

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

Lo que indica: Estás tratando el contexto como un contenedor sin orden en lugar de diseñar límites de funcionalidades cohesivos.

Solución: Agrupa datos relacionados en un único contexto con una API bien diseñada:

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

Smell 2: El Contexto Reemplaza a Todos los 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 -->

Lo que indica: Has hecho que los componentes dependan implícitamente del contexto, lo que los hace más difíciles de reutilizar y probar.

Solución: Usa props para dependencias explícitas, contexto para datos ambientales:

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

Smell 3: Contexto para Todo

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

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

Lo que indica: Estás usando el contexto donde un prop sería más simple y explícito.

Solución: Props para relaciones directas:

<Button color="blue" />

Smell 4: Proveedores Profundamente Anidados

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

Lo que indica: Cada proveedor es un concepto separado, lo cual está bien—pero el anidamiento es visualmente abrumador y sugiere que podrías consolidarlos.

Solución: Considera un único componente AppProviders que establezca todos los contextos:

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

Consideraciones de Memoria

Los valores de contexto persisten durante el tiempo de vida de su componente proveedor. Comprender las implicaciones de memoria te ayuda a evitar fugas sutiles en aplicaciones de larga ejecución.

Contexto y Ciclos de Vida de Componentes

Cuando un proveedor se desmonta, su contexto se vuelve inaccesible para nuevos consumidores. Sin embargo, cualquier closure o callback que haya capturado valores de contexto continúa manteniendo referencias:

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

La función de limpieza es fundamental. Sin ella, data permanece referenciado incluso después de que el componente se desmonta, impidiendo la recolección de basura de objetos potencialmente grandes.

Objetos Grandes en Context

Para grandes conjuntos de datos, considera si el objeto completo necesita estar en context:

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

El segundo enfoque permite a los consumidores acceder a lo que necesitan sin mantener referencias al conjunto de datos completo. Esto se vuelve significativo con miles de elementos o cuando los consumidores se montan y desmontan con frecuencia.

Detectar Problemas de Memoria

Usa la pestaña Memory de Chrome DevTools para identificar fugas relacionadas con context:

Toma un snapshot del heap antes de montar los componentes
Realiza acciones que monten/desmonten consumidores de context
Fuerza la recolección de basura (haz clic en el ícono de la papelera)
Toma otro snapshot del heap
Compara los snapshots para encontrar objetos retenidos

Busca objetos que deberían haber sido recolectados por el GC pero permanecen debido a referencias de context en closures o manejadores de eventos.

Consideraciones de Rendimiento en SSR

El context se comporta de manera diferente en el servidor. Entender estas diferencias previene sorpresas de rendimiento en producción.

Aislamiento de Context por Solicitud

En el servidor, cada solicitud HTTP crea su propio árbol de componentes con context aislado. Esto es esencial para la seguridad de los datos —no quieres que los datos del Usuario A se filtren al Usuario B— pero tiene implicaciones de rendimiento:

<!-- +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()}

Mueve las computaciones costosas a las funciones load de +page.server.ts o +layout.server.ts, donde los resultados pueden ser cacheados.

Coincidencia en la Hidratación

Los valores de context deben producir una salida idéntica en el servidor y el cliente durante la hidratación:

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

Los desajustes de hidratación hacen que el cliente descarte el HTML del servidor y vuelva a renderizar, anulando los beneficios de rendimiento del SSR.

Context vs. Datos de Funciones Load

A veces no necesitas context en absoluto—las funciones load de SvelteKit pueden 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()}

Usa context cuando necesites actualizaciones reactivas o métodos. Usa datos de funciones load para información estática por solicitud.

Benchmarking del Rendimiento de Context

Cuando necesites verificar que context no es un cuello de botella, mide con precisión en lugar de adivinar.

Medir el Tiempo de Búsqueda en Context

Las búsquedas en context son operaciones de Map. Aquí te mostramos cómo cuantificar el costo:

<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: Esto solo mide el tiempo de búsqueda, no las actualizaciones reactivas desencadenadas por la lectura de valores de context.

Medir la Frecuencia de Actualizaciones Reactivas

Rastrea con qué frecuencia se re-renderizan los componentes debido a cambios en context:

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

Si renderCount aumenta de manera inesperada, investiga qué cambios en las propiedades de context están desencadenando las actualizaciones.

Usar las APIs de Performance

Para mediciones precisas, usa la Performance API del 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>

Perfilar con DevTools

Para un análisis de rendimiento holístico:

Abre DevTools → pestaña Performance
Haz clic en Record
Interactúa con tu aplicación (desencadena actualizaciones de context)
Detén la grabación
Examina el flame chart en busca de tareas largas

Busca:

Actualizaciones pequeñas y frecuentes (puede indicar un context con exceso de reactividad)
Actualizaciones largas y únicas (puede indicar computaciones costosas en getters)
Actualizaciones inesperadas de componentes (puede indicar dependencias reactivas no intencionales)

Crear un Presupuesto de Rendimiento

Para aplicaciones grandes, establece 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)`
		)
	}
}

Integra las verificaciones de presupuesto en tu flujo de trabajo de desarrollo para detectar regresiones de rendimiento de manera temprana.

Consejos de Rendimiento

Estos patrones abordan preocupaciones específicas de rendimiento. Entender por qué cada uno importa te ayuda a aplicarlos de manera apropiada.

Consejo 1: Evitar Crear Objetos en Getters

Cuando un getter retorna un objeto recién creado, cada lectura crea una nueva referencia. Esto tiene dos consecuencias: asignación de memoria innecesaria y posibles problemas con las verificaciones de igualdad por referencia.

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

En el primer ejemplo, llamar a ctx.profile === ctx.profile retorna false porque cada acceso crea un nuevo objeto. Esto rompe la memoización, causa trabajo innecesario en los effects que comparan referencias y genera basura para que el GC la recolecte.

El segundo ejemplo retorna la misma referencia de objeto cada vez. Las mutaciones a profile.name o profile.email son rastreadas por el sistema de reactividad de Svelte, y la igualdad por referencia funciona como se espera.

Consejo 2: Mantener los Valores de Context Estables

El context se establece una vez durante la inicialización del componente. Si creas el objeto de context de manera inline, funciona—pero entender el momento de inicialización ayuda a evitar bugs sutiles.

<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 configuración estática, la diferencia es menor. Pero extraer el objeto hace que la intención del código sea más clara: esta configuración no cambia. También permite su reutilización si necesitas referenciar config en otro lugar del componente.

Para constantes a nivel de módulo que verdaderamente nunca cambian, considera definirlas completamente fuera del componente:

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

Luego impórtalas y úsalas directamente—no se necesita context para valores verdaderamente estáticos.

Consejo 3: Usa `$derived` para Valores Calculados

Los valores calculados deben calcularse una vez y almacenarse en caché, no recalcularse en cada acceso. La runa $derived maneja esto automáticamente.

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

En el primer ejemplo, si cinco componentes leen cart.total, el reduce se ejecuta cinco veces. Si esos componentes se vuelven a renderizar, el reduce se ejecuta nuevamente para cada uno.

Con $derived, el reduce se ejecuta una vez cuando items cambia. Todas las lecturas posteriores devuelven el valor en caché. Para arreglos simples esto puede no importar, pero para cómputos costosos o conjuntos de datos grandes, la diferencia es significativa.

Consejo 4: No Abusar del Contexto

No todo pertenece al contexto. La información de estilos, en particular, tiene mejores mecanismos de entrega.

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

Este enfoque tiene varios problemas:

Cada componente debe llamar a getContext para acceder a estos valores
Sin cascada CSS — se pierde la herencia natural de CSS
Sin soporte de DevTools — no se puede inspeccionar ni modificar en el navegador
Verboso — cada valor necesita su propia clave de contexto

Las propiedades personalizadas de CSS resuelven esto de manera 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>

Los componentes las usan mediante var(--button-primary). Los valores se propagan naturalmente a través del DOM, pueden inspeccionarse en DevTools y pueden sobrescribirse en cualquier nivel sin JavaScript.

Usa el contexto para:

Estado reactivo que cambia en tiempo de ejecución
Métodos y acciones
Datos de alcance de funcionalidad (contenido del carrito, estado de autenticación)
Configuración que afecta el comportamiento, no la apariencia

Usa propiedades personalizadas de CSS para:

Colores, espaciado, tipografía
Temas visuales
Todo lo que sea puramente presentacional

Consejo 5: Agrupa el Estado Relacionado

Cuando múltiples valores de estado siempre cambian juntos, considera si deberían ser un ú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()}

Svelte agrupa las actualizaciones de estado síncronas, por lo que la diferencia práctica suele ser mínima. Sin embargo, agrupar el estado relacionado:

Clarifica la intención — estos valores pertenecen juntos conceptualmente
Simplifica el reinicio — state = { isLoading: false, error: null, data: null }
Habilita actualizaciones atómicas — Object.assign(state, { isLoading: false, data: result })

La compensación: los consumidores que solo necesitan data también rastrearán los cambios en isLoading y error si acceden al objeto padre. Con estado separado, cada propiedad se rastrea de forma independiente. Elige según tus patrones de acceso.

Depurar el Rendimiento del Contexto

Si sospechas que hay problemas de rendimiento relacionados con el contexto, aquí te explicamos cómo investigarlos:

Verificar Qué Se Vuelve a Renderizar

<script>
	import { getContext } from 'svelte'

	const data = getContext('data')

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

Inspeccionar las Dependencias del Contexto

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

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

Perfilar con DevTools del Navegador

Abre DevTools → pestaña Performance
Graba mientras interactúas con tu aplicación
Busca actualizaciones inesperadas de componentes
Rastrea qué cambio de estado las desencadenó

Conclusiones Clave

El contexto es económico: Solo una búsqueda en un Map en el momento de inicialización. Sin sobrecarga en tiempo de ejecución.
La reactividad causa rerenderizados, no el contexto: Leer $state mediante getters crea suscripciones. El contexto es solo el mecanismo de entrega.
Granular por diseño: Solo los componentes que leen propiedades reactivas específicas se vuelven a renderizar cuando esas propiedades cambian.
Atención a las señales de alerta: Demasiados contextos, el contexto reemplazando props, o proveedores profundamente anidados indican problemas de diseño, no de rendimiento.
Mantén los valores estables: Evita crear nuevos objetos en getters. Usa $derived para valores calculados.
La herramienta adecuada para cada tarea: Contexto para datos ambientales y límites de funcionalidad. Props para APIs explícitas de componentes. CSS para estilos.

Conclusión

El rendimiento del contexto en Svelte no es un problema por diseño. La API es una envoltura delgada sobre operaciones de Map que ocurren una sola vez en la inicialización del componente. La verdadera historia de rendimiento tiene que ver con el estado reactivo, que funciona de manera idéntica ya sea que se entregue mediante contexto, props o acceso directo.

Esta claridad arquitectónica tiene implicaciones prácticas. Nunca necesitas dividir contextos para evitar rerenderizados (la reactividad de grano fino de Svelte lo maneja). No necesitas envoltorios de memoización ni patrones de selectores. Puedes anidar proveedores sin penalizaciones de rendimiento. El sistema simplemente funciona.

Las consideraciones de rendimiento genuinas son arquitectónicas, no mecánicas: mantener estables los valores del contexto, evitar cómputos costosos en los getters, comprender el ciclo de vida de la memoria en aplicaciones de larga duración y garantizar la compatibilidad con SSR/hidratación. Estas son decisiones de diseño, no técnicas de optimización.

Cuando encuentres problemas de rendimiento en una aplicación con mucho uso de contexto, la causa casi nunca es el contexto en sí. Busca en cambio el estado reactivo dentro del contexto, los cómputos desencadenados al acceder a ese estado o la estructura de componentes que lo consume. Perfila con mediciones reales, no con suposiciones.

¿Qué Sigue?

Comprende cuándo el contexto es la elección correcta en Context vs Other Patterns, comparando el contexto con props, stores, eventos y funciones de carga con un marco de decisión claro.

Ver También

Documentación Oficial

Svelte Context — Guía oficial de contexto
$state — Runa de estado reactivo
$derived — Valores calculados