Los Core Web Vitals (CWV) son un conjunto de métricas de rendimiento del mundo real que Google usa para evaluar la experiencia de la página como factor de posicionamiento. Miden tres aspectos específicos de la experiencia del usuario: qué tan rápido carga el elemento de contenido visible más grande (LCP, Largest Contentful Paint), qué tan estable es el diseño de la página mientras carga (CLS, Cumulative Layout Shift) y qué tan rápido responde la página a las interacciones del usuario (INP, Interaction to Next Paint).

No son métricas teóricas. Google las mide con datos reales del navegador Chrome de usuarios reales que visitan su sitio, agregados mediante el Chrome User Experience Report (CrUX). Si su sitio no cumple los umbrales de CWV para un porcentaje significativo de usuarios, su posicionamiento puede verse suprimido frente a páginas competidoras que sí los cumplen.

Cómo entender los tres Core Web Vitals

Largest Contentful Paint (LCP)

LCP mide el tiempo desde que la página comienza a cargar hasta que el elemento de contenido visible más grande, normalmente una imagen principal o un bloque grande de texto, se renderiza por completo. El umbral de Google para una calificación "Buena" es de menos de 2.5 segundos.

Los problemas de LCP más comunes incluyen:

Cumulative Layout Shift (CLS)

CLS mide los cambios inesperados de diseño: cuando los elementos se mueven en pantalla mientras la página carga, lo que hace que los usuarios pierdan su lugar o hagan clic por error en el elemento equivocado. El umbral para "Bueno" es menos de 0.1.

Causas comunes de CLS:

Interaction to Next Paint (INP)

INP reemplazó a First Input Delay (FID) como Core Web Vital en marzo de 2024. Mide el mayor retraso de interacción durante toda la visita a la página: clics, toques e ingreso por teclado. El umbral para "Bueno" es menos de 200 milisegundos.

Problemas comunes de INP:

Datos de campo vs. datos de laboratorio: Herramientas como Google Lighthouse y PageSpeed Insights muestran tanto datos de laboratorio (una prueba simulada y controlada) como datos de campo (mediciones de usuarios reales provenientes de CrUX). El factor de posicionamiento de Google usa datos de campo. Un puntaje perfecto en Lighthouse no garantiza buenos datos de campo si los usuarios reales, con dispositivos y condiciones de red reales, experimentan un rendimiento distinto. Optimizamos para ambos, con los datos de campo como objetivo principal.

Nuestro proceso de auditoría de Core Web Vitals

Antes de corregir nada, medimos con precisión qué está fallando y por qué. Nuestra auditoría de CWV incluye:

  1. Línea base de datos de campo: extraemos datos de CrUX de todas las páginas clave mediante la API de PageSpeed Insights para entender la experiencia real del usuario por tipo de dispositivo y velocidad de conexión
  2. Medición de laboratorio: ejecutamos auditorías de Lighthouse para identificar oportunidades y diagnósticos específicos
  3. Análisis de cascada: examinamos las cascadas de solicitudes de red en Chrome DevTools para identificar recursos bloqueantes, cadenas de dependencias y solicitudes lentas
  4. Perfilado del hilo principal: rastreamos la ejecución de JavaScript para identificar las tareas largas y su origen
  5. Auditoría del impacto de terceros: medimos el costo de rendimiento de cada script de terceros cargado en las páginas clave

Correcciones de optimización de Core Web Vitals

  • Precarga de la imagen principal con fetchpriority="high" en el elemento LCP
  • Conversión de imágenes a WebP/AVIF con srcset para una entrega adaptable
  • Ancho y alto explícitos en todas las imágenes para eliminar el CLS
  • font-display: optional o swap para evitar cambios de diseño provocados por las fuentes
  • Inserción de CSS crítico en línea para eliminar las solicitudes de hojas de estilo que bloquean el renderizado
  • División de código JavaScript y carga diferida de los scripts no críticos
  • Auditoría de scripts de terceros: eliminar o diferir los scripts que no sirven a los objetivos principales
  • Optimización del tiempo de respuesta del servidor mediante caché, CDN y mejoras de hosting

