Los Core Web Vitals (CWV) miden aspectos de la carga, la respuesta a las interacciones y la estabilidad visual. En WordPress conviene localizar qué recurso o comportamiento causa el problema antes de cambiar plugins o configuración. Google utiliza estas métricas en sus sistemas de posicionamiento, pero aprobarlas no garantiza primeras posiciones ni un aumento de contactos.
En esta guía te explico qué tocar y qué NO tocar para mejorar LCP, INP y CLS con criterio, evitando cambios que rompen el diseño o las conversiones.
Si prefieres que lo revisemos y ejecutemos con seguridad, esto encaja con mantenimiento web y, si hay que optimizar estructura/código, con desarrollo web.
1) Qué miden LCP, INP y CLS (en lenguaje claro)
- LCP (Largest Contentful Paint): tiempo hasta que se renderiza el elemento de contenido elegible más grande visible en la ventana; no siempre coincide con el hero.
- INP (Interaction to Next Paint): latencia desde un clic, toque o pulsación de tecla hasta la siguiente actualización visual. No mide necesariamente el tiempo total de una operación, como recibir la respuesta del servidor.
- CLS (Cumulative Layout Shift): inestabilidad visual por desplazamientos inesperados; también puede producirse después de la carga inicial.
Fuente oficial (Google): explicación de métricas en Web Vitals.
Los umbrales de experiencia buena son LCP ≤ 2,5 s, INP ≤ 200 ms y CLS ≤ 0,1, evaluados en el percentil 75 y separando móvil/escritorio. Con muestra suficiente de las tres métricas, las tres deben cumplirlos. PageSpeed puede emitir su evaluación con LCP y CLS si falta muestra de INP; eso no demuestra que las interacciones se hayan verificado. La puntuación global de Lighthouse es otra medida.
2) Cómo medir bien (sin caer en la trampa de una sola herramienta)
Para tomar decisiones correctas, combina:
- Datos reales (campo): Chrome UX Report / Search Console (si tienes suficiente tráfico).
- Datos de laboratorio: Lighthouse, también integrado en PageSpeed Insights, para reproducir problemas en condiciones controladas. PageSpeed puede mostrar además datos de campo.
Compara la misma URL y tipo de dispositivo, y comprueba si los datos de campo corresponden a esa URL o al origen. Su ventana de 28 días tarda en reflejar por completo un cambio reciente. Si no hay muestra de campo, no lo interpretes como aprobado: utiliza pruebas repetibles y revisa las interacciones.
Fuente oficial: PageSpeed Insights.
Para investigar una variación, guarda URL, fecha, dispositivo, métricas y condiciones de prueba; no compares solo la nota. Una medición aislada no identifica la causa. Según la documentación de INP, también hay que observar interacciones: cargar la página sin pulsar nada no comprueba su respuesta durante el uso.
3) Cómo localizar y mejorar el problema de LCP
3.1 Identifica el elemento LCP antes de optimizar el hero
El LCP puede ser una imagen o un bloque de texto, y cambiar entre móvil y escritorio. Si es una imagen, distingue espera del servidor, inicio de la descarga, descarga y retraso hasta que se muestra. Comprimir no resuelve un elemento oculto hasta que termina un script. La guía oficial de optimización de LCP explica este desglose.
- Compara calidad y peso de formatos como WebP/AVIF. Sirve variantes según el espacio y la densidad de pantalla, comprobando qué archivo se descarga. El diseño responsive no consiste solo en reducir la imagen con CSS.
- Compresión correcta (sin destruir calidad).
- Identifica la imagen que realmente produce el LCP y evita cargarla de forma diferida. No apliques esa excepción a todas las imágenes de la página.
- Si hay un carrusel, comprueba si retrasa el elemento LCP o descarga imágenes innecesarias. Simplifícalo cuando la medición lo justifique, sin atribuirle pérdidas de conversión no verificadas.
3.2 TTFB: diagnostica antes de cambiar de hosting
Si el primer byte tarda mucho (TTFB), la web va a sufrir en LCP. Señales típicas:
- Picos de carga en horas concretas
- Backoffice lento
- Caídas o “microcortes”
Separa latencia de red, trabajo de WordPress, consultas, caché y capacidad del servidor. La caché de página puede reducir trabajo de origen; una migración de hosting solo tiene sentido si el diagnóstico lo justifica. Integra las pruebas en el mantenimiento web.
3.3 Caché y recursos críticos
- Revisa la caché de página y su purgado, excluyendo contenido privado o personalizado que no deba compartirse entre visitantes.
- Minimiza CSS/JS cuando tenga sentido.
- Evita cargar bibliotecas pesadas si no son necesarias.
Ojo: “optimizar” no es activar 25 checks del plugin. Es mejorar sin romper layout ni tracking.
4) Cómo mejorar el INP (la métrica que más se resiente por scripts y plugins)
4.1 Localiza el trabajo que retrasa la interacción
Chat, mapas, widgets y scripts propios o de terceros pueden ocupar el hilo principal. Comprueba qué trabajo coincide con la interacción lenta antes de retirarlos o diferirlos. Valora:
- Lo imprescindible para negocio
- Lo que de verdad se usa
- Carga diferida (cuando aplique) y solo en páginas necesarias
4.2 Revisa plantillas y componentes antes de cambiar de constructor
Inspecciona si la plantilla, sus componentes o la cantidad de elementos dificultan la actualización de la pantalla. No hace falta sustituir el constructor por defecto: valora primero un ajuste acotado. Si el diagnóstico exige cambios profundos, compara el alcance de un diseño web a medida con las mejoras de desarrollo web sobre la web existente.
4.3 Formularios, popups y eventos mal implementados
El desplazamiento de la página no es una interacción medida por INP, aunque el trabajo asociado al scroll o a temporizadores puede bloquear la respuesta a un clic o una tecla. Localiza esas tareas antes de intervenir. Para entender las señales de consentimiento utilizadas en la medición, revisa Google Consent Mode v2; esa configuración no soluciona por sí sola un problema de INP.
5) Cómo reducir CLS y los desplazamientos inesperados
5.1 Reserva espacio para imágenes, banners y embeds
- Define dimensiones o aspect ratio en imágenes.
- Evita insertar un banner que empuje contenido ya visible sin espacio reservado. Añadir una transición no elimina por sí solo el desplazamiento; comprueba también que no tape controles.
- Ojo con iframes (maps, vídeos, reseñas).
5.2 Tipografías: controla el “flash” de fuentes
Una fuente que carga tarde puede cambiar el tamaño del texto y desplazar todo. Soluciones habituales:
- Reserva la precarga para fuentes realmente críticas y comprueba que no compitan innecesariamente con otros recursos.
- Elige una fuente de respaldo con métricas compatibles y revisa el intercambio de fuentes. Configurar
font-displayno garantiza por sí solo que desaparezcan los saltos; la guía de reducción de CLS explica estas causas.
Guía (MDN) sobre font-display.
6) Lo que NO debes hacer (aunque lo veas en tutoriales)
- No desactives scripts a ciegas: puedes romper formularios, carrito, conversiones o medición.
- No dupliques funciones de caché, minificación o carga diferida sin comprobar su compatibilidad: el problema es el solapamiento, no un número concreto de plugins.
- No cargues todo diferido si afecta a elementos críticos (menú, hero, CTA).
- No persigas un 100/100 en Lighthouse sacrificando funciones necesarias. Una nota alta no demuestra que menú, formularios o compras funcionen correctamente.
En CRO esto se ve mucho: una web puede ser rápida pero no convencer. Por eso rendimiento y conversión deben ir juntos: CRO + UX/UI.
7) Ejemplo de plan de cambios en 7 días
Es un calendario orientativo para un alcance acotado, no un plazo garantizado de aprobación. Comprueba cada cambio en laboratorio y tareas reales; evalúa después la evolución de los datos de campo.
Día 1: medición y diagnóstico
- PageSpeed en 3 URLs clave: home, servicio, contacto (y producto si ecommerce).
- Lista de scripts de terceros por página.
Días 2–3: LCP
- Optimizar el elemento LCP detectado y revisar la caché aplicable
- Revisar servidor/TTFB si hay señales
Días 4–5: CLS
- Reservar espacio para imágenes/iframes/banners
- Revisar fuentes
Días 6–7: INP
- Reducir scripts de terceros
- Limpiar plugins innecesarios
- Optimizar interacciones críticas (menú, formularios, filtros)
Antes de aplicar cambios, prepara una copia recuperable y define cómo revertirlos. Tras cada ajuste, compara con la medición inicial y revisa las funciones afectadas en móvil y escritorio. Coordina las pruebas de formularios o compras para no generar contactos o pedidos confundibles con los reales.
Mejorar Core Web Vitals en WordPress consiste en localizar las causas y comprobar la solución: no en activar todas las opciones de un plugin ni en garantizar una nota permanente.
Si quieres que lo revisemos y lo dejemos fino (sin romper diseño ni conversiones), lo abordamos con mantenimiento web, optimización de hosting cuando sea necesario y ajustes a nivel de desarrollo web para abordar las causas detectadas.
