Core Web Vitals: guía para empresas sobre LCP, INP y CLS

Los Core Web Vitals son tres métricas con las que Google evalúa la experiencia real de las personas en una página: qué tan rápido aparece lo principal (LCP), qué tan rápido responde a un toque o un clic (INP) y qué tan estable se mantiene mientras se lee (CLS). Aparecen en informes que usted seguramente ya recibió de su agencia o de su equipo técnico, a menudo con colores y siglas que no se explican.

Esta guía las traduce a lenguaje de negocio sin perder precisión: qué mide cada una, cómo medirlas con datos confiables, qué suele empeorarlas, qué correcciones son habituales y qué esperar de ellas en términos de posicionamiento. Evita las cifras de impacto a propósito, porque dependen de cada sitio, y es honesta con los límites: son una señal útil, no una fórmula para subir en Google.

Los Core Web Vitals forman parte de lo que Google llama señales de experiencia de página. No miden si su contenido es bueno ni si su oferta es atractiva; miden cómo se siente usar la página: si lo importante aparece pronto, si la página reacciona cuando se toca algo y si los elementos se quedan en su lugar mientras se lee.

Hay dos razones para ocuparse de ellos, y conviene no confundirlas:

• La razón de negocio. Una página lenta, que se desplaza sola cuando uno va a pulsar un botón o que no reacciona a un toque, hace que las personas abandonen. Si su público navega sobre todo desde celular, con redes de calidad variable, la diferencia entre un sitio ligero y uno pesado se nota todavía más. Eso afecta a formularios enviados, a consultas y a compras, con independencia de cualquier buscador.
• La razón de visibilidad. Google incorpora estas métricas entre las señales que considera para ordenar resultados. Es una señal entre muchas, y su peso no se compara con el de la relevancia y la utilidad del contenido. Mejorarlas puede ayudar y rara vez perjudica, pero nadie honesto puede prometer una posición por hacerlo.

Tratar los Core Web Vitals como un trabajo de calidad del producto, y no como un truco de posicionamiento, evita decepciones y ordena las prioridades.

Las tres métricas responden a tres preguntas distintas que se hace cualquier visitante, aunque no las formule así:

• LCP (Largest Contentful Paint, o pintura del contenido más grande). Responde a "¿cuándo siento que la página cargó?". Mide cuánto tarda en aparecer el elemento más grande visible al abrir la página, que suele ser la imagen principal, un video de portada o un bloque grande de texto.
• INP (Interaction to Next Paint, o de la interacción al siguiente pintado). Responde a "¿me hace caso la página?". Mide cuánto tarda en reaccionar visualmente a lo que usted hace: tocar un botón, abrir un menú, escribir en un formulario. Considera las interacciones de toda la visita y sustituyó a una métrica anterior llamada FID, que solo observaba la primera.
• CLS (Cumulative Layout Shift, o cambio acumulado del diseño). Responde a "¿se queda quieto lo que estoy leyendo?". Mide cuánto se desplaza el contenido de forma inesperada mientras la página carga o se usa. Es la sensación de ir a tocar un botón y que, justo en ese momento, aparezca algo arriba y termine tocando otro.

Cada métrica se clasifica en tres niveles (bueno, necesita mejorar y deficiente) según umbrales que Google publica y que puede revisar con el tiempo; las herramientas de medición le muestran la clasificación sin que usted tenga que recordar los valores. Para que una página se considere buena en una métrica, el resultado favorable debe darse en la mayor parte de las visitas reales, no solo en una prueba afortunada. Y las tres se evalúan por separado para celular y para computadora, de modo que un sitio puede aprobar en una y fallar en la otra.

En las herramientas verá además otros indicadores, como el tiempo de respuesta del servidor o el tiempo total de bloqueo. No son Core Web Vitals, pero ayudan a encontrar la causa cuando una de las tres falla.

La velocidad de carga de un sitio web, tal como la percibe una persona, depende sobre todo de lo que ocurre antes de ver el contenido principal. Eso es lo que resume el LCP.

Qué suele empeorarlo

• Una imagen principal demasiado pesada, con dimensiones mayores a las necesarias o en un formato poco eficiente.
• Un servidor lento para responder o un alojamiento saturado: si el primer byte tarda, todo lo demás se retrasa.
• Hojas de estilo y scripts que bloquean el dibujado de la página hasta que terminan de descargarse.
• Fuentes web que tardan en llegar y retrasan el texto del titular.
• Contenido principal que solo aparece después de ejecutar mucho JavaScript en el navegador.
• Imágenes de portada configuradas por error para cargarse de forma diferida, como si estuvieran al final de la página.
• Redirecciones encadenadas antes de llegar a la página.

