Speculation Rules: prefetch y prerender

TL;DR — La API Speculation Rules permite indicar a Chrome o Edge qué página probablemente se abrirá después, para cargarla discretamente en segundo plano antes del clic. Así, la navegación puede parecer casi instantánea. Es una función de velocidad para personas que usan navegadores Chromium; no acelera el rastreo ni mejora directamente el posicionamiento, aunque una experiencia más rápida puede favorecer Core Web Vitals.

Qué es

Normalmente, el navegador comienza a descargar una página después del clic. La API Speculation Rules permite anticipar esa navegación y preparar la página probable. Cuando ocurre el clic, el navegador muestra el documento preparado en lugar de empezar desde cero.

Existen dos formas de preparación y la diferencia es importante:

• Prefetch: descarga discretamente el HTML de la página siguiente. Consume menos recursos y supone un riesgo menor.
• Prerender: carga y renderiza toda la página en una pestaña invisible, incluido JavaScript. Puede ofrecer una navegación instantánea, pero consume más recursos y debe usarse de forma selectiva.

La configuración se declara mediante un pequeño bloque JSON. Puede contener URL exactas o reglas para preparar enlaces que cumplan determinadas condiciones.

¿Ayuda al SEO?

No acelera el rastreo ni la indexación. Googlebot no necesita esta función, creada para visitantes humanos que usan Chrome o Edge.

Sí puede mejorar la rapidez percibida cuando una persona ya navega por el sitio. Esa experiencia puede reflejarse en Core Web Vitals y en conversiones. Ray-Ban, por ejemplo, comunicó mejoras importantes tras prerenderizar productos.

El principal riesgo

La analítica puede registrar visitas inexistentes. Si una página prerenderizada activa un evento «pageview» antes de mostrarse, puede contarse una visita fantasma. El script propio de Google Analytics 4 gestiona este caso, pero muchas otras etiquetas y píxeles necesitan una corrección técnica.

WordPress 6.8 y versiones posteriores activan de forma predeterminada una variante conservadora y segura basada únicamente en prefetch para visitantes sin sesión iniciada.

La pestaña Advanced explica en detalle prefetch, prerender, los niveles de eagerness, las URL que nunca deben prerenderizarse y la corrección del problema de analítica.

TL;DR — La API Speculation Rules (Chromium, Chrome/Edge 109+) permite a un sitio declarar —en JSON, en línea o mediante un encabezado Speculation-Rules— qué URL del mismo sitio debe prefetch el navegador (descargar el documento para reducir el TTFB) o prerender (obtener y renderizar por completo, además de ejecutar JS en una pestaña invisible, para reducir TTFB, FCP y LCP). Eagerness (immediate/eager/moderate/conservative) controla cuándo se activa una regla, por separado de qué URL abarca. No es un mecanismo de rastreo, indexación ni posicionamiento: Googlebot no depende de indicaciones de recursos como estas (según los comentarios generales de Illyes de febrero de 2026) y Google no publica documentación de Search al respecto. Sin embargo, Google Search la usa para hacer prefetch de sus resultados principales y Ray-Ban comunicó grandes mejoras de conversión y LCP; el beneficio es real para las personas mediante Core Web Vitals y la experiencia de usuario. Los principales riesgos son el conteo duplicado en analítica (se corrige con document.prerendering/prerenderingchange), las URL GET que cambian estado (cerrar sesión, añadir al carrito), con las que nunca debe especularse, y la compatibilidad exclusiva con Chromium. Conviene comenzar con prefetch de forma amplia y limitar prerender a una o dos páginas de alta confianza.

Qué es realmente la API Speculation Rules

La API Speculation Rules es una API del navegador —exclusiva de Chromium— que permite indicar qué páginas del mismo sitio deben prepararse antes del clic. Según MDN, está diseñada para mejorar el rendimiento de navegaciones futuras y, como apunta a URL de documentos en vez de archivos de recursos individuales, resulta adecuada para sitios de varias páginas, no para aplicaciones de una sola página. Sustituye al antiguo y obsoleto <link rel="prerender">, exclusivo de Chrome, y supera al ampliamente disponible <link rel="prefetch"> mediante una sintaxis JSON más expresiva.

Las reglas se declaran como JSON, ya sea en línea dentro de un bloque <script type="speculationrules"> o mediante un encabezado de respuesta HTTP Speculation-Rules. Pueden enumerar URL explícitas o hacer coincidir automáticamente enlaces de la página mediante condiciones where/href_matches (las llamadas reglas de documento).

Hay dos acciones especulativas y distinguirlas correctamente es fundamental:

• Prefetch descarga el cuerpo de la respuesta de la página indicada, pero no sus subrecursos. Reduce el TTFB de la página siguiente.
• Prerender obtiene, renderiza y carga la página en una pestaña invisible en memoria: todos los subrecursos, todo el JavaScript e incluso las solicitudes de datos iniciadas por JS. Según MDN, las navegaciones futuras a una página prerenderizada son casi instantáneas. Reduce TTFB, FCP y LCP, pero consume muchos más recursos y entraña mayor riesgo.

La síntesis de Harry Roberts en su guía por capas lo expresa bien: prefetch reduce TTFB; prerender, LCP.

