Qué son las core web vitals y cómo mejorar LCP, INP y CLS

Las core web vitals son tres métricas de Google que miden cómo vive un usuario real la carga, la respuesta y la estabilidad de una página: LCP (carga, bueno hasta 2,5 segundos), INP (respuesta, bueno hasta 200 milisegundos) y CLS (estabilidad visual, bueno hasta 0,1). Desde marzo de 2024, el INP sustituye al antiguo FID.

Imagina que acabas de lanzar el rediseño de tu sitio web corporativo. El diseño es moderno, los textos son persuasivos y las imágenes lucen profesionales. Sin embargo, pasan las semanas y notas que el tráfico orgánico se desploma. Antes, el instinto básico del marketing digital dictaba que la solución era simplemente inyectar más palabras clave en los textos o publicar más artículos.

Hoy, esa visión técnica obsoleta ya no es suficiente. Los motores de búsqueda han evolucionado para imitar el comportamiento humano. Si tu sitio web tarda en mostrar el contenido principal, bloquea la pantalla cuando el usuario intenta hacer clic, o mueve repentinamente un botón de compra de su posición original, serás penalizado, por mucha relevancia semántica que tengas. Aquí es donde entra en juego el concepto de core web vitals, una serie de indicadores vitales que separan a los sitios web mediocres de las plataformas digitales de alto rendimiento. En esta guía técnica y estratégica, desglosaremos exactamente cómo diagnosticar tu sitio y qué pasos tomar para dominar estos indicadores.

¿Qué son las core web vitals?

Las core web vitals son un conjunto de métricas estandarizadas por Google que miden la experiencia real del usuario en una página web. Sirven para evaluar la velocidad de carga, la interactividad y la estabilidad visual, diferenciándose de otras métricas de rendimiento por enfocarse estrictamente en lo que percibe el visitante. Los umbrales de una experiencia «buena» son: LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos.

El origen de este término se remonta a la iniciativa Web Vitals lanzada por Google en 2020. El objetivo de la empresa tecnológica era simplificar el caótico ecosistema de las métricas de rendimiento, proporcionando a los desarrolladores y expertos en posicionamiento un lenguaje común. En lugar de medir decenas de microeventos técnicos, se seleccionaron tres pilares fundamentales que representan el núcleo de la percepción humana frente a una pantalla.

Para comprender su lugar en el ecosistema, es útil comparar estos indicadores con otros conceptos técnicos que a menudo generan confusión entre los profesionales del marketing.

Concepto técnico	Principal diferencia	Ejemplo práctico
Core web vitals	Mide momentos exactos de la experiencia humana (ver, tocar, estabilidad).	Cuánto tarda el usuario en ver la foto principal del artículo.
PageSpeed Score	Es una puntuación algorítmica general del 0 al 100 basada en simulaciones.	Un sitio saca un 90/100, pero un usuario con mala cobertura lo siente lento.
Tiempo de Primer Byte (TTFB)	Mide exclusivamente la velocidad del servidor antes de dibujar nada.	El servidor responde en 0.1s, pero la página tarda 4s en mostrar información.

Un ejemplo ilustrativo de la vida diaria ayuda a asimilar esto: imagina entrar a una tienda física. El tiempo que tarda la puerta automática en abrirse de par en par es tu métrica de carga inicial. Si le preguntas algo al dependiente y este se queda congelado durante tres segundos antes de responderte, experimentas un problema de interactividad. Si intentas tomar un producto de una estantería, pero esta se desplaza repentinamente hacia un lado haciendo que dejes caer el producto, acabas de sufrir un fallo de estabilidad visual.

El propósito de las métricas: Por qué existen

Históricamente, los analistas técnicos medían la velocidad basándose en el evento "OnLoad" del navegador, es decir, cuando se terminaban de descargar absolutamente todos los archivos subyacentes. El problema de este enfoque era evidente: un usuario podía empezar a leer un artículo a los dos segundos, pero el evento completo podía marcar diez segundos porque un script invisible de análisis seguía cargando en segundo plano. Esto no reflejaba la realidad humana.

Las core web vitals existen para resolver ese sesgo. Se crearon para cuantificar la frustración humana y traducir el comportamiento errático de los navegadores en números objetivos que los equipos técnicos puedan corregir. Dentro del panorama general del ecosistema de búsqueda, estos indicadores forman parte de las señales de "Experiencia de página" (Page Experience). Se ubican justo después de la calidad del contenido; es decir, un contenido excepcional siempre ganará, pero ante dos contenidos de calidad idéntica, la experiencia técnica decidirá quién se queda con la primera posición.

