Qué es el Prefetching y Por Qué Importa

La navegación del lado del cliente en SvelteKit ya es rápida en comparación con las cargas de página completas. Cuando un usuario hace clic en un enlace, SvelteKit no recarga el navegador; ejecuta la función load de la ruta de destino, recibe los datos y vuelve a renderizar solo los componentes que cambiaron. Eso elimina el costo de recargar JavaScript, CSS y los componentes de layout compartidos.

Pero la función load aún tiene que ejecutarse cuando el usuario hace clic. Si esa función load realiza una solicitud de red, hay una brecha de latencia entre el clic y la aparición del contenido, incluso en conexiones rápidas. En redes móviles o con APIs lentas, esa brecha se vuelve perceptible.

El prefetching cierra esa brecha iniciando la función load antes de que el usuario haga clic, mientras están pasando el cursor sobre el enlace o mientras el enlace entra al viewport, y almacenando en caché el resultado para que cuando ocurra la navegación real, los datos ya estén disponibles. Para aplicaciones con patrones de navegación predecibles, páginas de listado con mucho contenido y rutas frecuentes conocidas, esto puede hacer que la navegación se sienta genuinamente instantánea.

SvelteKit proporciona dos formas de prefetching: prefetching de datos (ejecutar funciones load con anticipación y almacenar los resultados en caché) y prefetching de código (descargar el JavaScript de una ruta antes de que sea necesario). Ambos pueden aplicarse de forma declarativa mediante atributos HTML en elementos anchor, o de forma programática mediante funciones de $app/navigation.

La Brecha de Latencia en la Navegación

Imaginemos un blog con una lista de publicaciones en /blog. Cada publicación tiene un título, un extracto y un enlace a /blog/[slug]. Un lector escanea la lista, encuentra una publicación que le interesa y hace clic en el enlace. La función load de la publicación obtiene el artículo completo desde una API. Con un tiempo de ida y vuelta de 100ms, el usuario espera al menos 100ms después de hacer clic antes de que ocurra algún cambio. En una red móvil con un tiempo de ida y vuelta de 400ms, la espera se vuelve claramente perceptible.

Esta latencia tiene dos componentes: el tiempo de red (esperar a que el servidor responda) y el tiempo de código (esperar a que se descargue el bundle de JavaScript de la ruta si aún no se ha obtenido). Ambos contribuyen a la brecha entre la intención del usuario y la aparición del contenido.

Ahora imaginemos que el usuario pausa el mouse sobre el título de la publicación durante 150ms antes de hacer clic, lo cual es un comportamiento humano típico. Sin prefetching, esos 150ms son tiempo desperdiciado. Con prefetching, SvelteKit puede iniciar la función load al pasar el cursor y tener los datos listos antes de que siquiera se registre el clic. El usuario experimenta cero demora perceptible.

Este es el valor fundamental del prefetching: convierte el tiempo inactivo que el usuario pasa señalando y pensando en trabajo productivo que el navegador realiza obteniendo datos y código. Es una de las pocas optimizaciones de rendimiento que proporciona un beneficio proporcional a la velocidad normal de navegación humana, no solo a condiciones de red artificialmente lentas.

data-sveltekit-preload-data: El Enfoque Declarativo

La forma más sencilla de habilitar el prefetching es con el atributo data-sveltekit-preload-data en un elemento anchor o en un contenedor padre. SvelteKit iniciará el prefetching de la función load de la ruta de destino cuando se cumpla la condición de activación.

El atributo acepta dos valores: hover y tap.

hover

Con hover, SvelteKit inicia el prefetching cuando el usuario mueve el cursor sobre el enlace, o cuando el enlace recibe el foco mediante el teclado. Este es el activador más agresivo y da más tiempo para hacer el prefetching antes de un clic.

<!-- src/routes/blog/+page.svelte -->

<script lang="ts">
	import type { PageProps } from './$types'
	let { data }: PageProps = $props()
</script>

