Core Web Vitals en PrestaShop: qué frena de verdad en un catálogo

Respuesta breve

En una tienda PrestaShop, las tres Core Web Vitals suelen fallar por sitios distintos y ninguno es el que se mira primero. El LCP casi siempre es una imagen de producto servida a un tamaño que no corresponde con el que se pinta. El CLS viene del catálogo, que se recoloca cuando llegan imágenes sin dimensiones o bloques que inyectan los módulos. Y el INP lo produce el JavaScript acumulado de esos mismos módulos, que se ejecuta aunque la página no lo use. La caché del propio PrestaShop puede hacer que todo parezca resuelto sin haber tocado nada de eso.

Puntos clave

• Los umbrales de referencia son LCP por debajo de 2,5 s, INP por debajo de 200 ms y CLS por debajo de 0,1, medidos en el percentil 75 de visitas reales.
• PrestaShop genera varios tamaños de cada imagen; el problema no es que falten, es elegir el que no toca.
• Una miniatura de catálogo servida al tamaño de la ficha multiplica los bytes de toda la página de categoría.
• El CLS de una tienda se concentra en la rejilla de productos y en los bloques que aparecen tarde.
• El JavaScript de los módulos se encola por hook, no por necesidad: una página puede cargar el de un módulo que no usa.
• La caché combinada acelera lo que ya está mal y complica el diagnóstico: se mide con ella desactivada y se activa al final.

Dónde se mide, y por qué el laboratorio engaña

Las Core Web Vitals que cuentan son las de campo: visitas reales, con sus dispositivos y sus redes. Una herramienta de laboratorio simula una carga y sirve para diagnosticar, no para declarar cumplimiento; el INP, en particular, no puede medirse sin que alguien interactúe de verdad.

En una tienda hay que medir al menos tres plantillas, porque se comportan distinto: la portada, una categoría con su rejilla completa y una ficha de producto. Medir solo la portada —que suele ser la más cuidada— da una foto favorable y falsa del sitio.

LCP: casi siempre es una imagen, y casi nunca la que se cree

PrestaShop mantiene una lista de formatos de imagen y genera cada producto en todos ellos. La plantilla decide cuál pide, y ahí está el fallo más caro y más común: pedir el formato grande —el de la ficha— para pintar una miniatura de rejilla de unos pocos cientos de píxeles. La imagen se descarga entera y el navegador la reduce, así que el visitante paga todos los bytes y no ve ni un detalle más.

Se comprueba en un minuto: abre la categoría, mira una miniatura y compara el tamaño con el que se sirve. Si el ancho real pintado es mucho menor que el del fichero, ahí está el LCP y ahí están los bytes de toda la página, multiplicados por el número de productos que muestres.

La regla para elegir formato: el inmediatamente superior al ancho al que se pinta, contando que hay pantallas de doble densidad. Ni el más grande «por si acaso» ni el más pequeño, que se ve borroso justo en la imagen que decide la compra.

CLS: el catálogo que se recoloca

El desplazamiento de una tienda no suele venir de la tipografía sino de la rejilla. Tres causas, por frecuencia: imágenes sin width y height declarados, de modo que el hueco no está reservado hasta que llegan; bloques de módulos que se insertan por encima del contenido cuando su JavaScript termina; y avisos —cookies, promociones, envíos— que empujan la página hacia abajo en vez de superponerse.

Los tres se arreglan reservando el espacio antes de que llegue el contenido, no acelerándolo. Una imagen con sus dimensiones declaradas no salta aunque tarde; un banner con altura reservada tampoco.

INP: el JavaScript que nadie pidió

En PrestaShop, un módulo encola sus hojas y sus scripts cuando está enganchado al hook correspondiente, y eso no depende de que la página los necesite. Una tienda con veinte módulos activos carga en la categoría el JavaScript del comparador, el del formulario de contacto y el del selector que solo aparece en la ficha.

La consecuencia no es el peso —eso lo absorbe la caché— sino el trabajo: cada script se analiza y se ejecuta en el hilo principal, y mientras eso ocurre el navegador no puede responder a un toque. Ahí es donde se pierde el INP, y por eso una tienda ligera en bytes puede responder peor que otra más pesada con menos código ejecutándose.

El trabajo aquí es de inventario, no de optimización: qué módulo encola qué, en qué plantillas, y cuál de ellos se puede limitar a las páginas donde hace falta. Es exactamente el mismo criterio que en un WordPress sin sobrecargar de plugins, con otro sistema de hooks.

La caché que resuelve y la que tapa