Un error común de interpretación radica en confundir el entorno de pruebas con la realidad. Puedes lograr una calificación perfecta en herramientas de auditoría bajo condiciones de fibra óptica, pero reprobar la evaluación del algoritmo. ¿Por qué ocurre esto? Porque el algoritmo de clasificación se alimenta de los "Datos de Campo" (recopilados de usuarios reales navegando bajo redes 3G o con teléfonos móviles antiguos), no de los "Datos de Laboratorio".

Cuándo no necesitas priorizar las core web vitals: Existen escenarios donde obsesionarse con estas métricas es un desperdicio de recursos. Si tienes una aplicación interna de la empresa (intranet) que requiere inicio de sesión, los motores de búsqueda no la rastrearán, por lo que el posicionamiento no importa. Igualmente, en un prototipo experimental validando una idea de negocio, la velocidad extrema es secundaria frente a la funcionalidad central. Por último, en aplicaciones web progresivas orientadas a trabajar sin conexión tras la primera visita, la penalización inicial es un intercambio aceptable por características operativas más complejas.

El valor y los beneficios de la optimización

Mejorar la arquitectura de un sitio web no es un capricho técnico, es una decisión financiera con beneficios estructurados en dos grandes capas: el impacto comercial y la operatividad diaria de los equipos.

Valor comercial para la empresa

A nivel directivo, la velocidad web se traduce directamente en rentabilidad, retención de usuarios y mitigación de riesgos operativos. Cada segundo de retraso en entornos digitales competitivos aumenta la probabilidad de que el visitante abandone la página.

Vídeo, imágenes pesadas o código bloqueante devoran el presupuesto de adquisición de clientes. Si inviertes grandes sumas en captar tráfico, perder a un visitante porque el formulario de contacto tardó en responder es inaceptable.

Ejemplo ilustrativo:

• Contexto: Un gerente de marketing gestiona el portal de un software B2B para recursos humanos.
• Pasos realizados: Auditó los informes de Google Search Console, detectó tiempos de carga de 4,5 segundos en dispositivos móviles, redimensionó la imagen principal de la portada e implementó un sistema de precarga.
• Obstáculo y solución: Inicialmente, las imágenes perdieron demasiada nitidez. Resolvió la situación adoptando el formato moderno WebP, que mantuvo la calidad visual pero redujo el peso de forma notable.
• Resultado: El LCP bajó de 4,5 a 1,8 segundos, lo que generó un aumento visible e inmediato en el número semanal de solicitudes de demostración registradas en su CRM.

Beneficios para el equipo ejecutor

Para los desarrolladores, analistas y profesionales del marketing, estas normativas ofrecen un estándar claro. Ponen fin a las discusiones subjetivas sobre si un sitio "se siente lento" y establecen un lenguaje numérico común que alinea los esfuerzos entre departamentos técnicos y creativos. Además, facilitan la depuración, permitiendo a los ingenieros aislar problemas específicos en lugar de rediseñar sistemas completos a ciegas.

Beneficio directo	Métrica que se impacta	Tiempo para ver el resultado
Disminución de la tasa de rebote	LCP (Tiempo de carga)	2 a 4 semanas tras la indexación
Incremento en páginas por sesión	INP (Capacidad de respuesta)	Inmediato en la analítica interna
Reducción de clics accidentales	CLS (Saltos visuales)	Inmediato en mapas de calor

Descubre Orova.vn – una plataforma Biz AI Agent con la solución OROVA SEO completa, destinada a todos los sitios web. El sistema acompaña la optimización para motores de búsqueda de A a Z con las siguientes funciones: investigación de palabras clave, redacción de nuevos artículos optimizados para SEO, optimización de los contenidos existentes, seguimiento de posiciones, además del análisis de la competencia y el análisis técnico en profundidad. Regístrate hoy mismo para descubrir OROVA SEO de forma totalmente gratuita (oferta válida hasta el 7 de julio de 2027).

Cómo funcionan: Anatomía técnica y diagnóstico profundo

Para dominar este ecosistema, es necesario comprender la anatomía de sus tres componentes principales. Cada métrica evalúa una fase distinta del ciclo de vida de la página web y posee características únicas.

Análisis profundo de LCP (Largest Contentful Paint)

El LCP evalúa el rendimiento de la carga visual. Específicamente, mide el tiempo que transcurre desde que el usuario hace clic en un enlace hasta que el elemento de contenido más grande (generalmente una imagen de cabecera, un video o un bloque de texto masivo) se vuelve completamente visible en la pantalla. Google considera bueno un LCP de 2,5 segundos o menos.

