Core Web Vitals: qué son y cómo afectan directamente tus ventas

En 2021, Google empezó a usar la experiencia real del usuario como factor de ranking directo, a través de lo que llama Core Web Vitals. Eso significa que un sitio rápido puede rankear más arriba que uno con mejor contenido pero que carga lento, y viceversa: la velocidad y la estabilidad visual ya no son un detalle técnico, son parte de la nota que Google le pone a tu sitio. En Chile, donde buena parte del tráfico a sitios de empresas llega desde el celular y con planes de datos limitados, la mayoría de las empresas no tiene idea de cómo están sus propias métricas — y menos aún de cuánto les está costando en ventas.

Qué son los Core Web Vitals

Son tres métricas que Google mide directamente en usuarios reales de tu sitio, documentadas en detalle en su guía oficial de Web Vitals:

LCP — Largest Contentful Paint

¿Qué mide? Cuánto tarda en aparecer el elemento visual más grande de la página (normalmente una imagen hero o un bloque de texto grande).

Buena métrica: < 2.5 segundos Necesita mejora: 2.5 – 4 segundos Mala: > 4 segundos

Impacto en ventas: Amazon calculó que cada 100ms de latencia adicional les costaba 1% en ventas. Para tu empresa, un sitio que tarda 4 segundos en cargar pierde entre el 25% y el 50% de los visitantes antes de que vean tu contenido.

Qué lo empeora, en la práctica: imágenes pesadas sin comprimir, un servidor lento (TTFB alto), fuentes que bloquean el render, o código de terceros —chats, píxeles, banners de cookies— que se carga antes que el contenido real.

FID/INP — Interaction to Next Paint

¿Qué mide? Cuánto tarda la página en responder cuando el usuario hace click en algo (un botón, un menú).

Buena métrica: < 200ms Necesita mejora: 200 – 500ms Mala: > 500ms

Impacto en ventas: Una página que no responde inmediatamente se siente rota. Los usuarios abandonan formularios, carritos de compra y CTAs si la respuesta es lenta.

Qué lo empeora: JavaScript pesado ejecutándose en el hilo principal del navegador, típicamente plugins acumulados, sliders, widgets de chat en vivo o scripts de terceros que nadie revisó en meses.

Si esta es la métrica que peor te queda, vale la pena profundizar: cubrimos cómo mejorar el INP paso a paso con el detalle técnico completo.

CLS — Cumulative Layout Shift

¿Qué mide? Cuánto “salta” el contenido mientras carga. Esas imágenes que hacen que el texto se mueva justo cuando vas a hacer click.

Buena métrica: < 0.1 Necesita mejora: 0.1 – 0.25 Mala: > 0.25

Impacto en ventas: El CLS alto destruye la confianza. Si los elementos se mueven mientras el usuario lee, la experiencia parece poco profesional y disminuye la tasa de conversión.

Qué lo empeora: imágenes y videos sin width y height definidos, anuncios que se inyectan después de que la página ya cargó, fuentes web que corren el texto al terminar de cargar, y contenido dinámico que empuja lo que el usuario ya estaba leyendo.

Cómo medir tus Core Web Vitals

Herramientas gratuitas

1. Google PageSpeed Insights (pagespeed.web.dev): Analiza cualquier URL y te da los datos reales de usuarios + diagnóstico técnico. Empieza aquí. Revisa tanto mobile como desktop — en Chile la mayoría del tráfico es mobile y casi siempre sale peor.

2. Google Search Console: En “Experiencia > Core Web Vitals” ves el estado de todo tu sitio agrupado por tipo de página, según datos reales de usuarios de Chrome de los últimos 28 días.

3. Lighthouse (Chrome DevTools): F12 → Lighthouse → Generar informe. Ideal para desarrollo local y para probar si un cambio ayuda antes de subirlo a producción.

Interpretando los resultados

Importante: PageSpeed Insights muestra dos tipos de datos:

• Campo (CrUX): Datos reales de usuarios de Chrome en tu sitio, la base pública donde Google guarda estas métricas para millones de sitios. Son los que le importan a Google para el ranking.
• Lab: Simulación. Útil para diagnóstico, pero no es lo que rankea.

Si tu sitio es nuevo o tiene poco tráfico, es normal que PageSpeed Insights todavía no muestre datos de campo. En ese caso, el dato de laboratorio es la única referencia disponible hasta que el sitio acumule tráfico real.

Errores comunes que arruinan tus Core Web Vitals

Después de auditar sitios de empresas chilenas de tamaños distintos, los mismos errores se repiten una y otra vez:

• Subir imágenes directo desde el celular o la cámara. Fotos de varios megabytes que el navegador tiene que descargar completas antes de mostrar nada. Casi siempre son el primer sospechoso de un LCP alto.
• Instalar un plugin de “optimización” por cada problema. En WordPress es habitual terminar con cinco o seis plugins de caché, compresión y seguridad que se pisan entre ellos y suman más peso del que ahorran.
• Dejar activos scripts de agencias anteriores. Píxeles duplicados, heatmaps que nadie revisa, chats en vivo sin uso hace meses. Cada uno compite por el hilo principal del navegador.
• No definir el tamaño de las imágenes en el HTML. Sin width y height, el navegador no sabe cuánto espacio reservar y el layout salta cuando la imagen termina de cargar.
• Cargar fuentes personalizadas sin optimizar. Cada fuente adicional es una petición de red más antes de que el texto se vea con su tipografía final.
• Confundir “se ve rápido en mi computador” con “es rápido para mis clientes.” Tu notebook potente y tu wifi de oficina no representan a alguien navegando en el metro con datos móviles y un celular de gama media.

Ninguno de estos errores requiere rehacer el sitio completo. Se corrigen uno por uno, y cada corrección se refleja casi de inmediato en PageSpeed Insights.

