Core Web Vitals sin humo: cómo diagnosticar el rendimiento real de una web

Abres PageSpeed Insights, analizas una web y aparece un 72 en amarillo. Vuelves a probar y sale 84. Cambias de ordenador, repites la prueba y aparece un 91. Entonces empiezan las preguntas: ¿la web es rápida o lenta? ¿Hay que optimizarla? ¿Ese número afecta al SEO? ¿Por qué Google Search Console dice que hay URLs con problemas si Lighthouse parece estar bastante contento?

El problema empieza cuando reducimos el rendimiento de una web a una puntuación. Las Core Web Vitals no son un examen en el que haya que sacar 100. Son métricas diseñadas para describir partes concretas de la experiencia real de los usuarios y, sobre todo, son una herramienta de diagnóstico.

Entenderlas bien permite responder a una pregunta mucho más útil que “¿qué nota tiene mi web?”: ¿qué está haciendo que algunos usuarios tengan una mala experiencia y dónde está exactamente el cuello de botella?

Qué son realmente las Core Web Vitals

Actualmente hay tres Core Web Vitals:

• LCP — Largest Contentful Paint: mide la velocidad de carga percibida del contenido principal.
• INP — Interaction to Next Paint: mide la capacidad de respuesta de la página ante las interacciones del usuario.
• CLS — Cumulative Layout Shift: mide la estabilidad visual de la interfaz.

Para considerar buena la experiencia, las referencias actuales son:

Métrica	Buena	Necesita mejorar	Mala
LCP	≤ 2,5 s	2,5–4 s	> 4 s
INP	≤ 200 ms	200–500 ms	> 500 ms
CLS	≤ 0,1	0,1–0,25	> 0,25

Pero hay un detalle importante: no se trata de conseguir esos valores una vez en nuestro portátil. La evaluación se realiza pensando en la experiencia de la mayoría de usuarios y utiliza como referencia el percentil 75. Es decir, aproximadamente tres de cada cuatro experiencias deberían encontrarse dentro del umbral considerado bueno.

Eso cambia completamente la forma de diagnosticar rendimiento.

El primer error: obsesionarse con la puntuación de PageSpeed

PageSpeed Insights muestra mucha información, pero la puntuación de Lighthouse que aparece de forma tan visible suele acaparar toda la atención. Y no debería.

Una web puede sacar una puntuación excelente en una ejecución de laboratorio y, al mismo tiempo, ofrecer una experiencia mediocre a una parte importante de sus usuarios reales. También puede ocurrir lo contrario. La razón es sencilla: laboratorio y producción no están midiendo exactamente lo mismo.

Una prueba de laboratorio utiliza unas condiciones controladas: un dispositivo simulado, unas determinadas condiciones de red y una carga concreta de la página. Los usuarios reales, en cambio, llegan con móviles rápidos y móviles de gama baja, Wi-Fi, fibra o conexiones móviles deficientes, navegadores en distintas condiciones, cachés frías o calientes, extensiones, sesiones largas y diferentes formas de interactuar con la interfaz.

Por eso, antes de empezar a optimizar, hay que mirar qué tipo de datos estamos observando.

Datos de laboratorio y datos de campo no son intercambiables

Esta diferencia es probablemente una de las claves más importantes para interpretar correctamente las Core Web Vitals.

Datos de laboratorio

Herramientas como Lighthouse permiten reproducir una página en condiciones controladas y son especialmente útiles para detectar recursos que bloquean el renderizado, analizar JavaScript, estudiar la carga de imágenes, localizar tareas largas, comparar cambios durante el desarrollo o evitar regresiones antes de desplegar.

Pero una prueba de laboratorio es una simulación concreta, no la experiencia acumulada de tus usuarios.

Datos de campo

Los datos de campo proceden de usuarios reales. Google utiliza, entre otras fuentes, el Chrome User Experience Report (CrUX) para alimentar herramientas como PageSpeed Insights y el informe de Core Web Vitals de Search Console.

Estos datos reflejan situaciones que un test aislado difícilmente puede reproducir: dispositivos lentos, condiciones reales de red, usuarios que permanecen bastante tiempo en una página, interacciones que ocurren varios segundos después de la carga, contenido personalizado o de terceros y comportamientos que solo aparecen en producción.

De ahí podemos extraer una regla práctica bastante útil: los datos de campo sirven para detectar el problema y los datos de laboratorio ayudan a investigarlo. Confundir ambas cosas lleva fácilmente a optimizaciones innecesarias.

LCP: no siempre es “la imagen pesa demasiado”

El Largest Contentful Paint indica cuánto tarda en mostrarse el elemento de contenido más grande que ve el usuario inicialmente. Puede ser una imagen principal, un bloque grande de texto, una imagen de fondo o determinados elementos de vídeo.

Un LCP lento suele provocar la sensación de que la página tarda demasiado en estar realmente disponible, pero reducir el diagnóstico a “comprime la imagen” es demasiado simplista. Un LCP malo puede venir de varias fases distintas.

