Cuánto importa el rendimiento de tu tienda en línea

Una décima de segundo. Eso fue lo que movió la conversión de retail un 8,4% en el estudio que Deloitte hizo junto a Google y la agencia 55, midiendo 30 millones de sesiones reales en 37 marcas de Europa y Estados Unidos. En el mismo experimento, el valor del pedido promedio subió 9,2% y el paso de la ficha de producto al carrito, 9,1%. Nadie rediseñó nada durante ese periodo: solo se midió la velocidad hora a hora durante treinta días.

Ese número incomoda porque contradice cómo se presupuesta el rendimiento en la mayoría de las tiendas, que lo tratan como mantenimiento técnico y lo dejan para cuando haya tiempo. El rendimiento se compra y se cobra como cualquier otra inversión en ventas, con un precio que ya está medido. Y casi todo el mundo lo mide mal: mira un puntaje de laboratorio que Google no usa para posicionar, mientras el dato que sí cuenta, el de sus visitantes reales, va por otro lado.

1. ¿Qué le pasa a un cliente cuando tu tienda tarda?

Se va antes de ver el producto, y la probabilidad crece rápido. La investigación de Google con SOASTA, de 2017, calculó que cuando el tiempo de carga pasa de 1 a 3 segundos, la probabilidad de rebote sube 32%. De 1 a 5 segundos sube 90%. De 1 a 6 segundos, 106%. De 1 a 10 segundos, 123%. El salto más caro está en los primeros dos segundos, justo donde casi nadie mira.

Portent midió el otro lado de la misma moneda con más de 100 millones de páginas vistas. En comercio electrónico, los sitios que cargaban en un segundo convertían al 3,05%; en dos segundos, al 1,68%; en tres, al 1,12%; en cuatro, al 0,67%. Un sitio de un segundo convierte 2,5 veces más que uno de cinco.

Detrás de esos números no hay impaciencia. Alguien que espera está pagando con atención, y esa espera se lee como señal de calidad del negocio. Una tienda lenta se percibe como una tienda descuidada, y la sospecha llega justo antes de escribir el número de la tarjeta. Lo peor es que esa venta no aparece en ningún reporte, porque el cliente nunca llegó a intentarla.

2. ¿Qué mide Google exactamente?

Tres métricas, agrupadas bajo el nombre de Core Web Vitals, medidas en el percentil 75 de tus visitas. Ese percentil importa: no te califica el visitante promedio, sino el que está peor que tres cuartas partes de tu tráfico. Un sitio que funciona bien en fibra y mal en 4G reprueba, aunque el promedio se vea decente.

El LCP, o Largest Contentful Paint, mide cuándo termina de pintarse el elemento más grande de la primera pantalla. Bueno es 2,5 segundos o menos. El INP, o Interaction to Next Paint, mide cuánto tarda la página en responder visualmente cuando alguien toca algo: bueno es 200 milisegundos o menos. El CLS, o Cumulative Layout Shift, mide cuánto se mueve el contenido mientras carga, y bueno es 0,1 o menos.

Si tenías anotado el FID, bórralo. Dejó de ser Core Web Vital el 12 de marzo de 2024, cuando el INP lo reemplazó formalmente. La diferencia importa: el FID solo medía la primera interacción y solo su retraso inicial, mientras el INP mira casi todas las interacciones de la visita y cuenta hasta que la pantalla realmente cambia.

3. ¿Por qué el score de PageSpeed no es la nota que cuenta?

Porque Google no posiciona con ese número. Hay dos tipos de datos en la misma pantalla y se confunden todo el tiempo. Arriba están los datos de campo, recogidos de usuarios reales de Chrome a través del Chrome UX Report, sobre una ventana móvil de 28 días. Abajo está el análisis de Lighthouse, una simulación de laboratorio con una red y un dispositivo emulados. La documentación de Chrome dice explícitamente que el Chrome UX Report es lo que alimenta el factor de ranking de experiencia de página.

La propia documentación de PageSpeed Insights lo advierte sin rodeos: “tener buenos datos de laboratorio no significa necesariamente que las experiencias de usuarios reales también sean buenas”. Pasa seguido en tiendas con clientes en zonas de red irregular o con teléfonos de gama media, donde el laboratorio dice 92 y la gente real está esperando cuatro segundos.

Entonces, ¿para qué sirve Lighthouse? Para diagnosticar, y en eso es excelente. Es la herramienta que te dice qué imagen pesa de más y qué script está bloqueando el hilo principal. Úsala como radiografía.

Con eso en la mano, cuando alguien te venda “subimos tu score a 100” ya sabes qué preguntar: qué pasó con los datos de campo.

4. ¿Sigue siendo el rendimiento un factor de posicionamiento?

