Páginas con Carga Instantánea con Speculation Rules

Aprende cómo mejorar los Core Web Vitals haciendo que las páginas se carguen al instante con la Speculation Rules API

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-26

Mejora instantánea de los Core Web Vitals con la Speculation Rules API

¿Alguna vez os habéis preguntado por qué algunas páginas parecen cargarse al instante? Eso es probablemente porque esa página implementó Speculation Rules.

La Speculation Rules API mejora la velocidad de carga de futuras páginas en aplicaciones multipágina (MPAs) ya sea precargando o incluso prerenderizando las mismas. Los desarrolladores pueden configurar speculation rules para sugerir al navegador que precargue o prerenderice documentos para cargas de página más rápidas (o instantáneas). Las speculation rules reemplazan técnicas más antiguas como <link rel="prefetch"> para la precarga de recursos o el obsoleto <link rel="prerender"> exclusivo de Chrome.

Las speculation rules funcionan a nivel de documento, lo que las hace adecuadas para MPAs que implican navegaciones de página completa. Las aplicaciones de página única (SPAs) que utilizan principalmente llamadas a API o actualizaciones parciales de contenido no se beneficiarían tanto de esta API para sus cambios de ruta internos. Sin embargo, las Speculation Rules aún pueden beneficiar a las SPAs prerenderizando el estado inicial de la aplicación desde una landing page, compensando potencialmente el tiempo de carga inicial.

Última revisión por Arjen Karel en febrero de 2026

Inicio Rápido con Speculation Rules

¿Ya sabéis qué son las speculation rules? ¡Genial! Aquí tenéis algunos fragmentos listos para usar y comenzar inmediatamente. Solo elegid el fragmento adecuado para vosotros y colocadlo en el <head> de vuestra página (podéis cambiar prerender por prefetch y/o el eagerness).

<!--
   WordPress speculation rules by corewebvitals.io
   prefetches all internal links
   skips links that match wp-login, wp-admin, wp content
   skips links that have the nofollow attribute
   skips links that have a query string for example: /search?q=welcome
-->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "and": [
                { "href_matches": "\/*" },
                { "not": {
                    "href_matches": [
                        "\/wp-login.php",
                        "\/wp-admin\/*",
                        "\/*\\?*",
                        "\/wp-content\/*"
                    ]
                }},
                { "not": {
                    "selector_matches": "a[rel~=\"nofollow\"]"
                }}
            ]
        },
        "eagerness": "moderate"
    }]
}
</script>
<!-- Data-preload triggered speculation rules by corewebvitals.io -->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "selector_matches": "a[data-preload]"
        },
        "eagerness": "moderate"
    }]
}
</script>

Consejo: si necesitáis crear rápidamente vuestras propias speculation rules, ¿por qué no probáis el <b>generador de speculation rules</b>?

Impacto en el mundo real

Las speculation rules no son teóricas. Los nombres más importantes de la web ya las están utilizando con resultados medibles.

Ray-Ban implementó reglas de prerender en sus páginas de listado de productos con eagerness moderate. El LCP bajó de 4,69 segundos a 2,66 segundos en móvil (un 43% más rápido). Las tasas de conversión móvil aumentaron un 101% y las de escritorio un 156%.

Shopify desplegó prefetch conservative en toda su plataforma en junio de 2025. Sus pruebas A/B mostraron una mejora media de 130ms en escritorio y 180ms en móvil en todas las métricas de pintado.

Cloudflare Speed Brain, lanzado en septiembre de 2024, añade speculation rules a todos los planes de Cloudflare por defecto. Los sitios con precargas exitosas vieron una reducción del LCP del 45%.

Incluso Google Search usa speculation rules: los resultados de búsqueda se precargan con eagerness eager, ahorrando 67ms en el LCP de Android por cada clic.