Un matiz técnico poco explicado es que los recursos especulados llegan a la caché de memoria del navegador, cuya recuperación es más rápida que la de la caché HTTP usada por la indicación antigua <link rel="prefetch">. Además, un documento obtenido por prefetch o prerender también llena la caché HTTP. Por eso, incluso una especulación que nunca se activa no supone un desperdicio total: una navegación posterior todavía puede beneficiarse.

Eagerness: cuándo especular, por separado de qué URL

Una decisión de diseño acertada es separar eagerness de la segmentación. La publicación de Barry Pollard sobre las mejoras de la API lo plantea como la separación entre cuándo especular y con qué URL hacerlo. Hay cuatro niveles:

• immediate: especula en cuanto se procesan las reglas (al cargar la página).
• eager: comienza ante la señal más leve.
• moderate: aproximadamente doscientos milisegundos de desplazamiento del puntero sobre el enlace (o al presionar en una pantalla táctil).
• conservative: al presionar con el puntero o tocar; prácticamente ya se hizo clic.

Estas cuatro definiciones deben tratarse como las heurísticas actuales de Chrome, no como una especificación fija. Chrome ha cambiado los activadores móviles exactos más de una vez: trasladó moderate a heurísticas basadas en el área visible y ajustó el momento de eager incluso en enero de 2026. Conviene volver a consultar la documentación vigente antes de citar un umbral exacto de milisegundos o porcentaje en notas de implementación.

Conviene conocer dos mejoras relacionadas. No-Vary-Search permite que el navegador reutilice un documento almacenado en caché que solo difiere en parámetros ignorables, por ejemplo, variantes de una página con etiquetas UTM. El patrón más reciente prerender-until-script, explicado por CoreWebVitals.io, ofrece un punto medio entre prefetch simple y un prerender completo. En el momento de redactar este artículo sigue siendo una acción experimental no disponible de forma general, dentro de una prueba de origen de Chrome, y no una opción predeterminada ya publicada.

Protecciones propias de Chrome

Una regla demasiado amplia no puede saturar accidentalmente el dispositivo. La documentación de prerender de Chrome establece límites estrictos FIFO al margen de la configuración: las reglas con eagerness immediate admiten 50 prefetch y 10 prerender; las reglas basadas en interacción (moderate/conservative), 2 espacios. Chrome también trata prerender como una indicación y una mejora progresiva, no como una garantía: puede rechazarlo según la configuración o las restricciones de recursos, y no renderiza iframes de origen cruzado en una página prerenderizada hasta la activación. Una protección de privacidad integrada también bloquea el prefetch entre sitios cuando ya hay cookies del sitio de destino.

Reglas entre orígenes y funcionamiento interno de una página prerenderizada

Según MDN, prerender está restringido de forma predeterminada a documentos del mismo origen. Es posible prerenderizar entre orígenes dentro del mismo sitio, pero solo si la página de destino lo autoriza mediante el encabezado de respuesta Supports-Loading-Mode: credentialed-prerender. En el momento de redactar este artículo, prerender entre sitios no es posible. Prefetch entre sitios es más permisivo —funciona dentro del mismo sitio y entre sitios—, aunque sigue sujeto a la regla de privacidad que exige que no haya cookies del destino. Se documenta como planificada una autorización más amplia mediante Supports-Loading-Mode, pero aún no se ha lanzado.

Dentro de la pestaña oculta, una página en prerender no equivale a una carga normal. Las API intrusivas (alert()/confirm()/prompt(), requestFullscreen(), Navigator.share()) se bloquean o ignoran; las API asíncronas, como la geolocalización y getUserMedia(), se aplazan hasta la activación; tampoco se ejecutan antes los iframes de origen cruzado ni los scripts de workers. El almacenamiento de sesión recibe un tratamiento especial: una página en prerender comienza con un clon del almacenamiento de sesión de la pestaña, que se descarta al activarse en favor del almacenamiento real. Toda lógica que dependa de este almacenamiento debe probarse antes y después del evento prerenderingchange, no solo durante una carga normal. Para medir los tiempos, document.prerendering y prerenderingchange indican el estado y el momento de activación; PerformanceNavigationTiming.activationStart proporciona el tiempo transcurrido entre el inicio del prerender y la activación.

¿Afecta la API Speculation Rules al SEO, el rastreo o el posicionamiento?

Esta es la pregunta central para profesionales de SEO y suele tratarse de forma superficial. La respuesta precisa tiene dos partes.

Lo que NO hace

No es un mecanismo de rastreo, indexación ni posicionamiento. No existe documentación de Google Search Central que relacione la API Speculation Rules con la forma en que Googlebot rastrea o indexa, porque la API no opera en esa capa. Es una función del navegador para personas que usan Chromium.

La declaración pública más cercana de Google proviene de Gary Illyes en Search Off the Record a comienzos de 2026 y se refiere a las indicaciones de recursos en general, no a la API Speculation Rules por su nombre. Según informó Search Engine Journal, Illyes explicó que la infraestructura de Googlebot dispone de un ancho de banda casi infinito y una resolución DNS muy rápida. Por ello, indicaciones como DNS-prefetch y preload casi no aportan valor a su proceso de rastreo: ya puede comunicarse con los servidores con rapidez y no necesita que se le pida obtener recursos antes. Esto respalda la idea de que se trata de una función para navegadores y visitantes, no para rastreadores, pero debe respetarse su alcance: Illyes hablaba de la familia amplia de indicaciones de recursos, no específicamente de Speculation Rules. Se aplica el mismo criterio en el artículo relacionado sobre resource hints.

