Rendimiento Mobile-First: Estrategias de optimización para el índice móvil 2026

Google indexa y clasifica la versión móvil de una página, la que obtiene su rastreador para smartphones. Un sitio WordPress que solo encoge un diseño de escritorio al ancho del teléfono puede parecer correcto en una revisión rápida y aun así enviar una página pesada y lenta al dispositivo que decide cómo se indexa. Rendimiento mobile-first significa construir cada página primero para un teléfono con una red limitada y añadir peso para pantallas más grandes solo donde se justifique.

Conoce más sobre optimización de velocidad WordPress en WPPoland.

Esta guía explica qué exige la indexación mobile-first de Google, los umbrales de Core Web Vitals en móvil, cómo se mide la velocidad móvil en laboratorio y en campo, y las funciones y patrones de código de WordPress que mejoran LCP, INP, CLS y la navegación hacia atrás en el teléfono.

#Cronología de la indexación mobile-first de 2016 a 2024

Las buenas prácticas de indexación mobile-first de Google definen el término en una línea: Google usa la versión móvil del contenido de un sitio, rastreada con el agente para smartphones, para indexar y clasificar. Llevar a toda la web hasta ahí costó ocho años.

En la publicación de octubre de 2023, John Mueller y Nir Kalush describieron el pequeño grupo de sitios que aún seguían con el rastreador de escritorio. Los errores eran páginas que muestran errores a todos los usuarios móviles, una versión móvil bloqueada en robots.txt mientras la de escritorio sigue siendo rastreable, y páginas móviles que redirigen todas a la página de inicio. En junio de 2024 Mueller escribió que, después del 5 de julio de 2024, un sitio cuyo contenido no sea accesible en absoluto desde un dispositivo móvil dejaría de ser indexable. Googlebot Desktop sigue apareciendo en los registros del servidor para algunas funciones, como las fichas de producto y Google for Jobs, así que un agente de usuario de escritorio en tu registro de accesos no significa que tu sitio se haya omitido.

Por tanto, el “índice móvil 2026” no es un índice nuevo. El cambio se produjo en 2023 y 2024. Lo que sigue cambiando es el contenido de tus páginas móviles y lo rápidas que son para los visitantes reales.

#Qué pide revisar a los sitios WordPress la documentación mobile-first de Google

La página de buenas prácticas es una lista de comprobación de paridad. La versión móvil de una página debe coincidir con la de escritorio en:

• el contenido principal, incluidos texto, imágenes y vídeo
• los datos estructurados
• el elemento title y la meta descripción
• el texto alternativo de las imágenes
• las metaetiquetas robots
• los encabezados

La misma página advierte contra la carga diferida de contenido principal que solo aparece tras una interacción del usuario, como un toque o un deslizamiento, porque el rastreador no realiza esas interacciones. En WordPress los culpables habituales son las pestañas o acordeones que cargan su contenido por AJAX al hacer clic, y las plantillas móviles separadas de plugins móviles antiguos que eliminan secciones, schema o texto alternativo. Un tema responsive que envía el mismo HTML a todos los dispositivos supera la comprobación de paridad por diseño. Es un motivo para tener cuidado con el HTML específico por dispositivo, que se trata más abajo en la sección sobre Client Hints.

#Umbrales de Core Web Vitals para móvil en 2026

Los umbrales actuales son:

Desde marzo de 2024 la métrica de capacidad de respuesta es Interaction to Next Paint. La publicación de lanzamiento de Rick Viscomi en web.dev anunció INP como Core Web Vital estable en sustitución de First Input Delay y dio a los desarrolladores hasta el 9 de septiembre de 2024 para dejar FID. Una guía que todavía cita FID como Core Web Vital es anterior a ese cambio.

Cada umbral se evalúa en el percentil 75 de las cargas de página, por separado para móvil y escritorio (web.dev, Web Vitals). Móvil y escritorio son poblaciones distintas, así que un buen resultado en escritorio no dice nada del resultado en el teléfono.

