Qué es Core Web Vitals y cuánto importa de verdad

Este blog vive en HTML estático servido desde Vercel, y la razón principal fue esta métrica. Es una decisión defendible y conviene decir la otra mitad: Core Web Vitals es una señal de posicionamiento confirmada y pequeña. Ninguna página mala sube por ir rápido. Lo que hace la velocidad es decidir empates entre páginas que ya compiten, y evitar que una parte de tus visitas se vaya antes de ver nada. Las dos cosas valen dinero, y ninguna de las dos es lo que promete quien vende una auditoría de rendimiento como si fuera una estrategia.

¿Qué es Core Web Vitals?

Son tres umbrales sobre visitas reales: 2,5 segundos en LCP, 200 milisegundos en INP y 0,1 en CLS, en el percentil 75. En un sitio nuevo casi nunca son el problema; en uno de autoridad media son un margen; en uno consolidado, donde el contenido ya empata, pueden desempatar. No hay ponderación publicada.

Respuesta rápida

• Son tres métricas: LCP (cuánto tarda en verse lo principal), INP (cuánto tarda en responder al tocar) y CLS (cuánto se mueve la página sola).
• Se miden sobre usuarios reales, no en tu ordenador, y en el percentil 75. Que a ti te cargue rápido no dice nada.
• Es señal de posicionamiento confirmada y de poco peso. Desempata; no rescata.
• Casi todo el problema está en imágenes, JavaScript y fuentes, no en el alojamiento.

Qué tipo de problema es esto

El modelo mental dominante dice que la velocidad es un factor de posicionamiento importante y que mejorarla sube puestos. La primera mitad es una exageración y la segunda produce presupuestos mal gastados.

Google confirmó estas métricas como señal, y también dijo, en repetidas ocasiones, que el contenido relevante gana a la velocidad. La lectura práctica: entre dos páginas que responden igual de bien, la rápida tiene ventaja. Entre una página lenta que responde y una rápida que no, gana la que responde.

Hay una segunda razón para ocuparse de esto, y para muchos negocios pesa más que la primera. No es de posicionamiento sino de pérdida directa: quien cierra la pestaña antes de que cargue no aparece en ningún informe de posiciones, porque la impresión se contó y la visita nunca existió.

El detalle que invalida la mitad de las mediciones

Existen dos formas de medir esto y no dicen lo mismo.

Datos de laboratorio. Los que produce una herramienta simulando una carga: Lighthouse y el modo de laboratorio de PageSpeed Insights. Sirven para depurar porque son reproducibles y te señalan qué recurso concreto va mal.

Datos de campo. Los que Google recoge de usuarios reales de Chrome y agrupa en el informe CrUX, con una ventana móvil de 28 días. Son los que cuentan para la evaluación.

La diferencia importa porque la evaluación se hace en el percentil 75 de tus usuarios reales. Eso significa que tres de cada cuatro visitas tienen que cumplir el umbral, y que tu experiencia probando el sitio con fibra y un portátil bueno es irrelevante. Un sitio puede sacar 100 en Lighthouse y estar en rojo en campo, porque sus usuarios entran con móviles de gama media y red móvil.

Un sitio con poco tráfico puede no tener datos de campo suficientes. En ese caso no hay evaluación, y ninguna cantidad de trabajo la fabrica.

Las tres métricas, y dónde se rompen

LCP: lo que más se arregla con menos trabajo

Mide cuándo termina de dibujarse el elemento más grande de la parte visible, que casi siempre es una imagen o un bloque de texto grande.

Las causas habituales, por orden de frecuencia: una imagen de cabecera sin optimizar ni dimensionar, un servidor que tarda en responder la primera petición, y recursos que bloquean el renderizado antes de que se pinte nada. La primera se arregla en una tarde y suele ser la que decide el resultado.

INP: la que sustituyó a FID y aprieta más

Interaction to Next Paint reemplazó a First Input Delay en marzo de 2024, y el cambio no fue cosmético. FID medía solo el retraso del primer toque; INP mide la respuesta a todas las interacciones de la visita y se queda con la peor.

Por eso muchos sitios que aprobaban con FID suspendieron con INP sin haber cambiado nada. La causa casi siempre es JavaScript: scripts de terceros, gestores de etiquetas cargando de más, y manejadores de eventos que hacen demasiado trabajo en el hilo principal.

