Por qué tu PrestaShop va lento (y qué parte no es culpa del hosting)

El segundo y medio que decide la compra

Nadie abandona una tienda mirando el cronómetro. La gente abandona porque, mientras la página se pinta a trozos, deja de tener claro que vaya a funcionar. La lentitud no se percibe como lentitud: se percibe como desconfianza.

Y sin embargo, cuando una tienda PrestaShop va lenta, la conversación siempre empieza en el mismo sitio equivocado: el hosting. Se cambia de plan, se dobla la CPU, y la web sigue tardando lo mismo, porque el problema casi nunca estaba ahí.

Esta guía es el orden en el que conviene mirar. Está escrita para PrestaShop 8 y 9.

Antes de tocar nada: la línea base

Si optimizas sin medir antes, dentro de un mes estarás discutiendo con alguien sobre si la tienda va más rápida o no, y ninguno de los dos tendrá un dato.

Mide con PageSpeed Insights y fíjate en que la herramienta te da dos cosas distintas, aunque las pinte juntas:

Datos de laboratorio. Una simulación en un dispositivo y una red concretos. Cambia al instante cuando tocas algo, y por eso engancha. También es la que más miente sobre lo que vive tu cliente real.

Datos de campo. Lo que Google ha medido en visitantes reales durante los últimos 28 días. Es la que cuenta para el posicionamiento, y es la que tarda un mes en reflejar tu trabajo.

Las tres métricas que importan hoy:

Métrica	Qué mide	Umbral bueno
LCP	Cuánto tarda en aparecer el elemento principal	2,5 s o menos
INP	Cuánto tarda la página en responder a una interacción	200 ms o menos
CLS	Cuánto se mueve el contenido mientras carga	0,1 o menos

Si alguien te habla de FID, está trabajando con documentación vieja: Google lo sustituyó por INP en marzo de 2024.

Anota los tres valores de campo de tu ficha de producto más visitada y de tu categoría más visitada. Esa es tu línea base. Todo lo que viene después se compara contra ella.

Las tres causas reales, por orden de impacto

En las tiendas PrestaShop que llegan pidiendo velocidad, el reparto es casi siempre el mismo:

1. Imágenes sin optimizar. Suelen ser más de la mitad del peso de la página.
2. Ausencia de caché de página completa. Es lo que dispara el tiempo hasta el primer byte.
3. CSS y JavaScript que bloquean el pintado. Es lo que hace que la página esté “ahí” pero en blanco.

El orden importa, porque el esfuerzo de cada una es muy distinto y la primera es la más barata.

Imágenes: la mitad del problema

PrestaShop genera miniaturas en varios tamaños al subir un producto. El problema es lo que genera y en qué formato.

Desde PrestaShop 8.1 puedes elegir el formato en Diseño → Ajustes de imagen. Activa WebP y deja también el formato original marcado: PrestaShop servirá WebP a los navegadores que lo admiten y mantendrá el JPEG como respaldo. AVIF comprime todavía más, pero conviene tratarlo como un extra, no como el formato principal.

Después de cambiar el formato hay que regenerar las miniaturas, y ese proceso en catálogos grandes se cae por tiempo de ejecución. Si la regeneración se interrumpe a mitad, súbele los límites antes de repetirla:

; php.ini o .user.ini
max_execution_time = 600
memory_limit = 512M

Dos detalles que no salen en ningún panel y valen mucho:

La imagen del primer pantallazo no debe ir en carga diferida. El loading="lazy" en la imagen principal de la ficha retrasa exactamente lo que Google mide como LCP. Va en las de abajo, nunca en la de arriba.

Toda imagen necesita width y height en el HTML. Sin ellos el navegador no sabe cuánto sitio reservar, y el texto salta cuando la imagen entra. Eso es CLS, y es la métrica más fácil de arreglar y la que más gente ignora.

<img src="/img/p/1/2/12-home_default.webp"
     width="450" height="450"
     alt="Zapato de piel marrón, vista lateral">

Lo que este cambio no arregla: las imágenes que alguien pegó a mano dentro de la descripción HTML de un producto. Esas no pasan por el sistema de miniaturas de PrestaShop y se sirven tal cual se subieron, a menudo a 3.000 píxeles de ancho.

Caché: por qué PrestaShop es lento por diseño

Aquí está la confusión más cara de todas, y la tiene casi todo el mundo.

En Parámetros avanzados → Rendimiento hay una sección de caché de plantillas y otra de caché. Ninguna de las dos es caché de página completa.

La caché de Smarty guarda las plantillas ya compiladas para no volver a convertir el .tpl en PHP en cada visita. Ahorra compilación. No ahorra ni una sola consulta a la base de datos.

La caché de PrestaShop (ficheros, APCu, Memcached) guarda objetos sueltos. Ayuda, pero la página se sigue montando entera en cada visita.

Y montar una ficha de producto de PrestaShop significa, tirando por lo bajo, un par de centenares de consultas: precios con sus reglas, stock, combinaciones, transportistas, y cada hook de cada módulo instalado pidiendo lo suyo. Eso es lo que se te va en el tiempo hasta el primer byte, y ninguna de las dos cachés lo toca.

Lo que cambia el tiempo de respuesta es servir HTML ya montado. Es decir: la primera visita paga las doscientas consultas, y las siguientes reciben el resultado guardado sin tocar la base de datos.