Muchos equipos fijan objetivos internos por debajo de la línea de “bueno” para tener margen, porque los datos de campo varían con la mezcla de tráfico, las campañas y los scripts de terceros. La propia documentación de Google sobre experiencia en la página añade una advertencia: perseguir una puntuación perfecta solo por motivos de SEO puede no ser el mejor uso de tu tiempo.

#Cómo usa Google las señales de experiencia en la página para clasificar

La documentación de Google sobre experiencia en la página responde directamente a la pregunta sobre la clasificación:

• No existe una única señal de experiencia en la página. Los sistemas principales de clasificación tienen en cuenta muchas señales.
• Los sistemas de clasificación de Google usan las Core Web Vitals.
• Más allá de las Core Web Vitals, los demás aspectos de la experiencia en la página no ayudan directamente a posicionar mejor un sitio, aunque lo hacen más satisfactorio de usar.
• La experiencia en la página se evalúa en general por página, con algunas evaluaciones a nivel de sitio.
• Google sigue mostrando el contenido más relevante aunque la experiencia en la página sea floja. Una buena experiencia ayuda cuando muchas páginas son igual de útiles.

Para el trabajo en móvil esto fija prioridades. El tamaño de los objetivos táctiles, un menú móvil limpio y la compatibilidad con el bfcache merecen la pena para los visitantes y por las Core Web Vitals en las que influyen, pero Google no los describe como señales de clasificación independientes. La misma página no menciona ningún requisito de AMP: su autoevaluación cubre Core Web Vitals, HTTPS, visualización en dispositivos móviles, anuncios, intersticiales intrusivos y un área de contenido principal clara.

#Cómo medir la velocidad móvil en laboratorio y en campo

#Ajustes de emulación móvil de Lighthouse

La ejecución móvil por defecto de Lighthouse emula un Moto G Power (2022) con una ventana de 412 por 823 píxeles, definida en las constantes de configuración de Lighthouse. La documentación sobre limitación indica para la red 150 ms de latencia, 1,6 Mbps de bajada y 750 Kbps de subida, con la etiqueta “Slow 4G”, y la describe como aproximadamente el cuartil inferior de las conexiones 4G. La limitación de CPU usa un multiplicador constante de 4x, pensado para llevar un escritorio de gama alta al nivel de un móvil de gama media. En un portátil más lento ese multiplicador se pasa de la raya, así que revisa el valor “CPU/Memory Power” al final del informe antes de comparar ejecuciones de máquinas distintas.

• Lighthouse (Chrome DevTools): emulación móvil con limitación de CPU y de red
• PageSpeed Insights: datos de usuarios reales (CrUX) más una ejecución de laboratorio de Lighthouse
• WebPageTest: pruebas en dispositivos reales desde distintas ubicaciones

#Datos de campo de CrUX y Search Console

Los datos de campo son los que usa la evaluación de Core Web Vitals. La metodología de CrUX solo recoge datos de usuarios de Chrome que activan el envío de estadísticas de uso y sincronizan su historial de navegación, y Chrome en iOS queda excluido. Safari no es Chrome, así que tampoco aporta nada. Un sitio cuyo público móvil usa sobre todo iPhone obtiene su puntuación móvil de campo de sus visitantes con Android.

• Chrome User Experience Report (CrUX): datos de usuarios reales de Chrome
• Google Search Console (informe Core Web Vitals): grupos de móvil y escritorio para tus propias URL
• RUM (Real User Monitoring): herramientas como SpeedCurve, Calibre o New Relic para una monitorización continua en todos los navegadores

#En qué teléfonos reales conviene probar

Ningún emulador reproduce del todo un dispositivo real. Mantén al menos estos para pruebas:

• un smartphone de gama media (Moto G o Samsung Galaxy A)
• un smartphone reciente de gama alta (iPhone o Pixel)
• una tablet (iPad o Samsung Tab)

