Datos de campo (CrUX)
Revisión de cómo experimentan realmente la carga los usuarios que visitan el sitio, según el informe de experiencia de usuario de Chrome.
Diagnostico LCP, INP y CLS con datos de campo y de laboratorio, identifico qué recursos concretos están retrasando la carga o generando saltos visuales, y priorizo las correcciones junto a quien desarrolla el sitio, en lugar de entregar un informe genérico de “optimiza imágenes y scripts” sin contexto.
Core Web Vitals es un conjunto de tres métricas —LCP, INP y CLS— que Google usa para evaluar la experiencia real de carga y estabilidad visual de una página, desde la perspectiva de usuarios reales que la visitan. No miden únicamente “qué tan rápido carga” en abstracto: miden momentos concretos de la experiencia, como cuánto tarda en verse el contenido principal, qué tan rápido responde la página a una interacción, y cuánto se mueven los elementos en pantalla mientras carga.
Estas métricas forman parte de las señales que Google usa para evaluar la experiencia de página dentro de su sistema de ranking, junto a muchas otras señales de relevancia y autoridad. No sustituyen la importancia del contenido ni de la arquitectura del sitio, pero sí pueden representar una desventaja competitiva cuando otros factores están relativamente igualados frente a la competencia.
El servicio general de SEO Técnico cubre Core Web Vitals como una de varias áreas, junto a indexación, datos estructurados y arquitectura. Esta página profundiza específicamente en el diagnóstico y la corrección de rendimiento: qué está retrasando la carga, qué genera inestabilidad visual y cómo priorizar las correcciones frente al esfuerzo de desarrollo disponible.
Frente a Indexación y Rastreo, la diferencia es de capa técnica: esa solución trabaja si Google puede encontrar e indexar tus páginas; esta trabaja qué tan buena es la experiencia de carga una vez que un usuario —o Google— ya accedió a ellas. Ambas son necesarias, pero resuelven problemas distintos y no se sustituyen entre sí.
Es distinta también de Auditoría SEO, la landing comercial de diagnóstico técnico integral: esa página cubre todas las áreas del SEO técnico en un mismo proceso, mientras esta solución se contrata cuando el rendimiento ya se identificó como el problema prioritario a resolver.
El trabajo combina datos de usuarios reales con pruebas de laboratorio controladas, porque ambas fuentes responden preguntas distintas y ninguna por sí sola da una imagen completa.
Revisión de cómo experimentan realmente la carga los usuarios que visitan el sitio, según el informe de experiencia de usuario de Chrome.
Análisis controlado con herramientas como Lighthouse para aislar qué recursos específicos generan cada problema de rendimiento.
Detección de imágenes sin optimizar, fuentes bloqueantes, JavaScript excesivo o de terceros que retrasa la interactividad.
Identificación de elementos que carecen de dimensiones reservadas y provocan saltos de layout durante la carga.
Orden de correcciones según cuánto mejorarían las métricas y cuánto esfuerzo de desarrollo requieren.
Documentación clara de cada corrección para que un desarrollador la implemente sin ambigüedad ni interpretación libre.
Cada métrica responde una pregunta distinta sobre la experiencia de carga. Entender qué mide cada una ayuda a interpretar correctamente un informe de rendimiento en lugar de tratarlo como una sola nota genérica.
| Métrica | Qué mide | Causa típica cuando falla |
|---|---|---|
| LCP (Largest Contentful Paint) | Cuánto tarda en mostrarse el elemento principal visible de la página | Imagen o bloque principal sin optimizar, servidor lento o recursos bloqueantes |
| INP (Interaction to Next Paint) | Qué tan rápido responde la página tras una interacción del usuario | JavaScript excesivo o mal optimizado que bloquea el hilo principal |
| CLS (Cumulative Layout Shift) | Cuánto se mueven visualmente los elementos mientras la página carga | Imágenes o anuncios sin dimensiones reservadas, fuentes que cambian el layout |
El trabajo se entrega con paneles claros de LCP, INP y CLS por tipo de página, y con la línea de tiempo de carga que muestra exactamente qué recursos consumen más tiempo.
Ejemplo ilustrativo. No representa datos reales de ningún proyecto.
Ejemplo ilustrativo de secuencia de carga de recursos de una página.
Cada sitio combina un conjunto distinto de causas según su plataforma y las decisiones de diseño acumuladas con el tiempo. Estos son los escenarios más habituales.
Archivos pesados sin compresión ni formato moderno que retrasan significativamente el LCP, especialmente en móvil.
Chats, píxeles de anuncios o widgets externos que bloquean el hilo principal y deterioran el INP.
Elementos que aparecen sin espacio reservado, provocando saltos visuales que afectan clics y conversiones.
Tiempo de respuesta del servidor que retrasa el inicio de la carga antes incluso de que el navegador procese la página.
El proceso combina datos reales de usuarios con pruebas controladas, y termina en especificaciones concretas para quien vaya a implementar los cambios.
Reviso datos de campo y de laboratorio para las páginas más relevantes del sitio, en móvil y escritorio.
Identifico qué recursos, scripts o patrones de diseño específicos están generando cada problema detectado.
Ordeno las correcciones según impacto esperado en las métricas frente al esfuerzo de desarrollo que requieren.
Confirmo con nuevas mediciones que las correcciones implementadas mejoraron las métricas como se esperaba.
El indicador principal es el porcentaje de URLs que aprueban el umbral “bueno” en las tres métricas de forma simultánea, medido con datos de campo reales y no solo con pruebas de laboratorio, que pueden no reflejar la experiencia de usuarios con conexiones o dispositivos más limitados.
Más allá de las métricas técnicas, conviene observar el efecto en comportamiento: tasa de rebote, profundidad de navegación y conversiones, especialmente en tráfico móvil, donde el impacto de un mal rendimiento suele ser más pronunciado que en escritorio.
Proporción de páginas dentro del umbral “bueno” en las tres métricas.
Evolución individual de cada métrica en las páginas prioritarias.
Cambio en el comportamiento de usuarios en dispositivos móviles.
Efecto de la mejora de velocidad en acciones completadas desde móvil.
Core Web Vitals se conecta con Indexación y Rastreo dentro del silo de SEO Técnico, y con una guía del blog que ya profundiza en velocidad web móvil.
Respuestas pensadas para quien quiere entender qué esperar realmente de una mejora de rendimiento, sin promesas exageradas.
No de forma automática ni aislada. Core Web Vitals es una señal más entre muchas que Google usa para evaluar la experiencia de página, dentro de un sistema de ranking donde la relevancia del contenido y la autoridad del sitio siguen pesando de forma determinante. Mejorar estas métricas no compensa un contenido débil ni una arquitectura confusa.
Donde sí suele marcar diferencia es en mercados muy competidos, donde varios sitios tienen contenido y autoridad similares: ahí la experiencia de página puede ser el factor que incline la balanza. También mejora de forma directa la tasa de rebote y las conversiones, independientemente de su efecto en rankings, lo que ya justifica la inversión en muchos casos.
Los datos de campo, recogidos por el informe de experiencia de usuario de Chrome (CrUX), reflejan cómo experimentaron realmente la carga usuarios reales con sus propios dispositivos y conexiones, durante los últimos 28 días. Los datos de laboratorio, generados por herramientas como Lighthouse, simulan una carga en condiciones controladas y reproducibles, útiles para diagnosticar causas específicas pero no necesariamente representativas de lo que experimenta cada usuario real.
Un sitio puede tener buenos resultados de laboratorio y datos de campo deficientes, si sus usuarios reales navegan con conexiones más lentas o dispositivos menos potentes que las condiciones simuladas. Por eso el diagnóstico combina ambas fuentes: laboratorio para aislar causas técnicas, campo para confirmar el impacto real en usuarios.
Los datos de campo de Search Console se basan en una ventana móvil de 28 días de tráfico real, así que una corrección implementada hoy no se reflejará completamente en el informe hasta que transcurra ese periodo. Es habitual ver una mejora parcial en las primeras semanas, con la métrica estabilizándose por completo hacia el final de esa ventana.
Las pruebas de laboratorio, en cambio, reflejan el efecto de una corrección de forma prácticamente inmediata, lo que las hace útiles para confirmar rápidamente que un cambio técnico funcionó como se esperaba, incluso antes de que el dato de campo lo confirme con tráfico real.
Es una situación común, especialmente en sitios construidos con temas o plugins de terceros donde el propietario no programa directamente. En estos casos, mi trabajo se centra en diagnosticar con precisión y entregar especificaciones claras y accionables que un desarrollador, una agencia o el soporte del propio tema o plugin pueda implementar sin ambigüedad.
Priorizar bien las correcciones es especialmente importante en estos escenarios, porque cada cambio solicitado a un tercero tiene un costo de coordinación. Concentrar el esfuerzo en las dos o tres correcciones de mayor impacto suele ser más efectivo que entregar una lista extensa de mejoras menores.
Sí, y es importante hacerlo así porque suelen tener resultados muy distintos. Los dispositivos móviles típicamente tienen menos potencia de procesamiento y, en muchos mercados, conexiones más lentas que un escritorio, lo que hace que problemas de rendimiento que pasan desapercibidos en desktop se vuelvan mucho más evidentes en móvil. Google, además, prioriza la versión móvil del sitio para su indexación y evaluación en la mayoría de los casos.
Por eso el diagnóstico revisa ambos entornos por separado, y las correcciones suelen priorizarse primero para móvil cuando ese es el origen principal de tráfico del sitio, sin descuidar por completo la experiencia en escritorio.
No es una revisión de una sola vez. Cambios posteriores en el sitio —una nueva funcionalidad, un plugin adicional, una campaña con nuevos scripts de seguimiento— pueden introducir de nuevo problemas de rendimiento sin que nadie lo note hasta que las métricas se deterioran de forma notable. Una revisión periódica, por ejemplo cada trimestre o después de cambios significativos en el sitio, ayuda a detectar regresiones antes de que afecten la experiencia de forma prolongada.
Establecer este hábito de revisión es especialmente relevante en sitios que reciben actualizaciones frecuentes de plugins, temas o integraciones de terceros, donde el rendimiento puede degradarse de forma gradual sin un único cambio evidente que lo explique.
Cuéntame sobre tu sitio y revisemos con datos reales qué está afectando la carga antes de invertir en correcciones genéricas que quizá no ataquen la causa principal.