Guía· Técnica

Velocidad web y Core Web Vitals: lo que cuenta para vender

Una web rápida es una web cuya página principal se muestra en menos de 2,5 s, responde al dedo en menos de 200 ms y no se mueve durante la carga: son los tres umbrales de las Core Web Vitals de Google. Cuentan para el posicionamiento, pero sobre todo cuentan para el comprador con prisa que navega desde el móvil. Así se miden y esto es lo que hay que corregir primero.

Autor
Redacción de FindMyCompany
Publicado el
Lectura
6 min

En cifras

2,5 s

LCP: visualización del contenido principal

Umbral bueno según Google

INP: respuesta a una interacciónUmbral bueno según Google
200 ms
CLS: estabilidad visualUmbral bueno según Google
0,1
de las visitas de nuestras webs que venden se hacen desde el móvilOctubre de 2026
61 %
Umbrales: web.dev (Google), medidos en el percentil 75 de las cargas. Proporción móvil: Google Analytics 4 de nuestras propias webs, FindMyCompany.
Índice 8 apartados

Por qué la velocidad se paga en ventas

En Francia, «Core Web Vitals» se busca 1000 veces al mes, «temps de chargement» (tiempo de carga) 210 veces y «vitesse site internet» (velocidad web) 170 veces. La pregunta detrás de estas búsquedas es siempre la misma: ¿pierde clientes mi web porque es lenta?

Un estudio encargado por Google a Deloitte en 2020 («Milliseconds Make Millions», 37 marcas europeas y estadounidenses, sin revisión por pares) observó en las webs de comercio un aumento del 8,4 % de las conversiones y del 9,2 % del ticket medio por cada décima de segundo ganada en el móvil. Toma estas cifras por lo que son: una correlación medida por una parte interesada. El sentido, en cambio, no se discute.

El móvil es el terreno donde se decide: en nuestras propias webs que venden, el 61 % de las visitas medidas se hace desde el teléfono, a menudo con 4G, con un pulgar y poca paciencia.

Las tres Core Web Vitals, en claro

Google mide tres señales con visitantes reales (datos de Chrome) y considera buena una página cuando sus cargas superan el umbral en el percentil 75.

  1. LCP (Largest Contentful Paint): el tiempo que tarda en mostrarse el elemento visible más grande, a menudo la foto del producto o el título. Umbral bueno: 2,5 s.
  2. INP (Interaction to Next Paint): el tiempo entre un gesto (tocar un botón, abrir un menú, elegir una talla) y la respuesta en pantalla. Umbral bueno: 200 ms.
  3. CLS (Cumulative Layout Shift): el desplazamiento de los elementos durante la carga, el que te hace tocar el botón equivocado. Umbral bueno: 0,1 o menos.

Medir sin equivocarse

Hay dos tipos de mediciones, y confundirlas hace perder tiempo.

  • Los datos de campo: lo que viven tus visitantes reales, en 28 días. Aparecen en el informe «Métricas web principales» de Search Console y en la parte superior de PageSpeed Insights cuando la web tiene suficiente tráfico. Son los que usa Google.
  • Los datos de laboratorio: una prueba simulada, en el momento en que la lanzas (la puntuación sobre 100 de PageSpeed Insights, Lighthouse). Útil para encontrar las causas, engañosa para juzgar: un 60 en laboratorio puede esconder datos de campo en verde, y al revés.
  • Prueba desde una red y un dispositivo realistas: un móvil de gama media con 4G, no el ordenador de la oficina con fibra.
  • Mide las páginas que venden (ficha de producto, página de servicio, pago), no solo la portada.

Lo primero que hay que corregir: las imágenes

En una tienda, la foto del producto es casi siempre el elemento del LCP, y a menudo el más pesado de la página. El formato WebP ahorra peso sin pérdida visible: según Google, una imagen WebP con pérdida es un 25 a 34 % más ligera que un JPEG de calidad comparable, y una imagen WebP sin pérdida un 26 % más ligera que un PNG.

  1. El formato adecuado: WebP (o AVIF) para las fotos, SVG para los logotipos y los iconos.
  2. El tamaño adecuado: una imagen que se muestra a 600 píxeles de ancho no tiene por qué medir 4000. Sirve varios tamaños con srcset y deja que el navegador elija.
  3. Las dimensiones declaradas: width y height en cada imagen, para que la página reserve el espacio y no se mueva (CLS).
  4. La carga diferida para las imágenes por debajo de la línea de flotación (loading=«lazy»), nunca para la imagen principal de la parte superior, que al contrario debe tener prioridad (fetchpriority=«high»).