#Carga adaptativa según el dispositivo en WordPress

La carga adaptativa sirve versiones de distinto peso de la misma página según lo que pueda manejar el dispositivo del visitante.

#Cómo detectar las capacidades del dispositivo con JavaScript

// Detectar capacidades del dispositivo, con valores por defecto si falta una API
const getDeviceCapabilities = () => {
  return {
    // Núcleos de CPU
    cores: navigator.hardwareConcurrency || 4,
    // Memoria aproximada del dispositivo en GB (no disponible en todos los navegadores)
    memory: navigator.deviceMemory || 4,
    // Tipo de conexión efectiva
    connection: navigator.connection?.effectiveType || '4g',
    // Preferencia de datos reducidos
    saveData: navigator.connection?.saveData || false,
  };
};

MDN marca navigator.deviceMemory como de disponibilidad limitada, no Baseline, accesible solo por HTTPS y deliberadamente impreciso: el valor se redondea a una potencia de dos para dificultar el fingerprinting. Trátalo como una pista con un valor por defecto seguro. La elección del formato de imagen no necesita ninguna detección, porque el elemento picture que se muestra más abajo deja que el navegador elija AVIF o WebP por sí mismo.

#Qué servir a teléfonos de gama alta, media y baja

Según las capacidades detectadas:

Dispositivos de gama alta (8+ núcleos, 8+ GB de RAM, conexión rápida):

• imágenes AVIF de calidad completa
• JavaScript completo con animaciones
• carga especulativa más amplia de las páginas siguientes probables
• vídeos de fondo donde aporten al contenido

Dispositivos de gama media (de 4 a 6 núcleos, de 4 a 6 GB de RAM, 4G):

• imágenes de calidad media
• JavaScript reducido, animaciones CSS sencillas
• carga especulativa solo para los enlaces principales
• imágenes estáticas en lugar de vídeos de fondo

Dispositivos de gama baja (de 2 a 4 núcleos, menos de 4 GB de RAM, conexión lenta o Save-Data):

• imágenes comprimidas de forma agresiva
• solo el JavaScript imprescindible
• sin carga especulativa, para ahorrar ancho de banda
• un diseño simplificado sin efectos visuales

#Client Hints, Accept-CH y caché de páginas en WordPress

Los Client Hints permiten al servidor tomar la misma decisión antes de enviar el HTML. El navegador no los envía por iniciativa propia. Según la guía de Client Hints de MDN, el servidor anuncia qué pistas quiere en una cabecera de respuesta Accept-CH y el navegador las incluye en las peticiones siguientes. Por eso la primera página que ve un visitante nuevo llega sin ellas. Solo las pistas de baja entropía (Save-Data, Sec-CH-UA, Sec-CH-UA-Mobile y Sec-CH-UA-Platform) pueden enviarse por defecto. La memoria del dispositivo viaja como Sec-CH-Device-Memory, y la calidad de la red como ECT, RTT y Downlink.

// 1. Pedir al navegador pistas de dispositivo y de red en las peticiones siguientes
add_action('send_headers', function () {
    header('Accept-CH: Sec-CH-Device-Memory, ECT');
    header('Vary: Sec-CH-Device-Memory', false);
});

// 2. Leer las pistas y elegir un nivel de rendimiento
function device_aware_content_strategy() {
    $memory = isset($_SERVER['HTTP_SEC_CH_DEVICE_MEMORY'])
        ? (float) $_SERVER['HTTP_SEC_CH_DEVICE_MEMORY']
        : null;

    $ect = $_SERVER['HTTP_ECT'] ?? null;

    if ($memory && $memory >= 8 && $ect === '4g') {
        define('WP_DEVICE_TIER', 'high');
    } elseif (($memory && $memory <= 2) || in_array($ect, ['slow-2g', '2g'], true)) {
        define('WP_DEVICE_TIER', 'low');
    } else {
        define('WP_DEVICE_TIER', 'medium');
    }
}
add_action('init', 'device_aware_content_strategy');

