INP, LCP y CLS en 2026: las tres métricas que deciden si su sitio vende o se abandona

Si su página tarda en mostrar el producto, no responde al primer toque o se mueve cuando el cliente iba a pulsar «Enviar», la visita se corta. Google resume esa experiencia en tres métricas de campo llamadas Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). No sustituyen a su analítica de ventas. Sí le dicen, con umbrales públicos y estables, si la página se siente usable para la mayoría de quienes la abren.

INP sustituyó a First Input Delay (FID) como métrica de interactividad. Un artículo anterior de este blog llegó a escribir que el INP «debe ser mayor a 200 ms». Eso está al revés. Según web.dev/articles/vitals (actualizado el 31 de octubre de 2024) y la definición de umbrales, un INP bueno es de 200 milisegundos o menos. Este texto se queda en esos números oficiales. No inventamos porcentajes de conversión ni de tráfico.

Las tres métricas, con los umbrales de Google

Las Core Web Vitals miden carga, interactividad y estabilidad visual. Google las evalúa en el percentil 75 de las visitas reales, por separado en móvil y escritorio. Una página «pasa» solo si las tres están en «bueno» a ese percentil. Los cortes oficiales son:

• LCP (carga percibida): bueno ≤ 2,5 s (2.500 ms); necesita mejora entre 2,5 s y 4 s; pobre > 4 s.
• INP (respuesta al clic, toque o tecla): bueno ≤ 200 ms; necesita mejora entre 200 ms y 500 ms; pobre > 500 ms.
• CLS (desplazamientos inesperados del diseño): bueno ≤ 0,1; pobre > 0,25.

El mismo umbral aplica a móvil y escritorio. En la práctica, el informe móvil suele ser el más exigente: ahí está la mayor parte del tráfico de una pyme mexicana.

Esos cortes no son un ranking secreto. Están documentados en web.dev y en el informe de Core Web Vitals de Search Console. Sirven para que usted y su equipo hablen el mismo idioma: «el LCP del catálogo en móvil está en pobre» es una frase accionable; «el sitio se siente lento» no lo es.

LCP: cuándo aparece el contenido principal

LCP reporta el momento en que se pinta el elemento más grande visible en la ventana: una imagen de portada, un bloque de texto o un vídeo. No es el load del navegador ni el primer píxel (eso es FCP). Es la señal de que la página ya muestra lo que el visitante vino a ver.

Para una pyme, el LCP malo suele ser una portada pesada sin dimensiones, un servidor que tarda en entregar el HTML o recursos que bloquean el render (CSS y JavaScript en el <head>). web.dev recomienda medir en campo con CrUX, PageSpeed Insights, Search Console y la librería JavaScript web-vitals. En laboratorio, Lighthouse y DevTools sirven para reproducir el problema, no para declarar que «ya pasó».

• Identifique el elemento LCP en PageSpeed Insights (campo y laboratorio).
• Reserve ancho y alto de la imagen de portada; sirva un archivo comprimido, no un PNG de cámara.
• Priorice el HTML y el CSS crítico; deje de bloquear el primer pintado con scripts de chat, mapas o píxeles.
• Revise el Time to First Byte: si el servidor responde tarde, ningún recorte de imagen alcanza los 2,5 s.

Un LCP de 2,5 s o menos en el percentil 75, en móvil y en escritorio, es el listón «bueno». Por encima de 4 s, Google lo etiqueta pobre.

INP: el toque que no pinta nada

INP observa clics, toques y teclas a lo largo de toda la visita —no solo el primer gesto, que era lo que medía FID— y reporta la interacción más lenta, ignorando algunos valores atípicos. La latencia va desde que el usuario inicia el gesto hasta que el navegador puede pintar el siguiente fotograma. Un INP de 200 ms o menos se considera buena capacidad de respuesta; entre 200 y 500 ms necesita mejora; por encima de 500 ms es pobre.

En un sitio de pyme el INP se rompe en formularios de contacto, menús móviles, filtros de catálogo y botones de «cotizar» que disparan demasiado JavaScript en el hilo principal. El usuario toca, no ve cambio, toca otra vez y el menú se abre y se cierra. Eso no es «un detalle de front»: es la razón por la que abandonan el formulario.

• Mida INP en campo. En Lighthouse no hay INP de laboratorio comparable: la herramienta usa Total Blocking Time (TBT) como aproximación.
• Reduzca trabajo largo en el hilo principal: divida tareas, aplaze scripts de terceros y evite listeners pesados en cada tecla.
• Dé retroalimentación inmediata (estado «enviando», menú que empieza a abrirse) aunque la red tarde.
• Pruebe el flujo real en un teléfono de gama media, no solo en su laptop.

Si alguien le dice que el INP «tiene que ser mayor a 200 ms», corríjalo: bueno es ≤ 200 ms. FID ya no forma parte del conjunto estable.

CLS: cuando la página se mueve bajo el dedo

CLS suma los saltos inesperados de elementos visibles. Un anuncio que empuja el botón, una imagen sin alto declarado, una fuente que cambia de tamaño o un banner de cookies que empuja el contenido: el usuario iba a pulsar una cosa y pulsa otra. El umbral bueno es 0,1 o menos; por encima de 0,25 es pobre. El percentil sigue siendo el 75, en móvil y escritorio.