CLS: la más barata de arreglar y la más molesta

Cuantifica cuánto salta el contenido mientras carga. Es la métrica que produce el clic equivocado cuando un anuncio aparece de golpe y desplaza el botón.

Tres causas cubren casi todos los casos: imágenes sin width y height declarados, contenido insertado dinámicamente por encima de lo que ya se veía, y fuentes web que al cargar cambian el tamaño del texto. Las tres se corrigen declarando el espacio antes de ocuparlo.

Y aquí está el vínculo con un error que ya cuesta dinero en otro sitio: declarar unas dimensiones que no coinciden con el archivo real es peor que no declararlas. En este mismo proyecto se descubrió así que una imagen de 900x1252 estaba puesta como imagen social de todo el sitio, con dimensiones declaradas que no eran las suyas. Las dimensiones se leen del archivo; no se escriben a mano. Es el mismo principio que gobierna los datos estructurados, donde declarar algo que no coincide con la realidad de la página es peor que no declararlo.

En qué orden se ataca

1. Comprueba los datos de campo primero. Si no hay suficientes, el trabajo no se puede evaluar y probablemente hay prioridades mejores dentro del SEO técnico, que coloca el rendimiento en quinto lugar por este motivo.
2. LCP antes que nada. Es donde está el margen grande y donde el arreglo es más barato.
3. CLS después. Barato y con efecto directo sobre errores de usuario.
4. INP al final. Es el más caro porque toca el JavaScript, y a veces implica quitar herramientas que alguien quiere conservar.
5. Vuelve a medir en campo pasados 28 días. Es la ventana de CrUX; antes de eso, los datos todavía arrastran el estado anterior.

Cuándo NO trabajar en esto

Cuando el sitio no está indexado. Optimizar la velocidad de páginas que Google no ha guardado es la definición de gastar en la capa equivocada, y el informe de indexación dice en treinta segundos si ese es tu caso.

Cuando hay páginas en buena posición sin recibir clics. Ahí el problema es el título, no el rendimiento, y el arreglo cuesta minutos en vez de semanas. El diagnóstico de ese caso está en estás primero en Google y no recibes clics.

Cuando ya estás en verde. No hay premio por bajar de 2,5 a 1,8 segundos; el umbral es un umbral, no una escala continua de recompensa.

Qué dice Google, y el porcentaje que se ha inventado el sector

Buscando este tema el 12 de agosto de 2026 aparecía repetida una cifra: que los Core Web Vitals suponen entre el 10 y el 15 % de las señales de posicionamiento, atribuido a "investigación del sector". Google no publica ninguna ponderación de ninguna señal, y esa cifra no tiene fuente localizable.

Lo que sí dice su documentación, y conviene citarlo entero porque las tres frases se matizan entre sí:

"Los Core Web Vitals los usan nuestros sistemas de posicionamiento." Es una confirmación directa, y descarta la postura contraria de que no cuentan para nada.

"No hay una única señal. Nuestros sistemas principales miran una variedad de señales alineadas con la experiencia de página en general." Es decir, no existe un sistema de experiencia de página con nombre propio que se pueda aprobar o suspender.

Y la que ordena la prioridad: "obtener buenos resultados en informes como el de Core Web Vitals no garantiza que las páginas aparezcan arriba". Google añade que su búsqueda siempre intenta mostrar el contenido más relevante, incluso si la experiencia de página es mediocre.

Las tres juntas dicen algo distinto de las dos versiones que circulan. No son decorativos y no son una palanca. Son un umbral que conviene cruzar, y una vez cruzado no hay premio adicional por seguir bajando.

Cada métrica, con su diagnóstico propio

Las tres se agrupan bajo un mismo nombre y no se parecen en nada al arreglarlas.

LCP son cuatro tramos consecutivos con un reparto de referencia publicado, y comparar el tuyo contra ese dice cuál atacar: cómo mejorar el LCP.

CLS no suma los desplazamientos, toma la peor ráfaga y pondera área por distancia, que es lo que hace que arreglar cinco saltos pequeños no mueva el número: cómo arreglar el CLS.

INP tiene tres fases y solo una suele ser el problema, y además no mide desplazamiento ni zoom: qué es INP.

