Speculation Rules: cuándo acelera una web y cuándo la empeora

Cada cierto tiempo aparece alguna supuesta maravilla técnica que promete hacer que una web vaya mucho más rápida con solo copiar un bloque de código. Ahora le ha tocado el turno a speculationrules.

Y es que se está compartiendo bastante por Linkedin como si fuera una especie de truco capaz de hacer que una página «se sienta» mucho más rápida. Y sí, en ciertos contextos puede ayudar, aunque venderlo como si fuera una optimización universal es simplificar demasiado.

Esto no va de pegar un snippet y esperar milagros. Quien tiene algo de experiencia real en WPO ya sabe que no existen atajos perfectos, y que aquí toca ir revisando cada capa una a una.

El problema es que en redes sociales cada vez se aprende menos y se desaprende más. Cuando se simplifican temas técnicos para convertirlos en contenido llamativo, lo que acaba circulando no es conocimiento útil, sino una desinformación constante disfrazada de descubrimiento.

Qué es exactamente speculationrules

Un ejemplo muy básico sería este:

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": {
        "selector_matches": "a"
      }
    }
  ]
}
</script>

Aquí lo que se está haciendo es decirle al navegador que, tomando como base el documento actual, considere los enlaces <a> como candidatos para prefetch. Es decir, que pueda adelantar parte de esas navegaciones antes de que el usuario llegue a hacer clic. El problema añadido es que la regla apunta a todos los enlaces de esa URL, sin distinguir cuáles tendría sentido preparar y cuáles no.

Malos usos habituales

Uno de los errores más típicos es precisamente ese: lanzar reglas demasiado amplias, sin ningún filtro real sobre qué URLs conviene preparar y cuáles no.

Otro error bastante habitual sería aplicar prerender a páginas con estado delicado, por ejemplo carrito, checkout, áreas privadas o URLs con contenido muy dependiente del contexto del usuario.

En estos casos, el problema no es solo que la URL sea delicada, sino que la versión preparada por adelantado puede dejar de ser válida en segundos. Si cambia el stock, el precio, el carrito o la sesión, esa página ya no debería asumirse como correcta sin más. Si se decide usar prerender en este tipo de escenarios, hace falta lógica adicional en la propia aplicación para comprobar al entrar que ese estado sigue siendo válido o para refrescarlo si ya no lo es.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "selector_matches": "a"
      }
    }
  ]
}
</script>

Aquí el problema ya no es solo que la regla sea amplia. Es que además estás subiendo el nivel de agresividad al pasar de prefetch a prerender, con todo lo que eso puede implicar en consumo, ejecución anticipada, analítica o carga innecesaria al sistema.

También es mala idea apuntar estas reglas a zonas de navegación poco relevantes o llenas de enlaces secundarios, porque puedes terminar adelantando trabajo sobre URLs que apenas aportan valor real a la experiencia.

La diferencia importante: prefetch no es lo mismo que prerender

Aquí es donde conviene frenar un poco, porque muchas veces se mete todo en el mismo saco y no es lo mismo.

Prefetch

Sirve para adelantar una futura navegación de forma más ligera. El documento se descarga para acelerar la visita posterior, pero no se descargan sus subrecursos ni se ejecuta la página como en un render completo.

Prerender

Va bastante más allá. La página puede prepararse de forma mucho más completa antes de la entrada del usuario, incluyendo trabajo previo del documento y de sus recursos antes de la activación.

Además, no siempre se activa igual. Según cómo lo configures, el navegador puede esperar a ver una señal bastante clara de intención, por ejemplo que el usuario pase el ratón por encima de un enlace, mantenga ese hover un momento o empiece a hacer clic. Y si la configuración es más agresiva, puede incluso empezar a prepararlo antes de que exista esa intención tan clara.

Cuando funciona bien, la navegación parece instantánea, pero cuando lo aplicas sin criterio, estás generando bastante más trabajo antes de saber si esa visita se va a producir de verdad.

Consejo sensato: empieza implementando prefetch, no prerender

