Cuando hablamos de velocidad web y SEO aparece constantemente el término Core Web Vitals.

También aparecen siglas como:

LCP, INP y CLS.

El problema es que muchas veces terminamos obsesionados con conseguir números verdes en PageSpeed Insights sin entender qué estamos midiendo realmente.

Los Core Web Vitals intentan medir aspectos concretos de la experiencia que tiene una persona cuando utiliza nuestra página:

• ¿Cuánto tarda en aparecer el contenido principal?

• ¿Responde rápidamente cuando interactuamos?

• ¿Los elementos se mueven inesperadamente mientras carga?

Actualmente Google utiliza tres métricas principales: LCP, INP y CLS. Para considerar buenos los resultados, Google recomienda un LCP de hasta 2,5 segundos, INP inferior a 200 milisegundos y CLS inferior a 0,1.

Pero conseguir esas cifras no debería convertirse en el único objetivo.

Vamos a entender qué significan y qué podemos hacer cuando tenemos problemas.

¿Qué son los Core Web Vitals?

Los Core Web Vitals o Métricas web principales son un conjunto de métricas relacionadas con la experiencia real del usuario.

Actualmente son:

LCP (Largest Contentful Paint) → carga.

INP (Interaction to Next Paint) → capacidad de respuesta.

CLS (Cumulative Layout Shift) → estabilidad visual.

Google recomienda conseguir buenos Core Web Vitals tanto por la experiencia del usuario como por su relación con los sistemas que evalúan la experiencia de página.

Si trabajas posicionamiento, estos problemas encajan directamente dentro del SEO técnico, porque muchas veces necesitaremos investigar servidor, JavaScript, imágenes, CSS y arquitectura antes de encontrar el cuello de botella.

1. LCP: cuánto tarda en aparecer el contenido principal

Largest Contentful Paint mide el rendimiento de carga.

Simplificando bastante:

¿Cuánto tarda en mostrarse uno de los elementos principales que el usuario ve al entrar?

Google recomienda intentar mantener el LCP dentro de los primeros 2,5 segundos.

Un LCP problemático puede estar relacionado con:

• Servidor lento.

• Imágenes demasiado pesadas.

• CSS.

• JavaScript.

• Fuentes.

• Caché.

• Recursos externos.

Por eso no existe un plugin mágico que solucione cualquier problema de LCP.

Primero necesitamos descubrir qué elemento está actuando como LCP y qué está retrasando su aparición.

Ejemplo de un LCP malo

Imaginemos la portada de una web.

Tenemos:

• Cabecera.

• Menú.

• Texto.

• Una enorme imagen principal de 4 MB.

El navegador empieza a cargar.

El texto aparece rápidamente.

Pero la imagen principal tarda muchísimo.

Esa imagen puede convertirse en nuestro LCP.

La solución probablemente no consiste en cambiar de theme inmediatamente.

Empezaría optimizando esa imagen y su forma de carga.

El servidor también puede ser responsable

Podemos comprimir todas las imágenes y seguir teniendo una web lenta.

¿Por qué?

Porque el servidor tarda demasiado en comenzar a entregar la página.

En ese caso estamos intentando solucionar el problema equivocado.

Si detectamos que la infraestructura es el cuello de botella, conviene revisar aspectos como recursos, caché y configuración. En la guía sobre cómo elegir un buen hosting para una página web explicamos precisamente qué recursos y características conviene analizar más allá del típico reclamo de “espacio ilimitado”.

Este es un buen ejemplo de por qué SEO técnico y hosting están relacionados.

2. INP: cómo responde la web cuando interactuamos

Interaction to Next Paint mide la capacidad de respuesta de una página.

Google recomienda un INP inferior a 200 milisegundos para ofrecer una buena experiencia.

Imaginemos que pulsamos:

Abrir menú

y aparentemente no ocurre nada durante un momento.

O hacemos clic en:

Añadir al carrito

y existe un retraso considerable antes de recibir respuesta visual.

Eso genera sensación de lentitud aunque la página inicialmente haya cargado rápido.

JavaScript suele tener mucho que decir

Cuando existe un problema de INP investigaría especialmente:

• JavaScript pesado.

• Tareas largas.

• Scripts de terceros.

• Plugins.

• Constructores visuales.

• Widgets.

• Chats.

• Publicidad.

• Código innecesario.

Una web puede tener un buen LCP y, sin embargo, responder fatal cuando el usuario empieza a interactuar.

Por eso decir:

Mi web carga rápido.

no siempre significa:

Mi web ofrece una experiencia rápida.

Son conceptos relacionados, pero no idénticos.

3. CLS: cuando la página empieza a moverse

Cumulative Layout Shift mide la estabilidad visual.

Google recomienda mantener el CLS por debajo de 0,1.

Seguro que alguna vez os ha ocurrido esto:

Entráis en una web.

Veis un botón.

Vais a pulsarlo.

En ese instante aparece un anuncio y desplaza todo el contenido.

Termináis haciendo clic en otra cosa.

Eso es una experiencia horrible.

Qué puede provocar un CLS alto

Algunas causas habituales son:

