La feature prefetch y sus cuatro estrategias
Activar la feature prefetch de Astro con una línea de configuración, marcar enlaces con data-astro-prefetch y dominar las cuatro estrategias de precarga —hover, tap, viewport y load— entendiendo el coste de red de cada una, su intención implícita, cómo el foco por teclado también dispara la precarga, y por qué anticipar es una apuesta disciplinada sobre lo que hará el visitante.
Entre el instante en que un visitante decide ir a otra página y el momento en que su clic aterriza transcurre casi siempre más de un segundo: el tiempo de leer el enlace, mover el puntero y apuntar. Esa pausa es un regalo que casi nadie aprovecha. La feature prefetch de Astro la convierte en trabajo útil: trae en segundo plano el documento de destino antes del clic, de modo que cuando la navegación ocurre el HTML ya está en caché y la página siguiente aparece casi al instante. No es un router pesado ni magia; es anticipación apoyada en primitivas del navegador, activable con una sola línea.
- Activar la feature
prefetchdesdeastro.configy entender qué inyecta. - Consentir la precarga enlace por enlace con el atributo
data-astro-prefetch. - Distinguir las cuatro estrategias:
hover,tap,viewportyload. - Elegir estrategia según el coste de red y la probabilidad de la visita.
Activar la feature: una línea que abre la puerta
La precarga en Astro es opt-in, y esa decisión de diseño importa: no gastas ancho de banda de nadie hasta que lo pides explícitamente. Se enciende con una clave en la configuración.
// astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
prefetch: true,
});
Con prefetch: true, Astro añade un pequeño script de precarga a todas las páginas del sitio.
Pero ese script no actúa por su cuenta: se queda a la espera, y solo precarga los enlaces que tú hayas marcado.
Habilitar la feature y precargar un enlace son dos actos distintos —el primero prepara la maquinaria, el segundo la dispara— y entender esa separación evita la falsa impresión de que activar prefetch ya carga medio sitio.
Conviene fijar un límite desde el principio: la precarga solo opera sobre enlaces internos de tu propio sitio, nunca sobre enlaces externos. Tiene sentido, porque precargar un dominio ajeno ni acelera tu navegación ni está bajo tu control.
Si más adelante activas las View Transitions con el <ClientRouter />, verás que la precarga se enciende sola y con un comportamiento más agresivo. Lo trataremos en su lección, pero anótalo ya como excepción a la regla del opt-in.
data-astro-prefetch: consentir enlace por enlace
El interruptor concreto es un atributo de datos sobre el ancla. Añadir data-astro-prefetch a un <a> es decirle a Astro este destino sí, precárgalo.
<a href="/blog" data-astro-prefetch>Blog</a>
<a href="/docs" data-astro-prefetch="tap">Docs</a>
Cuando escribes el atributo sin valor, Astro aplica la estrategia por defecto, que es hover. Cuando le das un valor —tap, viewport, load— fuerzas esa estrategia para ese enlace concreto, por encima de cualquier valor por defecto.
Así, el mismo sitio puede precargar la mayoría de sus enlaces al pasar el ratón y, a la vez, tratar un destino caro con una estrategia más tacaña, sin tocar la configuración global.
<a href="/destacado" data-astro-prefetch="viewport">Destacado</a>
<a href="/normal" data-astro-prefetch>Normal, usa hover</a>
<a href="/caro" data-astro-prefetch="tap">Caro, apuesta tarde</a>
<a href="/todo" data-astro-prefetch="load">Precarga al cargar</a>
Cada enlace declara su propia apuesta, y esa granularidad es la clave de la eficiencia. No todos los destinos merecen la misma anticipación: el botón principal de una landing casi seguro se va a pulsar, mientras que un enlace al aviso legal casi nunca.
Marcar solo lo probable, y con la intensidad justa, es lo que separa una precarga que acelera de una que malgasta. La feature te da el control fino; la responsabilidad de usarlo con cabeza es tuya.
Las cuatro estrategias y su coste
Astro ofrece cuatro estrategias, y cada una responde a una pregunta distinta: ¿en qué momento es razonable apostar a que este enlace se va a pulsar? De la más conservadora a la más agresiva:
hover—la de defecto— precarga al pasar el ratón por encima o al enfocar el enlace con el teclado. Apuesta sobre la intención: quien apunta suele pulsar. Coste bajo y muy buena relación acierto/gasto.tapprecarga justo antes del clic, en elpointerdownotouchstart, ese puñado de milisegundos entre que el dedo baja y el evento de clic se emite. Es la más barata: solo gasta cuando la pulsación es ya casi segura. Ideal en móvil.viewportprecarga en cuanto el enlace entra en pantalla, con un observador de intersección. Apuesta sobre la visibilidad, no sobre la intención, así que precarga muchos más enlaces: útil para destinos muy probables, caro en páginas con listas largas.loadprecarga todos los enlaces marcados en cuanto la página termina de cargar. Es la más agresiva y la que más ancho de banda consume; reservada para sitios pequeños donde casi cualquier enlace es un destino plausible.
Un detalle fino y muy sensato: si el visitante navega en modo de ahorro de datos o con una conexión lenta, Astro degrada automáticamente cualquier estrategia a tap. La precarga no ignora el contexto de red; se vuelve tímida cuando debe.
Hay además una capa de detección de intención: un roce fugaz del ratón o un scroll veloz no disparan la precarga. Solo el gesto que sugiere una decisión real —detenerse sobre el enlace, enfocarlo— cuenta como señal, y así se evitan los mil falsos positivos de un puntero que solo cruza la pantalla.
El foco también cuenta: precarga accesible
La estrategia hover engaña con su nombre, porque no depende solo del ratón: también se dispara cuando el enlace recibe foco por teclado.
Quien navega con el tabulador —por preferencia o por necesidad— obtiene la misma anticipación que quien apunta con el puntero, sin que tengas que hacer nada especial.
Esa simetría no es un adorno. Atar la precarga únicamente al ratón dejaría fuera a parte del público y ligaría el rendimiento a un dispositivo concreto; atarla también al foco la vuelve universal.
Es un recordatorio de que las buenas primitivas de rendimiento y las buenas prácticas de accesibilidad suelen apuntar en la misma dirección: servir a la intención del visitante, la exprese como la exprese.
flowchart TD A[enlace con data-astro-prefetch] --> B[estrategia elegida] B -->|al enfocar o pasar el raton| H[hover] B -->|justo antes del clic| T[tap] B -->|al entrar en el viewport| V[viewport] B -->|al cargar la pagina| L[load] H --> R[documento en cache antes del clic] T --> R V --> R L --> R R --> N[navegacion casi instantanea] style A fill:#89b4fa,color:#11111b style R fill:#f9e2af,color:#11111b style N fill:#a6e3a1,color:#11111b
hover
Precarga al apuntar o enfocar. La opcion por defecto: apuesta sobre la intencion con muy buen equilibrio.
tap
Precarga en el pointerdown, milisegundos antes del clic. La mas barata y la reina en movil.
viewport
Precarga al entrar en pantalla. Potente para destinos probables, cara si hay muchos enlaces.
load
Precarga todo al cargar la pagina. Maxima anticipacion, maximo gasto: solo para sitios pequenos.
Bajo el capó, Astro usa <link rel="prefetch"> cuando el navegador lo soporta y cae a la fetch() API cuando no. En ambos casos el documento acaba en la caché del navegador con prioridad baja, listo para servirse sin red en cuanto navegues. Que sea prioridad baja es deliberado: la precarga no debe robarle recursos a la página que el visitante está mirando ahora. Recuerda además que solo aplica a enlaces internos; un href a otro dominio se ignora.
Si vienes de una versión antigua puede que recuerdes la integración @astrojs/prefetch. Quedó obsoleta: la precarga es hoy una feature del núcleo, sin instalar nada. La equivalencia es directa —lo que antes marcabas para el viewport ahora es data-astro-prefetch="viewport", y lo que precargabas por intención es data-astro-prefetch o data-astro-prefetch="hover"— y ya no necesitas ajustar límites a mano, porque la feature actual programa y agenda la precarga de forma óptima por su cuenta.
Las dos estrategias basadas en presencia —viewport y load— tienen un coste que crece con la cantidad de enlaces en pantalla o en la página. En un índice de blog con cincuenta entradas, load dispararía cincuenta descargas de las que el visitante abrirá una o ninguna. La regla práctica: usa hover o tap por defecto y reserva viewport/load para páginas con pocos destinos y alta probabilidad de clic. La anticipación es una apuesta, y apostar a todo es, casi siempre, perder.
Si no sabes qué estrategia poner, hover es la respuesta por defecto correcta casi siempre: barata, guiada por intención y accesible por foco. Sube a viewport o load solo para los pocos destinos que de verdad se encadenan, y hazlo cuando tengas una razón —o mejor, una medición— que lo respalde. Es más fácil volverse agresivo con un enlace concreto que descubrir tarde que estabas precargando medio sitio sin querer.
La feature prefetch parece un truco de velocidad, pero por debajo es un problema de teoría de la decisión bajo incertidumbre. Cada precarga es una apuesta: gastas ancho de banda ahora, contra el futuro incierto de que el visitante pulse ese enlace después. Si aciertas, cambias una descarga de red por una lectura de caché y la navegación se siente instantánea; si fallas, has gastado datos de alguien —a veces datos móviles que paga de su bolsillo— por una página que nunca verá. Las cuatro estrategias no son cuatro implementaciones distintas de lo mismo: son cuatro posiciones distintas en la curva que enfrenta probabilidad contra coste. tap apuesta tardísimo, cuando la certeza es casi total y el margen de aceleración, mínimo; load apuesta tempranísimo, cuando la certeza es baja y el margen, máximo; hover y viewport viven en el medio, la primera leyendo intención y la segunda leyendo presencia. Elegir estrategia es, por tanto, elegir dónde quieres situarte en ese compromiso, y la respuesta correcta depende de dos cantidades que solo tú conoces: cuánto cuesta el destino y con qué probabilidad se visita. Interiorizar esto cambia la forma de trabajar: dejas de preguntarte ¿activo prefetch? —una pregunta de sí o no— y empiezas a preguntarte ¿qué apuesta merece cada enlace? —una pregunta de diseño—. La precarga bien hecha no es la que precarga más, sino la que acierta más veces por cada byte que arriesga. Ese es el criterio que gobierna todo lo que viene en este nivel.
- Activa
prefetch: trueenastro.config.mjsy comprueba en la pestaña de red del navegador que sin marcar ningún enlace no se precarga nada. - Añade
data-astro-prefetcha un enlace y observa cómo, al pasar el ratón, aparece una petición de baja prioridad para el documento de destino. - Cambia ese enlace a
data-astro-prefetch="tap"y confirma que ahora la precarga se retrasa hasta elpointerdown, justo antes del clic. - Recorre con el teclado hasta enfocar un enlace
hovery verifica que la precarga también se dispara sin usar el ratón.