Después: los scripts y las extensiones

Después de las imágenes, lo que más ralentiza son los scripts de terceros: widgets de chat, ventanas emergentes, carruseles, píxeles publicitarios, extensiones del tema acumuladas con los años. Cada uno añade código que descargar y ejecutar, y empeora sobre todo el INP.

  1. Hacer inventario: enumera cada script de terceros y lo que aporta. Una herramienta que nadie consulta se quita.
  2. Diferir: carga después de mostrar la página todo lo que no es necesario para la compra (chat, vídeos, widgets de opiniones).
  3. Aligerar el tema: un tema que carga un deslizador, tres fuentes y una librería de animaciones en cada página pesa sobre toda la web.
  4. Fuentes: dos familias como máximo, en formato WOFF2, con font-display: swap.
  5. Caché y CDN: archivos estáticos en caché durante mucho tiempo, servidos desde una red cercana al visitante.

El proceso de compra, donde cada segundo cuesta

La velocidad de la portada se mide en todas partes; la del proceso de compra se olvida a menudo. Y es ahí donde espera el comprador decidido: añadir al carrito, abrir el carrito, página de pago. Un botón que tarda un segundo en responder hace dudar, y un comprador que duda pulsa dos veces o se va.

Tres reflejos. El botón de compra responde al instante, aunque el proceso tarde un poco (un estado «procesando» visible). El pago pasa por una página alojada por el proveedor de pagos, rápida y ya conocida por los compradores, en lugar de un formulario propio cargado de scripts. Y nada se interpone: ninguna ventana de suscripción a la newsletter entre el carrito y el pago.

El plan en una semana

  1. Día 1: revisa el informe Métricas web principales de Search Console, primero en móvil, y anota los grupos de URL en naranja o en rojo.
  2. Día 2: pasa tres páginas tipo (portada, ficha o servicio, pago) por PageSpeed Insights y anota el elemento del LCP de cada una.
  3. Día 3: convierte y redimensiona las imágenes de esas plantillas y declara sus dimensiones.
  4. Día 4: quita o difiere los scripts de terceros innecesarios.
  5. Día 5: vuelve a probar en laboratorio y espera a que se actualicen los datos de campo (cubren 28 días) antes de juzgar.

Preguntas frecuentes

¿Cuál es un buen tiempo de carga?

Google se fija en el LCP: un umbral bueno es 2,5 s o menos para mostrar el contenido principal, medido en el percentil 75 de las cargas de tus visitantes reales.

¿Cómo se mide la velocidad de una web?

Pasa tus páginas tipo (portada, ficha de producto o página de servicio, pago) por PageSpeed Insights, la herramienta gratuita de Google. Lee primero los datos de campo de la parte superior del informe, cuando tu web tenga suficientes visitas, y después el diagnóstico de laboratorio para encontrar las causas. El informe «Métricas web principales» de Search Console sigue después toda la web.

¿Cuenta para Google la puntuación de PageSpeed sobre 100?

No, es una prueba de laboratorio. Google usa los datos de campo (Core Web Vitals) de tus visitantes reales, visibles en Search Console.

¿Una web rápida adelanta a las demás?

No por sí sola. Google indica que las Core Web Vitals se usan en el posicionamiento, pero que una buena puntuación no garantiza una buena posición: primero va la relevancia del contenido.

¿Hay que cambiar de hosting?

Rara vez como primer paso. Las imágenes y los scripts de terceros explican la mayoría de las lentitudes; el hosting cuenta cuando el servidor tarda mucho en responder antes incluso de enviar la página.

Fuentes

Auditoría gratuita

¿Pierde tu web compradores en el móvil?

Móvil, HTTPS, imágenes, contenido: la auditoría gratuita comprueba las bases técnicas de tu portada en 30 segundos.

Gratis30 segundossin compromiso