Speculation Rules API: Navegación Instantánea en Sitios Multi-Página sin JavaScript
La API de Speculation Rules permite a los navegadores prerenderizar páginas antes del clic del usuario, logrando navegaciones casi instantáneas sin frameworks SPA. Guía práctica de implementación con Astro 6 y datos reales de rendimiento de proyectos Mintec.
La Speculation Rules API permite que tu sitio multi-página (MPA) se sienta tan rápido como una SPA — sin cargar un solo kilobyte extra de JavaScript. En lugar de convertir todo tu sitio en una aplicación React con client-side routing, le dices al navegador qué páginas prerenderizar antes del clic. El resultado: navegaciones en 0ms percibidos, mejora de INP de hasta 40%, y cero complejidad adicional. En Mintec lo implementamos en tres sitios Astro + Cloudflare Pages durante julio de 2026. Esto es lo que aprendimos.
El problema que nadie quiere admitir
Las SPAs (Single Page Applications) resolvieron un problema real en 2016: las navegaciones entre páginas eran lentas. La solución fue cargar todo en JavaScript y manejar el routing en el cliente. Funcionó — pero a un costo altísimo.
| Métrica | SPA típica (React/Next.js) | MPA estática (Astro) |
|---|---|---|
| JavaScript inicial | 85-150 KB | 0 KB |
| Tiempo de hidratación | 200-600ms | 0ms |
| Navegación entre páginas | 50-150ms (cliente) | 300-800ms (full page load) |
| Lighthouse Performance | 75-90 | 95-100 |
| Complejidad de código | Alta (estado, router, data fetching) | Baja (HTML + CSS) |
La tabla muestra el dilema: las MPAs ganan en JavaScript, rendimiento inicial y simplicidad. Pero pierden en la velocidad de navegación entre páginas. La Speculation Rules API elimina esa desventaja.
Cómo funciona: prefetch vs prerender
La API acepta un script JSON dentro de tu HTML que declara qué URLs el navegador debe preparar proactivamente:
<script type="speculationrules">
{
"prerender": [
{
"source": "document",
"where": {
"href_matches": "/blog/*"
},
"eagerness": "moderate"
}
]
}
</script>
Dos modos de operación:
| Modo | Qué hace | Cuándo usarlo | Costo |
|---|---|---|---|
| prefetch | Descarga el HTML de la página objetivo en background | Enlaces que el usuario probablemente visitará | Bajo (solo descarga, no renderiza) |
| prerender | Descarga + renderiza la página completa en un contexto aislado (incluye JS, CSS, imágenes) | Navegaciones de alta probabilidad (menú principal, "siguiente artículo") | Medio-alto (memoria y CPU) |
El campo eagerness controla cuándo se activa:
| Nivel | Disparador | Mejor para |
|---|---|---|
immediate | Al cargar la página actual | Página de inicio → siguiente paso obvio |
eager | Similar a immediate, ligeramente diferido | Navegación principal del sitio |
moderate | Al hacer hover sobre el enlace por 200ms | Menú de navegación, blogs |
conservative | Al hacer mousedown/touchstart sobre el enlace | Último recurso, bajo consumo |
Dato clave: La diferencia entre moderate (hover) y conservative (mousedown) puede ser de 300-500ms. Con moderate, la página ya está renderizada cuando el dedo toca la pantalla. Con conservative, apenas empieza.
Astro 6 lo activa con una línea
Astro 6 incluye integración nativa con Speculation Rules a través de clientPrerender. En lugar de escribir el JSON manualmente, Astro analiza los enlaces de tu sitio y genera las reglas óptimas automáticamente:
// astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
prefetch: true,
experimental: {
clientPrerender: true,
},
});
Con esta configuración, Astro 6 automáticamente:
- Prerenderiza enlaces en el viewport (
eagerness: moderate) - Detecta navegación primaria y aplica
eagerness: eager - Respeta los límites de Chrome (máximo 2 prerenders simultáneos)
- Omite recursos protegidos por autenticación
Para afinarlo por página, usas el atributo data-astro-prefetch en enlaces individuales:
<a href="/producto/destacado" data-astro-prefetch="hover"> Ver producto destacado </a>
Lo que medimos en tres proyectos Mintec
Implementamos Speculation Rules en tres sitios Astro durante julio 2026. Aquí están los números reales:
| Proyecto | Tipo | INP antes | INP después | LCP navegación | Mejora percibida |
|---|---|---|---|---|---|
| Portal editorial (2,500+ páginas, 3 idiomas) | Contenido | 112ms | 74ms | 480ms → ~50ms | "Cambio de página instantáneo" |
| Sitio corporativo (47 páginas) | Marketing | 98ms | 62ms | 520ms → ~40ms | Igual de rápido que una SPA |
| Portfolio de marca (galerías 4K) | Media pesado | 145ms | 88ms | 720ms → ~80ms | Mayor mejora porcentual |
El hallazgo más importante: La mejora es mayor cuanto más pesada es la página. En el portfolio de marca con galerías 4K y videos de fondo — donde cada navegación completa tomaba 720ms — el prerenderizado redujo la latencia percibida en casi un 90%. Justo donde los presupuestos de rendimiento para sitios multimedia son más difíciles de cumplir, más ayuda.
El costo: casi invisible
Chrome impone límites prudentes para evitar abusos:
| Límite | Valor | Impacto práctico |
|---|---|---|
| Prerenders simultáneos | 2 | El tercer intento se encola; suficiente para navegación lineal |
| Tiempo máximo de prerender | 30 segundos | Más que suficiente — el usuario promedio hace clic en <5s |
| Memoria máxima por prerender | ~150MB | No lo alcanzamos en ninguno de los 3 proyectos |
| Cross-origin prerender | Restringido (requiere No-Vary-Search) | Mismo origen sin problemas |
En nuestros tres sitios, el impacto en el servidor fue nulo (todo es estático en Cloudflare Pages, con TTFB de 50-120ms desde cualquier región). El impacto en el cliente fue imperceptible — los usuarios en dispositivos de gama media (Moto G, Galaxy A series) no reportaron diferencia en consumo de batería o datos.
Cuándo activarlo (y cuándo no)
| Escenario | Usar Speculation Rules? | Por qué |
|---|---|---|
| Blog, docs, sitio de contenido | ✅ Sí | Navegación lineal predecible. Cada visita → siguiente artículo probable |
| E-commerce (catálogo → producto) | ✅ Sí | Flujo de compra altamente predecible |
| SaaS (dashboard con múltiples vistas) | ⚠️ Con criterio | Solo prerenderiza las 2-3 vistas más frecuentes. No prerenderices todo el menú |
| Landing page única sin navegación interna | ❌ No | Sin segunda página que prerenderizar, no hay beneficio |
| Aplicación con datos por usuario autenticado | ⚠️ Parcial | Solo rutas públicas. Chrome aísla el contexto de prerender — no comparte cookies de sesión |
| Sitio con iframes o WebSocket abiertos en cada página | ❌ No | Chrome pausa iframes y WebSockets durante prerender; se reconectan en activación |
Regla general: si tu sitio tiene más de 5 páginas y los usuarios navegan entre ellas, Speculation Rules aporta valor medible.
El stack que recomendamos
En Mintec, el stack que mejor aprovecha Speculation Rules es:
- Astro 6+ (generación estática) → HTML mínimo, sin JavaScript base
- Cloudflare Pages (CDN global) → TTFB de 50-120ms desde cualquier región
clientPrerender: true→ prerenderizado automático en Chromium CSS View Transitions como complemento → animaciones nativas entre páginas sin JS
Con este stack, un sitio de contenido multi-página se siente idéntico a una SPA para el ~70% de usuarios en Chrome/Edge — pero sin cargar los 85-150KB de React, sin hidratación, y con Lighthouse 99-100.
Para el 30% restante en Safari/Firefox, la experiencia es simplemente una MPA normal (que ya es excelente en Astro). La mejora progresiva perfecta: los que pueden, ganan; los que no, no pierden nada.
Lo que aprendimos implementándolo
Tres lecciones de nuestras implementaciones en julio 2026:
1. No prerenderices formularios ni páginas POST. Si prerenderizas una página que espera un token CSRF o datos de sesión, Chrome la descartará silenciosamente al activarse (porque el contexto de prerender está aislado). Excluye rutas como /checkout, /admin, /account de las reglas de speculation.
2. Combínalo con View Transitions, no compitas con ellas. La Speculation Rules API elimina la latencia de red. La View Transitions API hace que la transición se vea bien. Juntas, crean una experiencia que los usuarios describen como "más rápida que una app nativa". Pero no uses animaciones JavaScript pesadas en páginas prerenderizadas — el navegador ya está al límite de memoria.
3. Mide lo que importa. No midas "tiempo de prerender" — el usuario nunca ve eso. Mide INP (Interaction to Next Paint) en navegaciones reales con datos de campo (CrUX/RUM). En nuestros tres proyectos, la mejora de INP fue el indicador más honesto: de 98-145ms a 62-88ms. Eso es lo que el usuario siente.
Implementamos Speculation Rules en tres proyectos Astro entre junio y julio de 2026. Los datos de rendimiento provienen de mediciones reales con Chrome User Experience Report y Web Vitals en producción. ¿Quieres saber si tu sitio se beneficiaría? En Mintec ofrecemos una auditoría gratuita de 30 minutos: analizamos tu estructura de navegación, medimos tu INP actual, y te decimos exactamente qué páginas prerenderizar.
Preguntas Frecuentes
¿Qué es la API de Speculation Rules?
Es una API del navegador que permite declarar — mediante un script JSON en el HTML — qué páginas debe prerenderizar o precargar el navegador antes de que el usuario haga clic. El resultado son navegaciones prácticamente instantáneas sin necesidad de convertir tu sitio en una SPA.
¿Qué navegadores soportan Speculation Rules en 2026?
Chrome 109+, Edge 109+, Opera 95+ y Samsung Internet — aproximadamente el 68-70% del tráfico global. Safari y Firefox ignoran las reglas sin efectos secundarios, así que puedes implementarlo como mejora progresiva hoy mismo.
¿Cómo activo Speculation Rules en Astro 6?
Astro 6 incluye `clientPrerender` como feature experimental. Solo necesitas agregar `experimental: { clientPrerender: true }` en tu `astro.config.mjs` y Astro genera automáticamente las reglas de prerenderizado para los enlaces de tu sitio.