También debe aclararse que Bing no ha publicado nada sobre la API Speculation Rules en relación con el SEO. Edge (Chromium 109+) la admite como función del navegador, pero no existe un ángulo relacionado con bingbot o la indexación, tal como cabría esperar de una función de renderizado del navegador y no del rastreador de un motor de búsqueda.

Lo que SÍ puede hacer

Puede mejorar las Core Web Vitals, sobre todo LCP e indirectamente INP al adelantar la ejecución de JavaScript antes de la interacción, para personas reales. Core Web Vitals es una señal de posicionamiento documentada, aunque modesta, dentro del sistema de experiencia de página, por lo que existe una vía indirecta. Sin embargo, el argumento más sólido es la experiencia y la conversión: lograr que la página siguiente parezca instantánea aporta valor comercial al margen del posicionamiento.

Sin exagerar el alcance: Speculation Rules no cambia el rastreo ni la indexación; hace que una página parezca instantánea cuando una persona ya navega por el sitio. Es una palanca de experiencia y Core Web Vitals, no de rastreo.

Resultados reales

Dos casos aportan la evidencia principal y ambos proceden de publicaciones de Google.

Google Search la usa en su propio producto. Según el anuncio del equipo de Chrome de 2025, uno de los primeros usos de estas reglas fue aplicar prefetch a los dos primeros resultados de búsqueda. Las mejoras medidas fueron las siguientes: en Chrome para Android, el LCP de los clics procedentes de Google Search se redujo 67 milisegundos; en escritorio, la mejora similar fue de 58,6 milisegundos. El prefetch basado en pasar el puntero sobre el resto de los resultados redujo el FCP de escritorio 7,6 milisegundos y el LCP, 9,5 milisegundos. Para los resultados entre orígenes, Google Search usa el proxy privado de prefetch de Chrome para anonimizar la solicitud. Es una demostración de que Google confía lo suficiente en la API como para usarla a escala en google.com/search y publicar las diferencias exactas en milisegundos.

El caso de Ray-Ban demuestra el impacto comercial. El caso de web.dev informa que, tras prerenderizar páginas de producto, las tasas de conversión de las PDP aumentaron 101,47 % en dispositivos móviles y 156,16 % en escritorio, con una mejora del LCP del 43 % en ambos. Las tasas de salida bajaron aproximadamente 13 % y las páginas vistas por sesión subieron 51,95 % en dispositivos móviles y 65,30 % en escritorio. La separación de la implementación resulta instructiva: en escritorio se usó eagerness moderate, activado al pasar el puntero sobre las tarjetas de producto; en móviles, donde no existe ese estado, se aplicó immediate solo a las primeras cuatro tarjetas, las más seleccionadas.

La escala ya es considerable: WordPress 6.8 (marzo de 2025) incorpora esta función de forma predeterminada a partir de un complemento que ya estaba presente en decenas de miles de sitios antes de integrarse en el núcleo. Por tanto, una parte relevante de la Web ya ejecuta reglas de especulación sin configuración manual.

Cómo implementarla de forma segura

La secuencia de adopción compartida por la documentación de Google y especialistas independientes es la siguiente:

1. Comenzar con prefetch de forma amplia. Según la guía de implementación, prefetch es relativamente seguro para la mayoría de los sitios y suele ser el punto de partida.
2. Añadir prerender más tarde y con alcance reducido. Chrome advierte contra el exceso de prerender por su costo de recursos y recomienda limitarlo a una o dos páginas. Harry Roberts llega de forma independiente a la misma conclusión: una coincidencia semejante a un comodín es demasiado agresiva; prerenderizar todo suele resultar caro y arriesgado, por lo que conviene exigir inclusión explícita.
3. Usar reglas de documento para escalar sin configuración por página. En vez de enumerar manualmente URL en cada página, una condición where/href_matches las obtiene del documento y permite aplicar un conjunto de reglas en todo el sitio.
4. Revisar la CSP. Los bloques en línea <script type="speculationrules"> necesitan permiso explícito en script-src, mediante 'inline-speculation-rules', un hash o un nonce; de lo contrario, fallan sin aviso cuando existe una Content Security Policy.

Qué NO debe someterse a prefetch ni prerender

MDN y la guía de Chrome dejan claro que nunca debe especularse con determinadas URL, porque una obtención especulativa sigue siendo una solicitud real capaz de provocar efectos secundarios reales. Deben excluirse:

• URL para cerrar sesión.
• URL para añadir al carrito.
• URL para cambiar de idioma o moneda.
• Flujos de inicio de sesión que activan un SMS o código OTP.
• URL que incrementan una cuota de uso o activan el seguimiento de conversiones publicitarias.

La corrección de fondo es de diseño: los cambios de estado, como una acción /logout, no deberían ser enlaces GET simples que una regla pudiera solicitar.

Prerender exige todavía más cautela. Tampoco deben prerenderizarse páginas que modifican el almacenamiento del cliente al cargarse, envían eventos analíticos o impresiones publicitarias durante la carga, o producen efectos secundarios como si hubiera existido una interacción. MDN señala que prerender supone más riesgo que prefetch y debe reservarse para los casos en que compense.

