Lo que te cuesta cada segundo que tarda tu ficha de producto
Pagas 0,45 € por clic en Meta para llevar tráfico a una ficha de producto. El anuncio funciona: el creativo es bueno, el CPC está contenido, el volumen entra. Y sin embargo el CPA no cuadra. Entonces revisas el creativo, cambias el copy, pruebas otro público, subes presupuesto. Nadie mira el eslabón que hay en medio: los cuatro segundos y medio que pasan entre el dedo del usuario y el momento en que la ficha es usable en un iPhone con 4G y la batería al 18 %.
Ese hueco no aparece en el panel de Meta ni en el de Google Ads. Y es donde se evapora una parte del dinero.
El clic que pagas y la sesión que recibes no son el mismo número
Coge el informe de la campaña del mes pasado y ponlo al lado del informe de adquisición de GA4. Los clics de la plataforma publicitaria y las sesiones atribuidas a esa fuente casi nunca coinciden. Una diferencia de entre el 10 % y el 30 % es habitual, y no toda es culpa de la velocidad: hay consentimiento de cookies, bloqueadores, redirecciones, clics accidentales, gente que abre y cierra sin querer.
Pero una parte sí es velocidad. Si el navegador tarda tres segundos en pintar algo reconocible, hay usuarios que se van antes de que el script de analítica llegue a dispararse. Ese usuario lo has pagado y no existe en ningún informe. No aparece como rebote: aparece como nada.
El agravante en tráfico social es que la mayoría llega por el navegador interno de Instagram o TikTok. Es un WebView: un navegador embebido dentro de la app, con menos caché reutilizable, a veces con menos recursos y casi siempre en una red peor que la de alguien sentado en su casa con el portátil. Tu tienda puede ir fina en tu Mac de la oficina e ir mal justo donde estás gastando el presupuesto.
Si tu tráfico de pago es mayoritariamente móvil y social, mide el rendimiento en móvil y con conexión limitada. El dato de escritorio, para esta conversación, no sirve de nada.
Las tres métricas que importan y una que puedes ignorar
Google publica un conjunto de métricas llamadas Core Web Vitals. Son tres y están razonablemente bien elegidas, porque miden lo que el usuario percibe, no lo que le pasa al servidor.
- LCP (Largest Contentful Paint): cuánto tarda en aparecer el elemento visual más grande de la parte visible. En una ficha de producto casi siempre es la foto principal. Es la métrica de "esto ya se ve".
- INP (Interaction to Next Paint): cuánto tarda la página en responder cuando el usuario toca algo. Sustituyó al antiguo FID en marzo de 2024. Es la métrica de "esto ya me hace caso". Si tocas el selector de talla y no pasa nada durante medio segundo, la gente lo vuelve a tocar, y ahí empiezan los pedidos raros y los abandonos.
- CLS (Cumulative Layout Shift): cuánto se mueve el contenido mientras carga. El clásico: vas a pulsar "Añadir al carrito", entra el banner de cookies o una imagen sin dimensiones reservadas, y acabas pulsando otra cosa.
| Métrica | Bien | Mejorable | Mal |
|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5–4 s | > 4 s |
| INP | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | ≤ 0,1 | 0,1–0,25 | > 0,25 |
| TTFB (auxiliar) | ≤ 0,8 s | 0,8–1,8 s | > 1,8 s |
La que puedes ignorar es la puntuación de PageSpeed Insights, ese número de 0 a 100 en verde, naranja o rojo. Es un resumen ponderado de una prueba de laboratorio hecha en un dispositivo simulado. Sirve para diagnosticar, no para decidir. He visto tiendas con 34 puntos vendiendo bien y tiendas con 78 con un INP horroroso porque el laboratorio no toca la página, y el usuario sí.
El laboratorio te dice qué está mal. Solo el dato de campo te dice si le importa a alguien.
Dato de campo frente a dato de laboratorio
El dato de campo es el que recogen los Chrome de tus usuarios reales (el conjunto se llama CrUX). Se mide en percentil 75: el valor por debajo del cual queda el 75 % de las visitas. No es la media. Es una forma de decir "así de mal lo pasa el cuarto de usuarios que peor lo pasa", que es exactamente la gente que se va.
Dónde consultarlo sin montar nada:
- El informe de Rendimiento web del panel de Shopify, en Analíticas. Usa datos de campo y te separa portada, colecciones y fichas de producto. Es el sitio más rápido para saber si tienes un problema.
- PageSpeed Insights con una URL de ficha concreta: arriba te da campo (si hay tráfico suficiente) y abajo laboratorio con el desglose.
- Search Console, informe de Core Web Vitals, que agrupa URLs por patrón. Útil para ver si el problema es de todas las fichas o de un tipo concreto.
Una advertencia: si tu tienda tiene poco tráfico, no habrá datos de campo suficientes y solo verás laboratorio. En ese caso, mide con el móvil de verdad. Coge tu teléfono, conéctate por 4G fuera de casa, abre el anuncio desde Instagram y cronometra. No es riguroso. Es infinitamente mejor que nada.
Por qué tu Shopify va lento: los sospechosos habituales
Shopify resuelve por su cuenta buena parte de lo que en un WooCommerce te destroza: la infraestructura, el CDN, la caché de servidor. El TTFB suele estar razonable. Lo que se rompe está casi siempre en el navegador, y casi siempre lo has metido tú o una app.
Apps que inyectan JavaScript en todas las páginas
Es la causa número uno. Reseñas, upsells, wishlist, popups de descuento, chat, buscador avanzado, badges de envío, contadores de urgencia, cuenta atrás, notificaciones de "alguien acaba de comprar en Girona". Una tienda con 25 apps instaladas puede estar cargando 900 KB de JavaScript de terceros antes de que el usuario haga nada. Cada script compite por el mismo hilo del navegador, y ese hilo es el que también tiene que responder cuando el usuario toca el selector de talla. Por eso las apps destrozan el INP más que el LCP.
Restos de apps que ya desinstalaste
Muchas apps antiguas metían su código directamente en los archivos del tema. Cuando las desinstalas, la app se va del panel y el código se queda. He abierto temas con llamadas a dominios de servicios que cerraron hace dos años: el navegador intenta conectar, espera, agota el tiempo y sigue. Gratis no es.
La imagen principal de la ficha
El CDN de Shopify sirve las imágenes en WebP y con el tamaño que le pidas, pero solo si el tema se lo pide bien. Si la ficha carga una imagen de 2.400 px de ancho para un móvil de 390 px, o si la imagen está dentro de un carrusel que se inicializa con JavaScript, el LCP se dispara. El carrusel es el enemigo silencioso: hasta que no se ejecuta el script, no hay imagen.
Fuentes personalizadas
Dos familias tipográficas con cuatro pesos cada una, cargadas desde Google Fonts o subidas como archivos al tema, son unos cientos de kilobytes y un bloqueo de renderizado. Shopify tiene fuentes servidas desde su propio dominio que ahorran una conexión entera.
El gestor de etiquetas mal puesto
Google Tag Manager con quince etiquetas dentro, todas disparándose en "Page View", incluidas dos herramientas de mapas de calor y un test A/B que dejaste corriendo en marzo. El test A/B es especialmente caro: para evitar el parpadeo, muchos bloquean el renderizado hasta decidir qué versión mostrar.
Antes de optimizar nada, haz la lista de todo lo que carga tu ficha de producto: pestaña Red de las herramientas de desarrollador de Chrome, filtro JS, ordenado por tamaño. Vas a encontrar cosas que no sabías que estaban ahí. Ese ejercicio cuesta media hora y suele ser el de mayor retorno de todos.
Lo que se arregla sin rehacer la tienda
La respuesta por defecto de mucha agencia es "hay que rehacer el tema". A veces es verdad. La mayoría de las veces, no. Esto es lo que se puede tocar en un tema existente, con su coste y su riesgo aproximados.
| Intervención | Esfuerzo | Riesgo | Métrica que mueve |
|---|---|---|---|
| Auditar y desinstalar apps que no usas | Bajo | Bajo | INP, LCP |
| Limpiar código huérfano de apps desinstaladas | Medio | Medio | INP |
| Precargar la imagen principal y sacarla del carrusel | Bajo | Bajo | LCP |
| Tamaños correctos de imagen y lazy load solo por debajo del pliegue | Bajo | Bajo | LCP |
| Reservar espacio para banners, popups e imágenes | Bajo | Bajo | CLS |
| Reducir fuentes a una familia y dos pesos | Bajo | Bajo | LCP |
| Aplazar scripts no críticos (chat, reseñas, heatmaps) | Medio | Medio | INP |
| Mover píxeles de terceros a Customer Events de Shopify | Medio | Medio | INP |
| Podar etiquetas muertas de GTM | Bajo | Bajo | INP |
Dos matices importantes sobre esta tabla.
El primero: aplazar scripts tiene contrapartidas reales. Si retrasas el widget de reseñas, la parte de reseñas aparece más tarde y en la sesión corta puede no llegar a verse. Si aplazas el chat, alguien que iba a preguntar por el plazo de envío quizá no lo haga. Si tocas los píxeles, puedes romper la atribución y descubrirlo tres semanas después, cuando ya no sabes qué campaña funcionaba. Cualquier cambio en medición se hace duplicando primero y desconectando lo antiguo después de comparar volúmenes durante al menos una semana.
El segundo: el checkout de Shopify no es tuyo y ahí no puedes optimizar rendimiento, para bien y para mal. Si pierdes pedidos en esa fase, el problema es de configuración y de fricción, no de milisegundos, y eso está en otro sitio. Lo mismo con la recuperación de compras a medias: la velocidad de la ficha reduce abandonos por impaciencia, pero la mayor parte del abandono tiene otras causas.
Lo que no se arregla sin meter mano al tema
Hay situaciones en las que parchear sale más caro que rehacer:
- Temas de la generación anterior a Online Store 2.0 con cinco años de modificaciones encima de diez desarrolladores distintos. El coste de tocar cualquier cosa sin romper otra ya no es predecible.
- Funcionalidad crítica atada a una app pesada: un configurador de producto, un buscador con filtros sobre 3.000 referencias, una lógica de precios por cliente. Ahí el JavaScript hace un trabajo de verdad y quitarlo no es una opción; hay que reescribirlo, y eso es un proyecto.
- Fichas de producto construidas con un maquetador visual de terceros. Suelen generar HTML muy pesado y son casi imposibles de aligerar desde fuera.
Si estás en ese punto, la conversación deja de ser de rendimiento y pasa a ser de plataforma y presupuesto: cuánto cuesta un tema nuevo, qué se pierde por el camino, cuánto tiempo estás sin poder lanzar nada. Esa decisión se parece bastante a la de cuándo compensa migrar y cuándo es tirar dinero, y merece los mismos números encima de la mesa.
Cuánto vale esto en euros
Aquí es donde casi todo el mundo miente. Existen estudios que correlacionan velocidad y conversión, y las cifras que circulan son grandes y bonitas. El problema es que son correlaciones sobre muestras enormes de sitios muy distintos al tuyo, y que las tiendas rápidas suelen ser rápidas porque están mejor gestionadas en general, no solo en milisegundos.
Lo honesto es esto: la velocidad no sube la conversión, quita un freno. Si tu producto, tu precio y tu ficha convencen, quitar dos segundos deja pasar a gente que se iba antes de ver la oferta. Si no convencen, la ficha se cargará más rápido y no venderás más.
Haz tú el cálculo con tus datos, aunque sea a ojo. Ejemplo inventado para que veas la mecánica: 30.000 sesiones al mes desde pago, conversión del 1,3 %, ticket medio de 60 €. Son 390 pedidos y 23.400 €. Si la mejora de LCP recupera un 5 % de sesiones que hoy se pierden antes de cargar y esas sesiones convierten peor que la media (digamos al 0,8 %), son unos 12 pedidos y unos 700 € al mes. Con una intervención de 1.500 €, se paga en dos meses. Con una de 12.000 €, la cuenta ya no sale por esa vía y tendrá que salir por otra.
Ese 5 % es un supuesto, no un dato. Cámbialo por el que tú creas y verás enseguida si merece la pena. Y si el número te sale ridículo, felicidades: acabas de ahorrarte un proyecto.
Cuando el gasto en publicidad es alto y el LCP en móvil pasa de cuatro segundos, el orden de prioridades cambia: cada semana que sigues invirtiendo estás pagando tráfico que no llega a ver la página. Ahí, la optimización va antes que el siguiente test creativo.
Orden de trabajo
Si vas a atacarlo, hazlo en este orden. Cada paso condiciona al siguiente.
- Establece la línea base. LCP, INP y CLS en móvil, percentil 75, solo de la plantilla de ficha de producto. Apunta la fecha. Sin esto no sabrás si has mejorado o si has tenido una semana con tráfico distinto.
- Inventaria. Lista de apps activas, lista de scripts que carga la ficha, lista de etiquetas de GTM. Marca cuáles ha usado alguien en los últimos noventa días.
- Poda. Desinstala lo que sobra y borra el código que dejaron. Es lo más barato y lo que más suele mover.
- Arregla la imagen principal. Tamaño correcto, formato correcto, fuera del carrusel si hace falta, precargada. Es el 70 % del LCP en una ficha.
- Aplaza lo que sobrevive. Lo que no hace falta en el primer segundo, que cargue después. Con un plan de comprobación de que nada se ha roto.
- Vuelve a medir a las cuatro semanas. El dato de campo necesita tiempo. No mires a los tres días y saques conclusiones.
Y una regla que ahorra discusiones: un cambio cada vez, con su fecha anotada. Si metes seis cosas el mismo martes y el INP mejora, no sabrás cuál fue, y la próxima vez volverás a pagar por las seis.
Si este problema está entre dos proveedores tuyos,
es justo donde suelo entrar.