Speculation Rules: prefetch, prerender y su coste

La promesa de ir más rápido antes de navegar

Una página web puede preparar el destino de un enlace antes de que el usuario pulse. La API Speculation Rules permite declarar posibles navegaciones y pedir al navegador que precargue el documento o, en los navegadores que lo implementan, que lo prerenderice. El premio potencial es una transición más rápida. El coste es trabajar por adelantado en algo que quizá nadie visite.

La diferencia importa. Prefetch recupera el documento HTML del destino y deja que la navegación lo reutilice; no descarga automáticamente todos los recursos secundarios de esa página. Prerender hace mucho más: prepara una página en un contexto invisible, carga recursos y puede ejecutar JavaScript. La segunda opción puede sentirse casi instantánea al activarse, pero consume más memoria, red y trabajo de servidor, y requiere vigilar efectos de scripts, analítica, anuncios, consentimiento y estado dinámico.

Qué se configura realmente

Las reglas se expresan como JSON, dentro de un elemento <script type="speculationrules"> o en un archivo indicado por la cabecera HTTP Speculation-Rules. La regla describe qué enlaces pueden ser candidatos y con qué nivel de urgencia. El estándar HTML vigente define una estructura para prefetch y prerender, pero la conducta final depende de la implementación del navegador y de sus condiciones. MDN clasifica la API como de disponibilidad limitada: no debe tratarse como una función universal ni como sustituto de una navegación normal.

Las reglas pueden seleccionar una lista concreta de URLs o encontrar enlaces del documento mediante patrones y selectores. La segunda modalidad permite que el navegador evalúe enlaces que ya aparecen en la página, en lugar de mantener una lista manual en cada plantilla. La propiedad eagerness expresa cuán pronto especular: desde conservative cuando hay una señal de interacción hasta immediate tan pronto como se descubre la regla. Los nombres describen una intención; no obligan al navegador a descargar cualquier destino ni garantizan que la especulación termine.

Un punto de partida acotado

Este ejemplo muestra una lista de permitidos: solo enlaces con la clase ggh-prefetch se vuelven candidatos. La clase no debe asignarse a enlaces de salida, acciones, cuentas personales o páginas que cambian datos. El ejemplo es una base para adaptar y probar, no un código desplegado en Gaia ni una regla que se haya medido en producción.

<script type="speculationrules">
{
  "prefetch": [{
    "where": { "selector_matches": "a.ggh-prefetch" },
    "eagerness": "conservative"
  }]
}
</script>

Una estrategia de prudencia comienza con pocas páginas internas, estables y ligeras. Las recomendaciones de Chrome para mejorar la carga de la siguiente página aconsejan acotar candidatos y considerar el coste. Se puede ampliar solo tras comprobar cuántas preparaciones terminan en navegación. Un sitio con páginas pesadas, muchos enlaces o alta proporción de usuarios móviles puede desperdiciar ancho de banda si especula demasiado pronto. Si el usuario activa el ahorro de datos o energía, el navegador también puede limitar la función; la aplicación no controla esa decisión.

Prefetch frente a prerender: elegir por coste y certeza

Si no hay una señal clara de qué enlace se abrirá, prefetch es el inicio más moderado: descarga menos que un prerender y no ejecuta toda la página en segundo plano. Si una navegación es muy probable, el destino es estable, el coste es bajo y se han revisado sus scripts, se puede valorar un prerender más limitado. No conviene escogerlo por el simple deseo de obtener una navegación instantánea.

Las reglas generales deben excluir rutas con efectos: cerrar sesión, enviar formularios, añadir al carrito, confirmar una compra, guardar cambios o abrir un paso personalizado. Una solicitud anticipada sigue siendo una solicitud; un prerender puede cargar recursos y ejecutar código antes del clic. Si una página muestra datos de una cesta, una cuenta o parámetros de URL, también hay que impedir que se active con un estado obsoleto. Chrome recomienda no especular páginas que cambian datos y limitar la especulación cuando no se sabe qué hará el usuario.

Un plan de prueba que evita confundir velocidad con tráfico extra

1. Define la navegación: elige una o dos páginas destino frecuentes y comprueba si son públicas, del mismo origen y relativamente estables.
2. Empieza con pocos candidatos: una lista explícita o selector de permitidos es más controlable que «todos los enlaces del sitio».
3. Usa el nivel menos agresivo que responda a la hipótesis: prueba primero prefetch con una señal conservadora; reserva prerender para un caso de alta probabilidad.
4. Revisa el funcionamiento: DevTools de Chrome ofrece un panel de especulación; la guía de depuración de Chrome DevTools explica cómo comprobar candidatos y estados. La pestaña de red puede mostrar solicitudes prefetch con la cabecera Sec-Purpose: prefetch. Comprueba cuántas se activan, fallan, cancelan o quedan sin uso.
5. Compara con una línea base: mide la navegación real antes y después en las mismas páginas y condiciones, incluyendo móvil. No atribuyas una mejora a la regla si cambiaron a la vez caché, imágenes o scripts. Puedes seguir un diagnóstico de rendimiento web sin mezclar cambios.
6. Audita efectos: confirma que analítica, anuncios, consentimiento, personalización y llamadas de red no se ejecutan de manera incorrecta durante un prerender. Las integraciones deben respetar la fase previa a la activación.
7. Amplía o retira: si casi nadie visita un destino especulado, limita la regla o quítala. Si el soporte no es el esperado, conserva la navegación ordinaria como mejora progresiva.

Lo que el estándar no promete

Las reglas son una indicación al agente de usuario, no un contrato de que toda página se cargará. El navegador puede ignorarlas por falta de compatibilidad, configuración del usuario, memoria o ahorro de recursos. La especificación de HTML y la implementación de Chromium tampoco significan que Firefox, Safari y todos los navegadores integrados ofrezcan las mismas capacidades. Comprueba la tabla de compatibilidad de MDN justo antes de implantar y vuelve a revisarla cuando cambie la matriz de navegadores de tu audiencia.

Tampoco sustituyen la optimización de la página destino. Una página lenta, pesada o con JavaScript costoso continúa teniendo ese problema; simplemente puede empezar a consumirse antes. El beneficio debe evaluarse sobre navegaciones activadas y el coste sobre trabajo y datos de todas las especulaciones, incluso las que no terminan en clic.

La decisión sensata

Speculation Rules no es un interruptor de «web rápida». Es una manera declarativa de preparar algunos destinos que se consideran probables. Prefetch ofrece un punto de partida más ligero; prerender puede adelantar más trabajo, pero también amplía la factura y los riesgos de estado. Una lista corta de destinos seguros, una política conservadora y mediciones de uso permiten aprender sin convertir cada visita en una descarga anticipada de todo el sitio.

Fuentes y agradecimientos

• WHATWG, HTML Living Standard, sección «Speculative loading». Agradecemos a sus editores y colaboradores por mantener el modelo y la sintaxis del estándar.
• Chrome for Developers, «Improve next page load performance». Agradecemos al equipo de Chrome por publicar recomendaciones de selección, urgencia y coste.
• Chrome DevTools, «Debug speculation rules». Agradecemos la documentación práctica para observar estados de especulación en el navegador.
• MDN Web Docs, «Speculation Rules API». Agradecemos a MDN por explicar el alcance y las limitaciones de compatibilidad de la API.