Pasas tu web por PageSpeed Insights, te da 98 sobre 100 en verde y respiras tranquilo. Entras en Search Console y el informe de Core Web Vitals aparece en rojo. Las dos herramientas son de Google y las dos dicen la verdad, porque están midiendo cosas distintas. Entender esa diferencia es la mitad del trabajo.
Los Core Web Vitals son tres métricas con las que Google evalúa la experiencia real de tus visitantes: cuánto tarda en aparecer el contenido principal, cómo de rápido responde la página cuando alguien interactúa y cuánto se mueve el diseño mientras carga. En 2026 siguen siendo las mismas tres y con los mismos umbrales, pero se miden sobre datos reales de usuarios, no sobre una prueba de laboratorio.
Qué mide cada una de las tres métricas
Cada métrica responde a una queja distinta del usuario. Verlas así ayuda a entender por qué importan, más allá del posicionamiento.
| Métrica | Qué mide | Umbral bueno | Qué siente el usuario si falla |
|---|---|---|---|
| LCP Largest Contentful Paint | Cuánto tarda en aparecer el elemento visible más grande | 2,5 segundos o menos | «Esto no carga» |
| INP Interaction to Next Paint | Cuánto tarda la página en responder a un clic o a una pulsación | 200 milisegundos o menos | «He pulsado y no pasa nada» |
| CLS Cumulative Layout Shift | Cuánto se mueve el contenido mientras carga | 0,1 o menos | «Iba a pulsar y se ha movido» |
De las tres, la que más ha cambiado el panorama es INP. Sustituyó en marzo de 2024 a la métrica anterior, que solo medía el retardo de la primera interacción del usuario. INP mide todas, así que ya no basta con que la página arranque bien: tiene que seguir respondiendo cuando alguien despliega un menú, abre un acordeón o rellena un formulario.
CLS es la más ignorada y la que más molesta al usuario. Es esa situación en la que vas a pulsar un enlace, carga una imagen por encima, el contenido baja de golpe y acabas pulsando otra cosa. En móvil es especialmente irritante.
El percentil 75 o por qué tu web te parece rápida
Google no evalúa la media de tus visitantes, evalúa el percentil 75. Es decir, para aprobar una métrica, al menos el 75% de las visitas tiene que estar dentro del umbral.
Traducido a la práctica: no basta con que tu web vaya rápida en tu portátil con fibra. Tiene que ir rápida también para el visitante número tres de cada cuatro, que normalmente es alguien con un móvil de gama media y una conexión irregular en la calle.
Esto explica una situación muy frecuente. Alguien mide su LCP medio, ve 2,1 segundos y da por hecho que aprueba. Pero si la media es 2,1 segundos, el percentil 75 puede estar perfectamente en 4 segundos, lo que significa que una cuarta parte de sus visitantes está teniendo una experiencia mala.
La consecuencia de diseño es que hay que trabajar pensando en el peor escenario razonable, no en el mejor. Y en España, con mucho tráfico móvil en movimiento, ese peor escenario es bastante habitual.
Datos de campo y datos de laboratorio
Es la confusión que explica el caso del principio y la que más tiempo hace perder. Las herramientas de Google dan dos tipos de datos que no son intercambiables.
Los datos de laboratorio son una simulación. Una herramienta carga tu página en condiciones controladas y te da una puntuación. Sirven para diagnosticar y para saber qué arreglar, porque señalan causas concretas.
Los datos de campo son mediciones reales tomadas de visitantes reales durante los últimos 28 días. Son los únicos que Google usa para evaluar tu sitio, y los que aparecen en Search Console.
| Datos de laboratorio | Datos de campo | |
|---|---|---|
| De dónde salen | Una simulación controlada | Visitantes reales de tu web |
| Cuándo se actualizan | Al instante | Ventana móvil de 28 días |
| Para qué sirven | Diagnosticar qué arreglar | Saber si apruebas |
| Cuentan para posicionamiento | No | Sí |
Y aquí llega el dato que casi ningún artículo menciona y que afecta directamente a la mayoría de webs de negocios pequeños: si tu web no tiene suficiente tráfico, no hay datos de campo en absoluto. Google necesita un volumen mínimo de visitas para generar métricas significativas, así que muchos sitios recientes o con poco tráfico simplemente no aparecen en el informe.
Si es tu caso, no significa que apruebes ni que suspendas: significa que Google no tiene datos suficientes para evaluarte. En esa situación, los datos de laboratorio son lo único que tienes, y siguen siendo útiles para arreglar problemas evidentes aunque no determinen nada de cara al buscador.
Qué causa cada fallo en una web WordPress
Las causas se repiten mucho, porque casi todas vienen de las mismas decisiones de montaje.
| Métrica | Causas típicas en WordPress |
|---|---|
| LCP | Imagen de cabecera enorme sin optimizar, alojamiento lento, carrusel en la parte superior, tipografías que bloquean la carga |
| INP | Exceso de complementos que ejecutan código, scripts de terceros como chats y píxeles, constructores visuales con muchos efectos |
| CLS | Imágenes sin dimensiones declaradas, anuncios o banners que se insertan al cargar, tipografías que cambian de tamaño al aplicarse, avisos de cookies que empujan el contenido |
Hay tres patrones que explican la mayoría de casos reales.
El primero es la imagen de cabecera. Casi siempre es el elemento que mide el LCP, y casi siempre pesa mucho más de lo necesario. Una foto de 3 megas redimensionada por CSS sigue descargándose entera.
El segundo son los scripts de terceros. Un chat, un píxel publicitario, un widget de reseñas y una herramienta de mapas de calor son cuatro cosas razonables por separado que juntas hacen que el navegador tenga que procesar mucho antes de poder responder a un clic. Es la causa número uno de un INP malo.
El tercero es el aviso de cookies. Es el sospechoso habitual del CLS y casi nadie lo mira, porque aparece y desaparece rápido durante las pruebas. Si empuja el contenido hacia abajo al cargar, está generando desplazamiento en cada visita.
Por qué arreglar una página no cambia el informe
Por dos motivos que conviene saber antes de frustrarse: Search Console agrupa URLs parecidas, y los datos tardan semanas en reflejar cualquier mejora.
Sobre lo primero: Search Console no evalúa página por página, sino que agrupa URLs similares y asigna el estado del grupo según la peor métrica. Eso significa que si el problema está en un elemento compartido, como la cabecera, el aviso de cookies o un script global, arreglar una sola página no mueve nada. Puedes ver una mejora clara en el navegador y que el informe siga exactamente igual.
La consecuencia práctica es que conviene atacar plantillas, no páginas. Arreglar la plantilla de entrada de blog corrige de golpe todas las entradas; arreglar una entrada concreta no corrige nada a efectos del informe.
Sobre lo segundo: los datos de campo se calculan sobre una ventana móvil de 28 días. Si arreglas algo hoy, el informe empezará a moverse en un par de semanas y no reflejará el efecto completo hasta el mes siguiente. Cambiar cosas cada tres días esperando ver resultados es la mejor forma de no saber nunca qué ha funcionado.
Por dónde empezar y en qué orden
Por lo que más impacto tiene con menos esfuerzo. Este es el orden que resuelve la mayoría de casos en una web de negocio.
- Optimiza las imágenes. Redimensionar a las medidas reales de uso, servir formatos modernos y declarar siempre ancho y alto. Ataca LCP y CLS a la vez y es lo más accesible.
- Revisa el alojamiento. Si el servidor tarda en responder, ninguna optimización posterior lo compensa. Es la partida donde más se equivoca la gente al recortar.
- Audita los complementos y los scripts externos. Desactiva lo que no uses y valora si cada herramienta externa justifica su coste en rendimiento.
- Comprueba el aviso de cookies. Que se superponga en lugar de empujar el contenido.
- Revisa las tipografías. Cargar cuatro familias con seis pesos cada una es habitual y casi nunca necesario.
- Mide otra vez pasadas cuatro semanas. Antes no tendrás datos que signifiquen nada.
Una advertencia sobre los complementos de optimización. Ayudan, y a veces mucho, pero no arreglan un problema de origen: si tu alojamiento es lento o tu web carga tres megas de imágenes, un plugin de caché maquilla el síntoma. Y configurados de forma agresiva pueden romper cosas de forma sutil, así que conviene revisar la web entera después de activarlos.
Cuánto importan realmente para el posicionamiento
Menos de lo que sugiere el ruido que generan, y más de lo que parece cuando se miran solo como métrica técnica.
Google es explícito: los Core Web Vitals forman parte de sus sistemas de ranking, pero no garantizan buenas posiciones. El contenido, la intención de búsqueda y la relevancia siguen siendo determinantes. En la práctica, el rendimiento suele actuar como desempate: pesa cuando dos páginas están muy igualadas en todo lo demás.
Ahora bien, hay un argumento más sólido que el posicionamiento y es el que yo pondría por delante: una página lenta pierde visitantes antes de que lleguen a leer nada. Si además estás pagando por ese tráfico, cada segundo de más se traduce directamente en presupuesto tirado. El rendimiento es una cuestión de conversión antes que de SEO.
Buena parte de estos problemas se evitan en el momento de montar la web, eligiendo bien el alojamiento y siendo comedido con los complementos, algo que comento en el artículo sobre cuándo conviene WordPress. Cuando ya están ahí, el trabajo consiste en identificar qué elemento concreto está causando cada fallo, que rara vez es evidente a simple vista y es parte de lo que reviso dentro del servicio de analítica y optimización.
