El Problema de la Frescura de Datos

Una aplicación de SvelteKit carga datos cuando un usuario navega a una ruta. La función de carga se ejecuta, los datos llegan y la página se renderiza. Hasta aquí todo bien. Pero las aplicaciones no son estáticas. Un usuario envía un formulario. Un registro se actualiza. La acción de otro usuario cambia el estado compartido. Un temporizador en segundo plano se dispara. En todas estas situaciones, la página ya tiene datos, y esos datos ahora están desactualizados. La pregunta es: ¿cómo logras que la página recargue sus datos sin una navegación completa del navegador?

La respuesta está en el sistema de seguimiento de dependencias de SvelteKit. Cada función de carga registra de manera pasiva qué partes del estado leyó durante la ejecución. Cuando alguna de esas entradas registradas cambia, SvelteKit vuelve a ejecutar la función de carga y actualiza los datos de la página en su lugar, sin una recarga completa de la página y sin descartar el estado de los componentes que no tienen nada que ver con los datos modificados.

Este sistema es el puente entre el modelo de carga de datos del lado del servidor de SvelteKit y la sensación dinámica y reactiva que los usuarios esperan de una aplicación web bien construida. Entenderlo con precisión significa que puedes controlar cuándo los datos están frescos, cuándo están desactualizados y exactamente cuánto cuesta actualizarlos. Hacerlo mal significa tener datos desactualizados en los que los usuarios no pueden confiar, o bien actualizaciones demasiado frecuentes que sobrecargan tu servidor sin motivo.

Este artículo cubre cada disparador de nueva ejecución en el sistema, cómo se registra cada uno y cómo trabajar con ellos de manera deliberada. Termina con un ejemplo completo de un dashboard con actualizaciones en tiempo real que pone en práctica cada concepto.

Por Qué las Nuevas Ejecuciones Automáticas No Son Suficientes

Considera un usuario en una página de listado de publicaciones. La URL es /app/posts?status=published&page=1. Hace clic en un botón que archiva una de las publicaciones. Tu función de carga en +page.server.ts devolvió la lista actual al navegar. Esa lista ahora está incorrecta. La publicación archivada debería haber desaparecido.

La solución ingenua es window.location.reload(). Eso funciona, pero destruye todo el estado del lado del cliente, desplaza al usuario hacia arriba y causa un viaje de ida y vuelta completo que vuelve a ejecutar todas las funciones de carga de layouts y páginas en la jerarquía de rutas, incluso si solo cambió la lista de publicaciones.

La función invalidate() de SvelteKit proporciona una alternativa quirúrgica. Le indicas a SvelteKit qué dependencia quedó desactualizada. Solo vuelve a ejecutar las funciones de carga que dependen de ese elemento, fusiona los nuevos datos y actualiza los componentes afectados. La posición del scroll se conserva. El estado del layout no se toca. La actualización es tan mínima como puede ser.

El desafío es que este sistema requiere que entiendas qué es una "dependencia" en el modelo de SvelteKit, qué entradas se rastrean automáticamente y cuándo necesitas declarar una dependencia de forma explícita en lugar de depender del seguimiento automático.

Qué Rastrea SvelteKit Automáticamente

Cada función de carga recibe un objeto de evento con varias entradas. SvelteKit envuelve cada entrada con lógica de seguimiento. Cuando una función de carga lee una entrada rastreada, esa entrada se registra como dependencia de dicha función de carga. Si la entrada cambia entre navegaciones, la función de carga se vuelve a ejecutar.

Las entradas rastreadas automáticamente son params, url, route y la salida de parent().

params

params rastrea solo las claves que lees. Si una función de carga lee params.slug, navegar a un slug diferente la vuelve a ejecutar. Si solo cambia otro parámetro y slug no ha cambiado, esta carga no se vuelve a ejecutar.

url

Las dependencias de url también se basan en lecturas y son granulares. Leer url.pathname rastrea los cambios de ruta. Leer url.searchParams.get('page') rastrea esa clave de consulta. Leer url.search en bruto rastrea la cadena de consulta completa, que es más amplia de lo que la mayoría de las cargas necesitan.