Google lo sostiene por escrito, en una página que actualizó en diciembre de 2025. La documentación de Search Central mantiene la frase: “Los Core Web Vitals son usados por nuestros sistemas de ranking”. La misma página aclara que no existe una única señal de experiencia de página, y que sus sistemas miran una variedad de señales. Lo que Google añade después marca el límite: obtener buenos resultados en los informes de Search Console o en herramientas de terceros no garantiza que tus páginas aparezcan arriba, y perseguir un score perfecto solo por SEO puede no ser el mejor uso de tu tiempo. En castellano llano, el rendimiento es un factor real entre varios, y una tienda rapidísima con contenido pobre sigue sin rankear.

Para una tienda hay un ángulo comercial que suele pesar más que el ranking. Una tienda lenta paga más caro cada visita comprada, porque parte del clic se pierde antes de que la página aparezca y el tráfico pagado se cobra igual.

5. ¿Qué rompe el LCP en una tienda y cómo se arregla?

Es una imagen en el 85,3% de las páginas de escritorio y en el 76% de las móviles, según el Web Almanac 2025 del HTTP Archive. En una tienda en línea eso significa el banner de portada o la foto principal del producto, justo la pieza que el diseño trata como intocable.

El LCP se descompone en cuatro partes que web.dev define sin huecos entre ellas: el tiempo hasta el primer byte, el retraso hasta que empieza a cargar el recurso, lo que tarda en descargarse y el retraso hasta que se pinta. La guía orientativa reparte alrededor del 40% al primer byte, menos del 10% al retraso de carga, cerca del 40% a la descarga y menos del 10% al pintado. No son reglas estrictas, y el propio web.dev advierte que si tu LCP ya está bajo 2,5 segundos, las proporciones dan igual. Sirven para saber dónde mirar.

Los arreglos que más rinden en tiendas son poco glamorosos. Sirve la imagen principal en formato moderno y en el tamaño que realmente ocupa en pantalla, en vez de una foto de 3000 píxeles reducida por CSS. Quítale el lazy loading a esa imagen: suena a optimización y en ese lugar concreto es un freno. Declárala con prioridad alta para que el navegador la pida antes que los scripts de terceros. Y si el texto es lo más grande de la primera pantalla, precarga la fuente del título.

6. ¿Qué está detrás de un INP malo?

JavaScript ocupando el hilo principal cuando el cliente quiere hacer algo. El INP mide tres tramos: el retraso hasta que empieza a ejecutarse el código de la interacción, lo que tarda ese código, y el tiempo hasta que el navegador pinta el resultado. Basta con que una tarea larga esté corriendo para que el primer tramo se dispare, aunque tu código propio sea eficiente.

El móvil se cae justo aquí. En los datos del Web Almanac 2025, el 97% de los sitios de escritorio tiene INP bueno, contra un 77% en móvil. Un teléfono de gama media tarda varias veces más que una laptop en interpretar el mismo JavaScript, y en una tienda ese código suele venir del carrito lateral, el buscador con sugerencias, los filtros de colección y el chat de soporte.

El síntoma que el dueño de la tienda reconoce es concreto. Tocas “agregar al carrito” y no pasa nada durante un instante largo, así que tocas otra vez, y terminan dos unidades en el carrito o un mensaje de error.

Lo mismo pasa con el filtro de talla que tarda en marcarse o el menú que se abre tarde, y en ninguno de esos casos el cliente piensa “qué mal está el JavaScript de esta tienda”. Piensa que la tienda no funciona.

7. ¿Y el CLS, el que hace saltar la página?

El CLS mide cuánto se mueve el contenido visible mientras carga, y es el más fácil de reproducir en casa. Abre tu tienda en el teléfono, ve a tocar un producto y fíjate si en el último momento entra un banner arriba y te manda el dedo a otro lado. Eso es CLS, y Google lo agrupa en ventanas de sesión: ráfagas de saltos separadas por menos de un segundo, con un máximo de cinco segundos por ventana.

Las causas que documenta web.dev se repiten idénticas en las tiendas. Imágenes y videos sin dimensiones declaradas, que reservan cero espacio hasta que llegan. Anuncios, widgets y elementos de terceros que se redimensionan solos. Fuentes que al cargar quedan más grandes o más pequeñas que la de respaldo y recolocan el texto.

A esa lista se le suma todo lo que se inyecta arriba del contenido, que en una tienda es bastante: la barra de envío gratis, el aviso de cookies, el cartel de descuento, la advertencia de stock bajo.

La solución casi siempre es reservar el espacio por adelantado. Ancho y alto declarados en cada imagen, y un contenedor con altura fija para el banner promocional. Ajusta además la fuente de respaldo para que ocupe lo mismo que la definitiva.

8. ¿Cuánto te está costando cada app instalada?