Cómo corregir el problema de analítica

Este problema afecta a sitios reales. Una página prerenderizada se carga por completo antes de mostrarse. Si al cargar se activa un page_view, una impresión publicitaria o un evento de Meta Pixel, se registra una visita inexistente, se inflan las sesiones de GA4 y se distorsiona la atribución.

MDN y las guías de Chrome documentan el mecanismo de corrección:

• document.prerendering vale true mientras la página está en prerender.
• El evento prerenderingchange se activa cuando se produce la activación, es decir, cuando la persona realmente navega a la página.
• Los servidores también pueden detectar solicitudes especulativas mediante el encabezado Sec-Purpose (prefetch o prefetch;prerender).

En la práctica, según la guía de Chrome, algunos proveedores de analítica, como Google Analytics, y de publicidad, como Google Publisher Tag, ya admiten estas reglas y no registran una visualización hasta que la página se activa. El script gtag.js de GA4 lo gestiona automáticamente. Las etiquetas personalizadas de GTM, Meta Pixel y los scripts propios suelen no hacerlo de forma predeterminada. En configuraciones con un administrador de etiquetas, puede retrasarse el propio script del administrador o bloquear código específico hasta que la página se active o sea visible. Se ha documentado un caso real: sitios con WordPress 6.8 que activaban GA4 y Meta Pixel y registraban visitas fantasma tras la habilitación automática de la función; Erwin Hofman explica la corrección en detalle.

Realidad de la compatibilidad con navegadores

Este límite modera las expectativas de retorno: la API Speculation Rules es exclusiva de Chromium (Chrome y Edge 109+) y no pertenece a Baseline. Firefox mantiene una postura favorable sobre el estándar solo para la parte de prefetch, pero no la ha lanzado; Safari dispone de una implementación tras una bandera desactivada de forma predeterminada. Una proporción relevante del tráfico de cualquier sitio —todas las personas que usan Firefox o Safari— no obtiene beneficio alguno, por lo que las expectativas deben ajustarse a esa realidad.

Speculation Rules en WordPress 6.8+

Una gran parte de la audiencia de búsqueda usa WordPress y recibió esta función de forma predeterminada. WordPress 6.8 (marzo de 2025) incorpora Speculative Loading, activo para visitantes sin sesión iniciada y con una configuración conservadora de solo prefetch. El comportamiento puede personalizarse —incluida la activación de prerender para URL clave— mediante el filtro wp_speculation_rules_configuration. Weston Ruter, ingeniero de Google y colaborador del núcleo de WordPress, publicó una guía. La opción predeterminada es deliberadamente segura, por lo que la mayoría de los sitios pueden mantenerla activa; esa misma activación automática explica que el problema de analítica sorprendiera a quienes nunca eligieron habilitarla.

Mitos desmentidos

• «Speculation Rules ayudará a Googlebot a rastrear el sitio más rápido». No. Es una función de renderizado del navegador para personas que usan Chromium; la infraestructura de Googlebot no necesita estas indicaciones y ningún documento de Google relaciona la API con el rastreo.
• «Es lo mismo que <link rel="prefetch">/<link rel="prerender">». No exactamente. Sustituye al obsoleto rel="prerender", exclusivo de Chrome; añade una sintaxis JSON más rica, con reglas de documento y eagerness, y almacena los recursos especulados en la caché de memoria, no solo en la caché HTTP.
• «Prerenderizar todo vuelve instantáneo el sitio completo sin desventajas». No. Chrome advierte contra el exceso, impone límites estrictos, y tanto Google como Harry Roberts recomiendan una o dos páginas prerenderizadas como máximo.
• “If I add speculation rules my analytics just works.” (traducción) «Al añadir reglas de especulación, la analítica funciona sin ajustes». Solo si todos los scripts analíticos y publicitarios esperan mediante document.prerendering/prerenderingchange. GA4 lo hace; muchas etiquetas de GTM y píxeles de terceros, no.
• «La compatibilidad es universal, por lo que sirve como valor predeterminado para todo el tráfico». No. Solo funciona en Chromium y no pertenece a Baseline; Firefox y Safari no la incorporan de forma predeterminada.
• «Prefetch no entraña riesgos, por lo que puede usarse un comodín». Es una exageración. Una coincidencia semejante a un comodín resulta demasiado amplia, sobre todo para URL GET que cambian estado y que no deberían ser enlaces solicitables.
• «Esto mejorará directamente el posicionamiento». Ninguna fuente oficial lo ha establecido como factor directo. La cadena creíble es Speculation Rules → mejores Core Web Vitals y conversiones de personas reales → la señal existente y modesta de experiencia de página, además de beneficios comerciales independientes del posicionamiento.

Dónde encaja

Es un tema de rendimiento web, no de rastreo, y mantener clara esa separación es esencial. Se relaciona estrechamente con las indicaciones de recursos (preload/preconnect/dns-prefetch/prefetch), que comparten la idea de adelantar el trabajo de red del navegador y la misma salvedad de que no ayudan a Googlebot. Alimenta las Core Web Vitals, sobre todo LCP, e interactúa con la caché y una CDN, ya que los documentos especulados llenan las cachés. Como equivalente del lado del rastreador, las solicitudes condicionales explican cómo Googlebot evita volver a descargar páginas sin cambios: es una capa distinta —rastreador, no navegador— que exige la misma disciplina para separar la mecánica de su impacto en el posicionamiento.