En los sitios monitorizados por CoreDash, las navegaciones prerenderizadas tienen un LCP p75 de 320ms comparado con 1.800ms para navegaciones estándar en los mismos sitios. Eso es una mejora del 82% con una sola API. Los sitios que usan speculation rules con eagerness moderate ven aproximadamente un 28% de las navegaciones precargadas o prerenderizadas con éxito. Las navegaciones precargadas muestran un TTFB p75 de solo 45ms, porque el HTML ya está en la caché en memoria del navegador.

Beneficios de las Speculation Rules

Mejora de la user experience (UX): Al predecir y precargar contenido, las Speculation Rules aseguran cargas de página casi instantáneas, haciendo que la navegación se sienta fluida para los usuarios. Esto iguala el rendimiento de las aplicaciones de página única incluso para sitios web multipágina tradicionales sin la complejidad y la dependencia de JavaScript. Tiempos de carga más rápidos significan una mejor experiencia de navegación, lo que probablemente aumentará la interacción de los usuarios y reducirá las tasas de rebote.

Ventajas SEO: Dado que la velocidad de página mejorada es un factor de posicionamiento directo y un mejor Time to First Byte resultará en un mejor Largest Contentful Paint, implementar speculation rules seguramente mejorará los Core Web Vitals y os dará esa bonificación de PageSpeed.

Complejidad reducida: Las cargas de página casi instantáneas solían ser posibles solo usando una SPA o escribiendo lógica de prefetch personalizada para MPAs. Para muchos casos de uso, la desventaja de una SPA es el tiempo de arranque inicial, que puede ser considerable ya que dependen en gran medida de JavaScript, y la mayor complejidad comparada con una MPA. Las speculation rules no tienen estos problemas. Esto hace que las cargas rápidas sean alcanzables para una gama más amplia de sitios web, especialmente los centrados en contenido.

La API también simplifica el proceso de decidir qué páginas prerenderizar delegando gran parte de la lógica al navegador. Esto es una gran mejora respecto a métodos anteriores que dependían de JavaScript para hacer estas comprobaciones e inyectar páginas a precargar. Los navegadores pueden tener en cuenta de forma nativa el contexto del usuario, como la memoria limitada en dispositivos móviles o el modo de ahorro de batería, al decidir si prerenderizar. Esta adaptación dinámica ayuda a conservar los recursos del usuario y asegura una experiencia más fluida incluso bajo restricciones.

Otros beneficios: La cabecera HTTP Speculation-Rules permite un despliegue más fácil a través de redes de distribución de contenido (CDN), eliminando la necesidad de modificar directamente el contenido del documento. El control granular con document rules permite a los desarrolladores definir condiciones precisas para la precarga o prerenderizado basándose en patrones de URL o selectores CSS. Esto reduce la especificación manual de URLs y permite conjuntos de speculation rules a nivel de todo el sitio. El ajuste de "eagerness" proporciona un control detallado sobre cuándo ocurre la especulación, equilibrando la velocidad de precarga con el consumo de recursos. Esto ayuda a reducir precargas innecesarias y previene el desperdicio de recursos.

Compatibilidad de navegadores

Las speculation rules están soportadas en Chrome 109+, Edge 109+ y todos los navegadores basados en Chromium. Esto cubre aproximadamente el 79% del tráfico global de navegadores según Can I Use. Firefox ha declarado una posición estándar positiva para la parte de prefetch pero aún no ha implementado el soporte. Safari 26.2 tiene una implementación funcional detrás de un flag pero no está habilitada por defecto.

Para navegadores que no soportan speculation rules, podéis usar detección de características para recurrir a <link rel="prefetch">:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  // browser supports speculation rules
} else {
  // fallback: inject <link rel="prefetch">
  const link = document.createElement('link');
  link.rel = 'prefetch';
  link.href = '/next-page.html';
  document.head.append(link);
}

Mecánica de las Speculation Rules