• Imágenes sin dimensiones reservadas.

• Publicidad.

• Banners.

• Fuentes.

• Contenido insertado dinámicamente.

• Widgets.

• Elementos que aparecen tarde.

La solución suele consistir en reservar correctamente el espacio necesario antes de que llegue el elemento.

Si sabemos que aparecerá un banner de 300 píxeles, deberíamos evitar que esos 300 píxeles aparezcan repentinamente desplazando todo lo que había debajo.

¿Los Core Web Vitals afectan al SEO?

Sí debemos prestarles atención, pero evitaría simplificarlo como:

Tengo 100 en PageSpeed = voy a posicionar primero.

Google explica que unos buenos Core Web Vitals están alineados con lo que sus sistemas principales buscan recompensar junto con otros aspectos de la experiencia de página.

Pero SEO incluye muchas otras variables.

Podemos tener:

LCP perfecto + INP perfecto + CLS perfecto

y una página que no responde correctamente a ninguna intención de búsqueda.

No vamos a superar automáticamente a un contenido muchísimo mejor por cargar unas décimas más rápido.

La optimización técnica debe acompañar al contenido.

PageSpeed Insights no es solamente una puntuación

Otro error habitual:

Mi PageSpeed tiene 63. Necesito llegar a 100.

Yo no empezaría por la puntuación.

Miraría qué está provocando los problemas.

Una puntuación es una simplificación útil.

Lo importante es diagnosticar.

Además, debemos diferenciar entre:

datos de laboratorio

y:

datos de usuarios reales.

No responden exactamente a la misma pregunta.

Search Console también muestra Core Web Vitals

Google recomienda utilizar el informe de Core Web Vitals de Search Console para consultar cómo funcionan nuestras páginas.

Esto resulta especialmente interesante porque podemos detectar grupos de URLs con problemas.

Por ejemplo:

150 URLs con LCP deficiente.

Quizá todas utilizan la misma plantilla.

Entonces no necesitamos optimizar 150 páginas individualmente.

Necesitamos descubrir qué elemento común está provocando el problema.

Busca patrones antes de tocar nada

Imaginemos:

Todos los artículos → bien.

Todas las categorías → mal LCP.

Todas las fichas de producto → mal INP.

Ya tenemos pistas.

Probablemente existe algo específico en las plantillas de categorías y productos.

Pensar por tipos de página puede ahorrarnos muchísimo trabajo.

Core Web Vitals en WordPress

WordPress merece atención especial porque podemos añadir funcionalidades constantemente mediante plugins y themes.

Un proyecto empieza sencillo.

Después instalamos:

• Constructor.

• Slider.

• Popup.

• Analytics.

• Chat.

• Publicidad.

• Formularios.

• Redes sociales.

• Plugins SEO.

• Scripts externos.

Individualmente cada cosa parece pequeña.

Juntas pueden generar una página considerablemente más pesada.

Si este es tu caso, antes de empezar a modificar Core Web Vitals al azar revisaría la guía sobre por qué WordPress va lento y cómo acelerarlo, porque allí repasamos hosting, plugins, caché, imágenes, themes, PHP, bases de datos y scripts externos.

Ese diagnóstico debería realizarse antes de instalar otra herramienta de optimización.

Cómo mejorar LCP

Empezaría comprobando qué elemento es el LCP.

Después investigaría principalmente:

Imágenes

¿Pesan demasiado?

¿Tienen dimensiones innecesariamente grandes?

¿Utilizamos formatos adecuados?

Servidor

¿Tarda demasiado en responder?

CSS

¿Tenemos recursos bloqueando la representación?

Fuentes

¿Retrasan la aparición del contenido?

JavaScript

¿Estamos cargando demasiado antes de mostrar lo importante?

La solución depende del diagnóstico.

Cómo mejorar INP

Para INP prestaría especial atención al trabajo que realiza el navegador cuando interactuamos.

Revisaría:

• JavaScript innecesario.

• Scripts externos.

• Plugins pesados.

• Eventos complejos.

• Tareas largas.

• Elementos interactivos.

También probaría la web en dispositivos menos potentes.

Nuestro ordenador de escritorio puede ejecutar JavaScript rápidamente mientras un móvil más modesto tiene bastantes más dificultades.

Cómo mejorar CLS

Aquí buscaría elementos que aparecen o cambian de tamaño después de comenzar la carga.

Especialmente:

imágenes

Reservar dimensiones.

anuncios

Reservar espacio.

banners

Evitar que empujen repentinamente el contenido.

fuentes

Controlar cómo afectan al diseño.

contenido dinámico

Planificar el espacio que ocupará.

La prueba visual suele ser bastante reveladora.

Si mientras carga la página vemos que todo “salta”, tenemos trabajo pendiente.

No instales cinco plugins de optimización

Especialmente en WordPress existe la tentación de solucionar cada recomendación con un plugin distinto.

Tenemos:

Plugin de caché.

Plugin de imágenes.

Plugin de JavaScript.

Plugin de CSS.

Plugin de base de datos.

Plugin de lazy loading.

Y quizá varias funciones se están solapando.

