Speculation Rules API: páginas que cargan antes del clic

La Speculation Rules API permite que el navegador empiece a preparar una página antes de que el usuario termine de hacer clic. No hablamos de comprimir una imagen, minificar un CSS o rezar al santo patrón del hosting compartido, sino de algo más ambicioso: anticipar la siguiente navegación mediante reglas declaradas por el sitio. El navegador puede descargar por adelantado el HTML de una URL probable, o incluso prerenderizarla en segundo plano para activarla casi al instante cuando el usuario entra.

La idea es sencilla, casi grosera de tan evidente: si un visitante está a punto de abrir una página, ¿por qué esperar al clic definitivo para empezar a cargarla? La diferencia está en quién toma la decisión y con qué límites. Con Speculation Rules API no se lanza JavaScript a lo loco para perseguir al usuario por cada enlace. Se entregan instrucciones al navegador, escritas en JSON, para que decida cuándo conviene hacer prefetch o prerender. Y ahí cambia la película. La velocidad deja de depender solo del servidor y empieza a apoyarse en una navegación predictiva, más parecida a tener el plato caliente en cocina antes de que el camarero cante la comanda.

Qué es realmente la Speculation Rules API

La Speculation Rules API es una tecnología de rendimiento web diseñada para acelerar futuras navegaciones entre documentos HTML. Su terreno natural son los sitios multipágina: medios digitales, blogs, ecommerce, webs corporativas, catálogos, documentación, comparadores y cualquier proyecto donde el usuario pasa de una URL a otra mediante enlaces normales. No está pensada para precargar cualquier archivo suelto, ni para sustituir una buena arquitectura, ni para maquillar una web que pesa como un armario de nogal.

La API funciona mediante reglas incluidas en la propia página con un bloque <script type="speculationrules"> o mediante una cabecera HTTP llamada Speculation-Rules, que apunta a un archivo JSON servido con el tipo MIME correcto. En esas reglas se indica qué URLs pueden anticiparse, bajo qué condiciones y con qué nivel de agresividad. El navegador recibe el mapa, mira el comportamiento del usuario y, cuando toca, empieza a cargar una página que quizá se visite en unos milisegundos.

El matiz importa. En prefetch, el navegador descarga la respuesta del documento para tenerla lista. Es una preparación ligera, útil cuando hay una probabilidad razonable de que el usuario pulse un enlace, pero no se quiere gastar demasiada memoria ni CPU. En prerender, el navegador va mucho más lejos: carga la página, sus subrecursos, ejecuta JavaScript y la mantiene como una pestaña invisible. Cuando el usuario entra, la sensación puede ser brutal: la página aparece como si ya estuviera allí. Porque, en cierto modo, ya estaba.

Esto no convierte la web en telepatía. Convierte la navegación en una apuesta controlada. El sitio sugiere, el navegador decide, y el usuario recibe —cuando todo sale bien— una carga mucho más rápida en la segunda, tercera o cuarta página visitada. La primera visita no mejora por arte de la Speculation Rules API, porque no había página previa desde la que especular. Esta tecnología no arregla el arranque inicial, sino los pasos siguientes del recorrido.

Prefetch, prerender y la diferencia que sí se nota

La confusión entre términos es habitual, porque el rendimiento web lleva años usando palabras parecidas para cosas distintas. Preload, prefetch, prerender, precache, lazy load… un pequeño zoológico técnico donde todos parecen primos. La Speculation Rules API se centra en navegaciones futuras de documentos, no en cargar antes una fuente, una imagen hero o un archivo JavaScript crítico. Para eso existen otros mecanismos.

El prefetch especulativo descarga el documento HTML de una página probable y lo guarda de forma temporal para que, si el usuario navega hacia ella, el proceso empiece con ventaja. Es como tener el periódico doblado en el mostrador antes de que el cliente lo pida. No está todo leído, pero ya no hay que buscarlo en el almacén. En términos prácticos, puede reducir tiempos de espera en navegaciones internas, especialmente cuando el HTML se sirve desde caché, CDN o infraestructura rápida.

