Core Web Vitals: qué son y cómo medirlos sin engañarse

¿Qué son las Core Web Vitals: LCP, INP y CLS?

Las Core Web Vitals son tres métricas de Google, medidas con visitas reales. Describen la carga (LCP), la respuesta a la interacción (INP) y la estabilidad visual (CLS) de una página. Cada una tiene un umbral bueno y uno malo, y web.dev los publica:

Los umbrales se miden sobre el percentil 75 de las visitas, separando móvil y escritorio. Es decir, su página no tiene que ser rápida en su computador: tiene que serlo para tres de cada cuatro visitantes.

Lo que está en juego no es solo Google: es quien compra. Vodafone comparó dos versiones de una landing page en una prueba A/B. Según el caso que publica web.dev (17-mar-2021), mejorar el LCP un 31 % le trajo un 8 % más de ventas.

Es el caso de una empresa grande, no una promesa para la suya. Pero muestra qué conviene mirar al final: ventas y contactos, no la nota.

Detalle de cada métrica: LCP, INP y CLS.

INP reemplazó a FID como métrica de respuesta el 12 de marzo de 2024. Si una guía todavía le habla de FID, está desactualizada; varias en español que revisé el 15-oct-2026 siguen así.

¿Qué diferencia hay entre laboratorio y campo?

PageSpeed Insights muestra dos cosas distintas en la misma pantalla. Los datos de campo salen de usuarios reales de Chrome durante los últimos 28 días. Los de laboratorio salen de una carga simulada en un solo dispositivo y con una red fija.

La puntuación de 0 a 100 sale solo del laboratorio. Lo que vive su visitante está en los datos de campo, cuando existen.

Si su sitio tiene poco tráfico, es normal que no haya datos de campo. En ese caso el laboratorio es lo único que tiene, y sirve para comparar cambios entre sí, no para afirmar cómo carga para sus usuarios.

Dos detalles cambian cómo se leen los datos de campo. Si su página no tiene visitas suficientes, PageSpeed puede mostrarle los del sitio entero en lugar de los de esa página. Y Search Console califica cada grupo de páginas por su peor métrica: un CLS malo hunde un LCP bueno.

Si su sitio está hecho con un constructor de IA, probablemente es una app de una sola página. En ese caso, Chrome atribuye a la primera página todo lo que pasa mientras la persona navega dentro del sitio. Los datos de campo de una página interna no son exactos, y desde los datos públicos no se pueden separar.

Otro detalle: Lighthouse no puede medir INP, porque en una prueba de laboratorio nadie hace clic. Usa el Total Blocking Time como aproximación, y no es un sustituto.

¿Por qué una sola corrida miente?

Porque la nota cambia con la red, la CPU y los scripts de terceros, aunque su sitio no cambie. La documentación de Lighthouse lo reconoce: buena parte de la variación se debe a las condiciones de la prueba, no a la herramienta. Recomienda pensar el rendimiento como una distribución, no como un número.

resultado A   rendimiento 80
resultado B   rendimiento 64
→ Cada corrida dio A o B. Nunca un valor intermedio.

Lo medí en un sitio que audito. Si me hubiera quedado con las primeras corridas, habría informado de un empeoramiento que no existía.

Mi regla: cinco corridas, e informo la mediana junto con el rango. Si el rango es amplio lo digo, porque entonces ninguna comparación con una medición anterior es confiable.

Para demostrar que un cambio funcionó, prefiero una cifra que no baile: cuántos kilobytes de JavaScript necesita la página.

En ese mismo sitio, el JavaScript de la página de contacto bajó de 142 a 84 KB al separar lo que no usaba. Lo medí en los archivos del build el 12 de septiembre de 2026. Esa cifra sale igual cada vez que se mide; la nota, no.

Con la mediana y el rango comparé la portada de mis dos sitios con la de siete agencias y diseñadores colombianos que venden páginas web. En PageSpeed móvil, cardonaseo.com sacó 92 y regresoempresarial.com 95; la mediana de las siete fue 62 (laboratorio, mediana de tres corridas, 17-oct-2026).