El cálculo del LCP no es un simple cronómetro de un solo paso. Técnicamente, se desglosa en cuatro sub-fases críticas: el tiempo de respuesta del primer byte desde el servidor, el retraso en descubrir el recurso principal, el tiempo físico de descarga de dicho recurso y, finalmente, el tiempo de renderización en la pantalla. Un tiempo de respuesta del servidor lento suele ser un cuello de botella oculto que limita cualquier optimización posterior.

Las fallas típicas del LCP ocurren cuando las imágenes no están optimizadas, cuando los recursos están alojados en servidores lentos sin redes de distribución de contenido, o cuando el código de diseño crítico está bloqueado por archivos secundarios.

Flujo de interacción con el nuevo indicador INP

El INP (Interaction to Next Paint) es la métrica de interactividad que sustituyó oficialmente al antiguo FID (First Input Delay) en marzo de 2024. A diferencia del FID, que solo medía el retraso de la primera interacción, el INP observa la latencia de todas las interacciones durante la visita y reporta una de las más lentas, por lo que refleja mejor la experiencia completa.

El INP evalúa el flujo completo: el tiempo que el navegador pasa esperando porque está ocupado, el tiempo que tarda en procesar el código de la acción solicitada y el tiempo que necesita para repintar el resultado visual en la pantalla. El objetivo es mantener este indicador en 200 milisegundos o menos.

Ejemplo ilustrativo:

• Contexto: Un líder técnico supervisa el portal web de una revista digital interactiva de alto tráfico.
• Pasos realizados: Observó que los usuarios tocaban el menú de navegación móvil y no ocurría nada. Utilizó las herramientas para desarrolladores, identificó que el hilo principal estaba bloqueado por el análisis de un código pesado, y fragmentó el código en bloques más pequeños.
• Obstáculo y solución: Fragmentar el código rompió algunas dependencias visuales iniciales. Solucionó esto priorizando estrictamente la lógica de la interfaz de usuario antes de cargar las funciones de seguimiento secundarias.
• Resultado: El indicador INP bajó de 450 milisegundos a unos estables 80 milisegundos, logrando que los menús se desplieguen instantáneamente al tacto.

Estabilidad estructural con CLS (Cumulative Layout Shift)

El CLS mide la estabilidad visual. A todos nos ha pasado: estás a punto de tocar un enlace y, justo antes de que tu dedo toque la pantalla, un anuncio se carga en la parte superior, empujando el contenido hacia abajo y haciéndote hacer clic en un lugar no deseado. El CLS rastrea estas alteraciones estructurales calculando la fracción de impacto (cuánto espacio de la pantalla cambió) y la fracción de distancia (cuánto se movió el elemento). Un valor bueno es de 0,1 o menos.

Ejemplo ilustrativo:

• Contexto: Un diseñador web trabaja en optimizar las páginas de producto de una tienda online de ropa.
• Pasos realizados: Notó que el botón de añadir al carrito saltaba hacia abajo repentinamente. Revisó la estructura, detectó un carrusel de imágenes dinámicas que no declaraba dimensiones físicas, y estableció alturas mínimas en la hoja de estilos.
• Obstáculo y solución: Al poner alturas fijas, el diseño se rompía en pantallas ultra pequeñas. Lo resolvió utilizando relaciones de aspecto flexibles (aspect-ratio) en lugar de alturas rígidas absolutas.
• Resultado: El salto visual se redujo por completo a 0, eliminando las frustrantes interacciones erróneas detectadas previamente por los analistas.

Problemas comunes en frameworks modernos

Las arquitecturas web contemporáneas basadas en JavaScript (como React, Vue o Next.js) enfrentan desafíos únicos. El problema central es el paradigma de renderizado del lado del cliente (CSR). En estas aplicaciones, el navegador recibe un documento HTML casi vacío y debe descargar y ejecutar un archivo JavaScript masivo para "dibujar" la página. Cuanto más JavaScript necesita la página para mostrarse, más trabajo tiene el navegador antes de que el usuario vea e interactúe con el contenido.

Esto destruye el LCP y ahoga el INP debido al proceso conocido como hidratación (hydration). Durante la hidratación, el hilo principal del navegador está tan ocupado ensamblando los componentes interactivos que no puede responder a ningún clic del usuario. Para mitigar esto, los equipos técnicos deben apoyarse en el renderizado del lado del servidor (SSR), separar el código en paquetes pequeños y diferir la ejecución de componentes que no son visibles de inmediato en la pantalla.

