Core Web Vitals en Palabras Sencillas (LCP, INP, CLS)
Si has visto «Core Web Vitals» marcado en un informe o una auditoría SEO y te has preguntado en silencio qué significan realmente LCP, INP y CLS — sin querer escuchar una conferencia de desarrollador — esto es para ti. Son más sencillos de lo que parecen, y no necesitas arreglarlos tú mismo. Sólo necesitas entender qué miden, qué cuenta como bueno y qué preguntar a las personas que gestionan tu sitio.
Qué son los Core Web Vitals
Los Core Web Vitals son tres métricas que Google usa para medir la experiencia real de cargar y usar una página web: la rapidez con la que aparece el contenido principal (LCP), la velocidad con la que la página responde cuando interactúas con ella (INP), y la estabilidad del diseño mientras carga (CLS). Juntas describen si una página se siente rápida y sólida, o lenta y torpe, para un visitante real.
Dos cosas las hacen dignas de tu atención. Primero, Google las usa como parte de cómo posiciona las páginas, así que afectan a la facilidad con la que la gente te encuentra. Segundo — y más importante — miden la experiencia que tienen realmente tus posibles clientes, que es lo que convierte una visita en una consulta. Vamos con cada una por turno.
LCP — la rapidez con la que carga el contenido principal
El Largest Contentful Paint (LCP) mide cuánto tiempo tarda en aparecer el elemento más grande e importante de la página — normalmente el titular principal o la imagen hero. Un buen LCP es de 2,5 segundos o menos.
Piénsalo como entrar en una tienda y esperar a que se enciendan las luces. Si el expositor principal está iluminado y visible casi de inmediato, te sientes bienvenido y orientado. Si te quedas a oscuras cuatro o cinco segundos, empiezas a preguntarte si hay alguien — y puede que simplemente des media vuelta. El LCP es ese primer momento de «la página está aquí», y los servidores lentos o las imágenes demasiado pesadas son las razones habituales por las que se ralentiza.
INP — la rapidez con la que la página responde al interactuar
El Interaction to Next Paint (INP) mide la rapidez con la que la página reacciona cuando un visitante hace algo — hace clic en un botón, abre un menú, marca una casilla. Un buen INP es de 200 milisegundos o menos, que es aproximadamente lo más rápido que el ojo percibe como instantáneo.
Imagina que pulsas el botón de un ascensor. Lo pulsas y la luz se enciende de inmediato, y te relajas: el edificio te ha escuchado. Lo pulsas y no pasa nada durante medio segundo, y lo vuelves a pulsar sin saber si se ha registrado. Un formulario de contacto lento o un menú que tarda crea exactamente esa pequeña duda corrosiva — y tiende a aparecer en el peor momento, justo cuando alguien está intentando actuar.
Una cosa que vale la pena saber, porque deja obsoletos muchos consejos anteriores: INP reemplazó a una métrica anterior llamada FID (First Input Delay) como Core Web Vital oficial en marzo de 2024. FID sólo medía el retraso en la primera interacción del visitante; INP analiza la capacidad de respuesta durante toda la visita, así que refleja mejor cómo se siente la página. Si una guía o herramienta sigue hablando de FID como algo actual, está desactualizada.
CLS — si el diseño salta mientras carga
El Cumulative Layout Shift (CLS) mide cuánto se mueve inesperadamente la página mientras carga. Un buen CLS es de 0,1 o menos — cuanto más bajo el número, más estable la página.
Has sentido un CLS malo aunque nunca lo hayas nombrado: vas a tocar un enlace, se carga una imagen o un anuncio encima, todo salta hacia abajo y tocas lo que no querías. Es el equivalente digital de que alguien te mueva la silla cuando te estás sentando. En un sitio profesional se percibe como descuido, y en un formulario o una llamada a la acción puede costarte el clic que más querías. Un buen CLS suele venir de reservar el espacio correcto para imágenes y elementos antes de que se carguen.
Datos de laboratorio vs datos de usuarios reales
Hay dos formas de medir estas métricas, y conocer la diferencia explica por qué tu informe mensual y una prueba puntual suelen discrepar. Los datos de laboratorio son una sola prueba realizada en condiciones controladas — útiles para diagnosticar problemas, pero es una visita simulada, no personas reales. Los datos de campo son la experiencia de tus visitantes reales, recogida de usuarios reales de Chrome durante los últimos 28 días.
Google juzga tus Core Web Vitals con datos de campo, y usa el percentil 75 — lo que significa que aproximadamente tres cuartas partes de las visitas reales necesitan alcanzar el umbral «bueno» para que la página pase. Por eso un sitio puede parecer rápido cuando lo pruebas en un buen portátil con conexión rápida, pero fallar en campo, donde muchos visitantes están en móviles de gama media con señal irregular. La prueba honesta es cómo funciona para ellos, no para ti. (Para el contexto más amplio sobre cómo medir un sitio honestamente, ver nuestra guía completa de rendimiento web para empresas B2B.)
Qué hacer con todo esto
Aquí viene la parte tranquilizadora: no se supone que los arregles tú mismo. LCP, INP y CLS son resultados técnicos de cómo está construido y alojado un sitio, y los arreglos corresponden a quien lo gestiona. Tu trabajo es simplemente saber lo suficiente para hacer las preguntas correctas y reconocer una respuesta directa.
Tres preguntas te llevan la mayor parte del camino:
- «¿Estamos pasando los Core Web Vitals en datos de campo, no sólo en una prueba de laboratorio?» Esto separa un aprobado real de una puntuación halagadora puntual.
- «¿Cuál de los tres estamos fallando, y por qué?» Un buen proveedor puede decírtelo claramente — p. ej. LCP lento por imágenes pesadas, o INP pobre por demasiado código ejecutándose.
- «¿Cuál es el plan para arreglarlo, y seguirá arreglado?» Un ajuste puntual se desvanece; quieres un rendimiento integrado y mantenido.
Muy a menudo el culpable subyacente es el mismo: un sitio construido sobre un page builder pesado carga tanto código extra que las buenas puntuaciones son difíciles de alcanzar y más difíciles de mantener. Lo desempaquetaremos en → Cluster 3: por qué los page builders como Elementor y Divi perjudican el rendimiento (próximamente). Y si quieres el argumento de por qué todo esto vale tu tiempo, está en qué hace realmente una web rápida por tu negocio.
¿No sabes dónde está tu sitio? Lo comprobamos por ti →
Preguntas frecuentes
Artículos
Relacionados