La caché es donde suele romperse la adaptación en el servidor. Un plugin de caché de página completa o una CDN guarda una copia del HTML por URL, salvo que su clave de caché incluya la pista. Sin eso, el nivel elegido para el primer visitante se sirve a todos los que llegan después. MDN recomienda listar en la cabecera Vary las pistas que cambian una respuesta y advierte de que las pistas con muchos valores posibles, como Downlink y RTT, hacen que una respuesta sea en la práctica imposible de cachear. Para la mayoría de los sitios WordPress, la división más segura es mantener el HTML idéntico para todos los dispositivos, dejar que srcset y sizes elijan los archivos de imagen y adaptar el JavaScript en el cliente. Así se mantiene además la paridad de contenido que pide la documentación mobile-first de Google.

#Cómo mejorar el LCP en móvil

El Largest Contentful Paint suele ser la métrica más difícil de mejorar en móvil, porque depende a la vez de la red, de la CPU y del tamaño del contenido.

#Cuál es el elemento LCP en móvil

En la mayoría de las páginas WordPress, el elemento LCP móvil es uno de estos:

• la imagen hero o destacada de la entrada
• una imagen de banner de un slider
• el primer bloque largo de texto, en páginas sin imágenes

#Subpartes del LCP y en qué se va el tiempo

La guía de web.dev para optimizar el LCP divide la métrica en cuatro subpartes: tiempo hasta el primer byte, retraso de carga del recurso (desde el TTFB hasta que el navegador empieza a cargar el recurso LCP), duración de la carga del recurso y retraso de renderizado del elemento (desde el final de la descarga hasta que el elemento se ha renderizado por completo). El reparto que propone la guía es que la mayor parte del tiempo se dedique a cargar el documento HTML y el recurso LCP, alrededor del 40 por ciento cada uno, mientras cada uno de los dos retrasos se queda por debajo del 10 por ciento. Un retraso de carga del recurso largo casi siempre significa que el navegador encontró la imagen tarde. La misma guía cita una imagen LCP definida como fondo CSS como un caso que el escáner de precarga no puede descubrir en el HTML, y dice que la imagen LCP no debe cargarse nunca de forma diferida.

#Cómo acelerar el LCP con precarga, formato y tamaño de imagen

Precargar el recurso LCP:

<link rel="preload" as="image" href="/images/hero-mobile.avif"
      type="image/avif" fetchpriority="high">

Eliminar cadenas de descubrimiento: El navegador debe descubrir el recurso LCP lo antes posible:

1. El HTML se descarga (TTFB)
2. Se descubre el recurso LCP en el HTML
3. Se inicia la descarga del recurso

Si tu imagen hero está referenciada en una hoja de estilos externa como background-image, el navegador no la descubrirá hasta que haya descargado y analizado el CSS. Coloca un <img> directamente en el HTML con fetchpriority="high".

Formato de imagen óptimo:

<picture>
  <source srcset="/images/hero-400.avif 400w,
                  /images/hero-800.avif 800w"
          type="image/avif" sizes="100vw">
  <source srcset="/images/hero-400.webp 400w,
                  /images/hero-800.webp 800w"
          type="image/webp" sizes="100vw">
  <img src="/images/hero-800.jpg"
       alt="Descripción relevante"
       width="800" height="450"
       fetchpriority="high"
       decoding="async">
</picture>

Tamaños de imagen específicos para móvil: No envíes el mismo archivo a teléfonos y a escritorios. Una pantalla de teléfono de 400 píxeles de ancho no necesita una imagen de 1920 píxeles:

// Añadir tamaños de imagen para diseños móviles
function add_mobile_image_sizes() {
    add_image_size('mobile-hero', 480, 270, true);
    add_image_size('mobile-thumbnail', 320, 180, true);
}
add_action('after_setup_theme', 'add_mobile_image_sizes');