Tabla comparativa de indicadores clave

Indicador	Tipo de fallo común	Solución táctica rápida (Cheat sheet)
LCP	Imágenes de cabecera pesadas	Implementar formatos de nueva generación y directivas de precarga inicial.
INP	Bloqueos por scripts largos	Diferir la ejecución de lógicas de terceros y ceder el control al hilo principal.
CLS	Inserción de bloques dinámicos	Reservar el espacio visual exacto antes de que el contenido termine de inyectarse.

Qué hacer para empezar a adaptarse y solucionar problemas

La adaptación a estas exigencias técnicas requiere enfoques distintos según la posición de responsabilidad. No es lo mismo ser el propietario de una tienda local que un analista técnico de una gran agencia.

Para pequeños empresarios o dueños de proyectos

Tu objetivo principal es evitar soluciones excesivamente complejas. La infraestructura básica es tu responsabilidad primordial.

1. Utiliza plataformas de alojamiento especializadas que cuenten con sistemas de caché integrados a nivel de servidor.
2. Comprime manualmente todo el material visual antes de subirlo al gestor de contenidos.
3. Elimina sin piedad los complementos visuales (plugins) que añadan animaciones innecesarias a la portada, ya que penalizan silenciosamente el rendimiento.
4. Revisa cómo luce el proyecto desde una conexión móvil simulada usando el modo incógnito del navegador.

Para el responsable de marketing interno

Tu enfoque debe ser el equilibrio estratégico entre funcionalidad comercial y salud técnica.

1. Realiza auditorías periódicas cruzando datos con analítica web para vincular caídas de conversión con picos de lentitud técnica.
2. Agrupa los recursos técnicos para planificar una limpieza de scripts inactivos.
3. Establece un presupuesto de rendimiento visual: exige a los proveedores externos que cualquier nueva etiqueta de seguimiento no sume más de un umbral específico de milisegundos.
4. Gestiona las actualizaciones alineándolas con tu calendario de contenidos, asegurando que los grandes lanzamientos comerciales ocurran sobre plataformas estables.

Para agencias o especialistas técnicos

El volumen de datos es el principal desafío a este nivel. Enfrentarse a informes con cientos de miles de advertencias genera parálisis por análisis.

1. Exporta el listado completo de fallos agrupados.
2. Emplea expresiones regulares para clasificar las direcciones web afectadas por tipo de plantilla (por ejemplo, ficha de artículo frente a listado de categorías).
3. Corrige la arquitectura de la plantilla matriz y verifica las mejoras en el entorno de pruebas limitando los anchos de banda del navegador.
4. Utiliza la función de validación en los portales para obligar a los rastreadores a reconsiderar un bloque completo de URL corregidas.

Error frecuente en la adopción	Consecuencia directa	Estrategia de prevención
Medir con ordenadores potentes	Falsa sensación de seguridad técnica	Restringir deliberadamente la CPU en pruebas.
Optimizar URLs de forma aislada	Desperdicio de horas de ingeniería	Identificar y corregir el archivo maestro.
Omitir el peso tipográfico	Bloqueos invisibles durante la carga	Usar fuentes del sistema o pre-cargar activos críticos.

Con OROVA.VN y el módulo OROVA SEO, pones fin definitivamente a las jornadas agotadoras de trabajo manual. En lugar de batallar durante horas para redactar artículos y elaborar informes, todo el proceso queda ahora optimizado y completado en tan solo 5 minutos.

Tendencias de rendimiento web para los próximos años: Mi perspectiva

Analizando la evolución constante de los algoritmos de clasificación y las infraestructuras de servidores, veo algunos vectores de cambio que pueden redefinir la manera en que construimos experiencias digitales en los próximos años. A continuación, comparto mi opinión sobre hacia dónde se dirige el rendimiento estructural.

La inteligencia artificial como modulador de experiencias

Observo una tendencia donde la inteligencia artificial dejará de ser únicamente una herramienta de generación de textos para convertirse en un orquestador de rendimiento. Considero probable que, en los próximos años, los servidores con sistemas predictivos analicen las capacidades del dispositivo receptor antes de responder. Si detectan un móvil de gama baja con batería limitada, podrían reescribir la página sobre la marcha, omitiendo librerías pesadas y entregando una versión simplificada pero de máxima puntuación. Las empresas deben preparar bases de datos flexibles donde el contenido no esté fuertemente atado a una presentación visual rígida.

El endurecimiento de los umbrales de latencia interactiva