Ajustes recomendados en producción, mientras tanto:

Modo depuración .................... No
Recompilar plantillas .............. Nunca recompilar
Caché de plantillas ................ Activada
Combinar, comprimir y cachear ...... Activado (con cuidado, ver abajo)

El punto delicado de la caché de página completa no es guardarla: es invalidarla en el momento justo. Una caché que no se limpia sola cuando cambias un precio te deja vendiendo a un importe viejo, y eso es peor que ir lento. Cualquier solución que adoptes tiene que invalidar al menos cuando cambia un producto, una categoría, un contenido CMS o la configuración de la tienda.

Y tiene que guardar variantes por contexto. Un mismo HTML no vale para un visitante anónimo y para uno con sesión iniciada y precios de grupo distintos. Si tu caché no distingue, acabarás enseñándole a un cliente el carrito de otro. Es un fallo raro, grave y difícil de reproducir: pregunta siempre por esto antes de instalar nada.

El CSS y el JS que bloquean el pintado

PrestaShop trae una opción llamada CCC (combinar, comprimir y cachear) en la misma pantalla de rendimiento. Junta los ficheros CSS y JS en uno solo para hacer menos peticiones.

Funciona, y a veces rompe cosas. El orden en que se combinan los ficheros no siempre respeta las dependencias entre módulos, así que actívalo, recorre la tienda entera —ficha, categoría, carrito, checkout, cuenta de cliente— y mira la consola del navegador. Si aparece un error de JavaScript que antes no estaba, ya sabes por qué.

Pero antes de combinar, conviene quitar. La pregunta útil no es “¿cómo cargo estos cuarenta ficheros más rápido?”, sino “¿por qué se cargan los cuarenta en todas las páginas?”.

Muchos módulos registran sus assets en el hook header sin comprobar en qué controlador están. Resultado: el JavaScript del comparador de productos viaja en el checkout, donde no hay nada que comparar. Un módulo bien hecho hace esto:

public function hookActionFrontControllerSetMedia()
{
    // Solo donde hace falta: cargar en todas las páginas es la causa
    // habitual de que una tienda arrastre cientos de KB inútiles.
    if ($this->context->controller->php_self !== 'product') {
        return;
    }

    $this->context->controller->registerJavascript(
        'modules-mimodulo',
        'modules/' . $this->name . '/views/js/front.js',
        ['position' => 'bottom', 'priority' => 150]
    );
}

Revisar esto módulo a módulo es trabajo manual y aburrido, y suele ser lo que más peso quita.

Lo que no funciona

Subir de plan de hosting sin diagnosticar. Si el tiempo se va en doscientas consultas por página, un procesador más rápido las hace igual de innecesarias, solo que un poco antes. Es la compra más habitual y la que menos devuelve.

Los módulos “optimizadores” que minifican y ya. Minificar CSS ahorra kilobytes; no ahorra consultas. La mejora se nota en la puntuación de laboratorio y no se nota en el tiempo hasta el primer byte, que es lo que sufre tu cliente.

Borrar la caché a mano cada mañana. Si alguien tiene esa costumbre es porque la invalidación automática no funciona. Arregla la invalidación, no cojas el hábito.

Perseguir el 100 en PageSpeed. Los últimos puntos se pagan carísimos y casi siempre a costa de romper algo. Con estar en verde en las tres métricas de campo has terminado.

Optimizar la portada. Es la página que menos tráfico orgánico recibe en casi cualquier tienda. Optimiza la plantilla de ficha de producto y la de categoría, que son el 80% de las visitas de Google.

Cómo demostrar que has mejorado

Vuelve a medir las mismas dos URLs de la línea base, y ten paciencia con los datos de campo: la ventana de Google es de 28 días móviles, así que un cambio bueno tarda un mes en verse completo y las dos primeras semanas parecerá que no ha servido de nada.

Mientras tanto, la métrica honesta de andar por casa es el tiempo hasta el primer byte con la caché caliente. Se mide sin herramientas:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://tutienda.es/categoria/

Lánzalo dos veces seguidas. La primera puede ser lenta —está generando y guardando—; la segunda es la que cuenta. Si la segunda sigue por encima de medio segundo, la caché de página no está funcionando o no está guardando esa URL.

Cuándo sí es el hosting

Después de todo lo anterior, si el TTFB con caché caliente sigue alto, entonces sí toca mirar el servidor. Señales de que el problema es de alojamiento y no de configuración:

• La segunda petición a una página cacheada tarda más de medio segundo.
• El panel muestra la CPU al límite con tráfico normal.
• La base de datos está en un servidor distinto y con latencia entre ambos.
• Estás en un plan compartido donde el rendimiento cambia según la hora.

Ahí un cambio de plan sí devuelve lo que cuesta. Antes, no.

Si te apañas con esto, no necesitas nada más

Todo lo de esta guía se puede hacer a mano, y si tu catálogo es pequeño y no lo tocas a menudo, hacerlo a mano es perfectamente razonable.

Lo que se complica con el tamaño es lo de siempre: regenerar miniaturas de miles de productos sin que se caiga el proceso, invalidar la caché de página en el momento exacto en que cambia un precio, y tener guardado el antes y el después para poder enseñarlo. Eso es mantenimiento, no ingenio.