#Funciones del núcleo de WordPress para imágenes responsive y carga diferida

Buena parte del trabajo con imágenes descrito arriba ya está en el núcleo de WordPress, y un plugin que lo repite puede estorbar.

• WordPress 4.4 (2015): srcset y sizes. La nota para desarrolladores de Joe McGill explica que WordPress añade srcset y sizes al marcado de imagen que genera, para que el navegador pueda descargar el tamaño más adecuado. El valor por defecto de sizes supone que la imagen se muestra a su propio ancho hasta el ancho completo de la ventana, y la nota indica a los temas que lo ajusten con el filtro wp_calculate_image_sizes (wp_calculate_image_srcset cambia la lista de candidatos). El filtro max_srcset_image_width limita los anchos incluidos, 1600 píxeles por defecto. La misma versión añadió el tamaño medium_large, de 768 píxeles de ancho y sin límite de altura, que solo se genera para las subidas nuevas o al regenerar los tamaños.
• WordPress 5.5: carga diferida nativa. El atributo loading lo controla wp_lazy_loading_enabled, introducido en la 5.5 y activado por defecto para los iframes desde la 5.7.
• WordPress 6.3: atributos de optimización de carga. wp_get_loading_optimization_attributes decide si una imagen recibe loading="lazy", fetchpriority="high" o decoding="async". No toca los atributos ya presentes y avisa si un elemento fuera a recibir a la vez carga diferida y prioridad alta. Desde la 7.0 también acepta fetchpriority="low" y fetchpriority="auto", de modo que no se añade la carga diferida.

La comprobación práctica está en el HTML renderizado de una página real con una ventana de teléfono: la imagen hero debe llevar fetchpriority="high" y no loading="lazy", y su valor de sizes debe coincidir con el espacio que ocupa realmente la imagen en el diseño móvil. Un tema que imprime el hero como fondo CSS se salta todo esto.

#Carga especulativa en WordPress 6.8

WordPress 6.8 activó la carga especulativa mediante la Speculation Rules API del navegador. La nota para desarrolladores de Felix Arntz expone los valores por defecto:

• Está activada en el frontend de todos los sitios, salvo para usuarios con sesión iniciada y sitios con los enlaces permanentes amigables desactivados.
• Las URL se precargan con una intensidad conservadora, que se activa cuando el usuario empieza a hacer clic en un enlace.
• Las URL con parámetros de consulta se excluyen automáticamente, lo que cubre la mayoría de las “URL de acción” que cambian el estado con una petición GET.
• Chrome, Edge y Opera admiten la API; los demás navegadores la ignoran, así que nada se rompe.

La nota indica que el plugin experimental funcionó en más de 50.000 sitios antes de la integración, y que los sitios que lo usaban mejoraron su tasa de aprobación del LCP en un 1,9 por ciento aproximadamente en la mediana, medido con datos de HTTP Archive y CrUX. En móvil, donde los toques de atrás y adelante y los toques en enlaces son todo el modelo de navegación, esto importa más que en escritorio. Los plugins con rutas de acción propias, como un carrito, deberían excluirlas:

add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $href_exclude_paths ) {
    $href_exclude_paths[] = '/cart/*';
    return $href_exclude_paths;
} );

#Cómo mejorar el INP en móvil

INP mide la rapidez con la que la página responde a la entrada del usuario. El artículo sobre INP de web.dev cuenta tres tipos de interacción: clics de ratón, toques en una pantalla táctil y pulsaciones en un teclado físico o en pantalla. Pasar el puntero por encima, hacer zoom y desplazarse no se observan. La latencia de cada interacción tiene tres partes: el retraso de entrada antes de que se ejecute ningún manejador, el tiempo de procesamiento de los manejadores y el retraso de presentación hasta que se pinta el siguiente fotograma. En un teléfono cada interacción es un toque y la CPU es más lenta, así que las tres partes crecen.