Resumen de IA

Síntesis de la versión avanzada:

• Qué es: una API exclusiva de navegadores Chromium (Chrome/Edge 109+) para aplicar prefetch (descargar el documento HTML y reducir TTFB) o prerender (cargar por completo y ejecutar JS en una pestaña invisible, reduciendo TTFB, FCP y LCP) a páginas del mismo sitio antes del clic. Se declara como JSON en línea o mediante un encabezado Speculation-Rules.
• Eagerness (immediate/eager/moderate/conservative) controla cuándo se activa una regla, por separado de qué URL abarca. Chrome impone límites estrictos (50 prefetch y 10 prerender para reglas inmediatas); los activadores exactos son heurísticas dependientes de la versión, no constantes fijas.
• Entre orígenes: prerender funciona de forma predeterminada en el mismo origen; entre orígenes del mismo sitio exige la autorización del destino (Supports-Loading-Mode: credentialed-prerender); prerender entre sitios no es posible. Prefetch es más permisivo, pero sigue sujeto a la regla de privacidad que exige que no haya cookies del destino.
• Realidad del SEO: no es un mecanismo de rastreo, indexación ni posicionamiento. Googlebot no necesita indicaciones de recursos (según los comentarios generales de Illyes de febrero de 2026), Google no tiene documentación de Search al respecto y Bing no ha publicado nada. Sí puede mejorar Core Web Vitals (LCP/INP) y conversiones: una palanca indirecta de posicionamiento y experiencia.
• Evidencia de funcionamiento: Google Search aplica prefetch a sus dos primeros resultados (LCP aproximadamente 58–67 ms menor); Ray-Ban comunicó aumentos de conversión de aproximadamente 100–156 % y una mejora del LCP del 43 % al prerenderizar PDP.
• Mayor riesgo, la analítica: una página especulada que activa un pageview al cargar infla GA4. Se corrige con document.prerendering / prerenderingchange. GA4 lo gestiona de forma nativa; las etiquetas personalizadas de GTM y Meta Pixel a menudo no.
• Nunca deben especularse URL GET que cambien estado: cierre de sesión, incorporación al carrito, cambio de moneda o idioma e inicio mediante OTP. Esas acciones deben rediseñarse para no depender de enlaces GET.
• Orden de adopción: prefetch de forma amplia, prerender en una o dos páginas como máximo y revisión de CSP ('inline-speculation-rules').
• WordPress 6.8+ incorpora carga especulativa conservadora, solo con prefetch y activa de forma predeterminada para visitantes sin sesión iniciada (filtro wp_speculation_rules_configuration para personalizarla).

Documentación oficial

Documentación de fuentes primarias. Los motores de búsqueda no publican nada al respecto como tema de SEO; las referencias autorizadas corresponden al navegador y a los estándares.

MDN / estándares

• Speculation Rules API — referencia técnica sobre sintaxis, prefetch frente a prerender, privacidad, CSP y compatibilidad con navegadores.
• Encabezado HTTP Speculation-Rules — declaración de reglas mediante un encabezado de respuesta en vez de un script en línea.

Chrome for Developers (Google)

• Prerenderizar páginas en Chrome para lograr navegaciones instantáneas — funcionamiento de prerender, su carácter de indicación y no garantía, y los límites FIFO de Chrome.
• Guía para implementar reglas de especulación en sitios más complejos — advertencia sobre analítica, gestión de scripts de terceros y precauciones ante cambios de estado.
• Mejoras de la API Speculation Rules (Barry Pollard, 2024) — reglas de documento, eagerness, No-Vary-Search y reutilización de la caché HTTP.
• Google Search ya usa la API Speculation Rules (Pollard y Busaryev, 2025) — uso por parte de Google y diferencias medidas de LCP/FCP.

web.dev (Google)

• Cómo Ray-Ban duplicó la tasa de conversión mediante prerender — caso sobre el impacto comercial.
• Prefetch, prerender y almacenamiento anticipado en caché — caché de memoria frente a caché HTTP y situaciones que requieren cautela.

WordPress (documentación oficial de la función)

• Speculative Loading in 6.8 (Make WordPress Core) — comportamiento predeterminado y filtro de configuración.
• Speculative Loading feature plugin — complemento en el que se basó su adopción en el núcleo.

Citas de las fuentes

Declaraciones de la documentación primaria del navegador y los estándares, además de publicaciones de Google. Como no es un tema de SEO para motores de búsqueda, no hay citas de Google Search; las fuentes son Chrome, MDN y web.dev.

MDN: qué es y qué hace

• “The Speculation Rules API is designed to improve performance for future navigations. It targets document URLs rather than specific resource files, and so makes sense for multi-page applications (MPAs) rather than single-page applications (SPAs).” (traducción) «La API Speculation Rules está diseñada para mejorar el rendimiento de las navegaciones futuras. Apunta a URL de documentos, no a archivos de recursos específicos, por lo que resulta adecuada para aplicaciones de varias páginas (MPA), no para aplicaciones de una sola página (SPA)». Ir a la cita

