Tu página abre rápido en tu computadora, pero un cliente te dice que el botón tarda en responder y que las imágenes empujan el texto mientras lee. Las Core Web Vitals de Google ayudan a investigar esas diferencias, porque evalúan aspectos de la experiencia de usuario que una revisión visual desde tu propio equipo puede pasar por alto.
Respuesta rápida para interpretar estas métricas
Las Core Web Vitals de Google son tres métricas que evalúan la carga del contenido principal, la respuesta a las interacciones y la estabilidad visual. Sus valores buenos son LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos, evaluados en el percentil 75 y por separado para móvil y escritorio.
Para aprovecharlas, identifica primero qué experiencia está fallando y en qué páginas ocurre. Después reproduce el problema, corrige su causa y comprueba el resultado tanto en pruebas controladas como en datos de visitantes reales.
Podría interesarte: Auditoría web online ¿qué revisar más allá de la puntuación?
¿Qué miden las Core Web Vitals de Google y cuáles son sus valores?
Estas métricas observan tres problemas diferentes, así que una mejora en una no compensa automáticamente un resultado deficiente en otra. Esta tabla permite interpretar sus umbrales sin confundir tiempos con puntuaciones.
| Métrica | ¿Qué evalúa? | Bueno | Necesita mejorar | Deficiente |
|---|---|---|---|---|
| LCP | Aparición del elemento de contenido más grande visible | Hasta 2,5 s | Más de 2,5 y hasta 4 s | Más de 4 s |
| INP | Respuesta visual a interacciones | Hasta 200 ms | Más de 200 y hasta 500 ms | Más de 500 ms |
| CLS | Desplazamientos inesperados del contenido | Hasta 0,1 | Más de 0,1 y hasta 0,25 | Más de 0,25 |
El percentil 75 indica que el 75 % de las experiencias medidas tiene un valor igual o inferior al mostrado; no es un promedio. Para considerar buenas las Core Web Vitals de Google, las tres métricas deben cumplir sus respectivos umbrales en esa referencia, cuando hay datos suficientes para evaluarlas.
LCP, cuándo aparece el elemento principal
Largest Contentful Paint mide cuánto tarda en mostrarse el elemento de contenido más grande dentro del área visible de la página. Puede ser una imagen de producto, una fotografía de portada o un bloque de texto, y puede cambiar entre móvil y escritorio.
Un LCP lento no demuestra por sí solo que necesites comprimir imágenes. El retraso puede comenzar en la respuesta del servidor, en el descubrimiento del recurso o en el trabajo necesario para mostrarlo después de descargarlo.
INP, cómo responde la página a una interacción
Interaction to Next Paint observa la latencia de clics, toques y entradas de teclado hasta que el navegador puede mostrar la siguiente actualización visual. Considera interacciones durante la visita y representa las de mayor latencia, con un tratamiento específico de valores atípicos.
En las Core Web Vitals de Google, INP sustituyó a FID el 12 de marzo de 2024. Si una guía presenta FID como la métrica vigente de respuesta, esa parte necesita actualizarse.
Piensa en un filtro de productos que parece quedarse congelado al tocarlo. INP ayuda a investigar esa falta de respuesta visual, aunque no mide por sí solo todo el tiempo que tarda una consulta remota en devolver los productos.
CLS, cuánto se desplaza el contenido inesperadamente
Cumulative Layout Shift evalúa la inestabilidad causada por desplazamientos inesperados de elementos visibles. Su puntuación no se expresa en segundos, sino que considera el espacio afectado y la distancia del movimiento.
Esta métrica permite detectar situaciones como un anuncio que aparece tarde y desplaza un botón. No debes interpretar cualquier movimiento o animación de la interfaz como un problema de CLS.
¿Por qué PageSpeed Insights y Search Console pueden discrepar?
PageSpeed Insights combina datos reales de Chrome, cuando existen, con una prueba de laboratorio realizada mediante Lighthouse. Los primeros resumen experiencias de los 28 días anteriores, mientras que la prueba representa una ejecución bajo condiciones concretas.
Además, los datos reales pueden corresponder a la URL analizada o al origen, es decir, al conjunto del sitio bajo ese protocolo y dominio. Search Console presenta grupos de páginas similares, por lo que no siempre estás comparando el mismo alcance.
Antes de concluir que las Core Web Vitals de Google muestran información contradictoria, revisa cuatro puntos. Esa comprobación evita atribuir a una sola página un resultado que representa un conjunto más amplio.
- ¿Estás mirando datos reales o una prueba de laboratorio?
- ¿El resultado corresponde a la URL o al origen?
- ¿Comparas móvil con móvil y escritorio con escritorio?
- ¿Los periodos de recopilación son equivalentes?
La puntuación de rendimiento de Lighthouse, de 0 a 100, tampoco equivale a aprobar estas tres métricas. Su prueba habitual de carga utiliza TBT, o tiempo total de bloqueo, como ayuda para investigar capacidad de respuesta; no sustituye al INP de usuarios reales.
¿Cómo medir las Core Web Vitals de Google sin sacar conclusiones apresuradas?
Empieza por una muestra de páginas que represente los recorridos importantes de tu negocio. Revisa, por ejemplo, una página de servicio, una categoría, una ficha de producto y un artículo, según el contenido que tenga tu sitio.
- Consulta Search Console para localizar grupos con problemas, separando dispositivos.
- Analiza URLs representativas en PageSpeed Insights y registra el alcance de sus datos.
- Anota la métrica afectada, su valor y la fecha de revisión.
- Reproduce el recorrido con Chrome DevTools, las herramientas de desarrollo del navegador, para investigar la causa.
- Formula una hipótesis concreta antes de modificar la página.
Un diagnóstico útil de las Core Web Vitals de Google termina con una decisión comprobable. Por ejemplo, “el espacio del módulo de recomendaciones aparece sin reservar” orienta mejor el trabajo que “hay que acelerar toda la web”.
Cuando el problema afecta muchas plantillas o coincide con una caída de visibilidad, una agencia especializada en SEO puede ayudar a relacionar el diagnóstico de rendimiento con las prioridades de búsqueda. La corrección técnica debe coordinarse con desarrollo y verificarse sobre las páginas afectadas, para saber qué cambió realmente.
Podría interesarte: ¿Mides lo correcto? ¿Qué es North Star Metric?
¿Qué corregir primero según el problema que encuentres?
Priorizar las Core Web Vitals de Google exige relacionar la evidencia con el alcance del fallo y la importancia de la página. Un error compartido por todas las fichas de producto merece una evaluación distinta de un efecto visual aislado en un artículo antiguo.
Si el contenido principal tarda en aparecer
Identifica primero qué elemento está marcando el LCP y dónde se consume el tiempo. Cambiar el formato de una imagen tendrá un alcance limitado si el navegador tarda demasiado en descubrirla.
- Si la respuesta inicial del servidor es lenta, revisa sus causas y la configuración de caché.
- Si el recurso principal empieza a descargarse tarde, comprueba cómo se descubre y prioriza.
- Si la imagen LCP utiliza carga diferida, revisa esa configuración para evitar retrasarla.
- Si la descarga es el cuello de botella, ajusta tamaño, resolución y compresión.
No apliques prioridad alta a todas las imágenes. La finalidad es que el navegador identifique los recursos verdaderamente importantes, y el resultado debe comprobarse después del cambio.
Si los botones o filtros responden tarde
Reproduce la interacción concreta, también mientras la página está cargando. Busca tareas largas de JavaScript, el código que controla buena parte de las interacciones, y trabajo excesivo para actualizar la interfaz.
El equipo de desarrollo puede reducir trabajo innecesario o dividirlo para permitir que el navegador responda antes. La solución debe mantener el funcionamiento del componente, por lo que desactivar scripts sin revisar sus dependencias puede crear otro problema.
Si los elementos cambian de posición
Reserva espacio para imágenes, anuncios y contenido incrustado antes de que aparezcan. Definir dimensiones o una proporción adecuada permite que el navegador organice el contenido sin esperar a que termine la descarga.
También revisa módulos que se insertan durante la visita y cambios provocados por fuentes tipográficas. Haz la prueba navegando e interactuando, porque algunos desplazamientos aparecen después de la carga inicial.
Un ejemplo para priorizar sin rehacer toda la web
Imagina una tienda de muebles cuyo equipo detecta dos incidencias al revisar las Core Web Vitals de Google. Las fichas desplazan el botón de compra cuando aparece un módulo de financiación y el filtro de materiales tarda en reaccionar; este es un escenario hipotético, no un caso con resultados medidos.
En lugar de cambiar de tema o rediseñar todo el sitio, el equipo podría organizar el trabajo así. Cada fila separa lo observado de una explicación que todavía debe comprobarse.
| Observación | Hipótesis por comprobar | Primera intervención si se confirma | Qué verificar después |
|---|---|---|---|
| El módulo de financiación desplaza el botón | Su espacio no está reservado | Reservar el área que ocupará | Estabilidad y legibilidad en varios tamaños de pantalla |
| El filtro responde tarde | La interacción ejecuta demasiado trabajo | Reducir o dividir ese trabajo | Respuesta del filtro y exactitud de los resultados |
| El problema se repite en varias fichas | La causa está en un componente compartido | Corregir la plantilla o el componente | Variantes de producto y páginas que lo utilizan |
La ventaja de este enfoque es que cada cambio responde a una hipótesis, tiene un responsable y puede revisarse por separado. Si mejoras el indicador pero desaparece una opción de financiación, el trabajo todavía necesita corregirse.
¿Basta un plugin o necesitas intervenir en el desarrollo?
En sitios que utilizan extensiones, puedes abordar las Core Web Vitals de Google con distintos niveles de intervención. La elección debería depender de la causa confirmada y del costo de mantener la solución.
| Opción | Cuándo considerarla | Ventaja | Límite o riesgo |
|---|---|---|---|
| Ajustar configuración o un plugin existente | La causa está en una función que ya puedes configurar | Menor intervención inicial | Un ajuste amplio puede afectar scripts necesarios |
| Corregir un componente o plantilla | El fallo se repite en un elemento compartido | Actúa sobre la causa localizada | Requiere desarrollo y pruebas de variantes |
| Revisar infraestructura o arquitectura | La evidencia muestra limitaciones más profundas | Permite abordar problemas estructurales | Mayor esfuerzo y riesgo si se decide sin diagnóstico |
Mi recomendación es empezar por la intervención más pequeña que resuelva la causa comprobada. Evita acumular herramientas que hacen lo mismo, porque después será más difícil identificar qué configuración provoca una mejora o un fallo.
Podría interesarte: ¿Tu web está lista? Auditoría SEO paso a paso
¿Cómo comprobar que la mejora se mantiene?
Después de publicar un cambio, repite el recorrido y compara pruebas realizadas en condiciones semejantes. Verifica también formularios, menús, filtros y otras funciones que puedan haberse visto afectadas.
Los datos reales de las Core Web Vitals de Google no se renuevan por completo al instante. La ventana de 28 días de CrUX sigue incluyendo visitas anteriores, por lo que una mejora de laboratorio puede aparecer antes que el cambio completo en el informe de campo.
Utiliza una ficha breve para conservar el contexto de cada corrección. Así podrás distinguir un avance sostenido de una ejecución favorable aislada.
- URL y plantilla afectadas.
- Dispositivo y alcance de los datos.
- Métrica y valor anteriores.
- Causa comprobada y cambio publicado.
- Fecha, responsable y forma de revertirlo.
- Resultado técnico y comprobación funcional posterior.
¿Qué relación tienen estas métricas con el SEO?
Google confirma que sus sistemas de posicionamiento utilizan las Core Web Vitals, pero obtener valores buenos no garantiza las primeras posiciones. La relevancia del contenido y otros aspectos de la experiencia siguen formando parte de una evaluación más amplia.
Por eso, mejorar las Core Web Vitals de Google debe integrarse con el trabajo editorial y técnico del sitio. Puedes seguir métricas de rendimiento y acciones comerciales por separado, sin atribuir automáticamente a una optimización cualquier variación posterior en visitas o ventas.
Mejorar la experiencia antes que perseguir el 100
Considero más útil corregir una interacción que dificulta comprar o contactar que invertir tiempo en una puntuación perfecta sin beneficio claro para el visitante. Esa prioridad permite justificar el esfuerzo por el problema que resuelve y no solo por el color de un panel.
El rendimiento necesita seguimiento, especialmente cuando añades componentes o cambias plantillas. Una web mejorada debe seguir siendo comprensible, funcional y fácil de mantener después de la optimización.
Preguntas frecuentes
¿Por qué no aparecen datos de usuarios reales?
Puede que la URL sea nueva o no reúna muestras suficientes para aparecer en CrUX. PageSpeed Insights puede mostrar datos del origen si los hay, pero la ausencia de datos no demuestra un rendimiento bueno ni malo.
¿Una web con poco tráfico puede mejorar su rendimiento?
Sí, puede investigar problemas con pruebas controladas y recorridos representativos. También puede implementar medición propia de usuarios reales, conocida como RUM, aunque una muestra pequeña exige cautela al interpretar resultados.
¿Validar la corrección solicita una nueva indexación?
No, iniciar la revisión del problema en Search Console no solicita una nueva indexación. Inicia un periodo de seguimiento de los datos para comprobar la corrección.
Fuentes principales utilizadas
- Google Search Central, documentación sobre experiencia en la página y su relación con el posicionamiento.
- web.dev, Web Vitals y metodología de los umbrales.
- web.dev, Largest Contentful Paint y su optimización.
- web.dev, Interaction to Next Paint y su optimización.
- web.dev, optimización de Cumulative Layout Shift.
- Google Developers, documentación de PageSpeed Insights.
- Ayuda de Google Search Console, informe Core Web Vitals y validación de correcciones.
- web.dev, flujo de trabajo con herramientas de Google.
- web.dev, anuncio oficial de incorporación de INP en marzo de 2024.