Si el contenido depende de JavaScript para existir, hay una capa anterior a las tres: JavaScript y SEO. Dónde encaja todo esto en el orden general está en SEO técnico, y el informe donde se miran los datos de campo, en Google Search Console.

La primera página en español lleva dos años desactualizada

Comprobado el 13 de agosto de 2026, varios de los resultados que ocupan esta consulta en español, incluida la entrada de enciclopedia, siguen enumerando las tres métricas como LCP, FID y CLS. FID dejó de ser una de las tres en marzo de 2024, cuando INP ocupó su lugar como métrica oficial de respuesta.

Son más de dos años. Y lo que lo vuelve instructivo es que la misma consulta en inglés devuelve INP sin excepción: no es que el dato sea difícil de encontrar, es que la actualización no cruzó el idioma. Un lector en español que se guíe por esa primera página va a optimizar una métrica que ya no se mide, con la agravante de que FID e INP no se arreglan igual: la primera solo miraba el retraso de la primera interacción y la segunda mira todas las interacciones de la sesión, de principio a repintado.

El caso general vale para cualquier tema técnico de este blog. Una guía en español puede estar perfectamente escrita y describir un sistema que cambió, porque la corrección viaja primero por la documentación original y llega al resto por traducción, cuando llega.

Errores que se repiten

• Medir en tu propio equipo. La evaluación usa el percentil 75 de usuarios reales, no tu conexión.
• Perseguir el 100 de Lighthouse. Es laboratorio; la evaluación es de campo.
• Cambiar de alojamiento para arreglarlo. Casi todo el problema está en imágenes, JavaScript y fuentes.
• Declarar dimensiones de imagen a mano. Si no coinciden con el archivo, es peor que no declararlas.
• Optimizar velocidad con el sitio sin indexar. No hay nada que desempatar todavía.
• Volver a medir a los dos días. La ventana de campo es de 28 días.

Datos y transparencia

Que varios de los primeros resultados en español para esta consulta siguen enumerando FID entre las tres métricas, mientras que los primeros resultados en inglés dan INP, es una observación propia del 13 de agosto de 2026 y se recoge como desfase, no como fuente. Que INP sustituyó a FID como métrica oficial en marzo de 2024 procede de la documentación de Google, comprobada el mismo día.

Que los Core Web Vitals los usan los sistemas de posicionamiento, que no existe una señal única de experiencia de página, y que obtener buenos resultados en esos informes no garantiza aparecer arriba porque la búsqueda prioriza la relevancia, procede de la documentación pública de Google sobre experiencia de página, comprobada el 12 de agosto de 2026. Google no publica ninguna ponderación, así que la cifra del 10 al 15 % de las señales que circula se nombra aquí como dato sin fuente, no se repite como hecho.

Los umbrales de LCP (2,5 s), INP (200 ms) y CLS (0,1), la evaluación en el percentil 75, la ventana móvil de 28 días del informe CrUX y la sustitución de FID por INP en marzo de 2024 proceden de la documentación pública de Google sobre Core Web Vitals, vigente a agosto de 2026. El caso de la imagen de 900x1252 declarada con dimensiones que no eran las suyas procede de este mismo sitio, donde se corrigió leyendo las dimensiones del archivo en lugar de escribirlas a mano. No se citan cifras de correlación entre velocidad y posiciones ni de mejora de conversión por milisegundo: las que circulan proceden de estudios cuyas condiciones no son extrapolables a un sitio cualquiera. Verificado a agosto de 2026.

Fuentes primarias, abiertas el 13 de agosto de 2026: la documentación de Interaction to Next Paint.

Lo que esto cambia

La conversación sobre velocidad suele plantearse como una carrera, y no lo es: es una aduana. Hay un umbral, se pasa o no se pasa, y pasarlo con holgura no da ningún premio adicional.

Eso reordena el presupuesto de una forma que incomoda a quien vende optimización por horas. La pregunta útil no es cuánto puedes mejorar, sino si estás dentro o fuera, y cuántos de tus usuarios reales están del lado malo. En la mayoría de los sitios que he revisado, la respuesta estaba a una imagen de distancia, y el resto del informe de rendimiento describía mejoras que nadie iba a notar.

Preguntas frecuentes