Chrome: uso por parte de Google Search (la evidencia más sólida)

• “One of the first uses of speculation rules was to prefetch the first two search results.” (traducción) «Uno de los primeros usos de las reglas de especulación fue aplicar prefetch a los dos primeros resultados de búsqueda». — blog de Chrome for Developers. Ir a la cita
• En Chrome para Android, el LCP de los clics procedentes de Google Search se “reduced by 67 milliseconds.” (traducción) «redujo 67 milisegundos». Ir a la cita
• En escritorio hubo una “similar improvement in LCP of 58.6 milliseconds.” (traducción) «mejora similar del LCP de 58,6 milisegundos». Ir a la cita

Hoja de referencia de Speculation Rules

Prefetch frente a prerender

Eagerness: cuándo se activa una regla (independiente de qué URL)

Límites estrictos de Chrome (al margen de la configuración)

• Reglas immediate: 50 prefetch y 10 prerender.
• Reglas basadas en interacción (moderate/conservative): 2 espacios FIFO.

Referencia rápida entre orígenes

• Prerender: mismo origen de forma predeterminada; entre orígenes del mismo sitio exige que el destino envíe Supports-Loading-Mode: credentialed-prerender; prerender entre sitios no es posible.
• Prefetch: funciona tanto dentro del mismo sitio como entre sitios, sujeto a la regla de privacidad que exige que no haya cookies del destino.

Datos rápidos

• Compatibilidad: solo Chromium (Chrome/Edge 109+). No pertenece a Baseline. Firefox solo mantiene una postura sobre el estándar de prefetch, sin lanzarlo; Safari lo mantiene tras una bandera desactivada de forma predeterminada.
• Declaración como JSON: <script type="speculationrules"> en línea o un encabezado HTTP Speculation-Rules.
• CSP: los bloques en línea necesitan 'inline-speculation-rules' (o un hash/nonce) en script-src.
• Detección de una carga especulativa: document.prerendering, el evento prerenderingchange o el encabezado de solicitud Sec-Purpose.
• No es una señal de rastreo o posicionamiento de Google. Google Search la usa (dos primeros resultados, LCP aproximadamente 58–67 ms menor). WordPress 6.8+ aplica de forma predeterminada prefetch conservador a visitantes sin sesión iniciada.

Qué no debe hacerse

Especular con URL GET que cambian estado. Una obtención especulativa es una solicitud real. Nunca deben someterse a prefetch ni prerender las acciones de cerrar sesión, añadir al carrito, cambiar moneda o idioma, iniciar sesión mediante OTP ni incrementar una cuota. La corrección de fondo es de diseño: esas acciones no deberían ser enlaces GET que una regla pueda solicitar. MDN y la guía de Chrome documentan esta precaución.

Aplicar prerender de forma amplia o mediante un comodín. Chrome impone límites y advierte contra el exceso de prerender por su costo de recursos; Harry Roberts considera demasiado agresiva una coincidencia semejante a un comodín. Debe limitarse a una o dos páginas de alta confianza.

Suponer que la analítica ya funciona correctamente. Si una página prerenderizada activa un pageview al cargar, GA4 se infla con visitas que nunca ocurrieron. gtag.js de GA4 lo gestiona, pero las etiquetas personalizadas de GTM, Meta Pixel y los scripts propios a menudo no. Se comunicaron visitas fantasma de GA4 y Meta en sitios con WordPress 6.8 tras la activación automática. El seguimiento debe condicionarse a document.prerendering / prerenderingchange.

Olvidar la CSP. Un <script type="speculationrules"> en línea falla sin aviso bajo una Content Security Policy, salvo que script-src permita 'inline-speculation-rules' (o un hash/nonce).

Esperar mejoras de rastreo o posicionamiento. No afecta a Googlebot. Presentarla internamente como una «corrección SEO del presupuesto de rastreo o el posicionamiento» crea expectativas erróneas; debe plantearse como una mejora de Core Web Vitals y conversión para visitantes reales en Chromium.

Sobreestimar el alcance. Solo funciona en Chromium. Las personas que usan Firefox o Safari no reciben ningún beneficio de forma predeterminada, por lo que el retorno no debe modelarse como si se aplicara a todo el tráfico.

Ejemplos prácticos

Bloques de reglas mínimos e ilustrativos. La segmentación debe adaptarse al sitio y siempre deben excluirse las URL que cambian estado.

1. Aplicar prefetch a dos URL explícitas (el punto de partida más seguro)

<script type="speculationrules">
{
  "prefetch": [
    { "urls": ["/pricing/", "/features/"] }
  ]
}
</script>

2. Reglas de documento: prefetch de enlaces del mismo sitio al pasar el puntero (moderate)

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}
</script>

3. Prerenderizar una página de alta confianza y excluir rutas peligrosas

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout*" } },
          { "not": { "href_matches": "/cart*" } }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

4. Entregar las reglas mediante un encabezado HTTP en vez de un script en línea

Speculation-Rules: "/speculation-rules.json"

…donde /speculation-rules.json devuelve el mismo JSON con el tipo de contenido application/speculationrules+json. Resulta útil cuando una CSP estricta dificulta los scripts en línea.

5. Evitar que la analítica se active durante prerender

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

