Su proveedor entrega fotos de producto espectaculares: 4000 por 4000 píxeles, 7 MB cada una. En su página de categoría las muestra como miniatura de 300 píxeles, pero el navegador sigue descargando esos 7 MB completos. Con 40 productos en una página, eso son casi 300 MB de imagen que tienen que viajar por la red. En móvil, en 4G, en el autobús.
Y justo en ese momento Google mide. El elemento más grande que aparece en pantalla, casi siempre una foto de producto, determina su Largest Contentful Paint. Con archivos así, se pone en rojo. No porque su tema sea malo o su hosting demasiado barato, sino porque la imagen de origen nunca se pensó para una tienda online.
Por qué su página de producto es lenta: la culpable es la foto
Cuando una página de producto se percibe lenta, todo el mundo señala primero al tema o a los plugins. Casi siempre injustamente. Las imágenes son la parte más pesada de una página media: según el HTTP Archive Web Almanac 2025, entre un 36 y un 37 por ciento del peso total de la página, con unos 911 KB de imagen en una página de inicio móvil mediana, más que JavaScript y fuentes juntos. En un catálogo de producto con fotos de proveedor sin procesar, esa cifra es aún mucho más alta.
El problema está en el desajuste. Un archivo de 4000 píxeles de ancho que muestra en un espacio de 300 píxeles se descarga entero primero y solo después el navegador lo reduce. Paga el ancho de banda de la foto grande y solo ve de ella una versión pequeña.
Qué mide Google exactamente: Core Web Vitals y LCP
Google evalúa la experiencia de carga de su página con tres Core Web Vitals. LCP (Largest Contentful Paint) mide con qué rapidez se vuelve visible el elemento más grande, INP (Interaction to Next Paint) con qué rapidez responde su página a un clic, y CLS (Cumulative Layout Shift) cuánto se desplaza el diseño durante la carga. Los umbrales: LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos, CLS por debajo de 0,1.
Para las fotos de producto, LCP es la métrica que más duele. Según web.dev, 2,5 segundos o menos es bueno, de 2,5 a 4 segundos hay que mejorar, y por encima de 4 segundos es malo, medido en el percentil 75 de sus páginas vistas. También es la más difícil de las tres: el Web Almanac 2025 muestra que solo el 62 por ciento de las páginas móviles logra un buen LCP.
Los Core Web Vitals son una parte confirmada de las señales de page experience de Google. La velocidad no convierte una página mala en buena, pero entre dos resultados igual de relevantes puede inclinar la balanza. Y puede que su competencia sí tenga las imágenes bien optimizadas.
Cuánto le cuesta de verdad la lentitud: del tiempo de carga a la facturación
Esto no es un detalle técnico para su desarrollador, afecta a sus ingresos. Se cita mucho el dato de Google de que el 53 por ciento de los visitantes móviles abandona con un tiempo de carga superior a 3 segundos. Y el estudio de Deloitte “Milliseconds Make Millions”, sobre 37 marcas y más de 30 millones de sesiones, mostró que 0,1 segundos menos de carga aumentaron la conversión de retail en un 8,4 por ciento y el valor medio del pedido en un 9,2 por ciento.
Una décima de segundo más rápido valió un 8,4 por ciento más de conversión en retail. La imagen es la mayor palanca que puede accionar para conseguirlo.
El problema en el origen: las fotos del proveedor no están pensadas para su tienda online
Los proveedores fotografían para la imprenta y el catálogo, no para su página de producto. Lo que recibe es un archivo de estudio: un JPEG de 4000 por 4000 píxeles, a veces una foto HEIC de 4,2 MB directa de un teléfono, con una calidad que en papel es preciosa y online es puro lastre.
- Fotos de 6 a 8 MB cuando a su página le bastarían 60 KB.
- Formatos como HEIC o TIFF que no todos los navegadores muestran sin más.
- La misma foto de ambiente que, en veinte variantes (purple, lila, violet), se entrega veinte veces y se almacena veinte veces.
Resolverlo a mano significa abrir cada archivo, exportarlo al tamaño correcto, comprimirlo y subirlo. Para cien productos, eso es un día. Para un catálogo en crecimiento, no se termina nunca.
archivo product.webpmedidas ~1600 px (srcset por espacio)peso 84 KBformato WebP + JPEG fallbackcarga eager, tamaño correcto// ~98% más ligero, LCP bajo 2,5s
Haga clic para alternar. La misma foto, otro archivo.
- Archivo de 4000px y 7 MB mostrado en un espacio de 300px
- Cada navegador descarga la resolución completa, también en móvil
- La misma foto guardada decenas de veces por variante
- LCP en rojo, ancho de banda y almacenamiento malgastados
- Cada foto de origen a WebP, con el tamaño correcto por espacio
- Miniatura, listado e imagen grande, cada uno a su propia resolución
- Las fotos duplicadas se guardan una sola vez (dedup)
- Hasta ~98% más ligero, LCP y Core Web Vitals vuelven a respirar
Qué puede automatizar: WebP, el tamaño correcto y dedup
Optimizar las fotos de producto para su tienda online no es una tarea de diseño por producto. Son tres pasos mecánicos que un pipeline repite infinitas veces y sin fallos.
Convertir a WebP
Según el propio estudio de Google, WebP produce archivos entre un 25 y un 34 por ciento más pequeños que JPEG con igual calidad visual, medida en SSIM. Y su uso es seguro: según caniuse.com, entre un 96 y un 97 por ciento de los navegadores admite WebP, con JPEG como fallback para el resto. AVIF comprime algo más, pero tiene menos cobertura, así que WebP es el estándar razonable.
El tamaño correcto por espacio
Una miniatura no necesita 4000 píxeles. Google aconseja explícitamente servir la imagen al tamaño correcto por dispositivo mediante srcset o picture, de modo que un teléfono reciba una variante pequeña y una pantalla grande, la grande. Se configura una vez, y cada foto nueva sale automáticamente en todos los tamaños.
Guardar las fotos duplicadas una sola vez
Los mayoristas suelen entregar la misma foto de ambiente para toda una serie de variantes. El dedup lo detecta y guarda el archivo una sola vez en lugar de treinta. Eso ahorra almacenamiento y mantiene ordenada su biblioteca de medios.
Qué NO es la optimización de imágenes de producto (y por qué eso es honesto)
Conviene dejarlo claro, porque en este terreno se promete mucho. Esto es compresión y optimización de formato. No es quitar el fondo, no es eliminar una marca de agua y desde luego no es un escalado con IA que convierta una foto mala en buena. Una foto de origen fea sigue siendo una foto fea, solo que más ligera.
Y no es destructivo. Sus originales se conservan y su tienda nunca se sobrescribe. Recibe variantes optimizadas junto a sus originales, que se integran de forma ordenada en la conexión con WooCommerce y Magento. Si quiere ver cómo encaja en su estructura actual, lea cómo SyncRefine lee su tienda existente y entrega las imágenes a medida.
Checklist: ¿están sus imágenes listas para la velocidad y para Google?
Repase estos puntos antes de concluir que su tema es lento:
- ¿Sirve WebP (con JPEG como fallback) en lugar de JPEG sin optimizar?
- ¿Recibe cada espacio su propio tamaño, o carga el archivo grande en todas partes?
- ¿La foto por encima de la línea de flotación NO está en lazy-load, para que su LCP no se desplome?
- ¿Se guardan las fotos idénticas una sola vez en lugar de por variante?
- ¿Mide el LCP en móvil en el percentil 75, y no en el wifi rápido de su oficina?
- El elemento LCP en una página de producto es casi siempre la foto de producto grande, así que una imagen pesada afecta directamente a su posicionamiento.
- WebP es un 25-34% más ligero que JPEG con igual calidad y lo admiten ~96-97% de los navegadores.
- La ganancia está en la automatización: convertir, aplicar el tamaño correcto por espacio y hacer dedup de las fotos duplicadas, no en trabajo manual por producto.
- Marco honesto: esto es compresión y formato, no quitar el fondo, no escalar, y sus originales permanecen intactos.