Técnicas de optimización de LCP

Corregir el LCP requiere identificar con precisión el elemento LCP (con frecuencia es distinto en celular y en escritorio) y luego optimizar la ruta específica que lo carga.

Precargar el recurso LCP: Agregar una etiqueta <link rel="preload"> con fetchpriority="high" le indica al navegador que comience a descargar la imagen LCP de inmediato, incluso antes de que el analizador de HTML llegue al elemento de imagen en el documento.

Servir formatos de imagen modernos: Las imágenes WebP suelen pesar entre un 25 y un 35 % menos que las JPEG con una calidad equivalente. AVIF ofrece una compresión aún mejor para imágenes fotográficas. Los implementamos con alternativas adecuadas mediante el elemento picture.

Eliminar los recursos que bloquean el renderizado: El CSS en el head del documento bloquea el renderizado hasta que se descarga y analiza por completo. Insertamos en línea los estilos críticos de la parte superior visible y diferimos la carga del CSS no crítico.

Mejorar el tiempo de respuesta del servidor: El TTFB afecta directamente al LCP porque nada puede renderizarse hasta que llega el HTML. El caché en el borde mediante Cloudflare, el caché del lado del servidor para páginas dinámicas y la optimización de consultas a la base de datos contribuyen a un TTFB más rápido.

Eliminación del CLS

El cambio de diseño es una de las experiencias más frustrantes para el usuario: está a punto de tocar un botón, la página se desplaza de repente y toca el elemento equivocado. Eliminar el CLS requiere rastrear cada fuente de movimiento inesperado:

Reservar espacio para los medios: Cada elemento de imagen y video debe tener atributos explícitos de ancho y alto, o una propiedad aspect-ratio de CSS. Esto le indica al navegador que asigne espacio antes de que cargue el medio, evitando que el contenido de abajo salte hacia abajo cuando se renderiza la imagen.

Métricas de fuentes de respaldo: Usar las propiedades size-adjust y ascent-override de CSS en las fuentes de respaldo hace que se aproximen a las dimensiones de la fuente web que se está cargando. Cuando llega la fuente web, el reacomodo del texto es mínimo en lugar de brusco.

Anclar el contenido dinámico: A los anuncios, los banners de cookies y otro contenido inyectado dinámicamente se les debe reservar espacio en el diseño. Si va a aparecer un banner de cookies, el diseño debe contemplarlo, en lugar de que el contenido salte hacia abajo cuando cargue.

Optimización de INP

INP es el Core Web Vital más reciente y, con frecuencia, el más exigente técnicamente de optimizar. Un INP deficiente normalmente se origina en tareas largas de JavaScript en el hilo principal que retrasan la capacidad del navegador de responder a la acción del usuario.

Dividir las tareas largas: Toda tarea de JavaScript que se ejecuta por más de 50 ms es una "tarea larga" que bloquea la respuesta a la entrada del usuario. Dividimos las tareas largas con scheduler.yield() o setTimeout(0) para darle al navegador oportunidades de procesar los eventos de entrada en cola.

Reducir el tamaño del paquete de JavaScript: Los paquetes grandes de JavaScript tardan más en analizarse y compilarse, lo que contribuye a la congestión del hilo principal. El tree shaking, la división de código por ruta y la eliminación de dependencias sin uso reducen el total de JavaScript procesado por página.

Auditar los scripts de terceros: Los píxeles de marketing, los widgets de chat y las herramientas de analítica pueden aportar cada uno cientos de milisegundos de bloqueo del hilo principal. Auditamos cada script de terceros para medir su contribución al INP y recomendamos eliminar o reemplazar los peores infractores.

Monitoreo de Core Web Vitals en el tiempo

