Core Web Vitals: qué son de verdad, qué te está fallando y cómo arreglarlo

Si le preguntas a diez dueños de negocio qué son las Core Web Vitals, ocho te dirán algo como «que la web vaya rápido». No van mal encaminados, pero esa respuesta no sirve para arreglar nada. Las Core Web Vitals son tres métricas con un número y un umbral exactos, y cada una falla por motivos muy distintos. Confundirlas es la razón por la que mucha gente paga por «optimizar la web» y su nota no se mueve ni un punto.

Las tres métricas, con sus umbrales reales

Nada de aproximaciones. Estos son los números que usa Google en septiembre de 2026:

Un apunte que aclara muchas dudas: el INP sustituyó al FID en marzo de 2024. Si lees un artículo o una herramienta que todavía habla de FID como métrica principal, está desactualizado. La diferencia importa: el FID solo medía la primera interacción; el INP mide todas, así que una web que reacciona mal al segundo o tercer clic (algo muy típico en menús desplegables o formularios largos) ahora sí penaliza.

El malentendido que más dinero hace perder: laboratorio contra visitantes reales

Aquí está la parte que casi ningún artículo explica bien, y que nosotros hemos tenido que resolver de verdad al construir ORMA Test: cuando compruebas tu web en PageSpeed Insights, en realidad te está dando dos mediciones distintas, no una.

1. Datos de campo (visitantes reales). Es la experiencia real de la gente que ha visitado tu web en los últimos 28 días, medida por el propio Chrome. Es lo que Google usa de verdad para posicionar. Si tu web no tiene tráfico suficiente para esa página en concreto, Google te da la media de todo el dominio en su lugar (lo verás como «Origen» en vez de «Esta URL» en PageSpeed).
2. Datos de laboratorio. Es una prueba simulada, en un móvil de gama media con una conexión 4G deliberadamente lenta. No mide a tus visitantes: mide el peor caso razonable.

Por qué esto te puede llevar a arreglar lo que no toca: hemos visto webs con visitantes reales perfectamente contentos (LCP de 2 s) que en la prueba de laboratorio marcan 10 o 12 segundos, porque la web pesa varios megas y con una conexión lenta de verdad eso se nota mucho. Si solo miras el número de laboratorio, puedes gastar dinero en una urgencia que, para tus clientes reales, no lo es tanto. Y al revés: una web que en laboratorio parece perfecta puede fallar con visitantes reales si su público usa móviles más antiguos o tiene peor cobertura de la que asume la prueba.

La regla práctica: si tienes tráfico suficiente, manda el dato de visitantes reales. El de laboratorio sirve para diagnosticar por qué falla, no para decidir si es grave.

LCP: por qué tarda en aparecer lo primero que se ve

No es casi nunca «la web en general es lenta». Casi siempre es una de estas tres cosas:

1. La imagen principal se carga en diferido (lazy loading) quitando puntos. Es la trampa más común en WordPress con maquetadores visuales: activan el lazy loading para todas las imágenes, incluida la que aparece nada más entrar. El navegador no empieza a descargarla hasta que detecta que está cerca de la pantalla, y como es la primera, eso añade un retraso completo. La regla es al revés de lo que parece intuitivo: la imagen que se ve sin hacer scroll nunca debe llevar lazy loading; el resto, sí.
2. El servidor tarda en responder antes de enviar nada. Si el HTML tarda más de 600-800 ms en empezar a llegar, todo lo demás se retrasa en cadena, por rápida que sea después la conexión. Es típico de hosting compartido saturado o sin ninguna caché de página activada.
3. Hay CSS o fuentes que bloquean el pintado. El navegador no pinta nada hasta que ha descargado y procesado las hojas de estilo que declaras arriba del todo. Cuantas más (típico de plugins que añaden cada uno la suya), más tarda en aparecer el primer píxel.

INP: por qué responde tarde al tocar