Intentaría utilizar el menor número posible de piezas y entender qué está haciendo cada una.

Más optimización automática no significa necesariamente más velocidad.

Cuidado con el lazy loading del elemento principal

El lazy loading puede resultar muy útil para imágenes que todavía están fuera de la pantalla.

Pero debemos tener cuidado con elementos críticos visibles inmediatamente.

Si retrasamos innecesariamente la carga de la imagen principal que actúa como LCP podemos empeorar precisamente la métrica que intentábamos mejorar.

No aplicaría reglas de optimización de forma indiscriminada.

Los scripts de terceros son difíciles de controlar

Publicidad, chats, mapas, vídeos, herramientas de analítica y widgets pueden afectar al rendimiento.

Aquí aparece una decisión de negocio.

Quizá un chat ralentiza ligeramente la página pero genera muchos clientes.

No lo eliminaría simplemente para conseguir:

100/100.

Buscaría primero formas de cargarlo mejor.

La optimización tiene que entender para qué existe la web.

Móvil primero, pero sin ignorar escritorio

Revisaría especialmente la experiencia móvil porque:

• La pantalla es diferente.

• El hardware puede ser menos potente.

• La conexión puede ser peor.

• Los elementos interactivos cambian.

Una web que funciona espectacularmente desde nuestro ordenador conectado por fibra no necesariamente ofrece la misma experiencia en un móvil.

Por eso las pruebas deberían representar mejor a los usuarios reales.

¿Merece la pena cambiar de hosting por los Core Web Vitals?

Solamente cuando tenemos evidencias de que el hosting es parte del problema.

No migraría una web porque una herramienta diga:

Reduce el tiempo de respuesta.

Primero comprobaría:

• Caché.

• Recursos.

• PHP.

• Base de datos.

• Plugins.

• Configuración.

• Consumo.

Si después de investigar vemos que el servidor limita claramente el proyecto, entonces sí estudiaría migrar.

Una buena decisión de hosting debería basarse en necesidades reales, no en miedo provocado por una puntuación.

Qué optimizaría primero

Si tenemos 40 recomendaciones, priorizaría.

Prioridad alta

Problemas que afectan claramente a usuarios reales y aparecen en muchas páginas.

Prioridad media

Mejoras razonables con impacto potencial.

Prioridad baja

Microoptimizaciones cuyo único beneficio parece ser conseguir dos puntos adicionales en una herramienta.

Esto evita pasar una semana intentando ahorrar 20 KB mientras ignoramos una imagen principal de 3 MB.

Mi proceso para mejorar Core Web Vitals

Seguiría aproximadamente estos pasos:

1. Revisar Search Console.

Buscar grupos de URLs problemáticas.

2. Analizar páginas representativas.

No probar únicamente la home.

3. Identificar la métrica problemática.

LCP, INP o CLS.

4. Encontrar la causa.

Servidor, imagen, JavaScript, layout, etc.

5. Aplicar un cambio.

Evitar modificar diez cosas simultáneamente.

6. Volver a medir.

Comprobar si realmente mejoró.

7. Monitorizar datos reales.

No quedarnos únicamente con una prueba de laboratorio.

No sacrifiques UX para mejorar una métrica

Puede parecer contradictorio, pero ocurre.

Eliminamos:

• Navegación útil.

• Imágenes necesarias.

• Funciones.

• Elementos de conversión.

solo para mejorar una puntuación.

Los Core Web Vitals existen precisamente para ayudarnos a mejorar la experiencia.

No deberíamos terminar empeorándola intentando optimizarlos.

SEO técnico no significa perseguir semáforos verdes

Este es probablemente el punto con el que me quedaría.

Las métricas nos ayudan a detectar problemas.

Pero un buen trabajo de SEO técnico en DSForo también implica indexación, rastreo, arquitectura, rendimiento, canonicals, redirecciones y muchos otros aspectos.

Core Web Vitals es una pieza del conjunto.

Y si estás construyendo o haciendo crecer un proyecto, en DSForo, foro SEO y comunidad de webmasters puedes encontrar debates sobre posicionamiento, WordPress, hosting y desarrollo que complementan precisamente este tipo de optimizaciones.

Conclusión

Los Core Web Vitals son útiles porque convierten determinados problemas de experiencia en métricas que podemos medir.

Recordando lo esencial:

LCP → carga del contenido principal.

INP → respuesta a las interacciones.

CLS → estabilidad visual.

Los objetivos recomendados por Google son:

LCP ≤ 2,5 segundos

INP < 200 ms

CLS < 0,1

Pero no intentaría conseguirlos instalando plugins o modificando código al azar.

El proceso correcto sería:

medir → diagnosticar → priorizar → optimizar → volver a medir.

Y siempre manteniendo una idea por encima de todas las métricas:

la página debe ser rápida y cómoda para la persona que realmente la está utilizando.

Si conseguimos eso, estaremos trabajando simultáneamente SEO técnico y experiencia de usuario.

¿Qué Core Web Vital os está dando más problemas actualmente: LCP, INP o CLS? ¿Y cuál ha sido la causa más difícil de detectar en vuestras webs?