La optimización de CWV no es una corrección única: es monitoreo y mantenimiento continuos. Los presupuestos de rendimiento se deterioran a medida que se agregan nuevas funciones, los equipos de marketing instalan scripts de terceros y los recursos de imagen se acumulan sin optimizar.

Recomendamos establecer presupuestos de rendimiento (valores máximos aceptables de peso de página, tiempo de ejecución de JavaScript y duración del LCP) y monitorearlos en cada despliegue. Las pruebas automatizadas en los flujos de CI/CD detectan las regresiones de rendimiento antes de que lleguen a los usuarios.

Para los clientes continuos, entregamos reportes mensuales de CWV con datos de CrUX, comparando el rendimiento de campo con las líneas base establecidas y señalando cualquier regresión para su investigación y corrección.

El impacto de Core Web Vitals en el negocio

Core Web Vitals no son solo métricas técnicas: son predictores directos del comportamiento del usuario y de los resultados del negocio. La investigación detrás de cada métrica se diseñó específicamente para medir las experiencias que hacen que los usuarios abandonen páginas, reduzcan su interacción o no conviertan. Entender lo que está en juego para el negocio en cada métrica aclara por qué el trabajo de optimización importa más allá del posicionamiento.

El LCP es la métrica más visible porque determina qué tan rápido siente cargada su página un visitante nuevo. Una página que logra un LCP "bueno" de menos de 2.5 segundos causa una primera impresión radicalmente distinta a la de una página que tarda de 4 a 5 segundos en mostrar su contenido principal. Las investigaciones en múltiples industrias muestran de manera constante que cada segundo adicional de LCP se correlaciona con mayores tasas de rebote y menores tasas de conversión. Para un negocio de servicios que paga por tráfico, ya sea mediante anuncios pagados o inversión en SEO orgánico, un LCP de 5 segundos significa que un porcentaje considerable de cada dólar gastado en adquisición se pierde por una página de carga lenta.

El CLS representa el tipo de frustración del usuario que no se le atribuye al sitio web pero que afecta de manera significativa las tasas de conversión. Cuando un usuario va a tocar un número de teléfono o hacer clic en un botón de contacto y el diseño se desplaza en el peor momento, la interacción falla. Para los usuarios de celular en particular, que representan más del 60 % del tráfico de la mayoría de los negocios de servicios del Sur de Florida, el cambio de diseño en momentos críticos de conversión reduce directamente los formularios de contacto completados y el volumen de llamadas. Lograr un CLS inferior a 0.1 elimina esas microfrustraciones que erosionan las tasas de conversión sin que se noten claramente en la analítica.

El INP afecta qué tan ágil se siente su sitio durante toda la sesión de navegación. Un usuario que toca un botón de menú y experimenta un retraso de 600 ms antes de que pase algo percibe el sitio como roto o lento, aunque la carga inicial de la página haya sido rápida. Esto importa especialmente en los recorridos de usuario de varias páginas: los negocios de servicios con flujos de reserva de consultas, formularios de contacto incrustados en varias páginas o herramientas interactivas son particularmente vulnerables a puntajes de INP deficientes que hacen que el sitio se sienta lento justo en los momentos en que los usuarios intentan actuar.

Datos de campo vs. datos de laboratorio: por qué importa la diferencia

La señal de posicionamiento de Google se basa en datos de campo: mediciones reales de rendimiento recopiladas de usuarios reales de Chrome que visitan sus páginas, agregadas en una ventana móvil de 28 días y reportadas mediante el Chrome User Experience Report (CrUX). Los datos de laboratorio, medidos por herramientas como Google PageSpeed Insights en su entorno simulado o Lighthouse en Chrome DevTools, ofrecen una prueba controlada que ayuda a diagnosticar problemas, pero no representan directamente lo que experimentan los usuarios reales.