Fueron tres corridas por sitio, no las cinco de mi regla, y una sola noche: sirve para comparar, no para prometer una nota. Si va a hacer una página nueva, pida esta medición antes de pagar la entrega, la haga quien la haga. Yo la publico en el diseño de páginas web con SEO.

Estas son cinco corridas de PageSpeed Insights de mi página, con el LCP de cada una, en segundos: [los cinco números].
Esto dice la sección de datos de usuarios reales: [lo que dice, o escriba «no hay datos»].
Calcule la mediana y el rango. Si me dice que la página es estable o inestable, diga con qué criterio. Use solo mis números.

Reglas de esta revisión:
1. Cite entre comillas el texto exacto que encontró. No lo parafrasee.
2. Si algo no se puede ver desde el navegador, escriba «no verificable desde el navegador». No suponga.
3. Entregue una tabla: elemento · lo que encontró · bien / revisar / falta · por qué importa en una frase.
4. No invente datos de tráfico, visitas ni posiciones. No prometa que algo subirá en Google.
5. Si no puede abrir una dirección usted mismo, dígalo en la primera línea y trabaje solo con lo que le pegué. No describa una página que no vio.

Si alguien le cotiza un arreglo de velocidad a partir de una sola corrida, pregúntele cuántas hizo y cuál fue el rango. Con una nota que baila no se decide en qué gastar, ni se comprueba después si el gasto movió algo. Esa medición, con cinco corridas, mediana y rango, va en la auditoría técnica; el diagnóstico gratuito le dice antes si hay un error grave.

¿Cuál es su elemento LCP?

El elemento LCP es el bloque más grande que se ve en pantalla al cargar, y no siempre es el que uno cree. Se suele asumir que es la imagen grande de la portada, pero los bloques de texto también son candidatos, y a veces ganan.

En ese mismo sitio, en septiembre de 2026, el elemento LCP era el título H1, no la imagen del hero, mucho más grande. Chrome descarta los elementos que cubren toda la pantalla porque los toma por fondo, así que optimizarla no habría movido el LCP.

Antes de optimizar, identifique el elemento. El panel Performance de las herramientas para desarrolladores de Chrome lo marca, y PageSpeed Insights lo señala en su diagnóstico. Sin eso, otro plugin de velocidad es gastar a ciegas.

¿Qué arreglar primero?

Primero lo que más pesa y menos cuesta corregir. Este es el orden en que lo reviso: scripts de terceros que sobran, imágenes y videos sin dimensiones y fuentes que mueven el texto. Al final, el elemento LCP concreto, que solo se toca después de identificarlo.

• Scripts de terceros que no usa. En un sitio que audité, dos etiquetas de Google cargaban 273 KB de JavaScript. Lighthouse medía 110 KB que nunca se ejecutaban (7 de septiembre de 2026).

• Imágenes y videos sin dimensiones, una de las causas de CLS que cita web.dev. Declare width y height reales, que coincidan con el archivo.

• Fuentes web que cambian de tamaño al cargar, porque también mueven el contenido. Alójelas en su propio servidor y elija un reemplazo de tamaño parecido.

• El elemento LCP concreto. Si es texto, lo que suele retrasarlo es la fuente o el JavaScript que pinta la página. Si es una imagen, su peso y su prioridad de carga.

Si su sitio depende de JavaScript para pintar el contenido, eso afecta a la vez al rendimiento y a lo que recibe Google. Lo explico en por qué una página no aparece en Google. Si todavía no la ha creado, es más barato evitarlo desde el principio: lo cuento en cómo crear una página web con IA.

En la auditoría SEO técnica mido así: cinco corridas, mediana y rango, y el elemento LCP identificado antes de recomendar nada.

¿Cómo optimizar las Core Web Vitals con ayuda de la IA?

Con la IA como ayudante, no como juez: mida con PageSpeed Insights y pídale a un agente que reúna el diagnóstico en un informe. Después corrija con Claude Code sobre su repositorio, un cambio cada vez, y vuelva a medir con el mismo instrumento. Por último, pídale a Google que rastree lo que cambió.