Esto aplaza el pageview hasta que la página se activa realmente, el mismo patrón que usa el script propio de GA4.

La analítica aumentó tras lanzar prerender

1. Pausar la regla de prerender, no todo el programa de rendimiento. Debe conservarse una copia de la regla implementada y devolver la ruta afectada a prefetch o desactivar la especulación. Si el tráfico inexplicable desaparece, puede continuarse la investigación de prerender.
2. Separar la activación de la carga en segundo plano. Debe reproducirse el caso en Chromium e inspeccionarse document.prerendering antes de navegar. Si la analítica se activa mientras vale true, la etiqueta registra una página que la persona no ha activado.
3. Identificar el origen del evento. Conviene comprobar por separado GA4, las etiquetas personalizadas de GTM, los píxeles publicitarios y los eventos propios. Si solo una fuente infla los datos, debe corregirse esa integración en vez de debilitar todas las reglas.
4. Condicionar el evento. El pageview o la impresión debe aplazarse hasta prerenderingchange o la activación. Si el proveedor ya admite prerender, debe eliminarse la lógica personalizada que duplica el evento.
5. Reproducir una navegación abandonada. Debe activarse prerender sin hacer clic; el evento debe permanecer ausente. Después se activa una vez la página y se confirma que se registra exactamente un evento.
6. Restaurar con alcance reducido. Debe rehabilitarse un destino de prerender de alta confianza, comparar las navegaciones activadas con los eventos analíticos y ampliar solo si los recuentos se mantienen alineados.

Revisar los efectos secundarios de un conjunto de reglas

Review this Speculation Rules JSON and a list of site routes. Classify every matched
route as safe to prefetch, safe to prerender, or exclude. Explicitly flag logout,
add-to-cart, language/currency switching, OTP, allowance-changing, analytics, storage,
and ad-impression side effects. Check eagerness, scope, and likely resource waste.
Return the smallest safe rule set plus validation and rollback tests. Do not claim a
crawling, indexing, or direct ranking benefit.

Diseñar un lanzamiento por etapas

Create a staged Speculation Rules rollout for this click-path data and browser mix.
Start with prefetch, choose at most one or two high-confidence prerender targets, and
explain why each route is likely enough to justify its cost. Include Chromium-only
segmentation, analytics activation handling, CSP checks, success metrics, an abandoned
navigation test, and rollback triggers. Do not invent conversion or performance gains.

Diagnosticar una especulación ausente

Given this page markup, response headers, CSP, browser version, and DevTools evidence,
diagnose why a speculation rule was not used. Check invalid JSON, CSP blocking,
unsupported browser, rule mismatch, resource limits, cross-origin restrictions, and
browser discretion. Return symptom, evidence, likely cause, smallest fix, and the
exact evidence that would confirm it.

Lista de verificación para un lanzamiento seguro

• Los datos de compatibilidad justifican una mejora progresiva exclusiva de Chromium.
• El lanzamiento inicial usa prefetch; prerender se limita a uno o dos destinos de alta confianza.
• Se excluyen el cierre de sesión, la modificación del carrito, el inicio de sesión o uso de OTP, el cambio de idioma o moneda, la modificación de cuotas y otras rutas GET que cambian estado.
• Las páginas prerenderizadas no modifican el almacenamiento ni activan impresiones antes de la activación.
• La lógica que depende del almacenamiento de sesión se prueba antes y después de prerenderingchange (la página en prerender comienza con un clon que se descarta durante la activación).
• Todo destino de prerender entre orígenes envía Supports-Loading-Mode: credentialed-prerender; no se intenta prerender entre sitios.
• La analítica personalizada y los píxeles comprueban document.prerendering y esperan prerenderingchange cuando corresponde.
• La CSP permite el método de entrega en línea o externo de las reglas.
• La segmentación y eagerness proceden del comportamiento de navegación observado, no de un comodín supuesto.
• DevTools confirma que la regla es válida, admisible y se usa solo en las URL previstas.
• Una carga especulativa abandonada no registra pageview, conversión ni cambio de estado.
• Safari y Firefox siguen recibiendo una navegación normal plenamente funcional.
• Los resultados de rendimiento y negocio se miden en navegaciones activadas, y las especulaciones desperdiciadas se registran por separado.

Integridad de la activación y la analítica

Prueba: Activar prerender sin hacer clic; después, repetir y activar la página una vez mientras se observan la analítica y las solicitudes de píxeles personalizados.

Resultado esperado: El prerender abandonado no registra pageview ni impresión; la navegación activada registra exactamente uno.

Interpretación del fallo: Una etiqueta se activa durante la carga en segundo plano o una lógica de activación duplicada registra la misma visita dos veces.

Ventana de seguimiento: Probar antes del lanzamiento, inmediatamente después y tras cambios en el administrador de etiquetas o la biblioteca de analítica.

Activador de reversión: Desactivar prerender para la ruta afectada si las cargas especulativas inflan sesiones, impresiones, conversiones o atribución.

Rendimiento de navegación y desperdicio

Prueba: Comparar las navegaciones activadas coincidentes con y sin la regla, y contar las especulaciones que nunca se activan.

Resultado esperado: Las navegaciones objetivo en Chromium muestran tiempos de documento y pintura más tempranos, sin un volumen inaceptable de trabajo sin usar ni regresiones en la página actual.