route

route.id se rastrea si se lee. Esto es menos común que params y url, pero sigue siendo útil para lógica específica del patrón de ruta, como la agrupación de analíticas.

Si deseas conocer en detalle los mecanismos de datos de URL y los patrones de implementación (params, url.searchParams, route.id, comportamiento del hash en SSR, ejemplos de paginación/filtros), consulta Using URL Data in Load Functions. Este artículo se centra en cómo esas lecturas afectan el comportamiento de rejecución.

parent()

Cuando una función de carga llama a await parent(), el resultado de las cargas de layouts ancestros se registra como dependencia. Si alguna carga de layout ancestro se vuelve a ejecutar, todas las funciones de carga descendientes que llamaron a await parent() se vuelven a ejecutar a su vez. La cascada se propaga hacia abajo a través de la jerarquía de layouts hasta cada función de carga que declaró la dependencia del padre; no hay un cortocircuito por comparación de datos.

Navegando Entre Páginas con Layout Compartido

Una implicación del modelo de seguimiento vale la pena enunciar explícitamente. Cuando un usuario navega entre dos páginas que comparten un layout, las funciones de carga del layout no se vuelven a ejecutar automáticamente. La URL cambió, pero la ruta del layout no. Los datos del layout se reutilizan.

Si la función de carga del layout sí leyó url.searchParams o un parámetro específico, y estos cambiaron, entonces la función de carga del layout se volvería a ejecutar. De lo contrario, se omite.

Este es el comportamiento correcto para la mayoría de los layouts. El encabezado de navegación, la barra lateral, la información del usuario en el shell: estas cosas no cambian cuando el usuario hace clic de /app/posts a /app/analytics. Omitir la función de carga del layout significa que el usuario ve los nuevos datos de la página sin un viaje de ida y vuelta innecesario para obtener datos que ya tiene.

Este comportamiento de rejecución selectiva es lo que hace que la navegación de SvelteKit se sienta rápida incluso cuando los layouts contienen sus propias peticiones de datos.

Invalidación Manual

Las nuevas ejecuciones automáticas cubren los cambios de estado provocados por la navegación. No cubren las mutaciones. Cuando un usuario archiva una publicación, la URL no ha cambiado, los parámetros no han cambiado y no se dispara ningún disparador automático. Los datos están desactualizados, pero SvelteKit no tiene forma de saberlo.

La invalidación manual es la herramienta para este caso. SvelteKit expone dos funciones del lado del cliente desde $app/navigation: invalidate(url) e invalidateAll().

invalidate(url)

invalidate(url) acepta una cadena de URL o un objeto URL. Marca como desactualizada cualquier función de carga que dependa de esa URL y la vuelve a ejecutar. Hay una distinción crítica aquí: este seguimiento de URL basado en fetch solo aplica a funciones de carga universales (+page.js, +layout.js). Las funciones de carga del servidor (+page.server.ts, +layout.server.ts) nunca rastrean automáticamente las URLs obtenidas, ya que hacerlo podría filtrar secretos del lado del servidor al cliente. Para las funciones de carga del servidor, depends() es el único mecanismo disponible para la invalidación manual.

Para las funciones de carga universales, "depende de esa URL" significa que la función de carga pasó esa URL exacta al wrapper fetch de SvelteKit durante la ejecución. SvelteKit registra cada URL pasada a su fetch, y invalidate(url) desencadena nuevas ejecuciones para todas las funciones de carga universales que tengan esa URL en su conjunto de fetch registrado.

<!-- src/routes/app/posts/+page.svelte (client-side action handler) -->
<script lang="ts">
	import { invalidate } from '$app/navigation'

	async function archivePost(postId: string) {
		const response = await fetch(`/api/posts/${postId}/archive`, { method: 'POST' })

		if (response.ok) {
			// The posts list is now stale. Tell SvelteKit which URL to invalidate.
			// This reruns any universal load function that fetched this URL.
			// For a server load function, use depends() + invalidate('app:identifier') instead.
			await invalidate('/api/posts')
		}
	}