Yo creo que el umbral actual del INP no es definitivo. Google lo ha fijado en 200 milisegundos, pero la evolución de los procesadores móviles podría hacer que esta meta parezca generosa. No me sorprendería que, con el tiempo, las expectativas se acerquen a las de las aplicaciones nativas instaladas. Quien empiece ya a sacar los procesos secundarios del hilo principal estará mejor preparado.

El futuro de la renderización en el borde

Me inclino a pensar que el modelo de un servidor central lejano perderá peso. La computación de borde (Edge computing) puede trasladar tanto el ensamblaje de la página como los micro-procesos de bases de datos a nodos situados a pocos kilómetros de la ubicación física del usuario. Esta arquitectura reduce la latencia inicial, pero exige a los equipos de desarrollo abandonar los monolitos tradicionales. No obstante, advierto que esta adopción tecnológica puede verse frenada temporalmente por los altos costes de transición en infraestructuras heredadas complejas.

Preguntas frecuentes sobre core web vitals

¿Qué es exactamente el umbral de "buena" experiencia?

Google evalúa cada métrica en el percentil 75 de las visitas reales, separando móvil y ordenador. Esto significa que una página (o un grupo de URL similares) aprueba cuando al menos el 75% de las visitas registran un LCP de 2,5 segundos o menos, un INP de 200 milisegundos o menos y un CLS de 0,1 o menos.

¿Afecta el servidor directamente a estas métricas?

Sí, de forma crítica. Un servidor lento incrementa el tiempo inicial de respuesta (TTFB), lo cual retrasa en cascada cualquier intento del navegador por renderizar textos o imágenes. Por mucha compresión visual que apliques, si el servidor tarda dos segundos en reaccionar, es imposible alcanzar un estado óptimo.

¿Son relevantes las core web vitals ahora que la IA genera respuestas directas?

Absolutamente. Aunque la inteligencia artificial extraiga y presente información en la página de resultados, la decisión del buscador sobre qué fuentes consultar sigue estando ponderada por la calidad técnica. Las core web vitals siguen formando parte de las señales de experiencia de página, y una página lenta o inestable también pierde a los visitantes que sí llegan desde esas respuestas.

¿Cómo mejorar las core web vitals sin saber programar?

La estrategia reside en utilizar plataformas modernas optimizadas por defecto y emplear herramientas automatizadas. Cambiar formatos de imagen convencionales a formatos ligeros, limpiar el gestor de contenidos de complementos inactivos y utilizar redes de distribución global son tareas operativas que no exigen escribir líneas de código profundo.

¿Qué herramientas sirven para medir las core web vitals?

El ecosistema gratuito proporciona todo lo necesario. Las plataformas oficiales de diagnóstico de rendimiento analizan una URL al momento, mientras que la consola de búsqueda para propietarios de sitios acumula y reporta datos históricos agrupando URLs problemáticas. Las extensiones oficiales del navegador son útiles para depurar fallos de manera individual mientras se navega.

¿Por dónde empezar hoy?

Enfrentarse a la optimización técnica por primera vez suele generar confusión sobre qué acciones priorizar. En lugar de listas de tareas interminables, la clave es adaptar la estrategia estrictamente al estado de madurez técnica de la organización.

Si te encuentras en un punto de partida donde no hay datos técnicos recolectados, tu primera acción indispensable esta tarde es habilitar la infraestructura de recopilación. Debes vincular tu dominio a la consola de administración de búsqueda de los motores principales. Sin este tablero histórico operando durante algunas semanas, estarás optimizando a ciegas, basándote en suposiciones de laboratorio en lugar de frustraciones reales de usuarios.

Por otro lado, si ya posees datos históricos pero la información es un caos de miles de enlaces defectuosos que nadie atiende, tu enfoque inmediato debe ser la arquitectura de plantillas. Descarga los reportes problemáticos y agrupa las direcciones afectadas según su estructura (por ejemplo, todas las entradas del blog en un grupo y las fichas de contacto en otro). Repara únicamente el código del esqueleto principal; esta sola acción solucionará cientos de incidencias derivadas de un plumazo.

Finalmente, si ya estás midiendo, tienes un diseño ordenado y no consigues bajar los tiempos de carga del contenido visual masivo, tu paso crítico es intervenir el orden de los recursos. Debes forzar al navegador a solicitar la imagen principal del documento de manera prioritaria usando comandos de precarga en la cabecera, mientras simultáneamente aplazas la carga de cualquier script promocional hasta que el usuario desplace la pantalla. Dominar las core web vitals no requiere rehacer tu sitio desde cero, sino administrar inteligentemente el flujo de prioridades.