Cada app que instalas suele traer scripts que se cargan en todas las páginas, incluso cuando su función vive en una sola. El widget de reseñas se carga en el carrito. El chat se carga en la página de gracias. El paquete de píxeles de marketing se carga siempre. Y como el efecto es acumulativo y silencioso, la tienda se degrada sin que ningún día parezca el culpable.

Las cifras que circulan sobre esto no aguantan un examen. Verás mucho “cada app añade entre 200 y 500 milisegundos”, pero ese número solo aparece en blogs de empresas que venden optimización, sin metodología ni fuente detrás. Lo que sí está medido es el contexto: el Web Almanac 2025 documenta que el 90% o más de las páginas carga al menos un tercero, y que entre los mil sitios más grandes la mediana ronda las 129 peticiones a terceros en escritorio y 106 en móvil.

El inventario honesto es un ejercicio de una tarde. Lista cada app instalada, escribe al lado qué ingreso o qué ahorro genera, y mide la tienda antes y después de desinstalar las que no tengan respuesta. Un detalle que cuesta ventas: desactivar una app no siempre elimina su código del tema, porque muchas dejan fragmentos incrustados que siguen cargando. Eso hay que quitarlo a mano, y es parte del trabajo que hacemos cuando auditamos una tienda en Shopify.

9. ¿Qué exige la plataforma y qué queda de tu lado?

La plataforma te da un piso, y el techo lo pones tú. Shopify, por ejemplo, exige que un tema tenga al menos 60 de puntaje promedio en Lighthouse para entrar a su Theme Store, medido sobre la portada, una página de producto y una de colección, con un límite de 16 KB para el bundle de JavaScript minificado. Es un requisito para el tema en limpio, antes de que le montes encima tus apps, tu contenido y tus scripts.

Hay una distinción aquí que confunde a mucha gente. El informe de velocidad que ves en el panel de Shopify no usa Lighthouse: se calcula con datos de usuarios reales de tu portada, tu producto más visitado y tu colección más visitada de los últimos 7 días, y reporta los Core Web Vitals en el percentil 75. El requisito de la tienda de temas y tu informe de velocidad miden cosas distintas, así que compararlos no te dice nada.

Lo que queda de tu lado es casi todo lo que se degrada con el tiempo. Las imágenes que alguien sube desde el celular sin optimizar, el video de fondo que pesa doce megas, los scripts de analítica que nadie revisa desde hace un año, las secciones que se fueron acumulando en la portada. Un tema rápido con una tienda mal mantenida encima da un sitio lento, y es el caso más común que nos llega.

10. ¿Cuánto se puede ganar de verdad? Los casos con números

La evidencia más limpia viene de pruebas A/B donde lo único que cambió fue la velocidad. Vodafone Italia sirvió a la mitad de sus visitantes una versión con mejor LCP, idéntica en diseño y funciones a la otra, con unos 100 mil clics diarios por variante. La versión rápida, con un LCP 31% mejor, vendió 8% más y mejoró la relación de visita a carrito un 11%. Al haber una sola variable en juego, ahí la velocidad no correlaciona con las ventas: las causa.

Rakuten 24, la tienda japonesa, hizo el mismo tipo de prueba durante un mes optimizando sus Core Web Vitals. El ingreso por visitante subió 53,37%, la conversión 33,13% y el valor del pedido promedio 15,20%, mientras la tasa de salida bajó 35,12%. Es el caso puro de comercio electrónico más fuerte publicado en web.dev.

Agrofy, el marketplace argentino de agronegocios, mejoró su LCP un 70% y su CLS un 72%, y el abandono durante la carga cayó del 3,8% al 0,9%. Ese último número es el más elocuente del conjunto: tres cuartas partes de la gente que se iba antes de que la página terminara de aparecer se quedó, sin que nadie tocara el catálogo ni los precios.

Ahora, una advertencia de honestidad sobre estas cifras. Son tiendas grandes que partían de un problema grave, y una mejora del 53% en ingreso por visitante presupone un sitio bastante roto de entrada. Si tu tienda ya carga en dos segundos, tu margen se parece más al 8% de Vodafone que al 53% de Rakuten. Sigue siendo dinero que no estás cobrando, pero conviene ir con la expectativa calibrada.

11. ¿Cómo mides el rendimiento sin engañarte?

Empieza por los datos de campo y deja el laboratorio para después. Los datos de campo son de tus visitantes reales con sus teléfonos y sus redes, y se calculan sobre una ventana móvil de 28 días, lo que tiene una consecuencia práctica: un arreglo publicado hoy tarda semanas en verse completo, y juzgarlo a los tres días no dice nada.

