Si llevas tiempo leyendo sobre rendimiento en WordPress te has cruzado con palabras como prefetch, prerender o preconnect en sitios distintos, con significados que no siempre coinciden, y la culpa, todo hay que decirlo, también es un poco de este blog, o sea mía.
En mi artículo sobre precarga de recursos, prefetch y prerender significan una cosa, luego, en cuando escribí sobre carga especulativa nativa de WordPress, las mismas dos palabras significan otra completamente distinta y, para seguir enredando, luego está eso de la bfcache, que no precarga nada de nada, va al revés.
Son cuatro técnicas con nombres que se pisan, y cada una vive en su propia capa del navegador, con sus propias reglas, así que se me ha ocurrido que igual no está de más ponerlas en orden para que dejemos de mezclarlas.
Si lo que buscas es la otra caché, la que guarda resultados ya generados para no repetir trabajo (página, objetos, base de datos, OPcache, CDN), esa la tienes entera en la guía de tipos de caché en WordPress. Hoy toca hablar de la familia de cachés que adelanta o conserva trabajo del navegador, no del servidor, que es un asunto distinto aunque también se llame caché en algún sitio.
Resource hints: precarga recurso a recurso
Esta es la que lleva más tiempo en el navegador y la que seguramente ya conoces, aunque no la llames así. Son cuatro etiquetas <link> distintas, cada una con un trabajo muy concreto sobre un recurso suelto, nunca sobre una página entera.
dns-prefetch: resuelve el nombre de dominio de un origen externo antes de que haga falta, así cuando llegue el recurso de verdad esa parte ya está hecha.preconnect: hace lo mismo quedns-prefetchy además abre la conexión TCP y negocia el TLS, así que cuando el recurso llega de verdad el navegador no tiene que esperar nada de eso.prefetch: descarga un recurso suelto entero, un documento o un recurso cualquiera, con prioridad baja, para tenerlo ya en caché cuando se necesite.preload: igual queprefetchpero con prioridad alta y de obligado cumplimiento, el navegador no puede ignorarlo. Se usa para lo que sabes seguro que vas a necesitar ya, como la fuente del título o la imagen del LCP.
Los cuatro se controlan recurso a recurso, dominio a dominio, decisión que tomas tú o que automatizas con plugins como DietPress, a golpe de clic, sin que escribas una sola línea de código.
WordPress trae de serie el filtro wp_resource_hints desde la versión 4.6 para añadir dns-prefetch y preconnect sin tocar el <head> a mano, aunque mucha gente, este blog incluido en su día, sigue escribiendo el echo directo en wp_head en vez de usarlo.
Si quieres un tutorial con el código y las herramientas para aplicarlo en la guía de prefetch, preload, preconnect y prerender en WordPress.
Un apunte para no liar (aún más) el tema es lo relativo al atributo fetchpriority, que suena de la misma familia, y a veces se mete en el mismo saco, pero hace algo distinto. No anticipa nada que el navegador no fuese a pedir igualmente, solo le dice con qué prioridad pedirlo, no es un resource hint en sentido estricto, es una instrucción de orden. Si quieres ampliar información puedes ver la guía de fetchpriority.
El prerender de siempre ya no hace nada
De las etiquetas de arriba hay una que solía acompañarlas, <link rel="prerender">, y que merece su propio apartado porque hoy no sirve absolutamente para nada. Chrome la abandonó hace años, sustituida por la tecnología de la siguiente sección, y cualquier navegador actual la ignora sin más.
No pasa nada por tenerlo, simplemente no aporta nada.
Speculation Rules: prefetch y prerender nativos de WordPress
Desde WordPress 6.8, trae de serie la carga especulativa, creada sobre la Speculation Rules API del navegador. Y aquí empieza el lío, porque esta tecnología también tiene su propio prefetch y su propio prerender, con los mismos nombres que los de la primera sección, pero que no funcionan igual ni a la misma escala.
Un resource hint clásico es como pedir que te dejen ya el cubierto puesto en la mesa. Speculation Rules es como si la cocina empezara a prepararte el plato entero en cuanto te ve mirar el menú, antes de que hayas pedido nada, o sea, precarga la página completa, con su HTML, su CSS y su JavaScript, no un recurso suelto.
Se declara en JSON dentro de un <script type="speculationrules">, es automático, y WordPress lo activa de serie solo para visitantes que no están conectados y solo si usas enlaces permanentes bonitos. Hay tres niveles de anticipación, la conservadora espera al clic, la moderada se dispara al pasar el cursor y la ansiosa salta con solo acercarte.
La compatibilidad con navegadores es la otra pieza importante para decidir si te conviene. Funciona en Chrome, Edge y el resto de navegadores con motor Chromium, que es la inmensa mayoría del tráfico mundial, Safari la incluye desde la versión 26.2 pero la trae desactivada por defecto, como función experimental, y Firefox de momento no la ha implementado, aunque sí se ha posicionado a favor de la parte de prefetch para más adelante.
Puedes excluir URLs concretas con el filtro plsr_speculation_rules_href_exclude_paths, o apagarla entera con wp_speculation_rules_configuration. Tienes el desarrollo completo, con el código y los pros y contras, en qué es y cómo funciona la carga especulativa nativa y en si te conviene desactivarla.
bfcache: la única caché que no anticipa nada, conserva lo que ya tenías
Las tres técnicas anteriores miran hacia delante, adivinan qué vas a necesitar y se adelantan. Sin embargo bfcache (back/forward cache) hace justo lo contrario y mira hacia atrás. Cuando sales de una página el navegador la congela en memoria tal cual estaba, y si pulsas atrás te la devuelve al instante en lugar de pedirla otra vez al servidor.
Es una optimización nativa de los navegadores desde hace años, no necesita ningún código tuyo para existir, pero WordPress la bloquea por su cuenta para usuarios conectados al enviar la directiva no-store en la cabecera de respuesta. Quitar esa directiva con el filtro wp_headers, o con el plugin Instant Back/Forward, es lo que la reactiva.
No tiene relación de competencia con ninguna de las tres anteriores, todo lo contrario, se complementan, porque bfcache acelera las páginas que ya visitaste, Speculation Rules acelera las que aún no has visto.
Las cuatro juntas y ordenadas, por aclarar
| Técnica | Qué anticipa | Automático o manual | Compatibilidad con navegadores | Cómo se controla en WordPress |
|---|---|---|---|---|
| Resource hints clásicos ( dns-prefetch, preconnect, prefetch, preload) |
Un recurso suelto: un dominio, una conexión, un archivo concreto | Manual, recurso a recurso, o automatizado con plugin | Amplio, todos los navegadores modernos | Filtro wp_resource_hints, código directo o plugin |
<link rel="prerender"> clásico |
Nada, está obsoleto | — | Ninguno, Chrome lo ignora | No lo uses |
| Speculation Rules | El documento completo de la siguiente página | Automático desde WordPress 6.8, configurable | Chrome y Edge sí, Safari detrás de una opción experimental, Firefox aún no | Filtro wp_speculation_rules_configuration |
bfcache |
Nada, conserva lo que ya estaba cargado | Nativo del navegador, pero WordPress lo bloquea con usuarios conectados | Amplio, todos los navegadores modernos | Filtro wp_headers o plugin |
Qué tienes activado ahora mismo en tu web
No hace falta que lo adivines, las herramientas de desarrollador de Chrome te lo dicen directamente:
- Resource hints clásicos: mira el código fuente de tu web y busca en el
<head>etiquetas<link rel="dns-prefetch">,<link rel="preconnect">o<link rel="preload">. - Speculation Rules: abre DevTools, pestaña
Application, apartadoSpeculative loads, secciónSpeculations. Pasa el cursor por algún enlace de tu web y mira si aparece algo en la lista. - bfcache: misma pestaña
Application, apartadoBackground services, secciónBack/forward cache, botónRun test. Te dice si la página entraría en bfcache o el motivo exacto por el que no.
Si en los tres casos sale en blanco, ya sabes a cuál de los artículos enlazados más arriba acudir para arreglarlo. Por dónde empezar depende de tu web. Si tienes un blog que actualiza poco, el bfcache es la ganancia más rápida y casi sin pegas, actívalo primero.
Si llevas una tienda con WooCommerce, revisa antes las exclusiones de Speculation Rules en el carrito y en finalizar compra, y prueba bien bfcache con un pedido real antes de darlo por bueno, que ahí sí hay estado que cuidar.
Si todavía no has tocado nada de esto, abre las DevTools del apartado anterior antes de instalar ningún plugin nuevo, para saber de qué punto partes. Y si después de mirarlo te queda alguna duda sobre cuál de las cuatro te conviene en tu caso, ya sabes dónde encontrarme, en los comentarios.
¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!