PrestaShop puede combinar y comprimir CSS y JavaScript, y encima suele haber una caché de página y a menudo un CDN. Cada capa mejora los tiempos y, a la vez, esconde el estado real del sitio: lo que sirve deja de ser lo que produce la tienda.

Por eso el diagnóstico se hace con la combinación desactivada, y solo al final se vuelve a activar comprobando que el resultado sigue siendo el esperado. Y conviene saber una cosa antes de dar por bueno un arreglo: vaciar la caché no garantiza que lo que se regenere sea lo nuevo. Un bundle combinado puede reconstruirse con el contenido anterior, y una capa de CDN por delante puede seguir sirviendo el fichero viejo durante horas aunque el disco ya tenga el correcto.

De ahí una regla que vale para cualquier tienda detrás de un CDN: la versión de un fichero de estilo o de script va en su nombre, no en un parámetro de la URL. Un parámetro es fácil de añadir y, según cómo se encolen los assets, puede romper el registro por completo y dejar la tienda sin ese CSS. Cambiar el nombre del fichero fuerza una URL nueva que ninguna caché puede confundir con la anterior.

En tres láminas

3 plantillas, no una. Portada, categoría con su rejilla completa y ficha de producto se comportan distinto. Medir solo la portada da una foto favorable y falsa.

Las tres métricas en un catálogo. Columnas: Causa habitual en una tienda. LCP: Causa habitual en una tienda → La imagen de producto servida a un tamaño mayor del que se pinta. CLS: Causa habitual en una tienda → La rejilla que se recoloca: imágenes sin dimensiones y bloques que llegan tarde. INP: Causa habitual en una tienda → El JavaScript que los módulos encolan por hook, la use o no la página

catálogo: ancho al que se PINTA la miniatura ~250 px / formato que pide la plantilla large_default / ancho real del fichero 800 px / / # se descarga entera y el navegador la reduce / # el visitante paga todos los bytes, x24 productos / # regla: el formato inmediatamente superior al / # renderizado, contando pantallas x2

Errores frecuentes

• Optimizar la portada y declarar el sitio arreglado. La categoría y la ficha son las que venden.
• Instalar un módulo de rendimiento antes de saber qué frena. Añade una capa más al diagnóstico.
• Medir con la caché activada y celebrar la mejora de la caché como si fuera del sitio.
• Comprimir imágenes sin cambiar el formato que se pide: se sigue sirviendo el tamaño equivocado, algo más ligero.
• Perseguir una puntuación agregada. Puede subir mientras empeora lo que siente el visitante.
• Dar por hecho que el fichero corregido ya se está sirviendo. Con un CDN delante, hay que comprobarlo pidiendo la página como la pide un navegador.

Preguntas habituales

¿Cambiar de hosting arregla las Core Web Vitals? Mejora el tiempo hasta el primer byte, que es una parte del LCP y no siempre la mayor. Si el LCP lo produce una imagen de 800 píxeles pintada a 200, el servidor nuevo la servirá igual de grande, solo que antes.

¿Merece la pena un módulo de optimización? Depende de qué haga y de si el problema es suyo. Los que reservan espacio, difieren scripts o sirven imágenes en el formato correcto resuelven causas; los que solo comprimen y combinan aceleran lo que ya está mal y hacen más difícil ver por qué.

¿Y si la tienda usa un tema con constructor visual? Cambia poco el diagnóstico y mucho el arreglo: las plantillas viven en la base de datos, así que un cambio hecho en el editor puede deshacer el trabajo. Lo que deba perdurar va en un módulo propio, no en la plantilla.

Próximo paso

Empieza por el inventario de formatos de imagen y por el ancho real al que se pintan las miniaturas en tu categoría. Es la comprobación más barata de todas y suele explicar a la vez el LCP y el peso de la página. Cuando eso esté, mira qué módulos encolan JavaScript en esa misma plantilla y cuáles se pueden limitar.

Si el catálogo además compite consigo mismo por las facetas y las variantes, ese es otro trabajo: está en filtros y facetas en PrestaShop y en categorías, productos y facetas.

Fuentes

• Google, Web Vitals: umbrales de LCP, INP y CLS y percentil de evaluación — web.dev/articles/vitals, consultado el 9 de septiembre de 2026.
• Google Search Central, SEO Starter Guide — RS-005.
• Observación propia sobre tiendas PrestaShop en producción, sin datos de cliente — RS-001.

Servicio relacionado

Si esto es lo que te está pasando, seo para prestashop es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver seo para prestashop