</script>

La coincidencia de URL utilizada por invalidate es exacta por defecto, pero puedes pasar una función en lugar de una cadena para realizar una coincidencia personalizada:

// Match any URL that starts with '/api/posts'.
// This reruns load functions that fetched '/api/posts',
// '/api/posts?status=published', '/api/posts/my-slug', and so on.
await invalidate((url) => url.pathname.startsWith('/api/posts'))

La forma de función te da un control preciso cuando un único endpoint sirve múltiples variantes filtradas y deseas invalidarlas todas con una sola llamada.

invalidateAll()

invalidateAll() vuelve a ejecutar todas las funciones de carga en la jerarquía de rutas actual, independientemente de lo que hayan obtenido. Es el martillo pesado. Todas las cargas de layout y la carga de página se vuelven a ejecutar.

import { invalidateAll } from '$app/navigation'

// After a significant state change, refresh everything.
// Use this sparingly. It causes every load function in the route to rerun.
await invalidateAll()

invalidateAll() es apropiado cuando un cambio es tan amplio que no puedes predecir qué URLs específicas necesitan invalidación. Cambiar el espacio de trabajo activo en una aplicación multi-tenant. Cambiar el usuario autenticado. Activar o desactivar un feature flag. Situaciones donde el alcance del cambio es global en el sistema en lugar de específico de un endpoint.

Para mutaciones dirigidas, prefiere invalidate(url). Para cambios amplios, invalidateAll() es la herramienta adecuada, con el entendimiento de que es más costosa.

Declarar Dependencias Personalizadas con depends()

invalidate(url) funciona cuando tu función de carga obtiene una URL a la que puedes hacer referencia desde el sitio de llamada. Pero no todas las dependencias son URLs. A veces los datos que devuelve una función de carga se derivan de una consulta a la base de datos, un cálculo, una ventana de tiempo o algún concepto a nivel de aplicación que no tiene una única URL a la que apuntar.

depends('app:identifier') resuelve este problema. Declara una dependencia nombrada que no es una URL. El identificador debe estar prefijado con una o más letras minúsculas seguidas de dos puntos, conforme a la especificación URI, por ejemplo app:dashboard, posts:list o user:session. Los esquemas como app: son la elección convencional.

Llamar a depends('app:posts') dentro de una función de carga registra app:posts como dependencia de esa función de carga. Llamar a invalidate('app:posts') desde cualquier parte del cliente desencadenará una nueva ejecución de cualquier función de carga que haya declarado esa dependencia.

// src/routes/app/dashboard/+page.server.ts
// The dashboard data depends on a concept called 'app:dashboard-metrics'.
// This is not a URL. It represents the broader concept of dashboard data freshness.
// Any client-side code that knows dashboard data has changed can call
// invalidate('app:dashboard-metrics') to trigger a rerun.

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

export const load: PageServerLoad = async ({ depends, fetch }) => {
	// Register a named dependency for this load function.
	// The load function will rerun whenever invalidate('app:dashboard-metrics')
	// is called from the client, regardless of what URLs it fetches.
	depends('app:dashboard-metrics')

	const [metricsResponse, activityResponse] = await Promise.all([
		fetch('/api/dashboard/metrics'),
		fetch('/api/dashboard/recent-activity')
	])

	return {
		metrics: metricsResponse.ok ? await metricsResponse.json() : null,
		activity: activityResponse.ok ? await activityResponse.json() : []
	}
}

<!-- src/routes/app/dashboard/+page.svelte -->
<!-- The refresh button triggers a rerun via the named dependency. -->

<script lang="ts">
	import { invalidate } from '$app/navigation'

	async function refreshDashboard() {
		await invalidate('app:dashboard-metrics')
	}
</script>

<button onclick={refreshDashboard}>Refresh</button>