#Principales causas de un INP móvil deficiente

1. JavaScript pesado en el hilo principal: scripts de terceros (analítica, chat, anuncios) que bloquean la interacción.
2. Hidratación de frameworks: React, Vue o Angular hidratando componentes después de la carga inicial.
3. Manejadores de eventos costosos: listeners que ejecutan cálculos pesados al tocar.
4. Tareas largas: la guía de web.dev para optimizar tareas largas define una tarea larga como cualquier tarea que dura más de 50 ms.

#Cómo reducir el INP aplazando JavaScript

Aplazar el JavaScript no crítico:

<!-- Cargar la analítica tras la primera interacción del usuario -->
<script>
  let analyticsLoaded = false;
  function loadAnalytics() {
    if (analyticsLoaded) return;
    analyticsLoaded = true;
    const script = document.createElement('script');
    script.src = '/analytics.js';
    document.head.appendChild(script);
  }

  // Cargar al primer toque, desplazamiento o pulsación de tecla, o tras 5 segundos
  ['touchstart', 'scroll', 'keydown'].forEach(event => {
    document.addEventListener(event, loadAnalytics, { once: true, passive: true });
  });
  setTimeout(loadAnalytics, 5000);
</script>

Usar requestIdleCallback para el trabajo no urgente:

// Ejecutar trabajo no crítico mientras el navegador está inactivo
requestIdleCallback((deadline) => {
  while (deadline.timeRemaining() > 0) {
    processNonCriticalTask();
  }
});

Ceder el control dentro de los manejadores de eventos:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

button.addEventListener('click', async () => {
  showSpinner();        // respuesta visible en el siguiente fotograma
  await yieldToMain();  // dejar que el navegador pinte primero
  heavyCalculation();   // la parte lenta se ejecuta en una tarea posterior
});

Envolver el trabajo pesado en requestAnimationFrame no ayuda, porque ese callback se ejecuta justo antes del siguiente pintado y sigue reteniendo el fotograma. Ceder el control divide el trabajo para que el navegador pueda pintar primero la respuesta al toque. La guía de tareas largas señala que scheduler.yield() es compatible con Chrome y Edge 129 y con Firefox 142, pero no con Safari, y por eso está ahí la alternativa con setTimeout.

#Cómo evitar el CLS en móvil en WordPress

El Cumulative Layout Shift (CLS) molesta sobre todo en un teléfono, donde la pantalla es pequeña y cualquier movimiento se nota. En un teléfono, un desplazamiento de 10 píxeles resulta mucho más molesto que en un monitor de 27 pulgadas.

#Qué causa el CLS en móvil

• imágenes sin dimensiones explícitas
• fuentes web que causan FOUT o FOIT
• anuncios y contenido inyectado dinámicamente
• barras de navegación que cambian de tamaño al desplazarse
• el teclado virtual que empuja el contenido

#Cómo reservar espacio para imágenes, fuentes y anuncios

Reservar espacio para imágenes:

/* Cajas con relación de aspecto para imágenes */
.wp-post-image {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
}

Precargar fuentes críticas:

<link rel="preload" href="/fonts/main-font.woff2"
      as="font" type="font/woff2" crossorigin>

/* font-display: swap con una fuente alternativa de métricas ajustadas */
@font-face {
  font-family: 'MainFont';
  src: url('/fonts/main-font.woff2') format('woff2');
  font-display: swap;
  size-adjust: 98%;
  ascent-override: 95%;
  descent-override: 22%;
}

Reservar espacio para anuncios:

.ad-slot {
  min-height: 250px; /* Altura esperada del anuncio */
  background: #f5f5f5;
  contain: layout;
}

#Cómo hacer que las páginas WordPress sean compatibles con el bfcache

