En 2026, los usuarios esperan navegación en menos de 2 segundos. Cada segundo adicional de tiempo de carga cuesta alrededor del 4,42% de las conversiones (Portent); el 7% que circula es de Akamai y mide 100 milisegundos. Google lo sabe y recompensa a los sitios rápidos con mejores posiciones en los resultados de búsqueda.
Esta guía no es teoría. Es código funcional y una lista de verificación que puedes implementar hoy en tu sitio WordPress o tienda WooCommerce. Cada técnica ha sido probada en producción y los resultados son medibles y verificables. Speculation Rules ayuda cuando el checkout y los fragmentos del carrito ya están bajo control; para ese orden de trabajo, consulta el caso de recuperación del rendimiento de una tienda WooCommerce y la guía de optimización del rendimiento de WooCommerce en 2026.
Cómo afecta la velocidad de carga a la tasa de rebote
Tasa de rebote según el tiempo de carga
| Tiempo de carga (desde 1s) | Probabilidad de rebote |
|---|---|
| 3s | +32% |
| 5s | +90% |
| 6s | +106% |
| 10s | +123% |
Fuente: Google y SOASTA, benchmarks de velocidad en móvil. Las cifras son el aumento de la probabilidad de rebote frente a un segundo de carga, no tasas de rebote absolutas. Think with Google
Google confirmó: Core Web Vitals son un factor de clasificación. En 2024, FID fue reemplazado por INP (Interaction to Next Paint), una métrica que mide la responsividad de la página ante las interacciones del usuario.
Qué es la velocidad percibida de una web
Puedes tener un servidor lento (TTFB 800ms), pero si el usuario ve contenido instantáneamente y la navegación se siente instantánea, el rendimiento percibido es excelente. Esta distinción es crucial para la estrategia de optimización: a veces es más efectivo mejorar la percepción que reducir milisegundos del servidor.
Eso es exactamente lo que hace la Speculation Rules API: precarga las siguientes páginas en segundo plano antes de que el usuario haga clic. El resultado es una experiencia de navegación que se siente instantánea, incluso en conexiones lentas.
Diferir JavaScript, AVIF y TTFB en WordPress
Antes de implementar técnicas avanzadas, asegúrate de que los fundamentos estén sólidos. Sin una base optimizada, las técnicas avanzadas tendrán un impacto mínimo.
Cómo diferir JavaScript en functions.php
// functions.php - Diferir JS no crítico
add_filter('script_loader_tag', function($tag, $handle) {
$defer_scripts = ['jquery', 'wp-embed', 'comment-reply'];
if (in_array($handle, $defer_scripts)) {
return str_replace(' src', ' defer src', $tag);
}
return $tag;
}, 10, 2);Soporte de AVIF en WordPress 6.5+
WordPress 6.5+ soporta AVIF nativamente. AVIF ofrece un 20-30% de mejor compresión que WebP, lo que se traduce en páginas más ligeras y tiempos de carga más rápidos sin sacrificar calidad visual.
<img
src="producto.avif"
srcset="producto-400.avif 400w, producto-800.avif 800w"
sizes="(max-width: 600px) 400px, 800px"
loading="lazy"
decoding="async"
alt="Producto"
>Cómo bajar el TTFB de 200 ms
| Optimización | Impacto en TTFB |
|---|---|
| PHP 8.3+ con OPcache | -30% |
| Redis Object Cache | -50% |
| CDN Edge Caching | -70% |
| WP-Cron en crontab del sistema | -10% |
Cómo mejorar INP y CLS en WordPress
Cómo corregir el INP dividiendo tareas largas
INP sufre cuando el hilo principal está bloqueado. Los culpables típicos son los constructores de páginas pesados (Elementor, Divi), scripts de chat (Intercom, Zendesk) y píxeles de seguimiento (Facebook, Google Ads).
Solución: dividir tareas largas
// Dividir tareas largas en fragmentos menores < 50ms
async function longTask(items) {
for (const item of items) {
await processItem(item);
// Ceder al hilo principal
await new Promise(resolve => setTimeout(resolve, 0));
}
}Cómo evitar el CLS en imágenes y anuncios
/* Reservar espacio para imagenes */
img {
aspect-ratio: 16 / 9;
width: 100%;
height: auto;
}
/* Reservar espacio para anuncios */
.ad-slot {
min-height: 250px;
}Ejemplos de prefetch y prerender con Speculation Rules
Este es el corazón de esta guía. Speculation Rules API es una función nativa del navegador que permite precargar páginas en segundo plano, haciendo que la navegación se sienta instantánea para el usuario.
Regla de prefetch para todos los enlaces internos
<script type="speculationrules">
{
"prefetch": [
{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/wp-admin/*" } },
{ "not": { "href_matches": "*.pdf" } }
]
},
"eagerness": "moderate"
}
]
}
</script>Prerender del carrito, checkout y páginas de producto
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["/cart/", "/checkout/"],
"eagerness": "immediate"
},
{
"source": "document",
"where": {
"or": [
{ "href_matches": "/product/*" },
{ "selector_matches": ".important-link" }
]
},
"eagerness": "moderate"
}
]
}
</script>Diferencias entre prefetch y prerender
| Técnica | Qué hace | Cuándo usarla | Coste de recursos |
|---|---|---|---|
| Prefetch | Descarga solo la respuesta HTML, sin subrecursos | Navegación amplia | Bajo |
| Prerender | Carga, renderiza y ejecuta la página en una pestaña oculta | Alta probabilidad de clic | Alto |
Niveles de eagerness en Speculation Rules y su significado
conservative: al pulsar con el puntero o al tocar la pantalla; es el valor por defecto de las reglas de documentomoderate: en escritorio, tras 200 ms de hover (o al pulsar, si ocurre antes); en móvil, 500 ms después de que se detenga el desplazamiento, para enlaces grandes cercanos al último toqueeager: desde Chrome 143, tras 10 ms de hover en escritorio y 50 ms después de que un enlace entre en el viewport en móvilimmediate: en cuanto el navegador lee las reglas; es el valor por defecto de las reglas de lista
Los tiempos proceden de la guía de prerender de Chrome. Antes de Chrome 143, eager se comportaba igual que immediate, así que los artículos antiguos que lo describen como “inmediatamente, de forma agresiva” hablan del comportamiento anterior.
Qué hace WordPress 6.8 con la carga especulativa por defecto
Desde WordPress 6.8, la Speculation Rules API forma parte del núcleo. La función se trasladó desde el plugin Speculative Loading, que funcionaba en más de 50.000 sitios antes de la fusión, y la nota de desarrollo del núcleo indica que los sitios que lo usaban mejoraron su tasa de aprobación de LCP en torno a un 1,9% en la mediana, según datos de HTTP Archive y CrUX. La misma nota señala que más del 8% de las navegaciones en Chrome ya se apoyan en reglas de especulación.
Configuración por defecto de la carga especulativa en el núcleo de WordPress
Sin tocar nada, el núcleo imprime en el frontend un único conjunto de reglas con el modo prefetch y la eagerness conservative. Ambos valores se guardan como auto, de modo que una versión futura puede cambiar lo que significa auto sin romper tu configuración. El prefetch empieza cuando el usuario pulsa sobre un enlace, lo que da una pequeña ventaja de unos cientos de milisegundos y apenas genera peticiones desperdiciadas.
El núcleo desactiva la función en tres situaciones:
- para usuarios con sesión iniciada, de modo que la barra de herramientas, las vistas previas y los enlaces del panel nunca se especulan,
- en sitios sin enlaces permanentes amigables,
- para URLs con parámetros de consulta, que quedan excluidas del prefetch y del prerender por defecto.
La última regla es importante para WooCommerce. Los enlaces de añadir al carrito usan una cadena de consulta, así que la configuración por defecto nunca los precarga. Un plugin que expone otras “URLs de acción” (peticiones GET que cambian el estado) tiene que excluirlas por su cuenta, sobre todo si subes la eagerness.
Cómo cambiar la carga especulativa con filtros de WordPress
El núcleo ofrece dos filtros y una acción. wp_speculation_rules_configuration recibe un array con mode y eagerness, o null cuando la especulación está desactivada para la petición. Los modos válidos son auto, prefetch y prerender; los valores válidos de eagerness son auto, conservative, moderate y eager. immediate se rechaza a propósito, porque se desaconseja con firmeza para reglas a nivel de documento.
// Cambiar la regla del núcleo a prerender al pasar el ratón
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
if ( is_array( $config ) ) {
$config['mode'] = 'prerender';
$config['eagerness'] = 'moderate';
}
return $config;
} );
// Excluir las rutas personalizadas solo del prerender
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths, $mode ) {
if ( 'prerender' === $mode ) {
$paths[] = '/my-account/*';
}
return $paths;
}, 10, 2 );
// Añadir una regla extra junto a la regla del núcleo
add_action( 'wp_load_speculation_rules', function ( WP_Speculation_Rules $rules ) {
$rules->add_rule( 'prerender', 'shop-cart', array(
'source' => 'list',
'urls' => array( '/cart/' ),
'eagerness' => 'moderate',
) );
} );El filtro de rutas excluidas acepta patrones con la sintaxis URL Pattern, relativos al frontend del sitio, y un argumento opcional $mode. La acción wp_load_speculation_rules te entrega un objeto WP_Speculation_Rules, y add_rule() admite tanto reglas de lista como reglas de documento con una condición where. Si el filtro de configuración devuelve null, la especulación se desactiva para esa petición.
Cómo excluir enlaces con las clases no-prefetch y no-prerender
Los editores pueden excluir enlaces concretos sin escribir código. Añade no-prefetch en el campo “Clase(s) CSS adicional(es)” del panel Avanzado de un bloque para sacar sus enlaces por completo de la carga especulativa, o no-prerender para permitir el prefetch pero bloquear el prerender. Como el prefetch forma parte del prerender, no-prefetch cubre ambos modos. Es la solución más rápida cuando un widget concreto, como un calendario de reservas, falla después de un prerender.
Ajustes del plugin Speculative Loading frente al núcleo
El plugin Speculative Loading del equipo de rendimiento de WordPress sigue existiendo y es más agresivo que el núcleo. Por defecto usa prerender con eagerness moderate, así que la página se renderiza en segundo plano cuando el usuario pasa el ratón por encima de un enlace. El modo y la eagerness se configuran en Ajustes, Lectura.
| Ajuste | Núcleo de WordPress 6.8+ | Plugin Speculative Loading |
|---|---|---|
| Modo por defecto | prefetch | prerender |
| Eagerness por defecto | conservative | moderate |
| Usuarios con sesión iniciada | siempre desactivado | desactivado por defecto, activable para todos los usuarios o solo administradores |
| Excluido por defecto | URLs con cadena de consulta | wp-login.php, wp-admin, URLs con nonce, enlaces nofollow |
| Requisitos | WordPress 6.8 | WordPress 6.9+, PHP 7.4+ |
El plugin avisa cuando activas la especulación para usuarios con sesión iniciada sin una caché de objetos persistente, porque cada página especulada cuesta entonces una petición PHP completa sin caché. Su filtro de exclusión se llama plsr_speculation_rules_href_exclude_paths. En una tienda WooCommerce con mucho tráfico de usuarios identificados, mantén desactivada la especulación para ellos hasta tener una caché de objetos como Redis.
Cómo añadir Speculation Rules en WordPress
Método 1: reglas en un plugin propio
En WordPress 6.8 y versiones posteriores, el núcleo ya imprime su propio script speculationrules. Un script personalizado en wp_head añade un segundo conjunto de reglas junto a él, así que usa este método solo en versiones antiguas, o desactiva antes la regla del núcleo devolviendo null desde wp_speculation_rules_configuration. En las versiones actuales, los filtros mostrados arriba son el camino más limpio.
<?php
/**
* Plugin Name: Speculation Rules API
*/
add_action('wp_head', function() {
if (is_admin()) return;
?>
<script type="speculationrules">
{
"prefetch": [
{
"source": "document",
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/wp-*" } }
]
},
"eagerness": "moderate"
}
]
}
</script>
<?php
});Método 2: reglas dinámicas para carrito y paginación
add_action('wp_head', function() {
$prerender_urls = [];
// Prerenderizar productos del carrito
if (function_exists('WC') && WC()->cart) {
foreach (WC()->cart->get_cart() as $item) {
$prerender_urls[] = get_permalink($item['product_id']);
}
}
// Prerenderizar siguiente página del archivo
if (is_archive() || is_home()) {
$next_link = get_next_posts_link();
if ($next_link) {
preg_match('/href="([^"]+)"/', $next_link, $matches);
if (!empty($matches[1])) {
$prerender_urls[] = $matches[1];
}
}
}
if (empty($prerender_urls)) return;
$rules = [
'prerender' => [[
'source' => 'list',
'urls' => array_unique($prerender_urls),
'eagerness' => 'moderate'
]]
];
echo '<script type="speculationrules">' . json_encode($rules) . '</script>';
});Resultados de Speculation Rules en WooCommerce y en un blog
Caso 1: Tienda WooCommerce (500 productos)
Problema: La navegación de categoría a producto tomaba varios segundos
Solución: Prefetch para enlaces en el viewport, prerender para “Añadir al carrito” y “Checkout”
Resultado: De varios segundos de espera a una percepción instantánea. La tasa de rebote bajó de forma notable.
Caso 2: Blog WordPress (1000+ artículos)
Problema: INP fuera de la banda verde, los usuarios sentían “lag”
Solución: Diferir todos los scripts, prerender para “Leer más”, Object Cache (Redis)
Resultado: INP y LCP entraron en la banda verde. El tráfico orgánico creció.
Limitaciones de Speculation Rules y páginas a excluir
Páginas que no conviene prerenderizar
- Páginas con autenticación (login, panel de usuario)
- Páginas con efectos secundarios (suscripciones, pagos)
- URLs externas
Data Saver, soporte de navegadores y límite de prerender
- Data Saver desactiva la especulación; más abajo está la lista completa de condiciones que la bloquean
- Navegadores no compatibles (Firefox, y Safari sin la opción experimental) ignoran las reglas
- Límite de prerender: Chrome permite 10 prerenders para reglas
immediatey solo 2 paraeager,moderateyconservative, donde se descarta primero el más antiguo
Límites de especulación de Chrome por nivel de eagerness
Chrome limita cuántas especulaciones puede mantener una página a la vez, y el límite depende de la eagerness. Las cifras proceden de la guía de prerender de Chrome.
| Eagerness | Prefetch | Prerender |
|---|---|---|
immediate | 50 | 10 |
eager, moderate, conservative | 2 | 2 |
En los tres niveles basados en la interacción, la cola funciona como FIFO: una especulación nueva cancela la más antigua. Una URL cancelada puede volver a especularse más tarde, y sus recursos cacheables suelen seguir en la caché HTTP. Quitar de la página un script con reglas de lista libera capacidad immediate, algo útil cuando una regla del carrito debe ceder el sitio a otra regla después del checkout.
Cuándo ignora Chrome las reglas de especulación
Las reglas de especulación son una sugerencia, y Chrome las descarta cuando:
- el usuario tiene activado Save-Data,
- el Ahorro de energía está activo y la batería está baja,
- el dispositivo tiene poca memoria,
- el ajuste “Precargar páginas” está desactivado, algo que hacen algunas extensiones como uBlock Origin,
- la página está abierta en una pestaña en segundo plano.
Las páginas prerenderizadas también retrasan los iframes de otro origen hasta la activación, así que un mapa o un reproductor de vídeo incrustado solo se carga cuando llega el usuario. Las reglas de especulación dentro de una página prerenderizada se procesan después de activarla, y las reglas dentro de iframes se ignoran.
Fallback de prefetch para navegadores sin soporte
if (!HTMLScriptElement.supports?.('speculationrules')) {
// Fallback: prefetch clasico
document.querySelectorAll('a[href^="/"]').forEach(link => {
link.addEventListener('mouseenter', () => {
const prefetch = document.createElement('link');
prefetch.rel = 'prefetch';
prefetch.href = link.href;
document.head.appendChild(prefetch);
}, { once: true });
});
}Cómo hacer que las páginas de WooCommerce sean seguras para prerender
Una página prerenderizada ejecuta su JavaScript antes de que el usuario la vea. Por eso parece instantánea, y por eso puede romper una tienda si el código da por hecho que hay una visita real.
Qué URLs de WooCommerce no es seguro precargar ni prerenderizar
MDN considera inseguras para prefetch y prerender las URLs con efectos secundarios en el servidor: cerrar sesión, cambiar de idioma, añadir al carrito, enviar códigos SMS de un solo uso, consumir cuotas de uso y el seguimiento de conversiones publicitarias. En una tienda WooCommerce eso incluye el enlace de cierre de sesión de Mi cuenta, un selector de moneda o idioma implementado como enlace GET y cualquier URL personalizada de “comprar ahora”. Además, no es seguro prerenderizar páginas cuyos scripts escriben en un almacenamiento del cliente que leen otras pestañas abiertas, ni páginas que envían analítica o impresiones de anuncios antes de que el usuario las haya visto.
Las páginas prerenderizadas también pueden quedar desactualizadas. Una página prerenderizada mientras el visitante no tenía sesión iniciada sigue mostrando la vista de usuario anónimo si el visitante inicia sesión en otra pestaña. Chrome puede conservar una página precargada unos cinco minutos, así que el contenido puede tener esa antigüedad cuando se muestra.
Cómo borrar las páginas especuladas después de añadir al carrito
La cabecera de respuesta Clear-Site-Data acepta los valores prefetchCache y prerenderCache. Si se envía en cualquier petición del mismo sitio, por ejemplo la llamada AJAX que añade un producto al carrito, descarta las especulaciones hechas antes de que cambiara el carrito. El siguiente hover descarga entonces una página de carrito o de checkout nueva en lugar de mostrar la antigua.
// Descartar especulaciones obsoletas cuando WooCommerce cambia el carrito
add_action( 'woocommerce_add_to_cart', function () {
if ( ! headers_sent() ) {
header( 'Clear-Site-Data: "prefetchCache", "prerenderCache"' );
}
} );Cómo detectar peticiones especulativas en el servidor
Chrome marca las peticiones especulativas con la cabecera Sec-Purpose. Un prefetch envía Sec-Purpose: prefetch y un prerender envía Sec-Purpose: prefetch;prerender. Cualquier respuesta final fuera del rango 200 a 299, después de las redirecciones, detiene la especulación, y los códigos 204 o 205 detienen un prerender pero siguen permitiendo un prefetch. Devolver un error es la forma más tosca de bloquear la especulación en una ruta. MDN recomienda aceptar la petición y aplazar los efectos secundarios en JavaScript, porque una especulación bloqueada es una mejora de velocidad perdida.
Cómo retrasar la analítica hasta que se muestre la página prerenderizada
document.prerendering vale true mientras la página se renderiza en segundo plano, y el evento prerenderingchange se dispara cuando el usuario la activa. Envuelve la analítica, las impresiones de anuncios y todo lo que deba contar una visita real:
function initTracking() {
// analítica, impresiones de anuncios, widgets de chat
}
if (document.prerendering) {
document.addEventListener('prerenderingchange', initTracking, { once: true });
} else {
initTracking();
}Varias APIs del navegador esperan a la activación por sí solas. Según MDN, la geolocalización, las solicitudes de permiso de notificaciones, el registro de service workers y el acceso a la cámara devuelven una promesa pendiente hasta que se muestra la página, mientras que alert() retorna de inmediato y confirm() devuelve false. El código que depende de esos resultados durante la carga de la página necesita la misma protección.
Compatibilidad de Speculation Rules con navegadores en 2026
| Navegador | Prefetch | Prerender | Notas |
|---|---|---|---|
| Chrome 121+ | Sí | Sí | Prefetch desde la 110, prerender desde la 105, reglas de documento y eagerness desde la 121 |
| Edge 121+ | Sí | Sí | Mismas versiones que Chrome |
| Opera 107+ | Sí | Sí | Reglas de documento desde la 107 |
| Safari 26.2 | Solo con opción experimental | No | Prefetch tras la preferencia “SpeculationRules prefetch” |
| Firefox | No | No | No implementado |
Las versiones proceden de los datos de compatibilidad de MDN, que todavía marcan la función como experimental y fuera de Baseline. En la práctica, las reglas aceleran la navegación de los usuarios de Chromium y no hacen nada en el resto de navegadores, por eso el núcleo de WordPress las trata como mejora progresiva.
Cómo usar Speculation Rules con una Content Security Policy
Cómo permitir las reglas de especulación con una CSP estricta
Un bloque de reglas de especulación es un elemento <script>, así que una política script-src estricta lo bloquea como cualquier script en línea. MDN describe tres formas de permitirlo: un nonce, un hash o la palabra clave 'inline-speculation-rules'. La guía de Chrome añade que la palabra clave cubre las reglas inyectadas con un hash o un nonce, por lo que en sitios con CSP estricta las reglas suelen insertarse con JavaScript. Si el panel Speculative loads no muestra reglas en un sitio con un plugin de seguridad, lo primero que hay que revisar es la cabecera CSP.
Cómo servir las reglas con la cabecera Speculation-Rules
Las reglas también pueden vivir en un archivo JSON referenciado desde una cabecera de respuesta HTTP, lo que las saca del HTML y del problema de la CSP. La URL de la cabecera debe ir entre comillas, el archivo debe usar el tipo MIME application/speculationrules+json y un archivo de otro origen debe superar una comprobación CORS. Por defecto, las URLs relativas del archivo se resuelven respecto al propio JSON, así que añade "relative_to": "document" a una regla si sus rutas son relativas a la página.
Speculation-Rules: "/speculationrules.json"Las reglas de la cabecera y las reglas en línea se combinan en un único conjunto. Chrome 136 añadió el campo tag, que se envía en la cabecera de petición Sec-Speculation-Tags, de modo que una CDN o un servidor puede saber qué conjunto de reglas disparó una petición y tratarla de otra forma.
Qué especulaciones entre orígenes permite Chrome
Por defecto, el prerender se limita al mismo origen. Un subdominio del mismo sitio, como una tienda en su propio subdominio, solo puede prerenderizarse si responde con la cabecera Supports-Loading-Mode: credentialed-prerender, y el prerender entre sitios distintos no es posible. El prefetch entre sitios solo funciona cuando el usuario no tiene cookies del sitio de destino, lo que impide el rastreo. Las especulaciones rechazadas de este tipo aparecen en el panel Speculative loads de DevTools.
Cómo monitorizar los prefetch de Speculation Rules
Herramientas para comprobar las cargas especulativas
- Chrome DevTools: el panel Speculative loads en la pestaña Application
- Lighthouse CI: automatización de pruebas de rendimiento
- WebPageTest: pruebas reales desde distintas ubicaciones
- DebugBear: Real User Monitoring (RUM)
Cómo medir los aciertos especulativos en GA4
Resource Timing no tiene un tipo de iniciador “speculation”, así que una carga especulativa no se puede observar desde la página que la lanzó. Mide en la página a la que llega el usuario: un activationStart mayor que cero indica que la página se prerenderizó, y un deliveryType igual a navigational-prefetch indica que llegó desde un prefetch. Ambos campos están documentados en MDN.
// Informar de cómo se entregó la página actual
const nav = performance.getEntriesByType('navigation')[0];
let delivery = 'normal';
if (nav.activationStart > 0) {
delivery = 'prerender';
} else if (nav.deliveryType === 'navigational-prefetch') {
delivery = 'prefetch';
}
gtag('event', 'page_delivery', { delivery_type: delivery });Compara el número de aciertos prerender y prefetch con el número de peticiones especulativas que registran los logs del servidor (consulta la cabecera Sec-Purpose más arriba). La diferencia es el desperdicio. Según la guía de prerender de Chrome, Chrome mide los Core Web Vitals de una página prerenderizada desde la activación, no desde el inicio del prerender, y la librería web-vitals informa de esas navegaciones con un navigationType igual a prerender desde la versión 3.1.0. Segmenta tus datos de campo por ese valor, o el LCP casi nulo de las vistas prerenderizadas ocultará una navegación normal lenta.
Checklist de Speculation Rules para WordPress
Antes de implementar
- Medir puntuación Lighthouse base
- Verificar TTFB < 200ms
- Asegurar que Object Cache esté activo
- Imágenes servidas como AVIF
Durante la implementación
- Agregar prefetch básico (moderate)
- Analizar mapas de calor (Hotjar, Clarity)
- Identificar top 3 rutas de navegación
- Agregar prerender para enlaces de alta intención
- Probar en 10% del tráfico (A/B)
- Monitorear prefetches “desperdiciados”
Después de implementar
- Comparar LCP, INP y tiempo de navegación
- Revisar la tasa de aciertos de caché
- A largo plazo: tasa de rebote y tasa de conversión
Resumen
Speculation Rules API es un cambio importante en 2026. Al precargar páginas en segundo plano, la navegación se vuelve instantánea sin cambios de infraestructura.
Puntos clave:
- Comienza con prefetch con eagerness moderate, es seguro
- Agrega prerender para el flujo de checkout en e-commerce
- Monitorea métricas, no adivines, mide
¿Necesitas optimización profesional? Como desarrollador WordPress, ayudo a acelerar sitios WordPress y WooCommerce. Consulta también la auditoría de seguridad WordPress.