depends() es la herramienta correcta cuando deseas desacoplar el disparador de invalidación de las URLs específicas que se están obteniendo. Permite que las funciones de carga evolucionen (cambiando qué URLs obtienen) sin requerir cambios en los sitios de llamada de invalidación.

Múltiples funciones de carga pueden declarar la misma dependencia. Si dos funciones de carga diferentes llaman a depends('app:user-data'), entonces invalidate('app:user-data') desencadenará la nueva ejecución de ambas. Esto permite una invalidación coordinada a través de la jerarquía de carga sin que cada sitio de llamada necesite saber qué funciones de carga específicas están involucradas.

Optar por No Participar en el Seguimiento con untrack()

El sistema de seguimiento es valioso, pero hay casos en los que deseas que una función de carga lea un valor sin crear una dependencia sobre él. El ejemplo clásico es leer un valor para propósitos de logging o telemetría: quieres incluirlo en un encabezado de solicitud o en un mensaje de log, pero no deseas que la función de carga se vuelva a ejecutar cuando ese valor cambia.

untrack(fn) acepta una función y la ejecuta sin registrar ninguna dependencia sobre las entradas leídas dentro de la función. El valor de retorno es lo que sea que devuelva la función.

// src/routes/app/posts/[slug]/+page.server.ts
// The load function depends on params.slug to fetch the post.
// It reads url.searchParams.get('ref') for analytics, but the page
// should not rerun when the referring source changes. untrack prevents
// the ref parameter from becoming a dependency.

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

export const load: PageServerLoad = async ({ params, url, untrack, fetch }) => {
	// Read the referring source without tracking it.
	// Changing ?ref=newsletter vs ?ref=twitter does not trigger a rerun.
	const referrer = untrack(() => url.searchParams.get('ref'))

	const response = await fetch(`/api/posts/${params.slug}`)

	if (!response.ok) {
		error(404, 'Post not found')
	}

	const post = await response.json()

	if (referrer) {
		// Fire-and-forget analytics recording.
		// The SvelteKit event fetch supports relative URLs on the server and works correctly here
		// because the response is never consumed; SSR capturing only hooks into .json()/.text(),
		// which are never called. Not awaited because analytics must never block the page render.
		fetch('/api/analytics/referrer', {
			method: 'POST',
			headers: { 'Content-Type': 'application/json' },
			body: JSON.stringify({ postId: post.id, referrer })
		}).catch(() => {
			// Analytics failure should never break page load.
		})
	}

	return { post }
}

Sin untrack, la función de carga se volvería a ejecutar cada vez que el parámetro de consulta ref cambiara. Con untrack, solo se vuelve a ejecutar cuando params.slug cambia, que es el comportamiento correcto.

untrack también es útil cuando se leen valores de configuración o derivados del entorno que sabes que no cambiarán durante una sesión. Leer un feature flag que es fijo por despliegue, o leer un identificador de configuración regional que solo cambia con una acción explícita del usuario que manejas por separado, ambos pueden envolverse en untrack para evitar nuevas ejecuciones espurias.

Cada Situación que Desencadena una Nueva Ejecución

Con todos los mecanismos cubiertos, resulta útil tener una referencia completa de cada condición que desencadena que una función de carga se vuelva a ejecutar.

Hay dos disparadores implícitos adicionales. Llamar a goto(url, { invalidateAll: true }) desde $app/navigation se comporta como una navegación seguida de invalidateAll().

Para una invalidación quirúrgica dentro de una llamada a goto, la opción de array invalidate acepta los mismos argumentos que invalidate() — cadenas, objetos URL o funciones predicado — y desencadena solo las funciones de carga que coincidan en lugar de todas: goto('/somewhere', { invalidate: ['/api/posts'] }).

Usar enhance en un elemento <form> también llamará a invalidateAll() por defecto después de un envío de formulario exitoso, que es la razón por la que las acciones de formulario de Svelte actualizan los datos de la página automáticamente.

Ejemplo Práctico: Un Dashboard con Actualizaciones en Tiempo Real