1. El servidor tarda demasiado en responder

Antes de mostrar el contenido, el navegador necesita recibir el documento inicial. Un TTFB elevado puede arrastrar todo lo que ocurre después, por lo que habría que revisar aspectos como backend, generación dinámica de páginas, caché, CDN, redirecciones o infraestructura.

2. El navegador descubre demasiado tarde el recurso LCP

Imagina una imagen principal que solo puede descubrirse después de descargar CSS o ejecutar JavaScript. La imagen podría pesar poco y aun así empezar a descargarse demasiado tarde.

En ese caso tenemos un problema de priorización, no necesariamente de tamaño.

3. El recurso tarda demasiado en descargarse

Aquí sí entran factores como un archivo excesivamente pesado, un formato inadecuado, dimensiones superiores a las necesarias, un servidor lento o una CDN mal configurada.

4. El recurso ya existe, pero tarda en renderizarse

La imagen puede haberse descargado correctamente y continuar sin aparecer porque el navegador está ocupado procesando CSS, JavaScript o renderizado.

Por eso, un buen diagnóstico de LCP debería separar, cuando corresponda: TTFB → retraso de carga del recurso → descarga → retraso de renderizado.

La pregunta correcta no es simplemente “¿cómo bajo el LCP?”, sino “¿en qué parte del LCP estamos perdiendo el tiempo?”

INP: cuando la web carga rápido pero responde tarde

Una web puede parecer rápida al cargar y ser desesperante cuando empiezas a utilizarla. Pulsas el menú y tarda en abrirse, seleccionas una opción y durante unas décimas no ocurre nada, escribes en un buscador y la interfaz responde con retraso o añades algo al carrito y no sabes inmediatamente si el clic ha funcionado.

Eso es precisamente el terreno de Interaction to Next Paint.

INP analiza la latencia de las interacciones realizadas durante la vida de la página y busca representar si la interfaz responde de forma consistente. No se limita al primer clic después de cargar, y esto es importante porque una página puede cargar perfectamente y degradarse después.

Las causas habituales suelen encontrarse en tareas JavaScript demasiado largas, exceso de trabajo en el hilo principal, listeners costosos, renderizados innecesarios, un DOM excesivamente grande, scripts de terceros, cálculos síncronos o una hidratación pesada en determinadas aplicaciones.

Lighthouse no puede medir el INP real de tus usuarios

Lighthouse ejecuta una carga automatizada sin un usuario real interactuando durante toda la sesión. Por eso no puede medir INP de la misma forma que los datos de campo.

En laboratorio se utilizan otras señales, como Total Blocking Time (TBT), para encontrar problemas que pueden acabar afectando al INP. Pero TBT e INP no son la misma métrica: un buen TBT puede ser una pista, mientras que el INP real sigue necesitando interacciones reales.

CLS: una web que se mueve también es una web lenta

El Cumulative Layout Shift mide los desplazamientos inesperados de elementos visibles. Seguro que lo has sufrido alguna vez: vas a pulsar un botón y justo antes aparece otro elemento encima; estás leyendo un párrafo y de repente baja media pantalla; intentas abrir un enlace y terminas pulsando un anuncio porque el contenido ha cambiado de posición.

Ese tipo de experiencia no tiene que ver con esperar tres segundos a que cargue una página, pero sí tiene mucho que ver con rendimiento percibido.

Entre las causas frecuentes encontramos imágenes sin espacio reservado, vídeos o iframes sin dimensiones, banners añadidos después de cargar, anuncios dinámicos, widgets externos, fuentes que cambian notablemente las dimensiones del texto o contenido insertado por JavaScript delante de elementos ya visibles.

En este caso, optimizar suele significar algo muy concreto: dar estabilidad al layout antes de que llegue el contenido.

Cómo diagnosticar Core Web Vitals sin optimizar a ciegas

Un diagnóstico serio debería seguir un orden.

1. Empieza por los datos reales

Primero comprueba qué Core Web Vital falla, si el problema aparece en móvil, escritorio o ambos, qué conjunto de URLs está afectado, si existen suficientes datos de campo y si el problema es estable o puntual.

Search Console y PageSpeed Insights son buenos puntos de partida. No abras todavía el código buscando algo que optimizar: primero identifica qué experiencia está fallando.

2. Busca patrones entre páginas

Si veinte URLs presentan un LCP parecido y comparten la misma plantilla, probablemente no tienes veinte problemas distintos. Tienes un problema de plantilla.

Esto resulta especialmente útil en ecommerce, blogs, fichas de producto, directorios, webs multidioma o aplicaciones con layouts reutilizados. Agrupar antes de analizar ahorra muchísimo trabajo.

3. Reproduce el problema en laboratorio

Una vez sabes qué estás buscando, DevTools, Lighthouse y el panel Performance se vuelven realmente útiles.

Ya no estás preguntando “¿qué puedo optimizar?”, sino algo mucho más preciso: “¿por qué esta plantilla tiene un LCP alto en móvil?” o “¿qué tarea bloquea el siguiente frame cuando el usuario abre este menú?”