Las speculation rules se definen usando una estructura JSON y pueden implementarse de dos formas:

  • Script Inline: Incluir el JSON dentro de una etiqueta <script type="speculationrules"> ya sea en el <head> o <body> del documento HTML principal.
  • Cabecera HTTP: Entregar las reglas usando la cabecera HTTP Speculation-Rules en la respuesta del documento. Esta cabecera apunta a un archivo JSON que contiene las reglas, facilitando despliegues CDN más sencillos sin modificar el contenido HTML directamente.

La estructura JSON usa arrays "prefetch" y "prerender" para contener reglas para cada tipo de carga especulativa. Cada regla puede usar diferentes fuentes: ya sea una lista de URLs o document rules.

  • urls (una lista de URLs): Un array de URLs para precargar o prerenderizar.
  • where (document rules): Un objeto que usa condiciones para determinar qué enlaces de la página deberían precargarse o prerenderizarse.

Cada regla se define como un objeto que incluye propiedades como:

  • requires: Un array de strings para establecer restricciones en las especulaciones. Actualmente, el único string válido es "anonymous-client-ip-when-cross-origin", que indica que una precarga cross-origin debería anonimizar la dirección IP del cliente.
  • target_hint: Un string que proporciona una pista sobre el nombre del destino navegable ("_self" o "_blank"), permitiendo al agente de usuario optimizar el proceso de carga.
  • referrer_policy: Una política de referrer para aplicar a las URLs precargadas o prerenderizadas.
  • relative_to (solo para fuente "list"): Especifica si las URLs proporcionadas en el array "urls" son relativas a la URL base del documento ("document") o a la ubicación del archivo JSON de speculation rules ("ruleset").
  • eagerness: Controla la agresividad con la que el navegador debería precargar o prerenderizar. Los ajustes disponibles son "immediate", "eager", "moderate" y "conservative", cada uno con diferentes disparadores.
  • expects_no_vary_search: Una pista que indica al navegador si se espera que la URL especulada tenga una respuesta diferente basada en los parámetros de búsqueda. Útil para páginas con parámetros UTM u otros query strings de seguimiento que no cambian el contenido.

Finalmente, cada regla tiene un ajuste de eagerness que permite definir cuándo deberían ejecutarse las especulaciones, separando cuándo especular de qué URLs ejecutar las especulaciones. El ajuste de eagerness está disponible tanto para reglas de fuente list como document y tiene cuatro configuraciones: immediate, eager, moderate y conservative.

  • immediate: Se usa para especular lo antes posible, tan pronto como se observen las speculation rules.
  • eager: En escritorio se activa después de pasar el cursor sobre un enlace durante 10 milisegundos. En móvil (desde enero de 2026) se activa 50ms después de que un enlace entre en la viewport.
  • moderate: Realiza especulaciones si pasáis el cursor sobre un enlace durante 200 milisegundos (o en el evento pointerdown si es antes, y en móvil donde no hay evento hover).
  • conservative: Especula en pointer o touch down.

Límites de Chrome

Chrome establece límites en las especulaciones concurrentes para prevenir abusos y proteger los recursos del dispositivo:

  • immediate / eager: Hasta 50 precargas y 10 prerenderizados.
  • moderate / conservative: Hasta 2 precargas y 2 prerenderizados (FIFO: las nuevas especulaciones reemplazan las más antiguas).

Chrome también desactiva la especulación por completo cuando el modo Ahorro de datos está habilitado, el dispositivo está en modo Ahorro de energía con batería baja, o el usuario ha desactivado la configuración "Precargar páginas".

Prefetch o Prerender

La Speculation Rules API soporta dos formas principales de carga especulativa: prefetching y prerendering. Aunque ambas técnicas pueden resultar en cargas de página más rápidas, difieren en su complejidad y consumo de recursos.

  • Prefetching es la forma más ligera de carga especulativa. Descarga y almacena en caché el HTML de la URL de destino sin renderizar la página ni sus subrecursos. Este enfoque mejora principalmente el Time to First Byte. Un Time to First Byte mejorado llevará a mejores métricas de pintado como el Largest Contentful Paint y el First Contentful Paint.
  • Prerendering hace mucho más que solo descargar el HTML. Descarga el HTML, todos los subrecursos y renderiza la página completa en una pestaña oculta e invisible. Al navegar a esta página, el resultado es una visualización casi instantánea. Esta técnica mejora el Largest Contentful Paint de más formas que solo mejorando el Time to First Byte. También descarga y renderiza el elemento LCP. El prerendering también puede eliminar el Cumulative Layout Shift porque las dimensiones de los recursos ya son conocidas después del prerendering.