Correcciones habituales

• Dimensionar y comprimir la imagen principal, emplear formatos modernos y entregar el tamaño adecuado para cada pantalla.
• Indicar al navegador que esa imagen es prioritaria y no diferir su carga.
• Mejorar el tiempo de respuesta del servidor con memoria caché, una red de distribución de contenido, un alojamiento acorde con el tráfico y consultas a la base de datos optimizadas.
• Reducir y posponer lo que bloquea el dibujado: separar el estilo crítico y diferir los scripts que no hacen falta al inicio.
• Cargar las fuentes de forma eficiente, limitar la cantidad de variantes y evitar que el texto quede invisible mientras llegan.
• Entregar el contenido principal ya construido desde el servidor, en lugar de depender de que el navegador lo arme.
• Eliminar las redirecciones innecesarias.

El INP es la métrica que más depende de lo que el navegador está haciendo en cada momento. Mientras ejecuta código, no puede responder a su toque, y la persona percibe una página "pegada".

Qué suele empeorarlo

• Demasiado JavaScript, propio o de bibliotecas, ejecutándose de una sola vez.
• Scripts de terceros: widgets de chat, administradores de etiquetas con muchas etiquetas, herramientas de analítica y publicidad, mapas y videos incrustados, ventanas emergentes.
• Tareas largas que bloquean el hilo principal, por ejemplo al filtrar un listado o al validar un formulario con mucha lógica.
• Páginas con una estructura muy grande y profunda.
• Animaciones y efectos que obligan al navegador a recalcular el diseño en cada fotograma.

Correcciones habituales

• Auditar y retirar los scripts de terceros que ya no aportan, y cargar el resto de forma diferida o después de la primera interacción.
• Dividir las tareas largas en partes pequeñas, para que el navegador pueda responder entre una y otra.
• Aligerar lo que ocurre al tocar: responder de inmediato (por ejemplo, mostrando que el botón fue presionado) y mover el trabajo pesado a un segundo plano.
• Simplificar la estructura de la página y los componentes que se actualizan con frecuencia.
• Reemplazar efectos costosos por alternativas ligeras.

Aquí pesan los acuerdos entre marketing, analítica y desarrollo: cada etiqueta y cada widget tiene un costo de rendimiento que alguien debería aprobar de forma consciente, no acumular por inercia.

El CLS es el más fácil de entender y, con frecuencia, el más fácil de corregir, porque casi siempre se debe a espacio que no se reservó.

Qué suele empeorarlo

• Imágenes, videos y marcos incrustados sin dimensiones declaradas.
• Anuncios, avisos de cookies, barras de aviso o formularios que se insertan encima del contenido ya visible.
• Fuentes web que, al cargarse, cambian el tamaño del texto y desplazan lo que viene después.
• Contenido que se agrega de forma dinámica por encima de lo que la persona ya estaba leyendo.
• Animaciones que modifican el tamaño o la posición de los elementos en lugar de transformarlos.

Correcciones habituales

• Declarar el ancho y el alto (o la proporción) de todo el contenido multimedia, para que el espacio quede reservado antes de que cargue.
• Reservar espacio para anuncios, avisos e incrustaciones; si hay que mostrar un aviso, hacerlo sin empujar el contenido.
• Configurar la carga de fuentes y elegir una de respaldo con proporciones similares, para reducir el salto al cambiar.
• Evitar insertar contenido sobre lo que ya se ve; colocarlo debajo o en un espacio previsto.
• Animar con propiedades que no alteran el diseño de la página.

La confusión más frecuente con los Core Web Vitals viene de mezclar dos tipos de datos que responden preguntas distintas.

• Datos de campo. Provienen de visitantes reales, recopilados durante un período reciente, e incluyen la variedad de dispositivos, redes y comportamientos de su público. Es lo que Google considera para evaluar su sitio. Su límite es que los cambios tardan en reflejarse y que las páginas con pocas visitas pueden no tener datos suficientes; en ese caso, las herramientas pueden mostrar información agregada del conjunto del sitio.
• Datos de laboratorio. Son pruebas simuladas en condiciones controladas, con un dispositivo y una red definidos. Se pueden repetir, sirven para depurar y para verificar un cambio al instante, pero no reflejan toda la variedad de sus visitantes. Como en el laboratorio no hay una persona interactuando, el INP se estima con indicadores aproximados.

Las herramientas más útiles son estas:

• PageSpeed Insights. Se introduce una dirección y muestra datos de campo (cuando existen) y de laboratorio, junto con recomendaciones concretas. Mire primero la parte de campo y luego la de laboratorio.
• El informe de Core Web Vitals de Google Search Console. Agrupa las direcciones de su sitio por estado según datos de campo, separadas por celular y computadora. Es especialmente útil para detectar grupos de páginas con la misma causa, por ejemplo todas las que comparten una misma plantilla.
• Las herramientas del navegador (DevTools y Lighthouse). Sirven para investigar a fondo: qué elemento es el LCP, qué desplazó el contenido, qué tarea bloqueó la página.
• Medición propia de visitantes reales. Cuando el sitio es crítico para el negocio, registrar los Core Web Vitals en su propia analítica permite ver el efecto de cada cambio con datos suyos y sin esperar.

Algunas reglas de buen uso: pruebe primero en celular; mida por plantilla (una página de servicio, un artículo, una ficha de producto, la página de contacto) y no solo la página de inicio; mida antes de tocar nada para tener una línea base y anote la fecha de cada cambio; repita las pruebas, porque una sola corrida puede engañar; y no persiga un puntaje global. El puntaje de rendimiento que muestran las pruebas de laboratorio es un resumen útil para diagnosticar, pero no es lo mismo que aprobar los Core Web Vitals con datos de campo.

Conviene fijar expectativas con claridad, porque aquí abundan las promesas exageradas.

Google trata estas métricas como una parte entre muchas del conjunto de señales con las que ordena los resultados. La relevancia del contenido para lo que la persona busca, su calidad y utilidad, los enlaces y el contexto de la búsqueda pesan, en general, más. Por eso un sitio muy rápido puede no posicionar si su contenido es débil, y un sitio con métricas imperfectas puede posicionar bien si responde mejor que los demás a la búsqueda. Si en igualdad de condiciones dos páginas compiten, la experiencia puede inclinar la balanza; ese es el sentido en que ayuda, y nadie puede prometerle una posición concreta por mejorarlas.

Otros puntos que ayudan a tomar decisiones realistas:

• Los cambios no se ven al instante. El laboratorio refleja una corrección de inmediato; el campo necesita visitas reales durante un tiempo para actualizarse.
• Hay decisiones de fondo, no solo técnicas. El video de portada, el chat flotante, la herramienta de mapas o las etiquetas de publicidad tienen un costo de rendimiento. A veces conviene conservarlas y a veces no; lo importante es decidirlo de forma consciente.
• Los resultados se degradan si nadie los cuida. Cada complemento nuevo, cada imagen sin optimizar y cada etiqueta agregada puede deshacer el trabajo anterior. Incorporar controles de rendimiento al proceso de publicación evita retrocesos.
• No siempre es la causa de una caída. Si lo que le preocupa es una pérdida de posiciones, no asuma que son los Core Web Vitals: primero conviene diagnosticar el origen, como explica la guía sobre por qué bajó su posicionamiento en Google.

Un orden sensato de trabajo, sea quien sea el proveedor, es este:

1. Identifique las páginas que más importan al negocio: las que reciben más visitas y las que generan consultas o ventas.
2. Mida su estado en campo y en laboratorio, en celular y en computadora, y anote la línea base.
3. Ataque primero las correcciones de mayor efecto y menor riesgo: la imagen principal, los scripts de terceros innecesarios, las dimensiones reservadas y la memoria caché.
4. Después, las estructurales: el alojamiento, la arquitectura del código y los componentes pesados, que pueden exigir un trabajo de desarrollo web más profundo.
5. Vuelva a medir con los mismos criterios y documente lo que cambió.
6. Establezca controles para que el rendimiento no retroceda con cada nueva publicación.

Si quiere revisar el estado general de su sitio antes de decidir qué corregir, la checklist de auditoría de sitio web cubre velocidad, rastreo, indexación y medición en una sola lista, y el trabajo de SEO técnico integra el rendimiento con el resto de las bases técnicas.

Para la optimización en sí, el servicio de optimización de velocidad web sigue nuestro proceso habitual: una llamada estratégica gratuita de 30 minutos, sin presión de venta, en la que le decimos con franqueza si podemos ayudarle; una propuesta escrita con alcance, entregables y precio, sin letra pequeña; el trabajo con pruebas de rendimiento antes del lanzamiento; y la entrega de los accesos a todo lo construido. Lo que necesitamos de su lado son los accesos al alojamiento, a la analítica, a Search Console y al administrador de etiquetas, y alguien que pueda decidir qué scripts de terceros se quedan. No prometemos puntajes ni posiciones específicos, porque dependen de su sitio, de sus herramientas externas y de su alojamiento. Trabajamos de forma remota con empresas de toda América Latina, y Victor J. Rosario atiende personalmente las llamadas y supervisa cada proyecto. Si prefiere comentar primero su caso, puede escribirnos.