Ese cambio de pregunta es la diferencia entre medir y diagnosticar.

4. Identifica la causa, no el síntoma

Una recomendación automática puede indicar “reduce JavaScript no utilizado”. Puede ser correcto, pero eso todavía no explica qué está causando el problema.

Quizá tengamos 300 KB de JavaScript innecesario y eliminarlos apenas afecte al Core Web Vital que realmente está fallando. Optimizar rendimiento no consiste en completar una lista de sugerencias, sino en encontrar qué recurso, tarea o decisión arquitectónica está condicionando la métrica problemática.

5. Corrige una causa y vuelve a medir

Las optimizaciones deberían poder relacionarse con una hipótesis.

Por ejemplo: el hero se descubre tarde porque está cargado como background desde una hoja CSS secundaria. La intervención sería hacer el recurso visible antes para el navegador y ajustar su prioridad. El resultado esperado sería reducir el retraso antes de iniciar la descarga del elemento LCP.

Eso es mucho más útil que instalar tres plugins de optimización y celebrar que PageSpeed ha subido nueve puntos sin saber por qué.

No persigas un 100 en Lighthouse

Un 100 puede ser agradable, pero no debería ser el objetivo del proyecto. A partir de cierto punto, perseguir la puntuación perfecta puede llevar a dedicar muchas horas a cambios con un impacto prácticamente imperceptible para el usuario.

Incluso puede provocar decisiones equivocadas: eliminar funcionalidades útiles, cargar todo de forma diferida sin criterio, retrasar scripts que sí necesita la interfaz, complicar innecesariamente la arquitectura o introducir hacks específicos para una auditoría.

El objetivo debería ser otro: que los usuarios tengan una experiencia rápida, estable y reactiva de forma consistente.

Las métricas existen para ayudarnos a evaluar eso, no al revés.

Tampoco optimices únicamente la página de inicio

Otro error frecuente es analizar exclusivamente la home. Pero una web puede tener una portada muy optimizada y, al mismo tiempo, fichas de producto lentas, páginas de categoría con demasiado JavaScript, posts con imágenes enormes, formularios con mal INP o layouts que generan CLS.

Los usuarios no experimentan “la web” como una única URL. Experimentan páginas concretas.

Por eso conviene diagnosticar plantillas, tipologías de página y recorridos, no una captura aislada de la portada.

Core Web Vitals y SEO: importantes, pero sin magia

Google recomienda conseguir buenas Core Web Vitals tanto por experiencia de usuario como para tener éxito en Search, y estas señales forman parte del conjunto de aspectos relacionados con la experiencia de página.

Pero eso no significa que bajar un LCP de 2,8 a 2,4 segundos vaya a disparar automáticamente una web diez posiciones en Google.

Una página rápida no sustituye contenido relevante, una buena arquitectura, una indexación correcta, autoridad, respuesta a la intención de búsqueda o un SEO técnico bien implementado.

Las Core Web Vitals tampoco deberían tratarse como un truco SEO. Son, ante todo, una forma bastante útil de detectar experiencias deficientes, y arreglar una experiencia deficiente ya es una buena razón para trabajar sobre ellas.

Entonces, ¿cuándo merece la pena intervenir?

Cuando los datos reales muestran un problema consistente, cuando una plantilla completa está perjudicando a una parte significativa de los usuarios, cuando la interacción se siente pesada, cuando el contenido se desplaza, cuando la carga principal tarda demasiado o cuando una regresión reciente empeora métricas que antes funcionaban bien.

Lo que no tiene demasiado sentido es optimizar durante horas una métrica verde únicamente para conseguir que un círculo cambie de 97 a 100.

Medir rendimiento es fácil. Diagnosticarlo es otra cosa

Hoy cualquiera puede introducir una URL en PageSpeed Insights y obtener una lista de recomendaciones. La parte difícil empieza después.

Hay que saber distinguir síntomas y causas, laboratorio y producción, datos de una URL y patrones de plantilla, optimizaciones con impacto y cambios cosméticos, métricas técnicas y experiencia real.

Ahí es donde las Core Web Vitals dejan de ser tres siglas y empiezan a ser realmente útiles.

Una buena optimización no empieza intentando conseguir mejores números. Empieza entendiendo por qué esos números son malos.

Y cuando el diagnóstico es correcto, muchas veces no hace falta hacer veinte cambios. Hace falta hacer los dos o tres que realmente importan.

¿Tu web tiene problemas de Core Web Vitals y no sabes de dónde vienen?

En Tornem desarrollamos y optimizamos proyectos web analizando el problema desde la implementación, no únicamente desde una puntuación automática.

Si Search Console muestra problemas de Core Web Vitals, PageSpeed ofrece resultados contradictorios o una web simplemente no responde como debería, podemos estudiar qué está ocurriendo y priorizar las mejoras que realmente tengan impacto.

Porque hacer una web más rápida no consiste en perseguir un 100. Consiste en saber qué está frenando la experiencia y arreglarlo donde toca.