Aquí el problema casi nunca son las imágenes: es JavaScript ocupando el hilo principal justo cuando alguien interactúa.

1. Maquetadores visuales con muchos widgets. Cuantos más módulos de Elementor, Divi o similares metas en una página, más scripts se ejecutan al cargar, y mientras se ejecutan, el navegador no puede atender un clic con fluidez.
2. Scripts de terceros que se cargan sin esperar. Chats en directo, píxeles de publicidad y herramientas de analítica que se disparan todos a la vez nada más entrar en la página son la causa número uno de una web que «se queda pillada» un instante al tocar el menú.
3. Tareas largas sin dividir. Cuando un script hace un trabajo pesado de una sola vez (por ejemplo, procesar una tabla grande o inicializar un slider complejo), bloquea cualquier interacción hasta que termina. La solución técnica se llama dividir tareas largas: partir ese trabajo en trozos más pequeños para que el navegador pueda atender al usuario entre medias.

CLS: por qué los elementos saltan mientras carga

Casi siempre es la falta de una medida reservada de antemano:

1. Imágenes sin ancho ni alto declarados. El navegador no sabe cuánto espacio va a ocupar hasta que la descarga entera, así que empuja el contenido de debajo cuando por fin la coloca. Basta con indicar sus dimensiones (o usar aspect-ratio en CSS) para que reserve el hueco desde el principio.
2. Fuentes que cambian de tamaño al cargar. Si la tipografía de reserva y la definitiva no ocupan lo mismo, el texto «rebota» cuando la fuente final llega. Se corrige alojando la fuente en tu propio servidor (más rápido) y ajustando su métrica de sustitución.
3. Banners de cookies o avisos que empujan el contenido hacia abajo después de que la página ya se había pintado. La solución es que ocupen una capa superpuesta, no que desplacen el resto.

Compruébalo con tu web ahora mismo

ORMA Test · auditoría gratuita

¿Cómo van las Core Web Vitals de tu web?

ORMA Test te da la nota de velocidad con datos reales cuando existen, y de laboratorio cuando no. En 30 segundos y sin registro.

Dirección de tu web AnalizarAnalizar→

Cuatro mitos que se repiten sin comprobar

• «Si tengo 100 en PageSpeed, mi SEO está resuelto.» No. El rendimiento es una señal de posicionamiento entre muchas, y un 100 en la prueba de laboratorio no garantiza que tus visitantes reales cumplan las Core Web Vitals: puedes tener buena nota y mal dato de campo si tu público usa dispositivos peores que el de la prueba.
• «Cuantos más plugins de caché, mejor.» Dos o tres plugins de caché activos a la vez suelen entrar en conflicto entre ellos y generar más problemas de los que resuelven. Con uno bien configurado basta.
• «Cambiar de hosting siempre lo arregla.» Arregla el problema de servidor lento (parte del LCP). No arregla un INP malo causado por exceso de JavaScript: eso es un problema de la propia web, no del servidor donde vive.
• «En mi ordenador va rápido, así que está bien.» Tu ordenador de trabajo con fibra no es representativo de un cliente con un móvil de gama media y datos móviles. Es exactamente la diferencia entre laboratorio y visitantes reales que hemos explicado arriba.

Lo que puedes revisar hoy sin necesitar a un desarrollador

• Abre tu web en el móvil con los datos (no con wifi) y cronometra cuánto tarda en verse el titular.
• En el panel de WordPress, busca si tu maquetador tiene una opción de «cargar diferido» y comprueba que no está aplicada a la imagen de portada.
• Cuenta cuántos plugins de caché tienes activos. Si son más de uno, desactiva todos menos el mejor configurado.
• Mira si tu banner de cookies aparece encima del contenido o empujándolo hacia abajo.

Si después de esto sigues sin saber por dónde empezar, es lo normal: diagnosticar bien cuál de estas causas es la tuya lleva su tiempo, y equivocarse de arreglo es tirar el dinero. Para eso está la revisión humana, gratis.