El prerender es otra bestia. Ahí el navegador no solo trae el documento: lo construye por detrás. Renderiza, carga recursos, ejecuta scripts y deja la página lista para activarse. Si el usuario entra en esa URL, el navegador cambia al documento prerenderizado. La carga parece instantánea porque se ha pagado antes. Y aquí aparece la factura: consumo de memoria, red, CPU y posibles problemas si esa página ejecuta acciones que no deberían ocurrir hasta que una persona la vea de verdad.

Por eso conviene usar prefetch como primer escalón y reservar prerender para rutas con alta probabilidad de clic y bajo riesgo. Una portada de noticias que anticipa el artículo principal puede tener sentido. Una ficha de producto desde una categoría, quizá también, si la intención es clara. Una URL de cerrar sesión, cambiar idioma, añadir al carrito, confirmar una reserva, consumir un cupón o disparar una conversión publicitaria… eso no se toca. Ahí la especulación deja de ser velocidad y se convierte en un gremlin mojado.

Niveles de activación y sentido común

La API incluye además niveles de “eagerness”, la palabra técnica para definir cuándo se activa la especulación. En modo conservador, la carga se dispara muy tarde, cuando el usuario ya está interactuando con el enlace. En modo moderado, puede activarse con señales más tempranas, como mantener el puntero sobre un enlace durante un breve intervalo. En modos más agresivos, el navegador puede empezar mucho antes, pero el riesgo de desperdiciar recursos aumenta. No hay heroicidad en precargar media web si luego nadie la visita. Eso no es optimización; es turismo energético.

Por qué interesa al SEO, aunque no sea una varita de rankings

La Speculation Rules API no es un factor de posicionamiento con etiqueta roja y sirena. Google no premia una web por tener un bloque JSON bonito en el HTML. La importancia viene por otro lado: mejora la experiencia de navegación real, reduce la fricción entre páginas y puede impactar en métricas de rendimiento percibido, especialmente en recorridos donde el usuario hace varias visitas internas.

En SEO técnico hay una tentación permanente de confundir herramienta con resultado. Pasó con AMP, con los Core Web Vitals, con el server-side rendering, con los CDN milagrosos y con cualquier plugin que prometa transformar una web lenta en un guepardo. Speculation Rules API no sustituye a un buen TTFB, no compensa JavaScript excesivo, no arregla imágenes mal servidas, no limpia plantillas pesadas ni convierte un hosting saturado en infraestructura de élite. Lo que hace es ganar tiempo antes del clic.

Ese tiempo puede notarse mucho en sitios con arquitectura multipágina. Pensemos en un medio digital. El usuario entra en una noticia desde Discover, baja, ve una pieza relacionada y roza el enlace. Con reglas documentales y un nivel moderado o conservador, el navegador puede empezar a preparar esa segunda noticia. Si el lector entra, la página aparece antes. Menos espera, menos rebote por impaciencia, más continuidad editorial. No hay que dramatizarlo; tampoco quitarle mérito. En una web donde cada salto interno tiene medio segundo de fricción, reducir esa espera puede cambiar el ritmo de lectura.

En ecommerce ocurre algo parecido. Categoría, ficha, variante, guía de tallas, carrito. Un itinerario con pasos previsibles. Si se anticipan bien las páginas más probables, la tienda se siente más fluida. No necesariamente más “rápida” en laboratorio, porque el primer render inicial seguirá dependiendo de lo que dependa, sino más inmediata en la navegación. Esa diferencia, pequeña en la tabla y grande en el dedo, es la clase de detalle que separa una web pulida de una web que parece caminar con botas mojadas.

