¿Qué es la Speculation Rules API?

La Speculation Rules API es un mecanismo del navegador Chrome para anticipar la siguiente página que va a visitar un usuario y empezar a prepararla antes de que haga clic. No es una técnica nueva en su idea (precargar recursos existe desde hace años con rel=prefetch y rel=preload), pero sí lo es en su alcance: en lugar de precargar un archivo suelto, puede preparar la navegación completa, incluida la ejecución de JavaScript.

Sustituye a la antigua etiqueta link rel=prerender, que Chrome retiró por su coste de recursos poco controlado. La nueva API define reglas mediante un bloque script type=speculationrules con formato JSON, lo que permite especificar con precisión cuándo actuar: una lista fija de URLs, o un patrón que aplica a cualquier enlace que cumpla una condición, lo que la especificación llama document rules.

Es una función específica de navegadores basados en Chromium; no forma parte de un estándar universal soportado por todos los navegadores a fecha de esta redacción. Para el resto de navegadores, la página se sigue cargando de la forma habitual, sin el adelanto que aporta esta API.

La API distingue dos acciones. Prefetch descarga el documento de destino y lo guarda en memoria, sin ejecutarlo ni renderizarlo; es la opción más ligera. Prerender va más allá: carga la página completa en una pestaña oculta, ejecuta su JavaScript y la deja lista para mostrarse, de modo que al hacer clic el navegador solo tiene que sustituir la pestaña visible por la ya preparada, sin tiempo de carga perceptible.

Cuándo se dispara cada acción lo controla el parámetro eagerness, con cuatro niveles: immediate actúa en cuanto el navegador ve la regla, eager la dispara tras una interacción mínima (unos 10 milisegundos de ratón sobre el enlace en escritorio), moderate espera una interacción más clara (unos 200 milisegundos, o el inicio de un toque en móvil), y conservative solo actúa cuando el usuario ya ha empezado a pulsar. A mayor eagerness, más rápido llega el contenido, pero también más peticiones se lanzan sin necesidad real.

Las document rules permiten definir el criterio con selectores CSS o patrones de URL (href_matches, selector_matches), en lugar de listar cada enlace a mano, para que la regla se aplique automáticamente a todos los enlaces de un listado o de una categoría.

La función se introdujo en Chrome 109, en enero de 2023; el parámetro eagerness llegó en Chrome 121, y versiones posteriores (136, 138) han añadido más control, incluida la posibilidad de indicar en qué pestaña debe activarse el resultado.

Cuando las imágenes ya están comprimidas y el servidor responde rápido, el margen que queda para mejorar el LCP (Largest Contentful Paint) suele estar en la propia navegación: el tiempo que tarda el navegador en empezar a cargar la página siguiente después del clic. Prerender puede reducir ese tiempo a prácticamente cero, porque la página ya estaba cargada cuando el usuario hizo clic.

Es la explicación técnica detrás de sitios que «aparecen» sin el parpadeo habitual de carga: no es que el servidor sea más rápido, es que el navegador empezó a trabajar antes del clic. Para un sitio que ya ha agotado las optimizaciones de imagen y de servidor, es de los pocos recursos que quedan para seguir bajando el LCP.

El coste está en el otro lado: cada prerender consume ancho de banda y CPU del visitante aunque no llegue a usarse, así que aplicarlo sin criterio a listados largos puede cargar páginas que nadie visitará. Por eso existe el parámetro eagerness: para que ese coste se pague solo cuando hay una señal razonable de que el usuario va a hacer clic. Ignorar ese equilibrio significa regalar velocidad real o gastar capacidad de servidor sin necesidad.

• Empieza por prefetch en listados largos (resultados de búsqueda interna, catálogos) y reserva prerender para las rutas más previsibles, como el siguiente paso de un embudo de compra.
• Usa eagerness moderate o conservative en enlaces poco predecibles, y eager o immediate solo donde el siguiente clic es casi seguro, por ejemplo un botón de siguiente en una paginación.
• No apliques prerender a páginas con efectos secundarios al cargar, como una compra, un envío de formulario o un evento de analítica no deseado; la carga sucede aunque el usuario no haga clic.
• Mide el impacto real en el LCP con datos de campo (CrUX), no solo en laboratorio: el comportamiento cambia según el dispositivo y la conexión del visitante.
• Revisa el consumo de datos en dispositivos móviles con conexión limitada antes de activar reglas amplias basadas en listas o patrones (document rules).
• Comprueba el soporte del navegador antes de depender de esta técnica como única mejora de rendimiento: a fecha de esta redacción es específica de navegadores basados en Chromium.

• Aplicar prerender a todo el listado de resultados sin filtrar, lo que multiplica peticiones y puede saturar la conexión del visitante sin mejorar la experiencia real.
• Confundir prefetch con prerender: prefetch no ejecuta JavaScript ni renderiza, así que no ofrece el mismo salto de velocidad ni sirve para el mismo caso de uso.
• No comprobar que la página de destino no tiene efectos secundarios al cargarse, lo que puede disparar acciones no deseadas antes del clic real.
• Tratarlo como sustituto de optimizar imágenes o servidor, cuando es un recurso adicional que solo rinde una vez agotadas esas mejoras.
• Suponer que mejora el rastreo o la indexación: un rastreador de buscadores no navega como un usuario en Chrome, así que esta técnica no cambia cómo se accede a la página desde fuera del navegador, solo la experiencia del visitante humano.