Cómo acelerar WordPress: guía práctica de Core Web Vitals (LCP, INP y CLS)

Un WordPress lento rara vez tiene una sola causa. Suele ser la suma de un alojamiento justo, imágenes sin optimizar, un tema pesado y demasiados plugins que cargan JavaScript en cada página. La buena noticia es que casi todo es medible y corregible en un orden razonable. Esta guía explica cómo hacerlo con los tres indicadores que Google agrupa como Core Web Vitals.

Qué miden los Core Web Vitals y qué umbrales fijan

Son tres métricas de experiencia real de usuario. Google considera que una página es «buena» cuando, en el percentil 75 de las visitas, se cumplen estos umbrales, definidos en la documentación de web.dev:

• LCP (Largest Contentful Paint): tiempo hasta que se pinta el elemento principal, normalmente una imagen o un titular. Bueno: 2,5 segundos o menos.
• INP (Interaction to Next Paint): latencia de respuesta a toques, clics y teclado durante la visita. Bueno: 200 milisegundos o menos.
• CLS (Cumulative Layout Shift): cuánto se desplazan los elementos de forma inesperada. Bueno: 0,1 o menos.

Importan para la experiencia y forman parte de las señales de página de Google, aunque no sustituyen a un contenido relevante. Mejorarlas también reduce el abandono y favorece la conversión.

Primero medir: datos de campo y de laboratorio

Optimizar sin medir lleva a perder tiempo en lo que no pesa. Hay que distinguir dos tipos de datos:

• Datos de campo: de usuarios reales. Se consultan en PageSpeed Insights (sección de datos del informe de experiencia de Chrome) y en el informe de Core Web Vitals de Search Console, agrupados por tipo de URL.
• Datos de laboratorio: simulaciones con Lighthouse. Sirven para depurar un cambio concreto, pero no reflejan la variedad de dispositivos y redes reales.

Un orden útil: localizar en Search Console qué grupos de URL fallan, analizar una página representativa de cada grupo en PageSpeed Insights y abordar la métrica que suspende.

Servidor, caché y tiempo de respuesta

Si el servidor tarda en responder, ninguna optimización posterior compensa el retraso. Los puntos con más efecto son:

1. Alojamiento adecuado, con PHP actual (8.2 o superior), HTTP/2 o HTTP/3 y recursos suficientes. Un plan compartido saturado explica muchos casos de LCP inexplicable.
2. Caché de página para servir HTML estático a visitantes anónimos, en lugar de ejecutar PHP y consultas en cada visita.
3. Caché de objetos (Redis o Memcached) si el sitio es dinámico o tiene mucho contenido.
4. CDN para distribuir imágenes, CSS y JavaScript cerca del usuario.
5. Base de datos limpia: revisiones, transients caducados y opciones con `autoload` excesivo ralentizan cada petición.

Imágenes y LCP: el arreglo con más retorno

En la mayoría de sitios WordPress, el elemento LCP es una imagen. La guía de optimización de LCP descompone el tiempo en cuatro partes y deja claro que lo habitual es perderlo en cargar un recurso tarde. En la práctica:

• Servir WebP o AVIF en tamaños acordes con el diseño, con `srcset` y `sizes` correctos.
• No aplicar carga diferida (`loading="lazy"`) a la imagen principal: debe cargarse cuanto antes, y puede reforzarse con `fetchpriority="high"`.
• Aplicar carga diferida a todo lo que queda fuera de la primera pantalla.
• Precargar las fuentes críticas, limitar las familias y pesos, y usar `font-display: swap`.
• Evitar que el LCP dependa de un slider con JavaScript: el carrusel suele retrasarlo varios segundos.

JavaScript, CSS e INP

Un INP alto indica que el hilo principal está ocupado cuando el usuario interactúa. En WordPress casi siempre se debe a scripts de terceros y a plugins que cargan en todas las páginas. La documentación sobre optimización de INP recomienda dividir las tareas largas y retrasar lo no esencial.

• Auditar qué plugins cargan CSS y JS en páginas donde no se usan y descargarlos selectivamente con un gestor de recursos.
• Diferir o retrasar scripts de terceros: chats, mapas, vídeos incrustados, píxeles de seguimiento.
• Sustituir vídeos incrustados por una imagen de vista previa que cargue el reproductor solo al pulsar.
• Reducir CSS no usado y extraer el crítico, con cuidado para no producir parpadeos.
• Evitar constructores de páginas con estructuras de DOM excesivamente profundas.

CLS: estabilidad visual

Los saltos de diseño suelen venir de elementos sin espacio reservado. Se corrigen definiendo siempre `width` y `height` (o `aspect-ratio`) en imágenes y vídeos, reservando altura para banners, anuncios y avisos de cookies, evitando insertar contenido sobre lo ya visible y cargando las fuentes de forma que no cambie el tamaño del texto al sustituirse.

Para no dispersarse, un plan por prioridades funciona mejor que una lista infinita de ajustes:

1. Corregir el tiempo de respuesta del servidor y activar la caché de página.
2. Optimizar la imagen LCP y las fuentes de la primera pantalla.
3. Descargar plugins y scripts no esenciales, y diferir los de terceros.
4. Reservar el espacio de los elementos que cargan tarde y volver a medir.

Los datos de campo se calculan con una ventana móvil de 28 días, así que las mejoras tardan semanas en verse en Search Console aunque Lighthouse ya las refleje. Conviene no volver a cambiar todo a los tres días por impaciencia.

Mantener la velocidad con el tiempo

Un sitio rápido deja de serlo si cada plugin nuevo suma peso. Conviene fijar un presupuesto de rendimiento, revisar Search Console tras cada cambio importante y desinstalar lo que ya no se usa. Si el tema y los plugins son el cuello de botella, a veces es más barato rehacer la base que seguir parcheando: es el tipo de decisión que se analiza en la comparativa entre Next.js y WordPress.

En una tienda, estos ajustes tienen un impacto aún mayor en la facturación, y por eso les dedicamos una guía propia sobre velocidad y conversión en WooCommerce. AYM Flow integra la optimización de Core Web Vitals en todos sus proyectos de diseño web y la ofrece como auditoría independiente dentro del servicio de SEO técnico.

Compartir:XLinkedInWhatsApp