Si vas a probar este tipo de estrategia, lo razonable no suele ser arrancar directamente con prerender. Lo más sensato es empezar por algo más controlado, medir, observar y entender qué pasa en tu web de verdad, porque prerender no solo acelera, también anticipa bastante más trabajo previo, y ahí ya depende bastante del contexto técnico de la web.

Por ejemplo, en una home con hero, CTAs y varios enlaces destacados, una aproximación prudente sería empezar con una regla de prefetch limitada a zonas concretas, no a todos los enlaces de la página:

<script type="speculationrules">
{
  "prefetch": [
    {
      "where": {
        "and": [
          { "selector_matches": ".hero a, .cta-home a" },
          { "not": { "selector_matches": "[rel~=nofollow], .no-prefetch" } },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/carrito*" } },
          { "not": { "href_matches": "/checkout*" } }
        ]
      }
    }
  ]
}
</script>

Aquí no se está diciendo “hazlo con todo”, sino “empieza por enlaces concretos que sí podrían tener sentido”. Además, se excluyen enlaces que no conviene anticipar alegremente, como salidas de sesión, carrito o checkout, precisamente porque son páginas con estados sensibles o cambiantes, muy dependientes del contexto del usuario, de la sesión o del momento exacto de la navegación.

La lógica es bastante simple: prefetch es una forma más prudente de empezar, mientras que prerender es bastante más agresivo y conviene dejarlo para escenarios donde ya hayas validado bien el contexto técnico, la caché, el comportamiento de la analítica y el tipo de URLs que quieres adelantar.

La caché aquí no es un detalle: lo cambia todo

Uno de los puntos más importantes de este tema es la caché. Chrome puede reutilizar caché HTTP, y eso ayuda mucho a reducir el coste de estas especulaciones si los recursos están bien servidos y correctamente cacheados. Pero si el HTML no es cacheable, o la personalización hace que la cache key se fragmente, entonces la historia cambia bastante. Cada especulación puede terminar convirtiéndose en una petición real al origen.

Aquí también entra en juego cómo esté definida la caché a nivel de cabeceras y de CDN. Si la respuesta depende de demasiados factores, o la cache key se fragmenta demasiado, el margen para reutilizar esas especulaciones cae bastante.

No basta con decir “tengo CDN”. La diferencia real está en si esa capa intermedia resuelve bien estas especulaciones desde edge (desde la capa CDN más cercana al usuario) o si, por el contrario, cada intento termina golpeando origen. Ahí cambia bastante la película.

Y ahí ya no estás solo “mejorando sensación de velocidad”. Ahí puedes estar generando más carga al backend, más peticiones que no siempre acabarán en navegación real, más consumo de infraestructura y más posibilidades de que una web pesada sufra todavía más.

En un sitio muy bien montado, con edge caching decente y lógica fina en CDN, el impacto puede controlarse bastante mejor. En un sitio pesado, con HTML dinámico, backend ajustado y una arquitectura poco limpia, el invento puede salir bastante más caro de lo que parece cuando alguien enseña solo el snippet bonito.

En móvil también puede liarla

Otro punto del que se habla poco es el ancho de banda y el contexto de navegación del usuario. Prerenderizar implica mover datos y preparar contenido antes de que la visita ocurra realmente. En escritorio y con buena conexión esto puede parecer irrelevante, pero en móvil no siempre lo es.

Si la conexión va justa, si el usuario al final no entra en esa URL o si la página preparada pesa bastante, puedes estar metiendo trabajo extra en la red y en el dispositivo para nada. Y eso puede empeorar la experiencia, aunque el clic final parezca más rápido.

Mucho ojo con la analítica

Este es uno de los grandes riesgos silenciosos. Muchos píxeles, scripts de analítica, heatmaps o sistemas de testing no están bien preparados para convivir con una fase de prerender.

El problema de fondo es que muchos píxeles, heatmaps o tests A/B no comprueban estados como document.prerendering, y por eso pueden disparar eventos antes de tiempo.