La implicación práctica es que optimizar sus puntajes de laboratorio sin mejorar los de campo no mejora su señal de posicionamiento. Lo vemos con frecuencia en negocios que hicieron optimizaciones que se ven excelentes en las pruebas de PageSpeed Insights pero no movieron sus datos reales de CrUX, normalmente porque la optimización atendió el entorno de prueba simulado y no la distribución real de tipos de dispositivo, condiciones de red y comportamientos de usuario que representa su audiencia.

Los datos de campo tienen un rezago de 28 días: los cambios que haga hoy no se reflejarán por completo en sus datos de CrUX hasta dentro de cuatro semanas. Esto significa que el monitoreo posterior a la optimización requiere paciencia y claridad sobre cuándo medir. Establecemos protocolos de medición antes de empezar cualquier trabajo: se recopilan los datos de campo de la línea base, se implementa la optimización, se define una ventana de monitoreo de 30 días y se vuelve a medir a los 30 y a los 60 días para confirmar la mejora tanto en los datos de laboratorio como en los de campo.

Para páginas nuevas o sitios web sin suficiente tráfico para aparecer en los datos de CrUX, los datos de laboratorio son la única herramienta de medición disponible. En estos casos, establecemos líneas base de laboratorio completas en múltiples perfiles de dispositivo y condiciones de red para aproximar lo más posible el rendimiento del mundo real. También monitoreamos el rendimiento de la página a medida que se acumula tráfico y los datos de CrUX pasan a estar disponibles.

Core Web Vitals para la audiencia móvil del Sur de Florida

La demografía del Sur de Florida crea desafíos específicos de CWV. La gran proporción de usuarios móviles de la región, impulsada por visitantes internacionales, una población más joven en muchos vecindarios y un estilo de vida activo al aire libre que hace que las personas estén con frecuencia en el celular y no en una computadora, hace que el rendimiento de CWV en móvil sea especialmente determinante. La evaluación de posicionamiento de Google es mobile-first, es decir, sus puntajes de CWV en móvil determinan su posicionamiento, pero el impacto en el negocio de un mal rendimiento móvil es aún más directo: le falla a sus usuarios reales en el punto de contacto.

El tráfico turístico introduce consideraciones de rendimiento adicionales. Los visitantes de fuera de EE. UU. con conexiones de datos internacionales, o que usan redes WiFi de hoteles y resorts de calidad variable, experimentan sus páginas en condiciones distintas a las de los usuarios locales con banda ancha. Las páginas optimizadas solo para conexiones locales rápidas pueden fallar drásticamente para visitantes internacionales que las cargan con conexiones más lentas. Probamos el trabajo de optimización en múltiples condiciones de red, no solo en una conexión 4G rápida simulada, para asegurar que las mejoras de rendimiento se mantengan en todo el rango de conexiones que representan sus usuarios reales.

La naturaleza bilingüe del mercado de Miami hace que muchos sitios web ofrezcan dos versiones de idioma. Lograr que tanto la versión en inglés como la versión en español de su sitio cumplan los umbrales de CWV exige trabajo de optimización en ambos conjuntos de plantillas. Un descuido común es optimizar el contenido principal en inglés y suponer que la versión en español rinde igual; en la práctica, pequeñas diferencias en la extensión del contenido, los recursos de imagen o la configuración de las plantillas suelen producir puntajes de rendimiento notablemente distintos.

Cuando la optimización de CWV no es la raíz del problema

Core Web Vitals son importantes, pero son solo un componente de la experiencia de página, no el panorama completo. Si sus posiciones son deficientes a pesar de tener puntajes "buenos" de CWV, el problema está en otra parte. Un SEO on-page deficiente, un perfil débil de backlinks, contenido escaso, carencias de E-E-A-T o problemas más fundamentales de posicionamiento competitivo no se resolverán con la optimización de CWV. CWV es un requisito previo para posicionarse de forma competitiva, no una garantía de posicionamiento.

