Ir al contenido

Mostrar rápido el contenido principal de la página en el móvil

Técnica Actualizado el 4 oct 2026

Descripción

Este criterio mide la velocidad de la página en las condiciones de un teléfono medio: iPand la carga una vez, en frío, en un Pixel 7 simulado, con la red y el procesador ralentizados del perfil móvil de Lighthouse. Registra cuándo se muestra el elemento visible más grande (LCP) y cuánto tiempo bloquean la página los scripts (TBT); el tiempo de respuesta del servidor (TTFB) se mide al obtener la página directamente.

Es una medición de laboratorio, no la velocidad que perciben tus visitantes reales (Chrome UX Report).

Por qué importa para las IA

Google recomienda ofrecer una buena experiencia de página para aparecer en sus funciones de IA, y la velocidad de visualización forma parte de ella. Un servidor lento también frena el rastreo: cuando los tiempos de respuesta se alargan, Google rastrea menos páginas de tu web.

  • El LCP marca el momento en que el contenido principal se vuelve visible: web.dev lo considera bueno si no pasa de 2,5 s.
  • El TTFB no es una Core Web Vital, pero web.dev aconseja no superar 0,8 s: todo el resto de la carga espera la respuesta del servidor.
  • Cada tarea de JavaScript de más de 50 ms bloquea la página; el TBT suma esos bloqueos y señala una página que reacciona mal a las acciones de los visitantes.

Cómo corregirlo

  1. 1 Acelera la visualización del elemento principal El LCP no debe superar 2,5 s; es la medida que más pesa en el criterio. Localiza el elemento principal, a menudo la imagen de la parte superior de la página o el primer título. Sírvelo al tamaño adecuado y en un formato ligero, no aplaces su carga (loading=lazy) y precárgalo si el navegador lo descubre tarde.
  2. 2 Haz que el servidor responda más rápido El servidor debe enviar los primeros bytes de la página en 0,8 s como máximo. Almacena las páginas en caché en el servidor o en un CDN, evita las redirecciones previas a la página y aligera los procesos que se ejecutan en cada visita, como las consultas a la base de datos o las extensiones del CMS.
  3. 3 Aplaza los scripts no esenciales El TBT no debe superar 200 ms. Carga los scripts con defer o async, retira los scripts de terceros que ya no necesites (widgets, herramientas de seguimiento duplicadas) y divide los procesos largos. La parte de cada tarea que supera 50 ms se suma al TBT.
  4. 4 Deja margen bajo los umbrales Prueba la página con Lighthouse o PageSpeed Insights en modo móvil, en condiciones comparables a las de iPand. Un valor a ± 10 % de un umbral mantiene el veredicto del análisis anterior, para que el estado no cambie de un día para otro: apunta claramente por debajo.

Claves

iPand juzga la página como la vería un teléfono medio: contenido principal en 2,5 s, servidor en 0,8 s y bloqueo por scripts de 200 ms como máximo. Deja margen bajo estos umbrales para obtener un veredicto estable.

Para saber más