La lectura SEO seria es esta: Speculation Rules API trabaja en la capa de experiencia, no en la de relevancia semántica. No va a posicionar un contenido malo. No va a salvar una estrategia editorial hueca. Pero en igualdad de contenido, intención y autoridad, una navegación más suave ayuda a que el usuario siga vivo dentro del sitio. Y eso, aunque no quepa en una promesa de gurú, importa.

Cómo se implementa sin romper la web

La implementación mínima puede ser muy simple. Un bloque de reglas puede indicar al navegador que haga prefetch de una página concreta:

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/servicios/seo-tecnico/"]
  }]
}
</script>

Esto sirve para casos donde la siguiente página es casi obvia. Una landing con un botón principal, una guía dividida en capítulos, una pantalla de onboarding, una página de inicio con un enlace dominante. Pero la web real rara vez es tan limpia. Hay menús, módulos, enlaces relacionados, migas de pan, banners, filtros, paginaciones, avisos legales y ese enlace que alguien añadió en 2019 y nadie se atreve a borrar “por si acaso”.

Para escenarios amplios aparecen las reglas de documento, que permiten seleccionar enlaces existentes en la página mediante condiciones. En lugar de enumerar URLs una a una, se puede decir al navegador que considere enlaces internos, excluyendo rutas peligrosas o elementos marcados con una clase concreta:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": { "href_matches": "/salir/*" } },
        { "not": { "href_matches": "/*?add-to-cart=*" } },
        { "not": { "selector_matches": ".no-speculation" } }
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

Este ejemplo resume bastante bien la filosofía correcta: acelerar lo razonable y excluir lo delicado. Las rutas de logout, acciones de carrito, formularios, cambios de estado, flujos de pago, confirmaciones, filtros con datos muy variables o páginas con personalización fuerte deben tratarse con prudencia. Un enlace que provoca un efecto en el servidor nunca debería depender de que “el usuario seguramente no va a cancelar”. La navegación especulativa hace solicitudes reales. Y una solicitud real, si el backend está mal diseñado, puede tener consecuencias reales.

La forma más sensata de empezar en producción es usar prefetch con eagerness conservador o moderado en enlaces internos seguros. Después, medir. No al revés. Prerenderizar todo el sitio porque suena futurista es una manera elegante de calentar portátiles ajenos. En proyectos con WordPress, desde WordPress 6.8 existe carga especulativa en el núcleo con una configuración prudente, mientras que el plugin oficial del equipo de rendimiento permite ajustar modo y agresividad. En CDNs como Cloudflare, Speed Brain aprovecha la misma idea para anticipar páginas cacheadas, evitando tocar contenido dinámico cuando no conviene.

La implementación técnica también debe convivir con la política de seguridad del sitio. Si hay Content Security Policy estricta, los bloques speculationrules necesitan estar permitidos. Si se entrega por cabecera, el JSON debe servirse correctamente. Si se insertan reglas desde JavaScript, no vale cualquier inyección improvisada con innerHTML; hay formas concretas de registrar el script para que el navegador lo procese. Es un detalle aburrido, sí. También es el tipo de detalle que separa una implementación real de una captura bonita para LinkedIn.

Los riesgos: carritos, analítica, privacidad y recursos desperdiciados

El riesgo más visible es el desperdicio. Si una página se prefetch o prerenderiza y el usuario nunca entra, se han consumido recursos sin retorno. En prefetch el coste suele ser menor; en prerender puede ser considerable. Red, memoria, CPU, batería. En escritorio quizá pase más desapercibido. En móvil, con conexión inestable o modo ahorro de datos, el navegador puede directamente ignorar la regla. Y hace bien. La API no es una orden militar; es una sugerencia.

El segundo riesgo es funcional. Algunas URLs no son inocentes. Una página puede cerrar sesión, cambiar moneda, activar una prueba gratuita, iniciar una descarga, generar un token, enviar un SMS, computar una visita de pago, reducir el cupo mensual de lectura o disparar un evento de conversión. Si esas acciones se ejecutan con una simple solicitud GET durante un prefetch, el problema no es la Speculation Rules API. El problema es una arquitectura que confundió enlaces con botones nucleares. Pero la API puede sacar ese fallo a la luz con una puntualidad cruel.

La analítica merece mención aparte. Una página prerenderizada puede ejecutar JavaScript antes de ser visible, aunque existen mecanismos para detectar si el documento está en prerender y retrasar ciertas acciones hasta la activación. Si se mide una visita antes de que el usuario vea la página, los datos se ensucian. Si se lanza publicidad o tracking de conversión en una navegación especulativa, peor. El remedio pasa por condicionar scripts sensibles a la activación real del documento, revisar eventos, mirar cabeceras como Sec-Purpose en servidor y comprobar cómo se comportan las herramientas de medición. La estadística, esa señora con gafas, no perdona alegremente.

También está la privacidad. La API se diseñó con límites para no convertir cada hover en una filtración de identidad entre sitios. Las especulaciones cross-site están restringidas, sobre todo cuando hay cookies implicadas. El navegador no debe permitir que un sitio pueda saber alegremente si el usuario tiene sesión en otro dominio a base de intentar precargarlo. Por eso muchas de las aplicaciones más fiables se dan en navegaciones internas, dentro del mismo origen o del mismo sitio, donde el control técnico y los riesgos son más manejables.

Hay otro riesgo menos espectacular: creer que todo esto mejora siempre los Core Web Vitals. No necesariamente. Puede mejorar una navegación posterior, puede reducir tiempos percibidos y puede hacer que determinadas cargas sean casi instantáneas. Pero si la página de destino tiene un INP pobre porque cada clic despierta un mamut de JavaScript, el mamut seguirá ahí. Si el layout salta como una persiana rota, seguirá saltando. Si el servidor tarda demasiado en responder en la primera visita, la Speculation Rules API no reescribe la física.

Cómo medirlo en serio

Medir Speculation Rules API exige mirar más allá de Lighthouse. Lighthouse carga una página en condiciones controladas; esta API brilla en navegaciones posteriores y escenarios reales de interacción. El laboratorio ayuda a detectar peso, bloqueo y estructura, pero no cuenta toda la historia. Aquí interesa saber cuántas especulaciones se activan, cuántas se usan, cuántas fallan, qué URLs generan desperdicio y si las páginas aceleradas mejoran métricas de usuario real.

Chrome DevTools incluye una sección específica para cargas especulativas dentro del panel de Application. Allí se pueden revisar reglas detectadas, especulaciones lanzadas, errores, URLs cubiertas y estados de prerender. También puede verse en Network el Sec-Purpose: prefetch para solicitudes de prefetch, aunque el prerender se ejecuta en un proceso separado y requiere herramientas de depuración específicas. Traducido: no basta con “yo lo he puesto y parece que va”. Hay que mirar si el navegador aceptó la regla, si la URL cumplía las condiciones y si la especulación acabó usándose.

En producción conviene cruzar datos de navegador, servidor y analítica. En servidor, las solicitudes especulativas pueden identificarse con cabeceras específicas y separarse de las navegaciones ordinarias. En cliente, APIs como PerformanceNavigationTiming permiten detectar si una navegación llegó desde prefetch o prerender mediante señales como deliveryType o activationStart, según el caso. En analítica, lo sensato es distinguir páginas vistas reales de documentos preparados en segundo plano. Pequeña molestia, gran diferencia.

La métrica que importa no es solo cuántas páginas se adelantaron, sino cuántas páginas adelantadas terminaron siendo útiles. Un hit rate bajo indica que se está especulando demasiado pronto, sobre demasiados enlaces o con mala selección. Un hit rate alto con poco impacto puede significar que las páginas ya eran rápidas, que el cuello de botella está en otra capa o que la activación llega cuando apenas quedaba nada por cargar. La optimización, por desgracia, sigue sin aceptar dogmas. Pide datos. Pesados, grises, maravillosos datos.

En un medio o blog, una prueba razonable podría centrarse en enlaces relacionados, siguiente artículo, portada a noticia principal o categorías con rutas muy transitadas. En ecommerce, fichas más clicadas desde categoría, pasos de checkout seguros y páginas informativas sin efectos secundarios. En SaaS o paneles privados, mucho cuidado: el contenido personalizado, los permisos, los estados de sesión y las operaciones internas hacen que la especulación deba entrar con guantes, no con botas.

Cuándo merece la pena y cuándo conviene dejarla quieta

La Speculation Rules API merece atención en webs con tráfico recurrente entre páginas, HTML cacheable, enlaces internos claros y rutas seguras. Un sitio editorial con muchos lectores que saltan de una noticia a otra puede beneficiarse. Una tienda con categorías y fichas también. Una documentación técnica donde el usuario avanza por secciones, más todavía. Cuanto más previsible sea la siguiente navegación, más sentido tiene anticiparla.

No es tan evidente en aplicaciones de una sola página, donde las transiciones internas no siempre son navegaciones de documento gestionadas por el navegador. En una SPA, la API puede servir para prerenderizar la entrada inicial desde una página anterior, pero no para convertir cada cambio de ruta interna en una navegación especulativa tradicional. Los datos de esas rutas pueden precargarse por otros mecanismos, con lógica propia de la aplicación, pero ya no estamos exactamente en el territorio de Speculation Rules API.

Tampoco es ideal para sitios con páginas muy dinámicas, HTML no cacheable, muchas áreas privadas o rutas llenas de acciones sensibles. En esos casos, la ganancia puede ser menor y el riesgo mayor. Se puede aplicar de forma quirúrgica, claro, pero no conviene encenderla como quien enciende una lámpara del salón. Una web con carrito, cuenta de usuario, reservas, pagos, formularios y personalización debe definir exclusiones con precisión. El navegador puede ser listo; el propietario del sitio debe serlo más.

La compatibilidad es otro punto decisivo. La API funciona principalmente en navegadores basados en Chromium. En navegadores sin soporte, las reglas se ignoran y la web sigue funcionando como antes. Eso es bueno: mejora progresiva, no dependencia frágil. Pero también significa que no todos los usuarios verán beneficios. Para un proyecto con mucho tráfico desde Chrome y Edge, puede ser interesante. Para una audiencia con peso fuerte de Safari o Firefox, el impacto global será más limitado. Otra vez: datos antes que fe.

Hay una regla práctica que rara vez falla. Si una URL puede cargarse de forma segura mediante una solicitud GET sin cambiar nada importante, puede ser candidata. Si una URL cambia estado, personaliza contenido crítico, consume saldo, activa eventos delicados o depende de frescura absoluta, mejor excluirla. La velocidad no compensa una sesión cerrada antes de tiempo, un carrito alterado o una conversión fantasma. Nadie quiere ganar 400 milisegundos para perder la confianza.

La web que se prepara en silencio

La Speculation Rules API representa una evolución lógica del rendimiento web: menos esperar al clic, más preparar el camino cuando la intención empieza a asomar. No sustituye al SEO técnico clásico ni a la buena ingeniería, pero añade una capa muy interesante para mejorar la navegación en sitios multipágina. Bien aplicada, convierte recorridos internos en una experiencia más suave, casi sin costuras. Mal aplicada, puede gastar recursos, manchar métricas o activar rutas que jamás debieron ser simples enlaces.

Su valor está en el equilibrio. Prefetch antes que prerender cuando haya dudas. Eagerness conservador o moderado antes de jugar a la ruleta con cada enlace. Exclusiones claras. Medición real. Y una idea básica, tan antigua como Internet y tan olvidada por algunos paneles de optimización: no todo lo que se puede cargar antes debe cargarse antes. La velocidad buena no mete ruido. Se nota porque desaparece.