<ul>
	{#each data.posts as post}
		<li>
			<a href="/blog/{post.slug}" data-sveltekit-preload-data="hover">
				{post.title}
			</a>
		</li>
	{/each}
</ul>

El atributo también puede colocarse en un elemento padre para aplicarse a todos los enlaces descendientes:

<!-- src/routes/blog/+page.svelte -->

<ul data-sveltekit-preload-data="hover">
	{#each data.posts as post}
		<li>
			<a href="/blog/{post.slug}">{post.title}</a>
		</li>
	{/each}
</ul>

SvelteKit aplica data-sveltekit-preload-data="hover" al elemento <body> de forma predeterminada en proyectos nuevos, mediante un atributo data-sveltekit-preload-data en la etiqueta raíz <body> en app.html. Esto significa que el prefetching por hover generalmente ya está habilitado en toda la aplicación sin necesidad de ninguna anotación por enlace.

tap

Con tap, el prefetching se activa en touchstart (móvil) o mousedown (escritorio), que es el momento en que el dedo del usuario toca la pantalla o presiona el botón del mouse, antes de que se dispare el evento de clic. Esta es una ventana más corta que hover pero es más amigable para dispositivos móviles, ya que los dispositivos táctiles no tienen estados de hover.

<a href="/blog/{post.slug}" data-sveltekit-preload-data="tap">
	{post.title}
</a>

En escritorio, tap es menos efectivo que hover porque el tiempo entre mousedown y clic es típicamente de 100-200ms, en comparación con los varios cientos de milisegundos que un usuario puede pasar haciendo hover. En dispositivos táctiles, tap es la mejor opción disponible.

Una Nota sobre el Modo de Ahorro de Datos

SvelteKit nunca activará el prefetching de datos si el usuario ha habilitado el modo de ahorro de datos en su navegador o sistema operativo. Cuando navigator.connection.saveData es true, tanto data-sveltekit-preload-data como preloadData se omiten silenciosamente. Este es el comportamiento correcto: el prefetching es una sugerencia de rendimiento, no un requisito, y debe respetar las preferencias del usuario.

data-sveltekit-preload-code: Prefetching Declarativo de Código

data-sveltekit-preload-code es el equivalente declarativo para el prefetching solo de código. A diferencia de data-sveltekit-preload-data, descarga el bundle de JavaScript de una ruta sin ejecutar su función load. Acepta cuatro valores en orden decreciente de agresividad:

"eager" — precarga el código de cada enlace en la página inmediatamente después de cada navegación, sin necesidad de ninguna interacción del usuario
"viewport" — precarga el código de los enlaces a medida que se desplazan hacia el viewport
"hover" — precarga al pasar el cursor o al recibir el foco por teclado (mismo activador que data-sveltekit-preload-data="hover")
"tap" — precarga en touchstart o mousedown

Nótese que "viewport" y "eager" solo se aplican a los enlaces que están presentes en el DOM inmediatamente después de la navegación. Los enlaces agregados posteriormente — dentro de bloques {#if}, por ejemplo — no se precargan de forma anticipada; recaen en el comportamiento de hover o tap.

<!-- src/routes/blog/+page.svelte -->

<!-- Preload the JavaScript bundle for each post as it enters the viewport -->
<ul data-sveltekit-preload-code="viewport">
	{#each data.posts as post}
		<li>
			<a href="/blog/{post.slug}">{post.title}</a>
		</li>
	{/each}
</ul>

Usa data-sveltekit-preload-code cuando quieras que el JavaScript de la ruta esté disponible antes de la navegación pero no puedas predecir o permitirte ejecutar la función load con anticipación — por ejemplo, si la función load llama a una API con límite de tasa o realiza consultas costosas a la base de datos.

preloadData: Prefetching Programático de Datos

La función preloadData de $app/navigation es el equivalente programático de data-sveltekit-preload-data. Llámala con una cadena de URL y SvelteKit ejecutará las funciones load de esa ruta y almacenará el resultado en caché, exactamente como si el usuario hubiera pasado el cursor sobre el enlace.

import { preloadData } from '$app/navigation'

// Start prefetching a specific route
await preloadData('/blog/introduction-to-sveltekit')

La función devuelve una promesa que se resuelve con el resultado de ejecutar las funciones load de la ruta. La forma resuelta es una unión discriminada:

type PreloadResult =
	| { type: 'loaded'; status: number; data: Record<string, any> }
	| { type: 'redirect'; location: string }

En la práctica, rara vez necesitas esperarla (await); dispárala y olvídala cuando la intención sea simplemente calentar el caché.

El prefetching programático es útil en situaciones donde el estado de hover no es significativo, por ejemplo cuando un componente se renderiza en el servidor y el "activador natural" del prefetching es algo distinto a la proximidad del cursor.

Prefetching con IntersectionObserver

Un patrón común es hacer prefetching de una ruta cuando su enlace se desplaza hacia el viewport. Esto es útil para listas paginadas o de scroll infinito donde el usuario claramente se está moviendo hacia una sección de la página:

<!-- src/routes/blog/+page.svelte -->

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

	let { data }: PageProps = $props()

	function prefetchOnVisible(node: HTMLAnchorElement) {
		const observer = new IntersectionObserver(
			(entries) => {
				for (const entry of entries) {
					if (entry.isIntersecting) {
						const href = node.getAttribute('href')
						if (href) preloadData(href)
						observer.disconnect()
					}
				}
			},
			{ rootMargin: '100px' }
		)

		observer.observe(node)

		return {
			destroy() {
				observer.disconnect()
			}
		}
	}
</script>

<ul>
	{#each data.posts as post}
		<li>
			<a href="/blog/{post.slug}" use:prefetchOnVisible>
				{post.title}
			</a>
		</li>
	{/each}
</ul>

La acción de Svelte use:prefetchOnVisible adjunta un IntersectionObserver a cada enlace. Cuando el enlace entra al viewport (con un margen de 100px para que el prefetching comience ligeramente antes de que el enlace sea completamente visible), se llama a preloadData y el observer se desconecta para evitar llamadas repetidas.

Prefetching por Intención Explícita del Usuario

Otro patrón es hacer prefetching en respuesta a una intención clara del usuario, como un resultado de búsqueda que se resalta o una tarjeta que recibe el foco:

<!-- A search results component -->

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

	type SearchResult = { title: string; href: string }

	let { results }: { results: SearchResult[] } = $props()

	function handleResultFocus(href: string) {
		preloadData(href)
	}
</script>

{#each results as result (result.href)}
	<a href={result.href} onfocus={() => handleResultFocus(result.href)}>
		{result.title}
	</a>
{/each}

preloadCode: Prefetching del JavaScript de Rutas

preloadCode es distinto de preloadData. Mientras que preloadData ejecuta funciones load y almacena los datos en caché, preloadCode solo descarga el bundle de JavaScript de una ruta sin ejecutar su función load. Garantiza que el código de la ruta esté disponible en el caché del navegador antes de que el usuario navegue hacia allí.

import { preloadCode } from '$app/navigation'

// Warm the JavaScript cache for all blog post routes
await preloadCode('/blog/*')

preloadCode acepta un pathname o patrón glob, no un patrón de ruta del sistema de archivos de SvelteKit. Usa /blog/* para coincidir con src/routes/blog/[slug]/+page.svelte, o una URL concreta como /blog/my-post para coincidir con una página específica. La notación de corchetes del sistema de archivos [slug] no se utiliza aquí.

El prefetching de código es más valioso en escenarios específicos. El primero es cuando hay bundles de rutas grandes donde el JavaScript de una página compleja tarda un tiempo significativo en descargarse. Para la mayoría de las rutas de SvelteKit con división de código, los bundles son lo suficientemente pequeños como para que la sobrecarga de descarga sea insignificante, pero los dashboards con muchos datos y múltiples componentes pueden tener chunks más grandes. El segundo es cuando la ruta no tiene función load, o los datos de la función load no son predecibles, por lo que el prefetching de datos no es útil pero tener el código en caché sigue siendo de ayuda.

El patrón típico es usar preloadCode para rutas que el usuario probablemente visitará pronto pero donde no se puede predecir la URL específica:

<!-- src/routes/blog/+page.svelte -->

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

	// Preload the blog post bundle as soon as the listing page mounts,
	// since most users landing on the listing will click a post
	onMount(() => {
		preloadCode('/blog/*')
	})
</script>

Cómo Funciona el Caché de Prefetching

Cuando SvelteKit hace prefetching de los datos de una ruta, ejecuta las funciones load y almacena los resultados en un caché en memoria indexado por URL. El caché no se persiste entre cargas de página; es un caché a nivel de sesión que vive mientras el runtime de JavaScript esté activo.

Cuando el usuario realmente navega a una URL con prefetching, SvelteKit verifica primero el caché. Si hay un resultado actualizado disponible, lo usa inmediatamente, haciendo que la navegación se sienta sincrónica. Si la entrada del caché es demasiado antigua o fue invalidada, SvelteKit ejecuta la función load nuevamente.

La duración del caché por defecto corresponde al tiempo que tarda un resultado prefetcheado en expirar antes de que el usuario navegue. SvelteKit no almacena en caché los datos prefetcheados durante minutos; los almacena durante la breve ventana entre el prefetching y la navegación. Un usuario que hace hover durante 200ms y luego hace clic obtiene el resultado del caché. Un usuario que hace hover durante dos minutos y luego hace clic probablemente desencadena una carga nueva.

Cómo Interactúa el Prefetching con el Seguimiento de Dependencias

El caché de prefetching respeta el sistema de seguimiento de dependencias de SvelteKit. Si una función load depende de params.slug y haces prefetching de /blog/post-one, el resultado almacenado en caché está indexado a /blog/post-one. Hacer prefetching de /blog/post-two es una entrada de caché separada. Este es el comportamiento correcto: el caché es específico por URL.

Si una función load declara un identificador depends() personalizado y ese identificador es invalidado antes de que se complete la navegación, el resultado del prefetching almacenado en caché se trata como obsoleto y se descarta. SvelteKit vuelve a ejecutar la función load en la navegación real. Esto garantiza la corrección: nunca verás datos prefetcheados que un invalidate() posterior habría eliminado.

// src/routes/feed/+page.server.ts

export const load: PageServerLoad = async ({ depends, fetch }) => {
	depends('app:feed')

	const res = await fetch('/api/feed/latest')
	return { items: await res.json() }
}

Si esta ruta se prefetchea mientras el usuario está en otra página, y luego se llama a invalidate('app:feed') antes de que ocurra la navegación, el caché de prefetching se limpia y la función load se vuelve a ejecutar en la navegación. El prefetching es una optimización de rendimiento, no una omisión de la consistencia de datos.

Errores Comunes y Anti-Patrones

Precarga de Todos los Enlaces de Forma Incondicional

La precarga de todos los enlaces en una página es tentadora pero poco eficiente. Una página con veinte enlaces podría desencadenar veinte ejecuciones concurrentes de funciones de carga al pasar el cursor, generando veinte llamadas a la API hacia las que la mayoría nunca se navegará. Esto desperdicia recursos del servidor, puede activar límites de frecuencia y puede saturar cachés de bases de datos compartidas con datos obsoletos o irrelevantes.

<!-- Avoid: Blanket prefetching on a large list -->

<ul data-sveltekit-preload-data="hover">
	{#each data.allProducts as product}
		<!-- Each of these prefetches on hover — may trigger hundreds of API calls -->
		<a href="/products/{product.id}">{product.name}</a>
	{/each}
</ul>

<!-- Preferred: Prefetch only high-probability navigation targets -->

<ul>
	{#each data.featuredProducts as product}
		<!-- Featured items are likely to be clicked; prefetch them -->
		<a href="/products/{product.id}" data-sveltekit-preload-data="hover">
			{product.name}
		</a>
	{/each}

	{#each data.otherProducts as product}
		<!-- Long tail items: code-only prefetch or none -->
		<a href="/products/{product.id}">
			{product.name}
		</a>
	{/each}
</ul>

Reserve la precarga de datos para rutas con alta probabilidad de navegación. Use preloadCode para todo lo demás si el tamaño del bundle lo justifica.

Llamar a preloadData Dentro de la Función de Carga

La precarga es una herramienta de rendimiento de navegación del lado del navegador. Llamar a preloadData dentro de una función de carga del servidor o durante el SSR no tendrá ningún efecto y puede lanzar un error dependiendo del entorno.

// Wrong: preloadData belongs in component code, not load functions

export const load: PageServerLoad = async ({ params }) => {
	await preloadData(`/blog/${params.slug}/comments`) // ← No effect on the server
	return { post: {} }
}

<!-- Correct: preloadData called in response to user interaction -->

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

<a
	href="/blog/{post.slug}/comments"
	onmouseenter={() => preloadData(`/blog/${post.slug}/comments`)}
>
	Read comments
</a>

Ignorar las Interacciones con la Plataforma y el CDN

La precarga realiza solicitudes HTTP. Si sus funciones de carga llaman a APIs protegidas por límites de frecuencia, generan carga en el backend o desencadenan consultas costosas a la base de datos, una precarga agresiva puede tener costos reales de infraestructura. Las páginas de acceso público también tendrán sus funciones de carga ejecutadas para solicitudes de precarga provenientes de tráfico no autenticado o generado por bots si dichos bots activan eventos de hover, aunque esto es poco frecuente en la práctica.

Si la función de carga de una ruta es costosa y los usuarios rara vez navegan hacia ella desde una página de listado, prefiera preloadCode sobre preloadData para guardar el bundle en caché sin ejecutar el trabajo del lado del servidor.

Consideraciones de Rendimiento y Escalabilidad

La precarga basada en hover brinda el mayor beneficio en aplicaciones de escritorio con navegación accesible mediante teclado. En aplicaciones móviles donde el hover no tiene significado, la precarga basada en tap proporciona un beneficio menor pero igualmente real. La precarga basada en IntersectionObserver es efectiva para interfaces con muchos listados donde la dirección de desplazamiento del usuario indica intención.

El beneficio de la precarga es proporcional a la latencia de sus funciones de carga. Si sus funciones de carga responden en 10ms desde una caché en memoria, la precarga aporta poco beneficio adicional porque los datos llegan rápidamente incluso sin ella. Si sus funciones de carga tardan entre 200 y 500ms porque realizan llamadas a APIs externas o ejecutan consultas complejas a la base de datos, la precarga al pasar el cursor puede eliminar prácticamente esa latencia percibida para los usuarios que siguen patrones de apuntado normales.

La precarga de código con preloadCode tiene un cálculo de costo-beneficio más claro. El bundle de JavaScript de una ruta se descarga una vez y el navegador lo almacena en caché. El costo es el ancho de banda; el beneficio es que las navegaciones futuras a esa ruta no necesitan descargar el bundle primero. Para rutas con árboles de componentes grandes, bibliotecas específicas de la ruta o bundles de editores, esto puede ser significativo.

Conclusión

La precarga es una de las herramientas de rendimiento más visibles para el usuario en SvelteKit, porque afecta directamente el tiempo entre el clic del usuario y la aparición de la página. Al iniciar las funciones de carga mientras el usuario todavía está decidiendo hacer clic, la precarga de datos basada en hover convierte el tiempo inactivo del puntero en tiempo de red productivo.

El enfoque declarativo con data-sveltekit-preload-data no requiere cambios en el código y es apropiado para la mayoría de los enlaces en la mayoría de las páginas. La función programática preloadData permite un control más fino para disparadores basados en el viewport, interfaces de búsqueda y señales explícitas de intención. preloadCode maneja el caso complementario de calentar la caché de JavaScript sin ejecutar el trabajo de las funciones de carga.

Usado de forma reflexiva, en objetivos de navegación de alta probabilidad con latencia significativa en las funciones de carga, la precarga puede marcar la diferencia entre una aplicación que se siente rápida y una que se siente instantánea.

Puntos Clave

data-sveltekit-preload-data="hover" en un elemento anchor o en un elemento padre activa la precarga de datos cuando el puntero entra al elemento. SvelteKit aplica esto al <body> por defecto en proyectos nuevos. tap se dispara en touchstart o mousedown y es el disparador adecuado para interfaces orientadas al tacto.

preloadData(href) de $app/navigation ejecuta las funciones de carga de una ruta de forma programática y almacena el resultado en caché. Úselo para disparadores basados en el viewport o en la intención mediante IntersectionObserver o eventos de foco.

data-sveltekit-preload-code es el equivalente declarativo para la precarga solo de código. Acepta "eager" (todos los enlaces de la página de inmediato), "viewport" (a medida que los enlaces entran al viewport), "hover" y "tap". Tenga en cuenta que "eager" y "viewport" solo se aplican a los enlaces presentes en el DOM al momento de la navegación, no a los enlaces añadidos dinámicamente.

preloadCode(pathname) descarga el bundle de JavaScript de una ruta de forma programática sin ejecutar su función de carga. Pase un patrón glob como /blog/* para coincidir con rutas dinámicas, o una URL concreta para una página específica. No use la sintaxis [param] del sistema de archivos — preloadCode usa patrones glob.

Ni data-sveltekit-preload-data ni preloadData se activarán cuando navigator.connection.saveData sea true. SvelteKit respeta automáticamente la preferencia de reducción de datos del usuario.

La caché de precarga está indexada por URL y tiene alcance de sesión. Respeta las declaraciones de depends(): si una dependencia personalizada se invalida después de la precarga y antes de la navegación, el resultado precargado se descarta y la función de carga se vuelve a ejecutar. La precarga es siempre una sugerencia de rendimiento, nunca una forma de eludir la consistencia de los datos.

¿Qué Sigue?

La precarga es el último tema importante de rendimiento en esta serie. El artículo final integra todo en el contexto de un tema que depende de casi todos los conceptos tratados hasta ahora: la autenticación. El próximo artículo, Patrones de Autenticación en Funciones de Carga, cubre por qué los guards de autenticación a nivel de layout no son confiables, cómo locals y hooks.server.ts forman la base correcta, y cómo construir una utilidad reutilizable requireLogin() que funcione en cualquier función de carga del servidor de su aplicación.

Lecturas Adicionales

Documentación de Opciones de Enlace de SvelteKit — referencia oficial para data-sveltekit-preload-data, data-sveltekit-preload-code y todos los demás atributos de comportamiento de enlace
SvelteKit $app/navigation — referencia oficial para preloadData, preloadCode, goto e invalidate
Reejecutar Funciones de Carga y Seguimiento de Dependencias — cómo depends() e invalidate() interactúan con la caché de precarga
Carga Paralela y Cómo Evitar Cascadas — el modelo de ejecución de carga paralela que hace efectiva la precarga: entender qué se ejecuta de forma concurrente dentro de una operación de precarga