¿Qué puede pasar? Que se disparen eventos antes de una visita real, que se inflen páginas vistas, que se contaminen embudos o que una prueba A/B registre interacciones que no deberían contar todavía.

Y a partir de ahí ya sabes cómo va esto: se ensucia la data, se interpretan mal los resultados y se toman decisiones creyendo que la medición era buena. Si se va a usar prerender, conviene revisar bien cómo responden tus herramientas y si hay lógica suficiente para evitar mediciones prematuras.

No todas las páginas son candidatas válidas

Esto también conviene dejarlo claro: no todas las URLs son buenas candidatas para prerender.

Si una página tiene estado que puede cambiar rápido o depende mucho del contexto del usuario, puedes estar preparando una versión que se queda vieja enseguida o que ni siquiera debería haberse preparado.

Por ejemplo:

• carrito,
• checkout,
• stock,
• precios,
• sesiones iniciadas,
• áreas privadas,
• contenido personalizado,
• o resultados que cambian según filtros o contexto.

En estos casos, usar prerender puede obligarte a añadir lógica adicional en la propia aplicación para refrescar o recomprobar ese contenido cuando la navegación se activa.

Y cuando una supuesta mejora de rendimiento empieza a exigir excepciones, condicionales y parches por todas partes, conviene hacerse una pregunta bastante simple: ¿de verdad este era el problema importante a resolver?

Cuándo sí puede tener sentido

No se trata de decir que no sirve. Sí puede servir, pero en escenarios bastante concretos. Suele tener más sentido cuando se cumplen varias condiciones: la navegación es muy predecible, las páginas de destino son relativamente estables, la caché está bien resuelta, la infraestructura aguanta, la analítica está revisada y la mejora de velocidad percibida realmente aporta valor al negocio o a la experiencia.

Eso no significa que no existan casos donde haya aportado valor real. Ray-Ban, por ejemplo, publicó un caso en el que el uso de prerender con Speculation Rules dentro de su journey crítico ayudó a mejorar el LCP y se asoció a una mejora clara del rendimiento de negocio, incluyendo una subida de la conversión. Pero precisamente por eso conviene leer bien este tipo de ejemplos: no demuestran que sea una receta universal, sino que en un contexto muy concreto, con una arquitectura preparada y un flujo especialmente sensible al rendimiento, puede tener sentido.

En determinados flujos cerrados o rutas muy claras de navegación, puede ser una buena ayuda. Lo que no haría es activarlo a lo loco en toda la web como si fuera un interruptor universal de rendimiento, porque no lo es.

Cómo probarlo minimizando riesgos

Si quieres testear esto con cuidado, yo lo enfocaría así: no lo expandas de golpe a todo el sitio y empieza por rutas muy concretas y fáciles de controlar. Antes de irte a prerender, mira cómo responde la web con una estrategia más ligera basada en prefetch.

Tampoco te quedes solo con “parece que va más rápido”. Revisa también servidor, consumo, navegación real tras la especulación y comportamiento en móvil. Y, por supuesto, deja fuera o trata con muchísimo cuidado páginas sensibles como logout, carrito, checkout, áreas privadas, páginas muy dinámicas o cualquier URL con estado delicado.

Por último, revisa bien caché y edge. Si tu HTML depende demasiado del origen o la caché está mal resuelta, conviene parar antes de meter más complejidad.

El problema no es la técnica, es cómo se está contando

speculationrules bien usado, puede mejorar la sensación de velocidad en ciertos contextos, aunque mal usado, puede disparar trabajo innecesario al backend, contaminar la analítica, consumir recursos de más y complicar páginas que ya iban suficientemente cargadas.

La cuestión no es si el snippet existe o si Chrome lo soporta. La cuestión real es otra: si tu web está en condiciones de beneficiarse de ello sin pagar un precio mayor por otro lado.

Porque en optimización web pasa mucho: la gente se enamora de la técnica antes de entender el sistema. Y ahí es donde empiezan bastantes decisiones malas.