Core Web Vitals y velocidad: cuánto te cuesta cada segundo de carga - PangoStudio

Core Web Vitals y velocidad: cuánto te cuesta cada segundo de carga

Conoces la sensación: la inversión en tráfico va bien, las campañas traen visitas, el catálogo está cuidado… y la tasa de conversión no se mueve. Antes de tocar el embudo otra vez, hazte una pregunta menos glamurosa: ¿cuánto tarda en cargar tu tienda? Porque cada segundo de espera no es un detalle técnico que vive en el panel del desarrollador. Es dinero que se cae del carrito antes de que el cliente llegue a verlo.

Esta guía va de eso: del impacto real de la velocidad y los Core Web Vitals en lo que vendes, de qué medir exactamente (sin perderte en métricas que no mueven la aguja) y de cómo mejorar el rendimiento web de una tienda online —con foco en Shopify, donde casi siempre el problema es el mismo puñado de cosas.

El problema: pagas por el tráfico dos veces

Tú ya pagas por traer a la gente a la tienda. Lo que casi nadie contabiliza es que una web lenta te hace pagar otra vez, en forma de visitas que se van antes de convertir. Y los números son brutales.

Según un estudio de Deloitte y Google sobre 37 grandes retailers, cada 0,1 segundos de mejora en la carga aumenta las conversiones un 8 % en retail. Al revés funciona igual de bien: un solo segundo de retraso puede costar hasta un 20 % de las conversiones en móvil (Portent, estudio de velocidad y conversión).

El abandono es todavía más despiadado. Google reporta que el 53 % de las visitas móviles se abandonan si la página tarda más de 3 segundos en cargar. Si tu tienda pasa de 4 segundos, el 63 % de los compradores se va (We Are Tenet, estadísticas de tiempo de carga). Ese tráfico ya lo habías comprado. Y se evapora en la pantalla en blanco.

Si te parece que solo afecta a los gigantes, mira la asimetría: una web que carga en menos de 2 segundos convierte de media un 3,05 %, frente a un 1,94 % cuando tarda entre 3 y 4 segundos. Es un 57 % más de conversión por ir un segundo más rápido, sin tocar precio, producto ni creatividad (BTNG Studio).

Walmart lo midió a su escala: por cada segundo de mejora en la carga, hasta un 2 % más de conversiones; por cada 100 ms, hasta un 1 % más de ingresos (WPO Stats). Ojo a la comparación: Walmart midió ingresos a volumen de gran retail y el estudio de conversión de tienda media mide otra cosa, con metodologías distintas. No son cifras directamente equiparables; lo que se repite caso tras caso es la dirección —más rápido, más conversión—, no el porcentaje exacto.

Por qué pasa: Google ya no se fía de tu cronómetro

Aquí entra la segunda mitad del problema, la que afecta al SEO. Google dejó de medir la velocidad con un número simplón hace años. Ahora usa los Core Web Vitals: tres métricas que intentan capturar cómo de buena es la experiencia real de carga para usuarios reales, no en tu MacBook con fibra, sino en el móvil de gama media de tu cliente con cobertura regular.

Y forman parte de la señal de posicionamiento. No son el factor dominante —el contenido y los enlaces siguen pesando más—, pero pasar las tres métricas se asocia a métricas de comportamiento mejores: las tiendas que las cumplen registran hasta un 24 % menos de rebote (corewebvitals.io). Menos rebote y mejor experiencia es exactamente lo que Google premia, directa e indirectamente. Es la misma lógica que aplica al resto del SEO técnico de un ecommerce: la nota la pone la experiencia del usuario, no tu panel.

La trampa habitual: confías en la nota de PageSpeed Insights del «laboratorio» y te sale 90. Pero Google posiciona con datos de campo: visitas reales de usuarios reales, recogidas en el informe CrUX. Tu nota de laboratorio puede ser excelente y tus Core Web Vitals de campo, un desastre. ¿Dónde lees el campo? En Search Console, en su informe de Core Web Vitals, y en la franja superior de PageSpeed Insights (la que dice «datos de los últimos 28 días»), no en la nota grande de colores. Mide siempre los dos.

Qué medir: las tres métricas, en cristiano

Olvida las cincuenta cosas que mide una auditoría. Para decidir si tu tienda va bien, te bastan estas tres, medidas en el percentil 75 de tus usuarios (es decir, que el 75 % de las visitas las cumpla), separando móvil y escritorio. Google usa el percentil 75 a propósito: si midiera la media, las visitas rapidísimas de quien tiene fibra y móvil de gama alta taparían el sufrimiento de la mayoría; el p75 te obliga a que la tienda vaya bien también para el cliente con conexión normal.

Métrica Qué mide Bien Mejorable Mal
LCP (Largest Contentful Paint) Cuánto tarda en pintarse el elemento grande principal (normalmente la imagen del producto o el hero) < 2,5 s 2,5–4 s > 4 s
INP (Interaction to Next Paint) Cuánto tarda la web en responder cuando el usuario toca, clica o escribe < 200 ms 200–500 ms > 500 ms
CLS (Cumulative Layout Shift) Cuánto «baila» la página mientras carga (el típico botón que se mueve justo al ir a pulsarlo) < 0,1 0,1–0,25 > 0,25
Columna «Bien» (valores con <) = en verde para Google. «Mejorable» = naranja. «Mal» (valores con >) = rojo, hay que actuar.