Mide siempre por tipo de página y por dispositivo. La portada, la página de producto y la de colección tienen problemas distintos, y el promedio de las tres esconde justo el que te está costando dinero. Lo mismo con el móvil: mezclarlo con el escritorio tapa la brecha, y esa brecha existe en todo el web. En el Web Almanac 2025, el 56% de los sitios de escritorio pasa los Core Web Vitals frente al 48% de los móviles.

Esa mitad reprobada es tu referencia real: estar en verde ya te pone en la parte buena de la web. El objetivo razonable es cruzar los umbrales y quedarte ahí. Un 100 no le cambia la vida a ningún cliente.

Y mide una cosa a la vez: si el mismo día cambias el tema e instalas dos apps, el número se mueve sin que sepas por qué.

Por dónde empezar

Para una tienda que ya está andando hay dos arreglos que rinden desde la primera semana: mirar los datos de campo en móvil antes que cualquier puntaje, y arreglar la imagen principal de la portada y de la ficha de producto. Ninguno de los dos exige rediseñar nada.

El inventario de apps viene después, y es el más incómodo, porque obliga a defender cada una con un número. También es donde solemos encontrar el margen más grande.

Luego está el trabajo de fondo, que rinde más pero pide constancia: reservar el espacio de todo lo que carga tarde para matar el CLS, y adelgazar el JavaScript que retrasa el carrito y el buscador. Y volver a medir cada vez que la tienda cambie, que es lo que casi nunca ocurre y explica por qué una tienda optimizada hace un año hoy vuelve a estar lenta.

Si quieres saber qué te está costando hoy la velocidad de tu tienda, medimos tus datos de campo y te decimos dónde está la fuga antes de tocar nada. Escríbenos y lo revisamos juntos.

Preguntas frecuentes

¿Cuánto afecta la velocidad a las ventas de una tienda en línea?

Está medido. El estudio de Deloitte con Google y la agencia 55, sobre 30 millones de sesiones en 37 marcas, encontró que una mejora de 0,1 segundos subió la conversión de retail un 8,4% y el valor del pedido promedio un 9,2%. En viajes la conversión subió 10,1%. Son décimas de segundo con efecto directo en ingresos.

¿Qué son los Core Web Vitals y cuáles son los valores buenos?

Son las tres métricas con las que Google mide la experiencia de carga de una página. LCP mide cuánto tarda en aparecer el contenido principal y debe quedar bajo 2,5 segundos. INP mide qué tan rápido responde la página al tocarla y debe estar bajo 200 milisegundos. CLS mide cuánto salta el diseño mientras carga y debe estar bajo 0,1.

¿El score de Lighthouse o de PageSpeed Insights afecta mi posición en Google?

No directamente. Google usa datos de usuarios reales recogidos por el Chrome UX Report, no el score de laboratorio que ves arriba en Lighthouse. La documentación de PageSpeed Insights lo dice claro: tener buenos datos de laboratorio no garantiza que la experiencia real de los usuarios también sea buena. El score sirve para diagnosticar, no para calificarte.

¿Sigue siendo el rendimiento un factor de posicionamiento en 2026?

Sí. Google Search Central lo mantiene por escrito: los Core Web Vitals son usados por sus sistemas de ranking. Al mismo tiempo aclara que sacar un score perfecto solo por SEO no suele ser el mejor uso de tu tiempo, porque hay más en juego que esas tres métricas. Es un factor real, no el principal.

¿Por qué mi tienda va bien en la computadora y mal en el teléfono?

Porque son condiciones distintas. Según el Web Almanac 2025 del HTTP Archive, el 56% de los sitios de escritorio pasa los Core Web Vitals frente a solo el 48% en móvil, y la brecha en INP es enorme: 97% de sitios buenos en escritorio contra 77% en móvil. El teléfono tiene menos procesador y peor red.

¿Qué es el LCP y cómo lo mejoro?

El LCP mide cuándo termina de pintarse el elemento más grande de la pantalla inicial. En el 76% de las páginas móviles ese elemento es una imagen, según el HTTP Archive, así que casi siempre se arregla ahí: formato moderno, tamaño correcto para cada pantalla, carga prioritaria y sin lazy loading en la imagen principal.

¿Las apps que instalo en mi tienda la hacen más lenta?

Cada app suele añadir scripts que cargan en todas las páginas, aunque su función viva en una sola. No existe una cifra oficial de cuántos milisegundos cuesta cada una, y desconfía de quien te la dé. Lo que sí puedes hacer es medir tu tienda antes y después de instalar, y desinstalar de verdad lo que dejaste de usar.

¿Cada cuánto debería revisar el rendimiento de mi tienda?

Una revisión mensual del informe de datos reales basta para una tienda estable, y una medición extra cada vez que instales una app, cambies el tema o agregues un script de marketing. Los datos de campo se calculan sobre una ventana móvil de 28 días, así que un cambio tarda semanas en reflejarse completo.