También existe una tercera opción: prerender until script. Esta nueva funcionalidad (Chrome 144, enero de 2026) obtiene el HTML, comienza el renderizado y la carga de subrecursos, pero pausa la ejecución de JavaScript en la primera etiqueta de script bloqueante. Esto elimina los efectos secundarios de los scripts (como el disparo de analíticas) mientras sigue precargando CSS, imágenes y fuentes.

Entonces, ¿qué es mejor? ¿Prerendering o Prefetching? Eso depende de la página y del visitante promedio. Aunque el prerendering puede ser más rápido por diseño, también usa muchos más recursos, tanto en el cliente como en el servidor. La elección entre prerendering o prefetching depende de:

  • Capacidades del dispositivo del usuario: El prerendering podría no ser la mejor opción si un alto porcentaje de visitantes accede desde dispositivos con memoria limitada.
  • Especificidad de la regla de prerender o prefetch. Algunos enlaces tienen más probabilidades de ser clicados y algunas páginas tienen más probabilidades de convertir. Esas páginas son candidatas perfectas para una regla de prerender. Otras páginas podrían ser más adecuadas para prefetch.

Recomendaría precaución contra el prerendering excesivo debido a su demanda de recursos, particularmente en dispositivos móviles o conexiones lentas. Los beneficios potenciales del prerendering deben sopesarse contra el riesgo de degradación del rendimiento y desperdicio de recursos.

Configurar el eagerness correcto

Qué configuración de eagerness usar depende de vuestro sitio. Para un sitio estático muy simple, especular con mayor eagerness puede tener poco coste y ser beneficioso para los usuarios. Los sitios con arquitecturas más complejas y payloads de página más pesados pueden preferir reducir el desperdicio especulando con menos frecuencia hasta obtener una señal más positiva de intención de los usuarios para limitar el desperdicio.

La configuración de eagerness en la Speculation Rules API influye en cuándo un navegador debería precargar o prerenderizar contenido basándose en la navegación prevista del usuario. Esta configuración ofrece un equilibrio entre maximizar los beneficios de la precarga y minimizar el desperdicio de recursos.

El eagerness por defecto para list rules es immediate. Las opciones moderate y conservative pueden usarse para limitar las list rules a URLs con las que un usuario interactúa en una lista específica. En muchos casos, las document rules con una condición where apropiada pueden ser más adecuadas.

El eagerness por defecto para document rules es conservative. Dado que un documento puede consistir en muchas URLs, el uso de immediate o eager para document rules debería usarse con precaución.

Al configurar el eagerness, los desarrolladores deberían tener en cuenta la user experience, los costes de recursos y las limitaciones del navegador. La especulación excesiva puede sobrecargar el ancho de banda, la memoria y la CPU del usuario, degradando potencialmente el rendimiento, especialmente en redes o dispositivos con restricciones. Además, factores como los modos de Ahorro de datos configurados por el usuario, condiciones de batería baja o extensiones del navegador pueden anular las speculation rules, priorizando la conservación de recursos.

Comprobar y depurar speculation rules

Para comprobar las speculation rules de una página, abrid Chrome DevTools, id al panel Application y navegad a Background Services > Speculative Loads > Speculations. (abrid el panel Speculations antes de cargar la página que queréis depurar) Este panel proporciona información sobre:

  • El número de especulaciones exitosas.
  • URLs individuales siendo prerenderizadas o precargadas.
  • El estado de cada especulación.