El escenario es un dashboard que muestra métricas clave. Las métricas deben actualizarse automáticamente cada 30 segundos sin ninguna acción del usuario. El usuario también puede hacer clic en un botón de actualización para obtener los datos de inmediato. Tanto el camino de actualización automático como el manual utilizan el mismo mecanismo de invalidación.

Función de carga con dependencia nombrada

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

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

export interface DashboardMetrics {
	activeSessions: number
	postsPublishedToday: number
	totalReadsThisWeek: number
	averageEngagementRate: number
	lastUpdated: string
}

export interface RecentActivity {
	id: string
	type: 'post_published' | 'comment_received' | 'milestone_reached'
	message: string
	occurredAt: string
}

export const load: PageServerLoad = async ({ depends, fetch }) => {
	// Declare the named dependency. This load function reruns whenever
	// invalidate('app:dashboard') is called from the client.
	// The load function also reruns if the URL or params change (none here),
	// or if invalidateAll() is called.
	depends('app:dashboard')

	const [metricsResponse, activityResponse] = await Promise.all([
		fetch('/api/dashboard/metrics'),
		fetch('/api/dashboard/activity?limit=10')
	])

	const metrics: DashboardMetrics | null = metricsResponse.ok ? await metricsResponse.json() : null

	const activity: RecentActivity[] = activityResponse.ok ? await activityResponse.json() : []

	return { metrics, activity }
}

El componente del dashboard con auto-actualización

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

<script lang="ts">
	import { onMount } from 'svelte'
	import { invalidate } from '$app/navigation'
	import type { PageProps } from './$types'

	let { data }: PageProps = $props()

	// Track the last refresh time for display purposes.
	let lastRefreshed = $state(new Date())
	let isRefreshing = $state(false)

	// Format the last refreshed time reactively.
	// Rebuilds whenever lastRefreshed changes.
	const refreshedLabel = $derived(
		lastRefreshed.toLocaleTimeString('en-US', {
			hour: 'numeric',
			minute: '2-digit',
			second: '2-digit'
		})
	)

	// Manual refresh triggered by the button.
	// Sets isRefreshing to true, calls invalidate, then resets.
	async function refreshNow() {
		isRefreshing = true
		await invalidate('app:dashboard')
		lastRefreshed = new Date()
		isRefreshing = false
	}

	// Auto-refresh every 30 seconds.
	// onMount ensures this only runs in the browser, not during SSR.
	// The interval is cleared when the component unmounts (user navigates away),
	// preventing memory leaks and orphaned timers.
	onMount(() => {
		const interval = setInterval(async () => {
			await invalidate('app:dashboard')
			lastRefreshed = new Date()
		}, 30_000)

		return () => clearInterval(interval)
	})

	// Format a number as a compact string: 1200 -> '1.2K', 1500000 -> '1.5M'
	function formatCount(n: number): string {
		return new Intl.NumberFormat('en-US', {
			notation: 'compact',
			maximumFractionDigits: 1
		}).format(n)
	}

	// Format an ISO timestamp as a relative time label: '2 minutes ago'
	function relativeTime(isoString: string): string {
		const diff = Date.now() - new Date(isoString).getTime()
		const minutes = Math.floor(diff / 60_000)
		if (minutes < 1) return 'just now'
		if (minutes < 60) return `${minutes}m ago`
		const hours = Math.floor(minutes / 60)
		if (hours < 24) return `${hours}h ago`
		return `${Math.floor(hours / 24)}d ago`
	}
</script>

