RECURSOS CORE

CLS e INP: Los Core Web Vitals que tu web probablemente está suspendiendo

LCP es solo uno de los tres Core Web Vitals. CLS e INP son igual de críticos para el posicionamiento y la experiencia de usuario, y la mayoría de webs los suspenden sin saberlo.

Cuando se habla de rendimiento web, casi toda la atención se concentra en el LCP. Es la métrica más visible, la que más se correlaciona con la percepción de velocidad del usuario y la que más se menciona en los informes de PageSpeed. Pero Google no mide solo el LCP. Los Core Web Vitals son tres métricas, y las otras dos — CLS (Cumulative Layout Shift) e INP (Interaction to Next Paint) — son igual de determinantes para el posicionamiento orgánico y para la experiencia del usuario.

La mayoría de los activos digitales suspenden al menos una de ellas. Y lo hacen en silencio, porque sus efectos son más difíciles de ver que un tiempo de carga lento pero igual de reales en términos de posicionamiento y percepción de marca.

CLS: cuando la web se mueve sola

El CLS mide la estabilidad visual de una página durante la carga. Específicamente, cuantifica cuánto se desplazan los elementos del layout de forma inesperada mientras el usuario está intentando leerla o interactuar con ella. Un CLS de 0 significa que nada se mueve. Un CLS alto significa que el contenido salta, se reorganiza o desaparece mientras carga — y el usuario pierde su punto de lectura, hace clic en el elemento equivocado o simplemente interpreta la experiencia como descuido.

El umbral que Google considera bueno es un CLS inferior a 0.1. Por encima de 0.25 se clasifica como deficiente. Y las causas más frecuentes son predecibles: imágenes sin dimensiones declaradas en el HTML, que el navegador no puede reservar espacio hasta que descarga el archivo; fuentes web que se cargan tarde y hacen que el texto cambie de tamaño o posición cuando sustituyen a la fuente del sistema; y banners de cookies, notificaciones o widgets de chat que se insertan dinámicamente en el DOM y empujan el contenido existente hacia abajo.

En Literal, el CLS se previene en la fase de desarrollo, no se corrige después. Declaramos las dimensiones de todas las imágenes en el HTML mediante los atributos width y height, lo que permite al navegador reservar el espacio correcto antes de descargar el archivo. Configuramos las fuentes web con la directiva font-display: optional o swap según el contexto, minimizando el impacto visual del cambio entre fuente de sistema y fuente cargada. Y los elementos que se insertan dinámicamente — consentimiento de cookies, popups, chats — se posicionan de forma que no desplacen el contenido existente.

INP: la métrica de respuesta que sustituyó al FID

En marzo de 2024, Google reemplazó el FID (First Input Delay) por el INP (Interaction to Next Paint) como el tercer Core Web Vital. El cambio es significativo: mientras el FID medía solo el retraso en la primera interacción del usuario, el INP mide el tiempo de respuesta de todas las interacciones durante toda la sesión — clics, taps, pulsaciones de teclado. Es una métrica mucho más exigente y mucho más representativa de la experiencia real.

El umbral bueno es un INP inferior a 200 milisegundos. Por encima de 500ms se considera deficiente. Cuando un usuario hace clic en un botón y la página no responde durante medio segundo, la percepción es de lentitud incluso si el LCP fue excelente. El INP alto es especialmente dañino en páginas con mucha interactividad: filtros, menús desplegables complejos, formularios con validación en tiempo real.

Las causas más comunes de un INP alto son tareas JavaScript largas que bloquean el hilo principal del navegador — el mismo hilo que procesa las interacciones del usuario — y código de terceros que se ejecuta sin control. Un script de analytics mal configurado, un chatbot que procesa eventos en el hilo principal, o una librería de animaciones que no está optimizada para el rendimiento pueden disparar el INP aunque el resto del activo esté perfectamente optimizado.

Cómo los medimos y corregimos en Literal

El diagnóstico preciso del CLS y el INP requiere datos de campo, no solo datos de laboratorio. Las herramientas sintéticas como Lighthouse o PageSpeed Insights simulan condiciones controladas que no siempre reflejan el comportamiento real en dispositivos variados y conexiones variables. En Literal, complementamos el diagnóstico de laboratorio con datos del Chrome User Experience Report (CrUX), que recoge métricas reales de usuarios que han visitado el activo, y con la monitorización continua mediante la Search Console, que clasifica las URLs según sus Core Web Vitals reales.

Para el CLS, el proceso de corrección empieza con identificar qué elementos producen los saltos — la herramienta de layout instability del panel de Performance de Chrome los marca directamente — y trabajar hacia atrás hasta encontrar la causa. En la mayoría de los casos son imágenes sin dimensiones, fuentes o contenido dinámico. La corrección es quirúrgica una vez que se sabe dónde mirar.

Para el INP, el diagnóstico es más complejo porque hay que identificar qué interacciones específicas producen las respuestas lentas y qué código se está ejecutando durante esa ventana. El panel de Performance de Chrome con la función de registro de interacciones permite aislar exactamente qué tareas JavaScript están bloqueando el hilo principal en cada clic. La corrección habitual involucra dividir tareas largas en microtareas con scheduler.yield(), diferir código de terceros y revisar los event listeners que se están ejecutando innecesariamente.

El impacto en posicionamiento y GEO

Los tres Core Web Vitals — LCP, CLS e INP — son factores de posicionamiento directo en Google desde 2021. Un activo con métricas deficientes en cualquiera de ellos compite en desventaja frente a competidores con rendimiento equivalente en contenido pero mejor experiencia técnica. Y esa desventaja no es teórica: es un multiplicador negativo que se aplica sobre todo el trabajo de SEO, por muy buenos que sean los contenidos.

Para el GEO, la relación es similar a la que describimos en el artículo de LCP: los modelos de lenguaje evalúan señales de calidad técnica cuando deciden qué fuentes citar. Un activo que no pasa los Core Web Vitals es un activo que proyecta falta de rigor técnico — exactamente lo contrario de lo que Literal construye.

Conclusión: los tres Vitals o ninguno

Optimizar el LCP y dejar el CLS e INP sin atender es como arreglar la fachada de un edificio y dejar la estructura sin revisar. Google mide los tres. Los usuarios los sienten los tres. Y los modelos de lenguaje los evalúan como parte del conjunto de señales de calidad del activo.

En Literal, los Core Web Vitals no son una lista de comprobación de última hora. Son condiciones de salida del proyecto: un activo no está terminado hasta que las tres métricas están en verde.

El rendimiento no es una feature. Es la base.

Literalmente, el activo digital que tu negocio necesita para escalar sin fricciones.

No construimos "páginas web". Diseñamos e implementamos arquitecturas de alto rendimiento, optimizadas para humanos y motores de IA (AEO). Es hora de que tu infraestructura técnica esté a la altura de tu ambición.

Inicia tu transición técnica