Interpretación del fallo: La predicción es débil, eagerness es demasiado agresiva o el trabajo en segundo plano compite con la página actual.

Ventana de seguimiento: Revisar durante un lanzamiento limitado en dispositivos y clases de conexión representativos antes de ampliar el alcance.

Activador de reversión: Retroceder de prerender a prefetch o eliminar la regla si las solicitudes sin usar o las regresiones superan el beneficio medido en las navegaciones activadas.

Exclusión de efectos secundarios

Prueba: Ejercitar cada ruta coincidente sin activarla e inspeccionar el estado del servidor, la autenticación, el contenido del carrito, los mensajes y los contadores de uso.

Resultado esperado: Ninguna solicitud especulativa cambia el estado de la persona ni del servidor.

Interpretación del fallo: Coincidió una ruta GET que cambia estado o una página ejecuta efectos secundarios durante la carga en segundo plano.

Ventana de seguimiento: Repetir cuando cambien las rutas, los selectores de reglas de documento o los efectos secundarios de la aplicación.

Activador de reversión: Eliminar la coincidencia de inmediato si una solicitud especulativa cierra una sesión, modifica un carrito, envía un mensaje, consume una cuota o registra una conversión.

Cuadro de mando de navegación especulativa

Métrica: Rendimiento de las navegaciones activadas para personas admisibles en Chromium, junto con la tasa de activación de especulaciones y la exactitud de los eventos analíticos.

Qué indica: Si la predicción acelera navegaciones reales a la página siguiente, con qué frecuencia se usa realmente el trabajo de prefetch o prerender y si la medición sigue siendo confiable.

Cómo obtenerla: Segmentar los tiempos de navegación y pintura de personas reales por navegador y exposición a la regla; registrar candidatos y activaciones de especulación; comparar los pageviews activados con los eventos analíticos. Las cohortes de prefetch y prerender deben mantenerse separadas.

Referencia o intervalo realista: Deben usarse la distribución propia del sitio antes del lanzamiento y un grupo de control. No existe un objetivo universal honesto de tasa de activación o conversión: la combinación de navegadores, la previsibilidad de las rutas, el peso de las páginas y la intención difieren entre sitios.

Cadencia: Vigilar el uso de recursos y la integridad analítica durante el lanzamiento; revisar cada semana el rendimiento y la activación mientras se ajustan las reglas; volver a auditar tras cambios de navegación, etiquetado, CSP o compatibilidad con navegadores.

Recursos recomendados

Artículos relacionados del autor

• Guía para principiantes de SEO técnico — contexto general para temas de experiencia de página y rendimiento como este.
• Core Web Vitals: qué son y cómo mejorarlas — métricas LCP/INP que Speculation Rules puede mejorar para personas reales. (Nota: todavía no existe una guía de Ahrefs dedicada específicamente a la API Speculation Rules; este artículo es el análisis detallado y esos enlaces son la cobertura adyacente más cercana.)

Presentaciones del autor

• Qué sigue para la experiencia de página: SMX Next 2021 (SlideShare) — charla sobre experiencia de página que señalaba técnicas de carga anticipada (una diapositiva «Obtener las cosas antes» enlazaba el prerender especulativo entonces experimental). Es anterior a la API moderna, pero apunta a la misma idea.
• Cómo funciona la búsqueda (SlideShare) — rastreo, renderizado, indexación y posicionamiento, útil para separar la capa del navegador de la del rastreador. Se mantiene la advertencia del autor: “This is my understanding of systems… not going to be 100% complete or accurate.” (traducción) «Esta es mi comprensión de los sistemas… no pretende ser completa ni exacta al 100 %».

Recursos del sector

• Google Search ya usa la API Speculation Rules (Chrome for Developers) — uso por parte de Google, con diferencias de LCP/FCP en milisegundos.
• Cómo Ray-Ban duplicó la tasa de conversión mediante prerender (web.dev) — el mejor caso de impacto comercial de prerender.
• Un enfoque por capas para Speculation Rules (Harry Roberts, CSS Wizardry) — la guía independiente más sólida, incluido el modelo «prefetch para TTFB, prerender para LCP».
• Google explica por qué su rastreador ignora las indicaciones de recursos (Search Engine Journal) — comentarios de Illyes de febrero de 2026 sobre por qué Googlebot no se beneficia de indicaciones de recursos (en general, no específicamente de Speculation Rules).
• Google Search ya usa Speculation Rules para acelerar la búsqueda (Search Engine Land) — corroboración de prensa especializada del anuncio de Chrome.
• Evitar analítica distorsionada al usar Speculation Rules (Erwin Hofman) — corrección detallada para la contaminación de GA4.
• Prerenderizar con eagerness URL clave mediante Speculative Loading en WordPress (Weston Ruter, Google/núcleo de WordPress) — personalización del valor predeterminado de WordPress 6.8 mediante el filtro wp_speculation_rules_configuration.
• Sitios ultrarrápidos con Speculation Rules (DebugBear) — guía práctica de un proveedor de herramientas de rendimiento.

Evaluación: Speculation Rules

Cinco preguntas breves sobre lo que hace y no hace la API Speculation Rules. Debe elegirse una respuesta para cada una y comprobarla después.

Registro de cambios