Escenario ilustrativo: un WordPress típico que puntúa 45

El caso más frecuente en Chile es un sitio WordPress con plugins de caché mal configurados, imágenes sin comprimir y dos o tres scripts de analytics acumulados de distintas agencias. Así se ve el diagnóstico y así se corrige.

Problemas habituales:

• LCP de 7.2 segundos (imagen hero sin width/height definidos)
• CLS de 0.34 (fuentes cargando con FOUT, iframe de formulario sin dimensiones)
• INP alto por JavaScript de un plugin de cookies

Cómo se corrige, en orden:

1. Migrar a un stack que no envíe JavaScript por defecto (Astro, por ejemplo)
2. Servir imágenes con width/height estáticos + lazy loading
3. Self-hostear las fuentes (Inter Variable u otra) en vez de pedirlas a un tercero
4. Eliminar los scripts que nadie está usando
5. Precargar los recursos críticos

Con esas cinco correcciones un sitio en ese estado normalmente sale de “deficiente” en las tres métricas. Cuánto sube el puntaje exacto depende del punto de partida, y el efecto en posiciones y ventas depende además de tu competencia y de tu contenido: la velocidad quita un freno, no reemplaza al resto.

Es el mismo patrón del eCommerce: cuando el sitio deja de competir contra su propio código, tráfico orgánico y conversión dejan de estar limitados por la carga. Lo profundizamos en nuestra guía de velocidad de carga y conversión en eCommerce.

Las mejoras más impactantes (priorizadas)

Si tienes que priorizar, en este orden:

1. Optimizar imágenes: Formato AVIF/WebP, compresión, width/height estáticos. Es la mejora con mejor relación esfuerzo/resultado: en la mayoría de los sitios el LCP baja de forma notoria solo con esto.
2. Eliminar render-blocking resources: Scripts que bloquean el render antes de que aparezca contenido. Muchos se pueden cargar en diferido (defer o async) sin perder funcionalidad.
3. Cargar fuentes correctamente: Font-display: swap + self-hosting. Evita depender de un servidor externo de fuentes que puede ser lento o estar caído justo cuando un cliente visita tu sitio.
4. Revisar servidor: Si el TTFB (Time To First Byte) es > 600ms, el problema está en el servidor, no en el frontend. Un hosting compartido saturado o sin CDN suele ser la causa.
5. Simplificar el stack: Cada plugin, widget y script externo tiene un costo. Antes de agregar una herramienta nueva, pregúntate si de verdad la necesitas.

Cómo priorizar según el tipo de sitio que tienes

No todos los sitios tienen el mismo cuello de botella:

• Sitio corporativo o landing page: normalmente el problema es acumulación — años de plugins, scripts de agencias distintas e imágenes sin optimizar. Aquí la limpieza (eliminar lo que no se usa) rinde más rápido que cualquier otra cosa.
• Blog o sitio de contenido: el enemigo suele ser el CLS, por anuncios, videos embebidos o imágenes dentro de los artículos sin dimensiones fijas. Vale la pena revisar plantilla por plantilla, no solo la home.
• Tienda online (eCommerce): el LCP en la ficha de producto es el que más pesa en la conversión, porque es la página que más tráfico pagado recibe. Si tu negocio vive de la tienda, este es territorio aparte — lo desarrollamos con más detalle en nuestra guía de velocidad de carga y conversión en eCommerce.

El stack técnico también importa: en WordPress con muchos plugins mejoras bastante con limpieza, pero chocas con un techo, porque cada plugin agrega JavaScript que no controlas del todo. Si estás evaluando reconstruir de cero, los frameworks que generan HTML estático como Astro parten con ventaja estructural frente a stacks que envían mucho JavaScript por defecto — comparamos las opciones en Astro vs Next.js: la mejor opción en 2026.

Cuándo Core Web Vitals no es tu prioridad número uno

Mejorar estas métricas no siempre es lo primero que hay que hacer. Tiene sentido postergarlo si:

• Tu sitio casi no recibe tráfico orgánico. Si Search Console muestra pocas impresiones y clics, el problema de fondo suele ser de contenido o de palabras clave, no de velocidad. Revisar primero tu estrategia de SEO local suele tener más impacto en ese escenario.
• Tu sitio ya está en zona verde en las tres métricas. Perseguir la perfección — pasar de 95 a 100 en Lighthouse — casi nunca se traduce en más ventas. El retorno decreciente aparece rápido una vez que sales de la zona roja o amarilla.
• Tienes un problema de conversión más grave y evidente, como un formulario que no funciona o una propuesta de valor confusa. Un sitio rápido con un mensaje que no convence sigue sin vender.

La regla práctica: si tus métricas están en rojo o amarillo, corrígelas primero — el retorno es alto y barato. Si ya están en verde, dirige el esfuerzo a tráfico y conversión, no a exprimir el último punto de Lighthouse.

El ROI del performance

La ecuación es simple: mejor Core Web Vitals → mejor ranking → más tráfico orgánico → más ventas sin gastar en ads.

Para un sitio con 1.000 visitas/mes y tasa de conversión del 2%, subir de la posición 10 a la posición 3 en una keyword importante puede triplicar el tráfico. Con la misma tasa de conversión, son 60 leads más al mes.

Y a diferencia de subir el presupuesto de publicidad, esta mejora es acumulativa: una vez que el sitio queda rápido, sigue rindiendo mes a mes sin que tengas que volver a pagarla.

¿Quieres saber cómo está tu sitio? Pedimos un diagnóstico gratuito y te entregamos un informe detallado con prioridades claras. Cada sitio que construimos en Web y eCommerce sale con estas métricas resueltas desde el día uno, no como un ajuste posterior.