<div class="dashboard">
	<div class="dashboard-toolbar">
		<h1 class="dashboard-title">Dashboard</h1>

		<div class="dashboard-controls">
			<span class="last-refreshed">
				Updated {refreshedLabel}
			</span>
			<button
				onclick={refreshNow}
				disabled={isRefreshing}
				class="refresh-button"
				aria-label="Refresh dashboard data"
			>
				{isRefreshing ? 'Refreshing...' : 'Refresh'}
			</button>
		</div>
	</div>

	{#if data.metrics}
		<div class="metrics-grid">
			<div class="metric-card">
				<h2 class="metric-label">Active Sessions</h2>
				<p class="metric-value">{formatCount(data.metrics.activeSessions)}</p>
			</div>

			<div class="metric-card">
				<h2 class="metric-label">Published Today</h2>
				<p class="metric-value">{data.metrics.postsPublishedToday}</p>
			</div>

			<div class="metric-card">
				<h2 class="metric-label">Reads This Week</h2>
				<p class="metric-value">{formatCount(data.metrics.totalReadsThisWeek)}</p>
			</div>

			<div class="metric-card">
				<h2 class="metric-label">Engagement Rate</h2>
				<p class="metric-value">
					{(data.metrics.averageEngagementRate * 100).toFixed(1)}%
				</p>
			</div>
		</div>
	{:else}
		<p class="metrics-unavailable">
			Metrics are temporarily unavailable. The dashboard will retry automatically.
		</p>
	{/if}

	<section class="activity-feed">
		<h2 class="activity-title">Recent Activity</h2>

		{#if data.activity.length === 0}
			<p class="activity-empty">No recent activity.</p>
		{:else}
			<ul class="activity-list">
				{#each data.activity as event (event.id)}
					<li class="activity-item activity-item--{event.type}">
						<p class="activity-message">{event.message}</p>
						<time datetime={event.occurredAt} class="activity-time">
							{relativeTime(event.occurredAt)}
						</time>
					</li>
				{/each}
			</ul>
		{/if}
	</section>
</div>

Varias decisiones de diseño en este componente merecen examinarse individualmente.

El indicador de estado isRefreshing proporciona retroalimentación visual al usuario durante la actualización manual. Sin él, el botón no da ninguna indicación de que hay una solicitud en curso, lo que lleva a los usuarios a hacer clic varias veces. El atributo disabled evita las invocaciones dobles.

La función de retorno de onMount es la limpieza. SvelteKit ejecuta las limpiezas de onMount cuando un componente es destruido, lo que ocurre cuando el usuario navega fuera de la ruta. Sin la limpieza, el intervalo continuaría disparándose y llamando a invalidate contra una página que ya no existe en el navegador. La limpieza no es opcional.

La llamada invalidate('app:dashboard') tanto en el flujo manual como en el automático es idéntica. Tanto el temporizador de 30 segundos como el botón manual desencadenan exactamente la misma reejecución de la función de carga a través del mismo identificador. La función de carga no tiene en cuenta cómo se desencadenó la invalidación. Simplemente se reejecutará y devolverá datos frescos.

Agregar una cuenta regresiva visual

Un patrón de UX común para dashboards con actualización en vivo es mostrarle al usuario cuánto tiempo falta para la próxima actualización automática. Esto es estado puramente del lado del cliente que no interactúa con la función de carga en absoluto:

<!-- Excerpt: add this to the dashboard toolbar section above -->

<script lang="ts">
	// ... existing imports and state ...

	const REFRESH_INTERVAL_MS = 30_000

	// Countdown in seconds until the next auto-refresh.
	let secondsUntilRefresh = $state(REFRESH_INTERVAL_MS / 1000)

	onMount(() => {
		// Countdown tick runs every second.
		const countdown = setInterval(() => {
			secondsUntilRefresh -= 1
			if (secondsUntilRefresh <= 0) {
				secondsUntilRefresh = REFRESH_INTERVAL_MS / 1000
			}
		}, 1000)

		// Data refresh runs every 30 seconds.
		const refresh = setInterval(async () => {
			await invalidate('app:dashboard')
			lastRefreshed = new Date()
			secondsUntilRefresh = REFRESH_INTERVAL_MS / 1000
		}, REFRESH_INTERVAL_MS)

		return () => {
			clearInterval(countdown)
			clearInterval(refresh)
		}
	})
</script>

<!-- In the toolbar markup: -->
<span class="refresh-countdown">
	Refreshes in {secondsUntilRefresh}s
</span>

El temporizador de cuenta regresiva se ejecuta con granularidad de 1 segundo puramente en el estado del componente. No llama a invalidate. El temporizador de actualización se ejecuta con granularidad de 30 segundos y llama a invalidate. Ambos son intervalos separados con manejadores de limpieza separados. La función de limpieza retornada por onMount ahora limpia ambos.

Errores Comunes y Anti-Patrones

Llamar a invalidate() con una URL que la función de carga nunca obtuvo

// Avoid: invalidating a URL that no load function actually used.
// This triggers a full dependency check but finds nothing to rerun.
// If the URL is slightly wrong (trailing slash, different query string),
// nothing reruns and the stale data persists silently.

async function archivePost(postId: string) {
	await fetch(`/api/posts/${postId}/archive`, { method: 'POST' })
	await invalidate('/api/posts/') // Trailing slash mismatch. Will not match '/api/posts'.
}

// Preferred: use the exact URL string that the load function passed to fetch(),
// or use a function for flexible matching.

async function archivePost(postId: string) {
	await fetch(`/api/posts/${postId}/archive`, { method: 'POST' })

	// Exact match for the URL used in the load function.
	await invalidate('/api/posts')

	// Or use a function to match any URL under /api/posts regardless of query string.
	await invalidate((url) => url.pathname === '/api/posts')
}

Cuando la coincidencia es incierta, la forma de función es la opción más segura. Hace que la lógica de coincidencia sea explícita y comprobable.

Usar invalidateAll() para cada mutación

// Avoid: calling invalidateAll() after every small mutation.
// This reruns every load function in the entire route hierarchy,
// including layout loads that have nothing to do with the changed data.

async function updatePostTitle(postId: string, newTitle: string) {
	await fetch(`/api/posts/${postId}`, {
		method: 'PATCH',
		headers: { 'Content-Type': 'application/json' },
		body: JSON.stringify({ title: newTitle })
	})
	await invalidateAll() // Reruns root layout, app layout, and page load.
	// Only the page load actually needs refreshed data.
}

// Preferred: invalidate only the specific dependency that changed.
// For universal load functions that fetched /api/posts, invalidating the URL is enough.
// For server load functions, the load function must call depends() and be invalidated
// via that identifier instead, since server loads never auto-track fetched URLs.
async function updatePostTitle(postId: string, newTitle: string) {
	await fetch(`/api/posts/${postId}`, {
		method: 'PATCH',
		headers: { 'Content-Type': 'application/json' },
		body: JSON.stringify({ title: newTitle })
	})
	await invalidate('/api/posts')
}

Olvidar limpiar el temporizador en onMount

<!-- Wrong: starting an interval in onMount without returning a cleanup function.
     The interval continues running after the user navigates away.
     Multiple navigations back to this route stack up multiple intervals,
     each firing invalidate() independently. This is a runtime bug, not just a style concern. -->

<script lang="ts">
	import { onMount } from 'svelte'
	import { invalidate } from '$app/navigation'

	onMount(() => {
		setInterval(async () => {
			await invalidate('app:dashboard')
		}, 30_000)
		// No return. No cleanup. Timer leaks.
	})
</script>

<!-- Correct: return the cleanup function from onMount.
     SvelteKit calls it when the component is destroyed. -->

<script lang="ts">
	import { onMount } from 'svelte'
	import { invalidate } from '$app/navigation'

	onMount(() => {
		const interval = setInterval(async () => {
			await invalidate('app:dashboard')
		}, 30_000)

		return () => clearInterval(interval)
	})
</script>

Declarar depends() de forma condicional

// Avoid: calling depends() inside a conditional.
// If the condition is false on the first run, the dependency is never registered.
// invalidate('app:dashboard') will not trigger a rerun.

export const load: PageServerLoad = async ({ depends, url, fetch }) => {
	const showMetrics = url.searchParams.get('view') === 'metrics'

	if (showMetrics) {
		depends('app:dashboard') // Only registered on some runs. Unreliable.
	}

	// ...
}

// Preferred: call depends() unconditionally at the top of the load function.
// Dependencies are always registered regardless of branching logic below.

export const load: PageServerLoad = async ({ depends, url, fetch }) => {
	depends('app:dashboard') // Always registered.

	const showMetrics = url.searchParams.get('view') === 'metrics'

	// ...
}

Consideraciones de Rendimiento y Escalabilidad

La invalidación es económica desde la perspectiva de SvelteKit: solo reejecutará las funciones de carga afectadas y actualizará únicamente los componentes que recibieron nuevos datos. El costo está completamente en el trabajo que realizan esas funciones de carga: las solicitudes de red que hacen, el cómputo del servidor involucrado y las actualizaciones de componentes desencadenadas por el cambio de datos en el árbol de componentes.

Para dashboards con actualización automática, el intervalo de sondeo merece atención deliberada. Un intervalo de 5 segundos en una página con 10,000 usuarios concurrentes genera 2 millones de solicitudes por minuto contra tu API. Un intervalo de 30 segundos genera 20,000 solicitudes por minuto. La diferencia es un factor de 100. Elige intervalos que sean lo suficientemente largos como para ser manejables a tu escala de tráfico. Considera usar WebSockets o Server-Sent Events para datos genuinamente en tiempo real en lugar de hacer sondeo, y reserva el sondeo con invalidate para datos que cambian en una cadencia de un minuto o más.

Cuando múltiples funciones de carga declaran el mismo identificador de depends(), invalidar ese identificador reejecutará todas ellas de forma concurrente. Esto es generalmente lo que deseas, pero ten en cuenta el efecto de expansión. Si tres funciones de carga dependen de app:dashboard, una llamada a invalidate('app:dashboard') desencadena tres conjuntos concurrentes de solicitudes a la API. Asegúrate de que las APIs que atienden esas solicitudes puedan manejar la ráfaga.

untrack() también es una herramienta de rendimiento. Si una función de carga lee muchas propiedades de la URL pero solo algunas de ellas afectan realmente a los datos que obtiene, envolver las lecturas no esenciales en untrack reduce la cantidad de reejecuciones. Una función de carga que lee url.search sin untrack se reejecutará cada vez que cambie cualquier parámetro de consulta, incluso los que son irrelevantes para los datos que se están obteniendo. Envolver esas lecturas en untrack evita que se formen dependencias espurias y mantiene las reejecuciones limitadas a las entradas que realmente importan. Ten en cuenta que url.hash no es accesible durante la carga en absoluto; no está disponible en el servidor, por lo que nunca es una preocupación de seguimiento.

Qué Sigue

Con la invalidación comprendida, la pregunta de rendimiento restante es la inversa: en lugar de actualizar datos después de un cambio, ¿puedes precargar datos antes de que el usuario navegue? El siguiente artículo, Precarga con preloadData y preloadCode, cubre las APIs de precarga programática de SvelteKit, cuándo es apropiada cada una y cómo los datos precargados se integran con la caché de la función de carga.

Ver También

Carga Paralela y Cómo Evitar Cascadas — el artículo anterior en esta serie, que cubre cómo SvelteKit ejecuta las funciones de carga de forma concurrente y cómo evitar la ejecución secuencial involuntaria a través de la trampa de await parent() y los patrones de Promise.all
Uso de Datos del Padre en Funciones de Carga — cubre los mecanismos de parent() en detalle, incluyendo exactamente qué datos retorna y el patrón fetch-before-parent para preservar la concurrencia
Fetch en Funciones de Carga — cubre el wrapper fetch de SvelteKit, el seguimiento de URL que habilita y por qué es distinto del fetch global
Documentación de Load de SvelteKit — referencia oficial del sistema completo de seguimiento de dependencias, todas las propiedades del evento de carga y la API completa de invalidación
Documentación de Invalidación de SvelteKit — referencia oficial de invalidate, invalidateAll, depends y untrack con ejemplos de uso canónicos