La API «Speculation Rules» permite a un navegador precargar, o incluso precargar previamente, las páginas que es probable que un visitante abra a continuación. En el caso de un sitio web bien orientado, esto puede hacer que la navegación sea casi instantánea y mejorar la Core Web Vitals. En el caso de un proyecto de una pyme, la ventaja es real, pero hay que establecer unas normas claras para evitar el desperdicio de ancho de banda, mediciones analíticas sesgadas y costes imprevistos.
¿Qué cambia concretamente la API «Speculation Rules»?
La API Speculation Rules es una API web, es decir, una funcionalidad que ofrece el navegador, diseñada para anticipar las futuras navegaciones. En lugar de esperar a que un usuario haga clic en un enlace, el sitio web puede indicar de antemano qué páginas conviene preparar.
Hoy en día, hay dos aspectos que son importantes para un responsable de la toma de decisiones. El prefetch descarga el documento HTML de una página probable. El prerender va más allá: el navegador carga y procesa la página en segundo plano, incluido JavaScript, antes de que el usuario la visualice realmente.
La diferencia desde el punto de vista empresarial es sencilla. Una precarga bien situada reduce la espera. Un prerenderizado bien situado puede dar la impresión de que la página se abre al instante. Chrome indica que la prerenderización puede producir un LCP cercano a cero, reducir ciertos retrasos visuales durante la carga y mejorar el INP, ya que la carga se completa antes de que se produzca la interacción.
El LCP (Largest Contentful Paint) mide el tiempo necesario para mostrar el contenido principal visible. El INP (Interaction to Next Paint) evalúa la capacidad de respuesta tras una acción del usuario. Estos indicadores forman parte de los Web Vitals Core, que suelen supervisarse en las auditorías de SEO y UX ; si tu página web ya es lenta, empieza también por entender Cómo reaccionan las actualizaciones de Google ante las señales de calidad.
Prefetch, prerender, prerender_until_script: tres niveles de anticipación
Le prefetch Es el nivel más prudente. El navegador recupera el futuro documento, pero no lo ejecuta como una página completa. Esto resulta útil para una página de categoría, un artículo relacionado o una ficha de producto que se consulta con mucha frecuencia tras visitar una página determinada.
Le prerender es más potente, por lo que entraña más riesgo. La página se carga y se representa antes de hacer clic, con sus scripts, sus recursos y su estado. Según MDN, una representación previa consume aproximadamente los mismos recursos que una representación en una , lo que pronto resulta pesado en el móvil o en páginas con mucho contenido.
Una tercera medida, prerender_until_script, aparece indicada en Chrome como experimental y en fase de prueba origin desde enero de 2026, a partir de la versión 144 de Chrome. Las notas de Microsoft Edge 146 también lo mencionan. Sinceramente, esta opción solo se justifica para equipos técnicos capaces de seguir la evolución de los navegadores y de aceptar cierto grado de inestabilidad.
Por otra parte, la API Speculation Rules sigue figurando como «Disponibilidad limitada» y «Experimental» en MDN en 2026. Funciona principalmente en el ecosistema Chromium, en concreto en Chrome, Edge y Opera. No se debe dar por sentado que Safari y Firefox sean compatibles en un proyecto de cifrado.
| Acérquese a | Qué hace el navegador | Ganancia esperada | Riesgo principal | Uso razonable |
|---|---|---|---|---|
prefetch |
Descarga el documento «Futuro» | Navegación más rápida | El ancho de banda es inútil si la segmentación es deficiente | Artículos siguientes, páginas muy probables |
prerender |
Carga y muestra la página completa | Página que se carga casi al instante tras la activación | Scripts, análisis o recursos ejecutados demasiado pronto | Recorrido corto y predecible |
prerender_until_script |
Previsualización parcial hasta el guion | Prometedor, pero experimental | Compatibilidad y mantenimiento | Pruebas supervisadas en un proyecto avanzado |
¿Cómo se pueden precargar las páginas con la API Speculation Rules?
Las reglas se pueden declarar directamente en la página con una etiqueta . También se pueden enviar a través de un encabezado HTTP Especulación: normas, que apunta a un archivo JSON externo; Chrome especifica alors que el recurso debe servirse con el tipo application/speculationrules+json.
Para un responsable de proyecto, lo importante no es elegir una sintaxis elegante. Lo que realmente importa es la orientación al usuario. Precargar todas las páginas de un menú solo porque es técnicamente posible es una mala idea: aumentas el consumo de red sin garantizar ningún beneficio apreciable.
Chrome recomienda limitar las páginas precargadas a una o dos como máximo. El navegador también aplica sus propios límites en función del nivel de urgencia, denominado entusiasmo, que indica si la regla se activa de forma anticipada o solo tras una señal fort, como el paso del cursor por encima o el inicio de un clic.
En los proyectos que llevamos a cabo, a menudo observamos una estrategia muy rentable: empezar con una regla prudente para dos o tres transiciones frecuentes, evaluar los resultados y, a continuación, ampliarla. Una tienda online puede dirigir al usuario a la ficha de producto más probable de una lista. Un medio de comunicación puede dirigir al usuario al siguiente artículo. Un sitio web B2B puede mostrar la página de contacto solo después de que el usuario haya visitado una página de ofertas.
- Identificar los recorridos más frecuentes en Matomo, Google Analytics 4 o los registros del servidor.
- Excluir las páginas sensibles: cesta de la compra, cuenta, proceso de pago, formularios prellenados.
- Prueba de abord
prefetch, y luego reservarprerendercon páginas realmente predecibles. - Comprueba los efectos en Chrome DevTools, en la sección «Aplicación» y, a continuación, en «Cargas especulativas».
- Mide el LCP, el INP, las conversiones y el consumo del servidor antes de ampliar.
WordPress 6.8: una interfaz de entrada más sencilla, pero no es la panacea
WordPress 6.8 introdujo la carga especulativa en el núcleo del CMS en 2025. Según Make WordPress Core, el núcleo incluye una regla predeterminada de cálculo conservador, y los desarrolladores pueden añadir sus propias reglas a través de wp_load_reglas_de_especulación.
El plugin WordPress «Speculative Loading» también es compatible con la API Speculation Rules y está pensado para navegadores basados en Chromium a partir de la versión 121, como Chrome, Edge y Opera. Su documentación indica que la carga especulativa está activada por defecto solo para los usuarios que no han iniciado sesión, ya que las páginas sin autenticación suelen ser más fáciles de almacenar en caché y más eficaces de precargar.
Esta distinción es fundamental. Una página web de presentación de WordPress con caché de servidor, CDN de Cloudflare y páginas públicas estables es una buena opción. Una extranet, un WooCommerce complejo o un área de miembros con contenidos personalizados requieren mayor precaución.
Las funciones y filtros de WordPress disponibles en 2026, como wp_speculation_rules_configuration, wp_get_speculation_rules(), WP_Reglas_de_especulación o los filtros de exclusión, permiten afinar el procesamiento. Por parte de la agencia, lo habitual es tratar estos ajustes como una función de rendimiento, no como una casilla que hay que marcar en la configuración.
Si tu proyecto ya se basa en numerosas extensiones, también hay que tener en cuenta toda la cadena: caché de páginas, CDN, consentimiento de cookies, scripts publicitarios, etiquetas de marketing y seguridad. Los riesgos son similares a los que se dan en las arquitecturas conectadas a varios servicios de terceros, un tema relacionado con los vulnerabilidades invisibles en la API cuando los acontecimientos no se producen en el momento previsto.
Beneficios cuantificados: interesantes, pero dependen del contexto
Los casos públicos proporcionan valores de referencia útiles. Google Search utiliza la precarga mediante «Speculation Rules» en Android desde octubre de 2022 y la ha implementado en ordenadores de sobremesa hasta septiembre de 2024. Los resultados de las pruebas A/B recopilados por Chrome indican, según las versiones, una mejora en ordenador de 7,6 ms en el FCP y de 9,5 ms en el LCP, y posteriormente otra mejora del LCP de 58,6 ms con Chrome para ordenador.
Estas cifras pueden parecer modestas. Pero, en el contexto de Google Search, son importantes. Para una pyme, demuestran sobre todo que el prefetch por sí solo no es una varita mágica si la página ya es rápida o si el siguiente clic es difícil de predecir.
Los resultados son más elocuentes con el prerenderizado. Un caso práctico de Ray-Ban publicado en web.dev en 2024 señala una reducción de la tasa de rebote del 13,1 % y una duplicación de la tasa de conversión tras utilizar el prerenderizado con la API Speculation Rules. Un estudio de Monrif de principios de 2025, que combina el prerenderizado de Speculation Rules y bfcache, indica una reducción del LCP de 17,9 puntos porcentuales y una mejora del compromiso del 8,9 puntos porcentuales.
El bfcache, o caché de retroceso, es una memoria del navegador que mantiene una página preparada hasta que el usuario se desplaza hacia atrás o hacia adelante. Funciona en paralelo al prerenderizado, ya que gran parte de la lentitud percibida se debe a los desplazamientos entre páginas. Es también aquí donde las interfaces modernas, como las transiciones entre vistas, pueden complementar el rendimiento técnico; este tema se relaciona con los enfoques descritos en torno a la API de transiciones de vista si tu sitio web la utiliza.
Un error habitual: confundir la velocidad percibida con la velocidad real de la infraestructura. El precargamiento puede ocultar una página lenta tras su activación, pero no siempre reduce la carga del servidor. Incluso puede aumentarla si se preparan páginas que luego nunca se consultan.
Presupuesto, plazos y decisiones de priorización para un proyecto de una pyme
En una instalación reciente de WordPress, una primera prueba básica puede durar entre medio día y dos días si el tema es estándar, la caché está bien configurada y las rutas de navegación son sencillas. Por el contrario, hay que contar entre tres y seis días para una web de comercio electrónico o una web con seguimiento avanzado, ya que hay que excluir las páginas de riesgo y comprobar los eventos.
En el contexto del presupuesto francés, según los proveedores, la incorporación controlada de reglas de optimización en una web ya existente suele oscilar entre los 500 y los 2.500 € sin IVA para una auditoría básica, la implementación y la aceptación. Un proyecto más completo de optimización del rendimiento, que incluya Web Vitals, CDN, caché, imágenes, JavaScript y mediciones antes y después, puede oscilar entre 3.000 y 10.000 € sin IVA, dependiendo de la deuda técnica.
Con este presupuesto, es mejor no vender la API «Speculation Rules» como una medida aislada si la web ya carga 3 MB de JavaScript innecesario. La mejor rentabilidad de la inversión suele consistir en reducir abord lo que ralentiza todas las páginas y, a continuación, precargar las dos navegaciones que realmente importan.
La compatibilidad también exige un equilibrio. Dado que la API no está disponible en todas partes, debe mejorar la experiencia de los navegadores compatibles sin perjudicar a los demás. Se trata de una mejora progresiva: Chrome y Edge se benefician de ella, mientras que los demás siguen funcionando como de costumbre.
En cuanto al SEO, mantén una actitud pragmática. Las fuentes fiables recientes hacen hincapié sobre todo en el desperdicio de recursos y ancho de banda que supone una segmentación inadecuada, no en un impacto directo demostrado en el presupuesto de rastreo de Googlebot. Si tu objetivo es la visibilidad, trabaja también el contenido, los datos estructurados y la coherencia editorial; los Datos de Schema.org útiles para comprender las páginas pueden completar un proyecto de rendimiento.
Las dificultades técnicas que los que no son expertos en tecnología descubren demasiado tarde
El primer riesgo tiene que ver con la analítica. Durante un prerenderizado, la página ya existe en segundo plano, pero el usuario aún no la ha visto. El codelab de Google indica que Google Analytics y Google Publisher Tag retrasan automáticamente ciertas acciones hasta que se activan, pero es posible que otros proveedores o scripts propios no lo hagan.
Posibles consecuencias: cifras infladas de páginas vistas, píxeles publicitarios activados antes de tiempo, pruebas A/B sesgadas. Para un departamento de marketing, esto es un problema. Se toman decisiones basadas en datos contaminados.
Otra limitación: el origine de las páginas. Chrome indica que el prerenderizado origine es el método predeterminado. El prerenderizado cross-origin same-site requiere que el destino lo acepte explícitamente mediante el encabezado Supports-Loading-Mode: credentialed-prerender. Actualmente no es posible el prerenderizado entre sitios.
En pocas palabras: no puedes redirigir libremente cualquier página de un dominio de terceros. Si tu túnel de reservas, tu sistema de pago o tu configurador están alojados en otro sitio, tendrás que comprobar la arquitectura. Lo mismo ocurre con algunos subdominios mal alineados.
Las páginas que dependen del estado del usuario merecen, por último, una atención especial. Cesta de la compra, cuenta de cliente, área privada, presupuesto dinámico, consentimiento de cookies: todo lo que dependa de una sesión debe excluirse o gestionarse con cuidado. Una navegación fluida no compensa un error en la cesta de la compra o un dato que se muestre en el momento inadecuado.
Definir este tipo de proyecto desde el principio evita la mayoría de las sorpresas desagradables: elección de las páginas, reglas de exclusión, medición antes y después, y posterior implementación progresiva. A menudo es aquí donde una perspectiva externa permite ahorrar tiempo, sobre todo cuando se entrecruzan el rendimiento, el SEO, el alojamiento y el seguimiento.
Preguntas frecuentes sobre la API de Speculation Rules
¿Funciona la API de Speculation Rules en todos los navegadores?
No. En 2026, MDN clasificó encore como «disponibilidad limitada y experimental». Afecta sobre todo a los navegadores basados en Chromium, como Chrome, Edge y Opera.
¿Hay que activar la prerenderización en todas las páginas de WordPress?
No. Es mejor empezar por las páginas públicas más probables y excluir el carrito, la cuenta, el pago, los formularios y los contenidos personalizados. WordPress 6.8 adopta precisamente un enfoque conservador por defecto.
¿Mejora directamente la API de Speculation Rules el SEO?
Puede mejorar indicadores de rendimiento como el LCP o la experiencia percibida, lo que contribuye a que un sitio web que ya es coherente sea aún mejor. No sustituye a un contenido útil, a una arquitectura clara ni a un trabajo técnico global.
¿Cuál es el coste realista para ponerlo en marcha?
Para una página web sencilla ya existente, suele haber que contar con un presupuesto de entre 500 y 2.500 € sin IVA, dependiendo del nivel de las pruebas. Un proyecto de rendimiento más amplio puede alcanzar un coste de entre 3.000 y 10.000 € sin IVA.
¿Cómo se comprueba que las reglas funcionan?
Chrome DevTools ofrece una sección llamada «Aplicación» y, dentro de ella, «Cargas especulativas» para examinar las reglas, los intentos y los errores. Es necesario complementarlo con mediciones reales sobre el LCP, las conversiones y la analítica.