Planteamos esta distinción de manera explícita durante nuestro proceso de evaluación. Si sus puntajes de CWV ya están en el rango "bueno", seguir optimizándolos producirá rendimientos decrecientes en comparación con invertir en la calidad del contenido, el link building o el SEO on-page. Evaluamos el panorama completo de lo que limita sus posiciones y recomendamos la optimización de CWV solo cuando representa una brecha real de rendimiento frente a su conjunto de competidores. Para algunos clientes, CWV es el principal cuello de botella; para otros, es una preocupación secundaria una vez resueltos los problemas de mayor impacto.

Preguntas Frecuentes

Los datos de CrUX se actualizan en una ventana móvil de 28 días, lo que significa que los cambios que haga hoy no se reflejarán por completo en los datos de campo de Google hasta dentro de unas cuatro semanas. Después, los cambios en las posiciones suelen empezar a aparecer entre dos y cuatro semanas después de que se actualicen los datos de CrUX. En la práctica, espere una ventana de seis a doce semanas desde que se completa el trabajo de optimización hasta que las posiciones reflejan la mejora, aunque algunas páginas con tasas de rastreo más rápidas pueden mostrar movimiento antes. Durante todo este proceso damos seguimiento tanto a las mejoras en los datos de laboratorio (visibles de inmediato) como en los datos de campo (visibles después de la ventana de 28 días).

Sí. Pasar de "necesita mejorar" a "bueno" en los tres Core Web Vitals puede llevar páginas de las posiciones 5-8 a los tres primeros lugares en palabras clave competitivas donde usted está cerca de posicionarse, pero lo superan competidores técnicamente mejores. Además, las mejoras de CWV tienen un impacto directo en el negocio, independiente de las posiciones: un mejor LCP reduce las tasas de rebote, un mejor CLS reduce los errores de interacción accidental y un mejor INP reduce la frustración del usuario durante toda la sesión de navegación. Estas mejoras en la experiencia del usuario afectan la tasa de conversión de todo el tráfico existente, no solo del tráfico orgánico futuro.

CWV afecta el rendimiento de Google Ads igual que el SEO orgánico. El Nivel de Calidad de Google, que determina su costo por clic, incorpora la experiencia de la página de destino como un factor. Un rendimiento deficiente de la página reduce el Nivel de Calidad, lo que aumenta su CPC y reduce la posición del anuncio. Mejorar Core Web Vitals en sus páginas de destino puede reducir el costo por clic, mejorar la posición del anuncio y aumentar la tasa de conversión del tráfico pagado, todo a la vez. Para las empresas que dependen en gran medida de Google Ads, la optimización de CWV suele ofrecer un ROI más rápido que en escenarios de tráfico puramente orgánico.

Usamos una combinación de Google PageSpeed Insights (datos de laboratorio y datos de campo de CrUX para URL individuales), el informe de Core Web Vitals de Google Search Console (datos de campo de todas las URL de su sitio, segmentados por escritorio y móvil), el panel Performance de Chrome DevTools (análisis detallado de trazas para problemas complejos de LCP e INP), WebPageTest (pruebas desde múltiples ubicaciones geográficas y condiciones de red) y CrUX Explorer (datos sin procesar de CrUX para análisis comparativo). Para diagnosticar INP en particular, utilizamos la API Long Animation Frames de Chrome y la instrumentación con performance.measure() para identificar las tareas de JavaScript específicas responsables de los retrasos en la interacción. La combinación de datos de campo que muestran el alcance del problema y herramientas de laboratorio que aportan el detalle diagnóstico es lo que hace que nuestro trabajo de optimización sea preciso y no de prueba y error.

Servicio Relacionado

Optimización de la velocidad del sitio

Optimización integral del rendimiento en todas las métricas de tiempo de carga: no solo Core Web Vitals, sino también el peso total de la página, el TTFB y el rendimiento real de los usuarios en todos los dispositivos.

Ver servicio