La caché de páginas anteriores y siguientes (bfcache) guarda en memoria una instantánea completa de la página, incluido el heap de JavaScript, de modo que al volver atrás se restaura casi al instante sin tocar la red. La guía del bfcache en web.dev de Philip Walton y Barry Pollard cita datos de uso de Chrome según los cuales 1 de cada 5 navegaciones en móvil es hacia atrás o hacia adelante, frente a 1 de cada 10 en escritorio. Todos los navegadores principales tienen bfcache, Chrome desde la versión 96.

#Qué impide el bfcache

• Listeners de unload. Desde Chrome 155, los manejadores de unload ya no se ejecutan por defecto en Chrome, y el cambio llegará también a otros navegadores basados en Chromium. Todavía pueden ejecutarse en Chrome para iOS y en sitios que los reactivan mediante Permissions Policy (Chrome for Developers, 16 de octubre de 2026). Según Chrome, el porcentaje de navegaciones en las que unload era el único bloqueo del bfcache bajó del 6% a alrededor del 1%. Firefox sigue excluyendo una página con un listener de unload, salvo en iOS (web.dev). Usa pagehide o visibilitychange en su lugar; Lighthouse tiene una auditoría no-unload-listeners que también detecta código de terceros.
• Cache-Control: no-store en el HTML. Históricamente los navegadores se han negado a guardar esas páginas en el bfcache. Para contenido que debe mantenerse actualizado pero no es sensible, la guía recomienda no-cache o max-age=0, que no afectan a la compatibilidad.
• Referencias a window.opener. Una página abierta con window.open() y controlada desde la página que la abrió no puede guardarse en caché. rel="noopener" lo evita y ahora es el comportamiento por defecto del navegador para target="_blank".
• Conexiones abiertas. Algunos navegadores descartan páginas con una conexión IndexedDB abierta, un fetch() o XMLHttpRequest en curso, o una conexión WebSocket o WebRTC abierta. La guía señala que Chrome (desde la versión 149) y Safari ya no bloquean por WebSockets abiertos. Cierra las conexiones en pagehide y vuelve a abrirlas en pageshow.

Los usuarios móviles navegan con el botón Atrás constantemente. Cuando una página vuelve desde el bfcache, aparece sin una nueva petición.

#Cómo comprobar si una página se restaura desde el bfcache

// Comprobar si la página se restauró desde el bfcache
window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('Page restored from bfcache');
    // Actualizar contenido dinámico, como el número de productos del carrito, si hace falta
    refreshDynamicContent();
  }
});

La guía también recomienda actualizar en pageshow los datos obsoletos o sensibles cuando persisted es verdadero, por ejemplo el total del carrito después de que el usuario lo haya cambiado en otra página.

#Ajustes de WordPress para el bfcache

// Enviar las cabeceras de caché y de política antes de cualquier salida
add_action('send_headers', function () {
    if (!is_user_logged_in()) {
        header('Cache-Control: public, max-age=300');
        // Rechazar manejadores unload, incluidos los añadidos por terceros
        header('Permissions-Policy: unload=()');
    }
});

// Eliminar un script de plugin que se sabe que registra un manejador unload
add_action('wp_enqueue_scripts', function () {
    wp_dequeue_script('plugin-with-unload-handler');
}, 99);

Las cabeceras van en send_headers, porque wp_enqueue_scripts se ejecuta dentro de wp_head, cuando la salida ya ha empezado. La línea de Permissions Policy sigue el consejo de la guía del bfcache para sitios que no usan unload en absoluto. Chrome DevTools incluye en el panel Application una prueba de la caché de páginas anteriores y siguientes que indica el motivo exacto del bloqueo de una página.

#Objetivos táctiles y menús móviles fáciles de pulsar

Los objetivos táctiles importan para la usabilidad y la accesibilidad. Google no los describe como una señal de clasificación.

#Tamaño mínimo de los objetivos táctiles