Son los umbrales oficiales de Google. El cambio más reciente: el 12 de marzo de 2024, INP sustituyó a FID como métrica de respuesta (web.dev, Web Vitals). FID (First Input Delay) solo medía el retraso hasta que el navegador empezaba a atender la primera interacción; INP es más exigente porque mide la interacción completa —desde que el usuario toca hasta que ve el resultado pintado en pantalla— y a lo largo de toda la visita, no solo en el primer clic. Traducido a tu negocio:

  • LCP malo = el cliente ve la pantalla a medio pintar y se pregunta si la tienda funciona.
  • INP malo = añade al carrito, no pasa nada visible, vuelve a pulsar, y se frustra.
  • CLS malo = va a pulsar «comprar», la página da un salto y pulsa otra cosa. Adiós a la confianza.

Para verlas: Google Search Console (informe de Core Web Vitals, con datos de campo de tu tienda real) y PageSpeed Insights para diagnosticar página a página. La primera te dice si tienes un problema; la segunda, dónde está.

Cómo se resuelve en Shopify (y dónde está casi siempre el cuello de botella)

La buena noticia de Shopify es que la infraestructura —servidores, CDN, checkout— ya es rápida y no la tocas tú. La mala es que casi todo lo que ralentiza una tienda Shopify lo has metido tú (o una agencia anterior) encima. Por orden de impacto real:

1. Las apps son el sospechoso número uno

Cada app que instalas suele inyectar su JavaScript y su CSS en todas las páginas, incluso donde no se usa. El dato es contundente: las tiendas con más de 8 scripts de apps de terceros tienen un LCP móvil mediano por encima de 3 segundos; las que se quedan en 3 o menos lo mantienen por debajo de 2 (corewebvitals.io, guía Shopify). Audita tus apps y desinstala las que no usas de verdad. Aquí va un matiz importante: desactivar una app no siempre basta. Muchos app builders dejan inyectado su CSS y su JavaScript aunque la función esté apagada; lo confirmas abriendo la pestaña «Network» de las herramientas de desarrollo del navegador y viendo qué dominios siguen cargando. Si no la usas de verdad, desinstálala. Y desconfía de cualquiera que prometa «mejorar la conversión» a base de añadir widgets.

2. Imágenes sin optimizar

La imagen del producto suele ser tu elemento LCP. Súbela ya comprimida y al tamaño correcto, deja que Shopify sirva formatos modernos (WebP) y aplica carga diferida (lazy loading) a todo lo que esté por debajo del pliegue. Una sola imagen de 4 MB en la ficha de producto puede arruinarte el LCP en móvil ella sola.

3. Layout shift: el CLS que se arregla con disciplina

El «baile» de la página viene de reservar mal el espacio: imágenes sin dimensiones declaradas, banners de cookies que empujan el contenido, fuentes web que cargan tarde y repintan el texto. Reservar el hueco de cada elemento antes de que cargue es trabajo de tema, no de app.

4. Tema e INP: el trabajo fino

Los temas modernos orientados a rendimiento (como Dawn y los basados en su arquitectura) parten de mejor base. Limita el número de fuentes web, apaga animaciones y carruseles que no aportan, y reduce el JavaScript que se ejecuta al interactuar —ahí se gana el INP—. Las optimizaciones serias (diferir scripts de terceros, precargar el recurso LCP, tocar Liquid con criterio) ya requieren manos de desarrollo, no un botón. Si tu tienda arrastra un tema heredado, muchas veces sale más a cuenta una migración de tema bien planteada que ir parcheando lo viejo.

Seamos honestos con el alcance: desinstalar apps inútiles y comprimir imágenes lo puedes hacer esta semana y notarás la diferencia. Llevar una tienda con apps pesadas y un tema heredado a pasar las tres métricas en verde es un proyecto de días de desarrollo, no una tarde. Quien te prometa los Core Web Vitals en verde «con un plugin» te está vendiendo humo.

El error de fondo: medir la nota, no el dinero

El fallo más común que vemos en responsables de ecommerce no es técnico: es perseguir el «100 en PageSpeed» como si fuera un trofeo. La nota de laboratorio no paga facturas. Lo que importa es el LCP de campo en la ficha de producto de tu superventas, el INP del botón de añadir al carrito y el CLS del checkout. Optimiza las páginas que venden, en el dispositivo en el que vende tu gente (el móvil, casi siempre), con datos reales.

Y cierra el círculo: mide la conversión antes y después. Si bajas el LCP de 4 a 2 segundos en las fichas y tu tasa de conversión móvil no se mueve nada en cuatro semanas, el cuello de botella estaba en otro sitio. La velocidad es una palanca enorme, pero solo una.

Resumen accionable

  1. Abre Search Console y mira tu informe de Core Web Vitals. Eso es tu línea base real.
  2. Pasa tus 3 plantillas clave (home, colección, producto) por PageSpeed Insights, en móvil.
  3. Audita apps: desinstala lo que no usas de verdad (y comprueba que no dejan código detrás).
  4. Comprime las imágenes de producto y activa carga diferida bajo el pliegue.
  5. Reserva el espacio de cada elemento para matar el CLS.
  6. Vuelve a medir conversión a las 4 semanas. Compara con la base.

Sigue leyendo

Lo medimos, lo arreglamos y te lo demostramos en la conversión

En Pango Studio auditamos el rendimiento web de tiendas Shopify a diario: separamos lo que se arregla en una tarde de lo que es proyecto, atacamos primero las páginas que más venden y medimos el antes y el después en lo único que importa —lo que ingresa la tienda—. Sabemos qué apps lastran sin aportar, dónde Shopify se queda corto y cómo dejar los Core Web Vitals en verde sin parches que se rompan al siguiente cambio de tema. Puedes ver cómo lo abordamos en nuestro servicio de optimización de rendimiento.

Si sospechas que la velocidad te está costando ventas, mándanos tu tienda y te decimos exactamente cuánto te cuesta cada segundo —y qué tocar primero para recuperarlo.

Hablar con Pango Studio →

Add comment: