Cómo mejorar LCP (Largest Contentful Paint)
LCP mide cuándo termina de renderizarse el elemento más grande del viewport. Un buen LCP es de 2,5 segundos o menos en el percentil 75. La mayoría de los problemas de LCP vienen de una respuesta lenta del servidor, recursos que bloquean el renderizado o una imagen principal sin optimizar. Esto es lo que más impacto tiene, en orden aproximado:
- Sirve el elemento LCP rápido: si es una imagen, comprímela, usa un formato moderno como AVIF o WebP, fija ancho y alto y añade fetchpriority high para que el navegador la cargue primero.
- Reduce el tiempo de respuesta del servidor (TTFB): cachea el HTML en el edge, usa un CDN y evita consultas lentas a la base de datos en la ruta crítica. Un TTFB por encima de 800ms hace casi imposible un buen LCP.
- Elimina el CSS y JavaScript que bloquean el renderizado: incrusta el CSS crítico inline, aplaza el resto y evita scripts de terceros síncronos above the fold.
- Precarga el recurso LCP: añade un enlace de preload para la imagen principal o la fuente para que empiece a descargarse antes de que el navegador la descubra en el DOM.
- No apliques lazy-loading a la imagen LCP: hacerlo en la imagen principal above the fold la retrasa. Usa lazy-loading solo below the fold.
Ejemplo: precargar y priorizar la imagen LCP
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
<img src="/hero.avif" width="1200" height="600" fetchpriority="high" alt="Hero image">
Cómo mejorar INP (Interaction to Next Paint)
INP sustituyó a First Input Delay como Core Web Vital en marzo de 2024. Mide la rapidez con la que la página responde a las interacciones durante toda la visita, no solo la primera. Un buen INP es de 200ms o menos en el p75. Los problemas de INP casi siempre son tareas largas en el hilo principal. Para mejorarlo:
- Divide las tareas largas: parte el trabajo que dura más de 50ms (una tarea larga) en trozos más pequeños y cede el hilo principal para que la entrada se procese entremedias.
- Aplaza el trabajo no urgente: saca analytics, hidratación y cálculos pesados de la ruta de interacción, por ejemplo con requestIdleCallback o esperando hasta después de que la interacción pinte.
- Envía menos JavaScript: divide el código por ruta y elimina los scripts de terceros sin usar que acaparan el hilo principal.
- Mantén ligeros los manejadores de eventos: aplica debounce a las actualizaciones costosas y evita el layout thrashing dentro de los manejadores para que una interacción pinte rápido.
- Mueve los cálculos pesados a un web worker para que nunca bloqueen el hilo principal durante una interacción.
Cómo mejorar CLS (Cumulative Layout Shift)
CLS mide el movimiento inesperado del diseño mientras se carga la página. Un buen CLS es de 0,1 o menos. Los desplazamientos casi siempre vienen de contenido que carga sin espacio reservado. Para arreglarlo:
- Fija ancho y alto, o una aspect-ratio, en imágenes, vídeos y embeds para que el navegador reserve su espacio antes de que carguen.
- Reserva espacio para anuncios, banners y embeds con un min-height para que el contenido que carga tarde no empuje la página hacia abajo.
- Precarga las fuentes y usa font-display optional o una fuente de respaldo bien ajustada para evitar el desplazamiento por un cambio tardío de fuente web.
- Nunca insertes contenido por encima del contenido existente salvo como respuesta directa a una interacción del usuario.
- Anima con transform y opacity, no con propiedades que provocan layout como top, left, width o height.
WordPress y los Core Web Vitals
Los sitios WordPress suelen suspender los Core Web Vitals por las mismas pocas razones: temas pesados, imágenes sin optimizar, CSS y JS de plugins que bloquean el renderizado y hosting lento. Las soluciones de mayor impacto:
- Añade caché de página, con un plugin de caché o caché a nivel de hosting, para servir el HTML rápido, más un CDN para los recursos. Esto solo ya suele arreglar el LCP.
- Optimiza las imágenes con un plugin de imágenes moderno que sirva AVIF o WebP, con el tamaño correcto y lazy-loading solo below the fold.
- Reduce el exceso de plugins: cada plugin que carga CSS o JS en cada página perjudica al INP y al LCP. Audita y elimina lo que no necesites.
- Elige un tema ligero y evita los page builders que envían grandes cantidades de CSS y JavaScript.
- Cambia de hosting si el TTFB es alto. El hosting compartido barato a menudo no puede ofrecer un buen LCP por mucho que optimices en la página.
¿Afectan los Core Web Vitals al SEO?
Sí. Los Core Web Vitals forman parte de las señales de experiencia de página de Google y pueden influir en el posicionamiento, sobre todo como criterio de desempate entre páginas de relevancia y calidad similares. No son una solución mágica que supere al contenido y los enlaces, pero unas métricas malas pueden frenar una página y unas buenas eliminan una desventaja.
La mayor ganancia suele ser comercial. Las páginas más rápidas y estables convierten mejor y tienen menos rebote, así que mejorar los Core Web Vitals suele compensar en ingresos antes que en posicionamiento. Google mide la señal con datos de campo reales de CrUX, así que las correcciones solo de laboratorio que no llegan a usuarios reales no mueven nada.
Relacionado: Core Web Vitals Checker · What are Core Web Vitals · Page Speed Monitoring