• WCAG 2.2, criterio de conformidad 2.5.8 (nivel AA): el documento Understanding exige objetivos de puntero de al menos 24 por 24 píxeles CSS, con excepciones por espaciado, control equivalente, objetivos en línea dentro del texto, controles del agente de usuario y casos esenciales. Para los controles importantes remite al criterio más estricto 2.5.5 Target Size (Enhanced).
• Recomendaciones de Lighthouse sobre objetivos táctiles: la documentación de la auditoría dice que los objetivos de 48 por 48 píxeles nunca fallan y que 8 píxeles entre objetivos es un buen punto de partida.

La excepción para elementos en línea importa para el CSS. Los enlaces dentro de los párrafos no necesitan una altura mínima, así que aplica el tamaño solo a la navegación, los botones y los controles de formulario:

/* Objetivos táctiles mínimos para controles, no para enlaces dentro del texto */
nav a, button, input, select, textarea, .wp-block-button__link {
  min-height: 48px;
  min-width: 48px;
  padding: 12px;
}

#Cómo hacer un menú móvil fácil de pulsar

Los menús de navegación móviles necesitan un cuidado especial con los objetivos táctiles:

.mobile-nav a {
  display: block;
  padding: 16px 24px;
  min-height: 48px;
  font-size: 16px; /* Legible sin zoom */
  line-height: 1.5;
}

.mobile-nav li + li {
  border-top: 1px solid #eee;
}

#Optimización de Core Web Vitals móviles con WPPoland

En WPPoland construimos para el dispositivo que el usuario tiene en la mano, no para el monitor de nuestro escritorio.

1. Carga adaptativa: mantenemos el HTML idéntico en todos los dispositivos y adaptamos imágenes y scripts donde las mediciones muestran una mejora.
2. Auditoría específica para móvil: probamos en dispositivos móviles reales, no solo con la emulación del navegador.
3. Primero los datos de campo: trabajamos sobre el informe CrUX móvil y llevamos los grupos de URL de “Malo” o “Necesita mejora” a “Bueno”.

#Preguntas frecuentes sobre rendimiento móvil

1. ¿Si tengo una app móvil, no necesito un sitio móvil rápido? Sí lo necesitas. La mayor parte de tu tráfico sigue llegando desde buscadores y enlaces en redes sociales. Si tu sitio móvil es lento, los visitantes se van antes de ver siquiera el enlace a tu app.
2. ¿Es mejor el Dynamic Serving que el Responsive Design? En la práctica la respuesta suele ser un enfoque híbrido. El HTML y el CSS siguen siendo responsive e idénticos para todos los dispositivos, mientras que los archivos de imagen, el JavaScript y las funciones no críticas se ajustan al dispositivo y a la conexión.
3. ¿Cuál es el objetivo de LCP en móvil en 2026? El umbral de “bueno” es 2,5 s en el percentil 75 de las cargas de página en móvil. Apunta por debajo con margen suficiente para que una semana de campaña con más carga no lleve la página por encima.

#Conclusión

Google rastrea e indexa la web como un smartphone desde que la migración terminó en 2023 y 2024. El trabajo de rendimiento móvil en WordPress se reduce ahora a unas pocas cosas medibles: el mismo contenido en todos los dispositivos, una imagen LCP que el navegador encuentra en el HTML, tareas cortas alrededor de cada toque, espacio reservado para todo lo que carga tarde y páginas que el bfcache puede conservar. Mídelas en CrUX para tus visitantes móviles, compruébalas con Lighthouse en un perfil con limitación y corrige cada métrica de Core Web Vitals en ese orden. Para el INP en concreto, consulta la guía de optimización de INP.

Si tus Core Web Vitals móviles están frenando tu posicionamiento, contacta con WPPoland para una auditoría móvil.

#Recursos relacionados

• Optimización de velocidad WordPress - Servicio completo de optimización
• Desarrollo WordPress profesional - Implementación mobile-first
• SEO, GEO y AEO - Posicionamiento móvil
• Auditoría de seguridad - Seguridad sin comprometer rendimiento