La pista Network en el panel Performance muestra la actividad de red relacionada con recursos prerenderizados sin necesidad de cambiar el contexto de DevTools. Además, podéis cambiar el contexto de DevTools a una página prerenderizada para inspeccionarla como una página normal.

Monitorización y análisis de Speculation Rules

  • Real User Monitoring (RUM): Usad herramientas RUM para medir la experiencia real de los usuarios. Observad métricas como Largest Contentful Paint (LCP) para evaluar el impacto de las speculation rules en los tiempos de carga de página. Buscad mejoras en el LCP para páginas prerenderizadas comparadas con páginas no prerenderizadas.
  • Pruebas A/B: Realizad pruebas A/B para comparar diferentes configuraciones de speculation rules e identificar la configuración más óptima para vuestro sitio web y base de usuarios específica.

Consideraciones

Consumo de recursos: El uso excesivo de especulación puede impactar negativamente en el ancho de banda, la memoria y el uso de CPU. Comenzad con eagerness conservative o moderate y monitorizad los resultados antes de aumentar.

Compatibilidad de navegadores: No todos los navegadores soportan completamente la Speculation Rules API. Usad el código de detección de características anterior para proporcionar un fallback para navegadores no Chromium.

Privacidad: Los desarrolladores deberían ser conscientes de cómo las speculation rules podrían revelar patrones de navegación del usuario e implementar medidas de privacidad apropiadas. Para prefetch cross-origin, usad el requisito "anonymous-client-ip-when-cross-origin" para enmascarar la IP del cliente a través del proxy de prefetch privado de Chrome.

Analíticas: Las páginas prerenderizadas ejecutan JavaScript, lo que significa que los scripts de analíticas se dispararán antes de que el usuario realmente navegue. Google Analytics y Google Publisher Tag gestionan esto automáticamente. Para otras herramientas de analíticas, retrasad la inicialización hasta que la página se active:

if (document.prerendering) {
  document.addEventListener('prerenderingchange', function() {
    initAnalytics();
  }, { once: true });
} else {
  initAnalytics();
}

La Speculation Rules API ofrece un enfoque poderoso para mejorar el rendimiento y la user experience de las aplicaciones web. Al comprender su mecánica, beneficios y consideraciones, los desarrolladores pueden usar esta API para construir sitios web más rápidos y atractivos.

Speculation Rules y WordPress

Desde WordPress 6.8 (abril de 2025), las speculation rules están integradas en el núcleo de WordPress. La configuración por defecto usa prefetch con eagerness conservative, aplicada a todas las páginas del frontend cuando el visitante no ha iniciado sesión y los permalinks están habilitados.

El equipo de Core Performance de WordPress también mantiene un plugin Speculative Loading independiente (más de 40.000 instalaciones activas) que ofrece más control. El plugin proporciona dos grupos de configuraciones:

  • Modo de especulación: Elegid entre prefetch y prerender. El prerendering resultará en tiempos de carga más rápidos que el prefetching. Sin embargo, el prefetching podría ser una opción más segura para contenido interactivo.
  • Eagerness: Elegid entre conservative (normalmente al hacer clic), moderate (normalmente al pasar el cursor) o eager (a la mínima sugerencia). La configuración de eagerness determina la rapidez con la que se activan las cargas especulativas.

Podéis excluir rutas específicas de la especulación usando un filtro PHP:

add_filter(
  'plsr_speculation_rules_href_exclude_paths',
  function($paths) {
    $paths[] = '/cart/*';
    $paths[] = '/checkout/*';
    return $paths;
  }
);

Para más formas de diferir scripts y optimizar la carga, consultad nuestra guía completa.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

Search Console flagged your site?

When Google flags your Core Web Vitals you need a clear diagnosis fast. I deliver a prioritized fix list within 48 hours.

Request Urgent Audit
Páginas con Carga Instantánea con Speculation RulesCore Web Vitals Páginas con Carga Instantánea con Speculation Rules