No todo movimiento cuenta. Un desplazamiento que ocurre muy cerca de un clic del usuario (la API marca hadRecentInput si hay interacción en 500 ms) no se trata igual que un salto sin aviso. Lo que sí duele es el contenido que llega tarde y recorre el resto de la página.

• Declare width y height (o aspect-ratio) en imágenes y vídeos.
• Reserve espacio para banners, embeds y el aviso de cookies antes de inyectarlos.
• Evite insertar anuncios o barras arriba del contenido ya pintado.
• Anime con transform, no cambiando top/left ni el alto de cajas vecinas.

Cómo medir: campo primero, laboratorio después

Google insiste en que las Core Web Vitals son, ante todo, métricas de campo. El Chrome User Experience Report (CrUX) alimenta PageSpeed Insights y el informe de Search Console. La librería web-vitals le permite enviar LCP, INP y CLS a su propio analítica. DevTools y Lighthouse sirven para diagnosticar en desarrollo; Lighthouse no reporta INP y usa TBT como proxy.

• Campo: CrUX, PageSpeed Insights, Search Console (informe Core Web Vitals), librería web-vitals.
• Laboratorio: Chrome DevTools y Lighthouse (LCP y CLS sí; INP no — use TBT como pista).

Search Console agrupa URLs similares y asigna el estado del grupo a la métrica peor. Si CLS está en pobre y LCP en bueno, el grupo queda en pobre. Un origen pequeño puede no tener datos suficientes: en ese caso PageSpeed Insights aún le da una prueba de laboratorio y, si hay muestra CrUX, el campo de esa URL.

Si necesita una web que cargue, responda y no salte —catálogo, formulario o tienda—, Presticorp trabaja ese recorte en páginas para pymes, y el mismo criterio aplica a un MVP de startup o a un checkout de ecommerce: primero el HTML y las imágenes, después los extras.

Checklist de 14 días (sin números inventados)

Catorce días no alcanzan para rehacer el sitio. Sí alcanzan para saber en qué umbral está y cerrar las causas más comunes. Use este plan como orden de trabajo, no como garantía de «pasar» el informe: CrUX y Search Console se mueven con una ventana de campo (en el informe de Search Console, del orden de 28 días).

• Días 1–2. Abra Search Console → Core Web Vitals (móvil y escritorio) y corra PageSpeed Insights en su home, una ficha o servicio, y el formulario de contacto. Anote LCP, INP y CLS del percentil 75. Separe «pobre» de «necesita mejora».
• Días 3–5 (LCP). Identifique el elemento LCP. Comprima la portada, fije dimensiones, quite scripts del <head> que no pintan contenido. Si el TTFB es alto, hable con hosting o caché antes de retocar CSS.
• Días 6–8 (INP). Grabe el flujo de cotizar / filtrar / abrir menú en un teléfono real. Recorte JavaScript de terceros (chat, mapas, pixels) y evite trabajo largo al primer toque. Recuerde: el objetivo de campo es ≤ 200 ms, no «más de 200».
• Días 9–11 (CLS). Ponga tamaño a imágenes, reserve el hueco del banner de cookies y deje de inyectar bloques arriba del contenido visible.
• Días 12–14. Vuelva a medir en laboratorio (Lighthouse/DevTools) para confirmar que el cambio se ve. En campo, no espere que Search Console se ponga verde al día siguiente: inicie el seguimiento de corrección cuando crea que el grupo ya no está en pobre, y mantenga PageSpeed Insights como control semanal.

Pasar las Core Web Vitals no es un certificado de ventas. Es la condición mínima para que el cliente vea, toque y envíe sin pelearse con la página.

La sugerencia del escritor

Las tres métricas caben en una frase que puede pegar junto al monitor: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, percentil 75, móvil y escritorio. INP ya sustituyó a FID. El listón de 200 ms es un techo, no un piso.

Esta semana haga una sola cosa: abra PageSpeed Insights con la URL que más le importa (home o ficha) y anote las tres cifras de campo. Si INP o LCP están en pobre, no empiece por un rediseño: empiece por la imagen LCP y por el JavaScript que corre al primer toque del formulario. El checklist de 14 días está para eso. Si quiere que alguien más recorte esa superficie —plantilla, portada, formularios, tienda—, el punto de entrada publicado es la landing de pymes de Presticorp.

Fuentes

• web.dev. «Web Vitals». Actualizado el 31 de octubre de 2024. https://web.dev/articles/vitals
• web.dev. «Interaction to Next Paint (INP)». https://web.dev/articles/inp
• web.dev. «Largest Contentful Paint (LCP)». https://web.dev/articles/lcp
• web.dev. «Cumulative Layout Shift (CLS)». https://web.dev/articles/cls
• web.dev. «How the Core Web Vitals metrics thresholds were defined». https://web.dev/articles/defining-core-web-vitals-thresholds
• PageSpeed Insights. https://pagespeed.web.dev/
• Ayuda de Search Console. «Core Web Vitals report». https://support.google.com/webmasters/answer/9205520

Nota editorial: los umbrales (LCP ≤ 2,5 s / pobre > 4 s; INP ≤ 200 ms / pobre > 500 ms; CLS ≤ 0,1 / pobre > 0,25) y el criterio del percentil 75 proceden de las páginas de web.dev citadas, consultadas el 31 de agosto de 2026. No se atribuyen a esas fuentes porcentajes de conversión ni de tráfico. FID ya no es Core Web Vital estable; el sucesor es INP.