Es el flujo que uso en este sitio. La IA hace el trabajo pesado; yo especifico, reviso y verifico.

• 1 · Mida. Pase cada URL importante por PageSpeed Insights cinco veces y anote la mediana y el rango. Lighthouse, en las herramientas para desarrolladores de Chrome, hace el mismo tipo de prueba de laboratorio.

• 2 · Pida el diagnóstico a un agente. La extensión de Claude para Chrome puede hacer esas pruebas por usted y entregarle un informe en un archivo .md. El prompt que uso va debajo de esta lista.

• 3 · Lleve el informe a Claude Code. Conecte su repositorio y pídale que contraste el informe con el código y revise a fondo el SEO técnico del sitio. Que le proponga un cambio cada vez y espere su «sí»; si no sabe cómo empezar, pregúnteselo a su proyecto en Claude.

• 4 · Corrija y verifique. Vuelva a medir con el mismo instrumento, cinco corridas. Compruebe también que el arreglo no se llevó nada que Google usaba: el título, la canónica, el H1 y el texto.

• 5 · Pida la indexación de lo que cambió. Se pide URL por URL en la inspección de URL de Search Console, con una cuota; si son muchas, envíe el sitemap. Si le da pereza, la extensión puede hacerlo mientras usted mira, siempre que usted sea propietario o usuario con acceso total de la propiedad.

Quiero un diagnóstico de Core Web Vitals y de SEO técnico de estas URL: [pegue aquí sus URL].
1. Pasa cada URL por PageSpeed Insights (https://pagespeed.web.dev/), en móvil, cinco veces. Anota la mediana y el rango de la puntuación, del LCP, del CLS y del TBT.
2. Copia los datos de campo (de usuarios reales) si PageSpeed los muestra. Si no hay, escribe «sin datos de campo»; no los estimes.
3. Indica cuál es el elemento LCP de cada página, tal como lo señala el diagnóstico.
4. Revisa en cada página el title, la meta descripción, que haya un solo h1, la canónica, las imágenes sin width y height y los scripts de terceros.
5. Entrégamelo en Markdown, listo para guardar como diagnostico-core-web-vitals.md, con la fecha y la herramienta de cada cifra.
No cambies nada en ningún sitio ni en ninguna cuenta. Si una prueba falla, dilo y no la cuentes.

Pinterest lo aprendió en 2017, cuando rehízo sus páginas para que cargaran más rápido. Según su equipo de ingeniería, la espera que ellos miden bajó un 40 % y el tráfico SEO subió un 15 %. Pero antes tardaron semanas en igualar el tráfico SEO de las páginas viejas, por diferencias en etiquetas como el h1 o la canónica.

¿Y Screaming Frog? Sirve para revisar el sitio entero de una vez, pero no mide las Core Web Vitals por sí solo. Las trae si lo conecta a la API de PageSpeed Insights, una función de la versión de pago.

Tres advertencias antes de empezar. PageSpeed y Lighthouse son laboratorio, y para Google cuentan los datos de campo de usuarios reales. Una IA no sustituye leer la documentación que cita, y un arreglo de velocidad, por sí solo, no le sube posiciones.

Si prefiere no hacerlo usted, el diagnóstico gratuito le dice si hay un error grave. Y si va a hacer una página nueva, en el diseño de páginas web con SEO la velocidad cuenta desde el diseño. Si una de sus referencias choca con ella, gana la velocidad.

Véalo explicado por quien lo construyó

Vídeos de los canales oficiales de Google. Están en inglés y llevan subtítulos automáticos; son la misma fuente que enlazo arriba, en vídeo.

• Qué es Interaction to Next Paint (INP) · Chrome for Developers, 52 segundos. La definición más corta y correcta de INP que existe.

• Cómo mejorar el Largest Contentful Paint · Google Search Central, 22 minutos. Es de 2021, así que todavía dice FID donde hoy hay que leer INP; la parte de LCP sigue siendo válida.

• Ver las Core Web Vitals en vivo en Chrome DevTools · Chrome for Developers, 6 minutos. Así se encuentra el elemento LCP real sin escribir una línea de código.

Preguntas frecuentes