¿Cuál es la mejor configuración en la pestaña «Parámetros Avanzados > Rendimiento» de PrestaShop?

La pestaña Parámetros Avanzados > Rendimiento de PrestaShop parece, a primera vista, una sala de mandos sencilla: unos interruptores, varios desplegables, algunas opciones con nombres casi amables. Pero conviene no dejarse engañar. Ahí dentro se decide si una tienda online respira con ligereza o camina por el barro con zapatos de plomo.

La ironía es deliciosa: muchas tiendas lentas no lo son por falta de tecnología, sino por exceso de “optimización” mal entendida. Se activa todo, como quien echa todas las especias al guiso esperando alta cocina, y luego llegan los misterios: botones que no responden, módulos que se descolocan, carritos que se comportan como gatos ofendidos y páginas que tardan en cargar lo mismo que una sobremesa familiar.

La mejor configuración de rendimiento en PrestaShop existe, sí, pero no como receta universal grabada en piedra. Depende de la versión de PrestaShop, del tema, de los módulos instalados, del servidor, de si usas CDN, de si hay tráfico real o solo visitas de prueba, y de si tu hosting tiene músculo o apenas hace yoga los domingos. Aun así, hay una base profesional muy clara para tiendas en producción.

Respuesta rápida: en una tienda PrestaShop en producción, normalmente conviene activar la caché de Smarty, usar “Recompilar plantillas si los archivos han sido actualizados”, activar las opciones CCC compatibles con tu tema, habilitar una caché persistente si el servidor la soporta correctamente y probar cada cambio con herramientas como PageSpeed Insights, WebPageTest, Lighthouse o GTmetrix. Pero el matiz importa. Mucho.

Antes de tocar nada: mide, respira y haz copia 🧭

Hay una tentación muy común: entrar en Parámetros Avanzados > Rendimiento, activar botones con entusiasmo y esperar que la velocidad aparezca como por arte de magia. Ojalá. La optimización web se parece más a afinar un instrumento que a pulsar un interruptor. Un violín no suena mejor porque aprietes todas las clavijas a la vez; de hecho, lo más probable es que rompas una cuerda.

Antes de cambiar la configuración de rendimiento de PrestaShop, haz tres cosas:

1. Copia de seguridad completa: archivos y base de datos. No solo “por si acaso”, sino porque ese “por si acaso” suele tener un sentido del humor impecable.
2. Mide el estado actual: registra TTFB, LCP, CLS, peso de página, número de peticiones y tiempo de carga.
3. Aplica cambios de uno en uno: activa una opción, limpia caché, prueba. Luego otra. La prisa es enemiga de la depuración.

Herramientas útiles:

• Google PageSpeed Insights: útil para Core Web Vitals y experiencia real de usuarios si hay datos suficientes.
• Lighthouse en Chrome: rápido para auditorías técnicas.
• WebPageTest: excelente para ver cascadas de carga, TTFB y comportamiento por ubicación.
• GTmetrix: práctico para comparar antes y después.
• New Relic, Blackfire o similares: para detectar cuellos de botella de PHP, base de datos y módulos.

Y una observación incómoda: si el servidor tarda 1,8 segundos en entregar el primer byte, minificar CSS no salvará la tienda. Será como perfumar una casa en llamas. Agradable, quizá. Insuficiente, seguro.

Configuración recomendada para una tienda PrestaShop en producción ✅

Esta tabla resume una configuración sólida para una tienda real, pública, con tráfico y sin tareas activas de desarrollo. No es una ley divina, pero sí un punto de partida profesional.

Idea central: la configuración de rendimiento de PrestaShop no debe buscar “activar todo”, sino activar lo correcto. La velocidad no es una acumulación de interruptores encendidos; es una coreografía entre servidor, caché, tema, módulos, imágenes, base de datos y navegador.

Smarty: compilación de plantillas y caché 🧠

PrestaShop utiliza el motor de plantillas Smarty para generar buena parte del HTML que ve el usuario. Smarty permite separar lógica y presentación, algo muy sensato, aunque a veces uno mire ciertos temas comerciales y piense que la sensatez fue invitada tarde a la reunión.

En Parámetros Avanzados > Rendimiento, la sección Smarty suele incluir opciones relacionadas con la compilación de plantillas y la caché.

Compilación de plantillas: ¿qué opción elegir?

Normalmente encontrarás opciones similares a estas, según la versión de PrestaShop:

• Nunca recompilar los archivos de plantilla: máxima eficiencia, pero peligrosa si haces cambios en el tema o módulos. Puede mostrar versiones antiguas.
• Recompilar plantillas si los archivos han sido actualizados: opción recomendada para producción en la mayoría de casos.
• Forzar compilación: útil en desarrollo, mala idea en producción porque consume más recursos.

La mejor configuración para una tienda activa suele ser:

Compilación de plantillas: Recompilar plantillas si los archivos han sido actualizados

Esta opción actúa como un buen bibliotecario: no reordena toda la biblioteca cada vez que alguien entra, pero sí presta atención cuando un libro cambia de estante. En tiendas con mucho tráfico, evita trabajo innecesario de PHP y reduce carga del servidor.

Caché de Smarty: activada en producción

Caché: Sí

En producción, la caché de Smarty debe estar activada salvo motivo técnico concreto. Desactivarla en una tienda real equivale a pedirle al camarero que cocine desde cero cada plato aunque todos hayan pedido lo mismo. Muy artesanal. Muy lento.

La caché permite reutilizar fragmentos ya generados, reduciendo trabajo de PHP y consultas repetidas. En catálogos grandes, especialmente con muchas categorías, filtros o bloques dinámicos, la diferencia puede ser notable.

Cuándo desactivar temporalmente la caché de Smarty

Hay momentos donde desactivar caché tiene sentido:

• Durante desarrollo de un tema.
• Al modificar plantillas .tpl.
• Al depurar un módulo que no muestra cambios.
• Cuando hay un comportamiento extraño y necesitas descartar caché corrupta.

Pero desactivar caché y dejarla así durante semanas es una de esas pequeñas negligencias que no hacen ruido hasta que llega una campaña de tráfico. Entonces sí: el servidor empieza a sudar como cristal frío en agosto.

CCC en PrestaShop: CSS, JavaScript y HTML 🎛️

CCC significa Combine, Compress and Cache: combinar, comprimir y cachear. Es una de las zonas más famosas de la configuración de rendimiento de PrestaShop, y también una de las más traicioneras. Promete velocidad, y en muchos casos la da. Pero si el tema o los módulos no están bien construidos, puede revelar grietas que estaban escondidas.

La antítesis es clara: el CCC puede convertir una tienda pesada en una página ágil, o una página funcional en una elegante ruina interactiva. Todo depende de la compatibilidad.

Smart cache para CSS

Configuración recomendada: Sí, después de probar.

Esta opción combina y cachea archivos CSS para reducir peticiones y mejorar carga. En muchas tiendas PrestaShop, especialmente con temas cargados de estilos, puede ayudar bastante.

Sin embargo, hay un matiz moderno: con HTTP/2 y HTTP/3, combinar demasiados archivos ya no siempre es tan beneficioso como lo era en HTTP/1.1, porque los navegadores manejan múltiples peticiones con más eficiencia. Aun así, en PrestaShop la reducción y minificación de CSS suele seguir aportando valor, sobre todo si el tema genera una procesión interminable de archivos.

Tras activarlo, revisa:

• Página de inicio.
• Categorías.
• Ficha de producto.
• Checkout.
• Versión móvil.
• Menús desplegables, sliders y filtros.

Smart cache para JavaScript

Configuración recomendada: Sí, pero con más cautela que CSS.

JavaScript es menos dócil. Un CSS roto afea la página; un JavaScript roto puede impedir comprar. Esa diferencia, en comercio electrónico, es casi filosófica: la belleza importa, pero el botón “Finalizar pedido” paga las facturas.

Al activar la optimización JavaScript en PrestaShop, comprueba especialmente:

• Añadir al carrito.
• Actualizar cantidades en carrito.
• Códigos descuento.
• Proceso de pago completo.
• Módulos de transportistas.
• Módulos de pago.
• Buscador interno.
• Filtros por facetas.
• Selector de combinaciones: talla, color, capacidad, etc.
• Consentimiento de cookies y etiquetas de analítica.

Si algo falla, no asumas que “PrestaShop no sirve”. A veces el culpable es un módulo que carga scripts como quien deja cables cruzados detrás de un televisor: funciona hasta que alguien intenta ordenar un poco.

Minificar HTML

Configuración recomendada: Sí, si no causa problemas.

Minificar HTML elimina espacios, saltos de línea y comentarios innecesarios. El ahorro no suele ser gigantesco, pero suma. En páginas con HTML voluminoso, menús enormes o muchos bloques, puede reducir algunos kilobytes.

Importante: si tu tienda utiliza fragmentos de código inline delicados, integraciones antiguas o módulos con comentarios condicionales raros, prueba bien. La minificación debería ser segura, pero en el mundo real “debería” es una palabra con demasiada imaginación.

Comprimir JavaScript dentro del HTML

Configuración recomendada: Sí, con pruebas en checkout y módulos externos.

Esta opción reduce JavaScript embebido directamente en el HTML. Puede mejorar algo el peso de la página, aunque su impacto depende mucho del tema y de los módulos instalados.

Presta especial atención si usas:

• Google Tag Manager.
• Meta Pixel.
• Scripts de afiliación.
• Chats online.
• Herramientas de mapas de calor.
• Módulos de financiación o pago aplazado.

Mover JavaScript al final

Configuración recomendada: Sí, si el tema lo permite.

Mover JavaScript al final del documento puede mejorar la carga percibida porque el navegador puede pintar antes el contenido visible. Es como dejar pasar primero a los clientes y luego ordenar el almacén. Buena idea, salvo que el almacén esté bloqueando la puerta.

Problema habitual: algunos temas antiguos o módulos mal diseñados esperan que jQuery u otro script esté disponible en la cabecera. Si se mueve todo al final, aparecen errores en consola como $ is not defined o funciones no disponibles.

Después de activar esta opción, abre la consola del navegador y revisa errores. En Chrome: clic derecho, Inspeccionar, pestaña Console. Si ves errores rojos relacionados con JavaScript, toca investigar.

Optimización Apache

Configuración recomendada: Sí, si tu servidor usa Apache.

Esta opción intenta añadir reglas al archivo .htaccess para mejorar compresión, caché del navegador y manejo de recursos estáticos. Es útil en servidores Apache o LiteSpeed compatibles con reglas tipo Apache.

Si usas Nginx, esta opción no tendrá el mismo efecto, porque Nginx no lee .htaccess. En ese caso, la compresión Gzip/Brotli, las cabeceras de caché y la entrega de estáticos deben configurarse en el bloque del servidor.

Cuidado: si al activar optimización Apache aparece error 500, revisa el archivo .htaccess. Puede haber directivas no permitidas por el hosting. Restaura una copia y regenera URLs amigables desde el back office si hace falta.

Sistema de caché: archivo, Memcached, Redis, APCu y compañía 🗄️

La sección de caché avanzada en PrestaShop ha variado según versiones, instalaciones y módulos. En algunas tiendas se ofrecen opciones como Memcached, APC/APCu, XCache —hoy prácticamente reliquia— o sistemas configurados mediante módulos y servidor. En entornos actuales también es común hablar de Redis, aunque no siempre aparece de forma nativa en la misma pantalla sin soporte adicional.

La pregunta importante no es “¿cuál suena más profesional?”, sino “¿cuál está correctamente instalado, monitorizado y soportado en mi servidor?”. Porque una caché mal configurada es como un archivador con etiquetas bonitas y documentos perdidos: promete orden, entrega confusión.

Sistema de archivos

Ventajas:

• Estable y fácil de usar.
• No requiere servicios externos.
• Compatible con la mayoría de hostings.

Desventajas:

• Puede ser menos eficiente en tiendas con mucho tráfico.
• Depende mucho del rendimiento del disco.
• En servidores con almacenamiento lento, puede convertirse en cuello de botella.

Para muchas tiendas pequeñas y medianas, el sistema de archivos bien gestionado es suficiente. No es glamuroso, pero funciona. Y en rendimiento web, lo aburrido que funciona suele ser más valioso que lo sofisticado que se cae.

Memcached

Memcached es un sistema de caché en memoria muy rápido. Puede reducir carga en base de datos y acelerar operaciones repetitivas. Requiere que el servicio esté instalado en el servidor y que PHP tenga la extensión correspondiente.

Cuándo usarlo:

• Tiendas con tráfico medio o alto.
• Servidores VPS, dedicados o cloud bien administrados.
• Entornos donde puedas controlar memoria y servicio.

Cuándo evitarlo:

• Hostings compartidos inestables.
• Servidores donde no puedes verificar configuración.
• Tiendas pequeñas donde el beneficio será marginal.

APCu

APCu es una caché de usuario en memoria para PHP. Puede ser útil, especialmente en un único servidor. Es rápida, relativamente simple y no requiere un daemon externo como Memcached.

Pero tiene una limitación: no es ideal para arquitecturas con varios servidores si no existe una estrategia clara de sincronización. En una tienda sencilla con VPS único, puede ir muy bien. En infraestructura distribuida, ya es otro cantar.

Redis

Redis es una base de datos en memoria muy utilizada para caché, sesiones y colas. En PrestaShop puede emplearse mediante configuración específica, módulos o integraciones del entorno de hosting. No siempre aparece como opción directa en la pantalla clásica de rendimiento, pero merece mención porque muchos proveedores modernos lo ofrecen.

Redis suele ser excelente cuando está bien configurado. La frase clave es esa: bien configurado. Sin límites de memoria, política de expulsión adecuada, persistencia entendida y monitorización mínima, Redis puede convertirse en una criatura rápida, sí, pero caprichosa.

¿Activar “Usar caché” en PrestaShop?

En producción, puedes activarla si:

• El sistema elegido está instalado y funcionando.
• No hay errores en logs.
• Has probado carrito, login, búsqueda y checkout.
• El tiempo de respuesta mejora realmente.

No la actives solo porque está ahí. Esa lógica también serviría para pulsar todos los botones de un ascensor y, técnicamente, nadie lo recomienda.

Funcionalidades opcionales: desactivar lo que no usas 🧹

PrestaShop incluye funciones potentes para catálogos complejos: combinaciones, características, grupos de clientes, personalizaciones. Son herramientas muy útiles, pero si no se usan, pueden añadir carga innecesaria en ciertas consultas y procesos.

En la sección de rendimiento puede aparecer un bloque de funcionalidades opcionales. Aquí la regla es sencilla:

Desactiva únicamente lo que tu tienda no necesita.

Combinaciones

Las combinaciones permiten vender variantes de un producto: talla, color, capacidad, material, etc.

Desactivar combinaciones: solo si todos tus productos son simples y no tienen variantes.

Si vendes camisetas con tallas o zapatos con números, no las desactives. Parece obvio, pero he visto tiendas donde alguien lo hizo “para acelerar” y luego los productos quedaron como estatuas sin sombra: visibles, sí, pero incompletos.

Características

Las características son atributos informativos del producto: composición, peso, dimensiones, tecnología, tipo de material. También pueden participar en filtros y comparaciones según el tema o módulos.

Desactivar características: solo si no las usas en fichas de producto, filtros ni comparadores.

Grupos de clientes

Los grupos de clientes permiten precios, descuentos, reglas y permisos diferentes. Son importantes para tiendas B2B, ventas mayoristas, clubes privados o tarifas segmentadas.

Desactivar grupos de clientes: solo si todos tus clientes tienen exactamente las mismas condiciones comerciales.

En una tienda B2B, desactivar grupos por rendimiento puede ser un pequeño desastre con traje administrativo.

Optimización del servidor: el elefante en la habitación 🐘

La pestaña de rendimiento de PrestaShop ayuda, pero no hace milagros. Si el hosting es lento, si PHP está desactualizado, si MySQL está mal configurado o si el disco parece escribir con pluma de ganso, ninguna opción del back office resolverá todo.

Hay una oposición brutal entre dos mundos: la tienda que intenta ahorrar unos euros al mes en hosting y la tienda que pierde ventas porque cada página tarda cuatro segundos en responder. Austeridad en la factura, derroche en abandono. Precioso, si no fuera tan caro.

PHP recomendado

Usa una versión de PHP compatible oficialmente con tu versión de PrestaShop. Como referencia general:

• PrestaShop 1.7.8: suele funcionar bien con PHP 7.4, aunque depende de módulos y parches.
• PrestaShop 8: está orientado a PHP 8.1 en muchas instalaciones, con compatibilidad según versión concreta.
• PrestaShop 9: eleva requisitos y conviene revisar documentación oficial antes de migrar.

No actualices PHP a ciegas. Primero revisa compatibilidad de módulos, tema y versión exacta. PHP moderno mejora rendimiento y seguridad, pero un módulo antiguo puede convertir la actualización en una tarde larga.

OPcache: imprescindible

OPcache almacena bytecode PHP compilado en memoria, evitando recompilar scripts en cada petición. En producción debería estar activado. Si no lo está, estás dejando rendimiento sobre la mesa.

OPcache es una de esas mejoras silenciosas que no salen en los escaparates, pero sostienen la tienda como vigas bajo un suelo elegante.

Base de datos

PrestaShop depende intensamente de MySQL o MariaDB. Un catálogo grande, muchos filtros, módulos de búsqueda, reglas de precio y estadísticas internas pueden generar consultas pesadas.

Recomendaciones:

• Usar MariaDB/MySQL actualizado y compatible.
• Revisar índices en tablas grandes.
• Limpiar datos antiguos de conexiones, logs y estadísticas si procede.
• Desactivar módulos estadísticos nativos si usas herramientas externas y generan carga excesiva.
• Analizar consultas lentas con slow query log.

Compresión Gzip o Brotli

Activa compresión para HTML, CSS, JS, SVG y JSON. Gzip sigue siendo habitual; Brotli suele comprimir mejor, especialmente en textos. Si usas Cloudflare, LiteSpeed, Nginx moderno o CDN avanzado, Brotli puede estar disponible fácilmente.

Caché del navegador

Los recursos estáticos —imágenes, fuentes, CSS, JS— deben enviarse con cabeceras de caché adecuadas. Esto permite que el navegador reutilice archivos en visitas posteriores. Es una mejora simple y poderosa: como dejar una llave bajo una piedra, pero sin el problema evidente de seguridad que tendría hacerlo de verdad.

CDN

Un CDN puede ayudar si vendes en varias regiones, tienes muchas imágenes o necesitas reducir latencia. Cloudflare, Bunny.net, Fastly, Akamai y otros servicios pueden acelerar recursos estáticos y mejorar disponibilidad.

Pero un CDN no arregla una tienda mal construida. Si el HTML dinámico tarda demasiado en generarse, el CDN será un mensajero rapidísimo esperando a que alguien termine de escribir la carta.

Configuración para desarrollo frente a producción 🧪

Una tienda en desarrollo y una tienda en producción no deberían tener la misma configuración. Una necesita mostrar cambios al instante; la otra necesita servir páginas rápido y sin caprichos.

Una anécdota breve, casi doméstica: una vez pasé media hora creyendo que un cambio CSS no funcionaba. Revisé selectores, prioridad, rutas, permisos. Incluso culpé mentalmente al navegador, ese viejo amigo al que todos acusamos antes de mirar nuestro propio escritorio. Al final era caché. Siempre es caché, excepto cuando no lo es, que entonces también parece caché durante un rato.

Errores frecuentes al optimizar PrestaShop y cómo resolverlos 🛠️

1. La tienda se ve rota después de activar CCC

Posible causa: CSS combinado en orden incorrecto, archivo no compatible, tema mal estructurado o caché antigua.

Solución:

• Vacía la caché desde PrestaShop.
• Borra caché del navegador o prueba en incógnito.
• Desactiva Smart cache CSS y comprueba.
• Regenera assets si tu tema usa herramientas externas.
• Revisa errores 404 en archivos CSS desde la pestaña Network del navegador.

2. El carrito o checkout deja de funcionar

Posible causa: optimización JavaScript incompatible, scripts movidos al final, dependencia de jQuery, conflicto con módulo de pago o transportista.

Solución:

• Desactiva Smart cache JavaScript.
• Desactiva “Mover JavaScript al final”.
• Prueba paso a paso hasta encontrar la opción conflictiva.
• Revisa consola del navegador.
• Actualiza módulo conflictivo o consulta al desarrollador.

3. No se ven los cambios en el tema

Posible causa: caché Smarty, caché del navegador, CDN o OPcache.

Solución:

• Vacía caché de PrestaShop.
• Activa temporalmente “Forzar compilación” en desarrollo.
• Limpia caché del CDN.
• Reinicia PHP-FPM si tienes acceso y OPcache mantiene archivos antiguos.

4. Error 500 al activar optimización Apache

Posible causa: reglas no permitidas en .htaccess, módulo Apache no disponible o directivas bloqueadas por hosting.

Solución:

• Restaura el .htaccess anterior.
• Desactiva la opción desde back office si puedes acceder.
• Regenera .htaccess desde configuración de URLs amigables.
• Consulta al hosting qué directivas están permitidas.

5. La tienda sigue lenta aunque todo está activado

Posible causa: servidor insuficiente, imágenes pesadas, módulos lentos, consultas SQL, exceso de scripts externos, tema sobrecargado.

Solución:

• Mide TTFB.
• Audita módulos instalados.
• Optimiza imágenes en WebP o AVIF cuando sea posible.
• Reduce sliders, popups y scripts de terceros.
• Analiza consultas lentas.
• Valora migrar a un hosting especializado en PrestaShop.

Qué impacto real puedes esperar 📊

Conviene ser honesto. La pestaña Parámetros Avanzados > Rendimiento puede mejorar notablemente una tienda mal configurada, pero no sustituye una optimización integral.

Impacto habitual por área:

En tiendas reales, he visto mejoras de varios segundos simplemente activando caché y corrigiendo CCC. También he visto tiendas donde esos ajustes apenas movían la aguja porque el problema estaba en un módulo de filtros haciendo consultas monstruosas. La optimización es detective, no adivinación.

La configuración ideal según el tipo de tienda 🛒

Tienda pequeña con catálogo simple

• Caché Smarty activada.
• Compilación: recompilar si hay cambios.
• CCC CSS activado.
• CCC JavaScript activado solo si no rompe funcionalidades.
• Sistema de archivos como caché suele ser suficiente.
• Desactivar combinaciones si no hay variantes.

Tienda mediana con módulos comerciales

• Activar caché Smarty y CCC con pruebas completas.
• Revisar cada módulo externo.
• Usar OPcache.
• Considerar Memcached, Redis o APCu si el servidor lo permite.
• Optimizar imágenes y usar CDN si hay tráfico geográfico amplio.
• Medir checkout tras cada cambio.

Tienda grande con alto tráfico

• Infraestructura VPS/cloud/dedicada correctamente dimensionada.
• PHP-FPM ajustado.
• OPcache configurado con memoria suficiente.
• Redis o Memcached evaluado con pruebas de carga.
• Base de datos optimizada y monitorizada.
• CDN para estáticos.
• Auditoría de módulos y consultas SQL.
• Entorno staging obligatorio antes de tocar producción.

Checklist práctica para configurar “Parámetros Avanzados > Rendimiento” en PrestaShop ✅

Si quieres una lista accionable, aquí va una configuración profesional para producción:

1. Haz copia de seguridad completa.
2. Mide velocidad actual con PageSpeed Insights, WebPageTest o GTmetrix.
3. Ve a Parámetros Avanzados > Rendimiento.
4. Configura Smarty en “Recompilar plantillas si los archivos han sido actualizados”.
5. Activa caché de Smarty.
6. Activa Smart cache para CSS.
7. Limpia caché y revisa diseño en escritorio y móvil.
8. Activa Smart cache para JavaScript.
9. Prueba carrito, checkout, login, filtros, buscador y módulos de pago.
10. Activa minificación HTML si todo funciona.
11. Activa compresión de JavaScript inline solo tras comprobar integraciones externas.
12. Prueba mover JavaScript al final; si hay errores, desactívalo.
13. Activa optimización Apache solo si tu servidor es compatible.
14. Evalúa caché avanzada: Memcached, APCu o Redis si tienes soporte real del servidor.
15. Desactiva funcionalidades opcionales que no uses.
16. Vuelve a medir rendimiento y compara datos.
17. Documenta cada cambio para poder revertirlo.

Configuración recomendada resumida para producción 🧾

Más allá de la pestaña de rendimiento: lo que realmente acelera PrestaShop 🌐

Sería cómodo pensar que toda la velocidad vive dentro de una sola pantalla del back office. Pero PrestaShop, como cualquier ecommerce serio, es un organismo. La pestaña de rendimiento es el sistema nervioso; el hosting, el corazón; la base de datos, el aparato digestivo; los módulos, bueno, algunos son vitaminas y otros parecen piedras en el zapato.

Para optimizar PrestaShop de verdad, revisa también:

• Imágenes: usa formatos modernos como WebP cuando sea posible, dimensiones correctas y compresión sin pérdida visual grave.
• Lazy loading: carga diferida de imágenes fuera de pantalla.
• Fuentes: limita variantes, usa font-display: swap y evita cargar familias innecesarias.
• Módulos: elimina los que no uses. Desinstalar no siempre borra todo; revisa hooks y tablas residuales.
• Hooks: algunos módulos se enganchan en posiciones donde no aportan nada y consumen recursos.
• Scripts externos: chats, píxeles, mapas, widgets sociales y herramientas de marketing pueden pesar más que la propia tienda.
• Base de datos: limpia tablas de logs, conexiones y carritos antiguos si procede.
• Plantilla: un tema ligero y bien construido gana a cualquier tema espectacular que cargue medio internet para mostrar un banner.

En rendimiento web hay una verdad poco romántica: lo que no se carga, carga rapidísimo. El archivo más optimizado es el que nunca se solicita.

Cómo probar después de cambiar la configuración 🔍

No basta con mirar la home. La home es el escaparate, pero el dinero se decide en lugares menos fotogénicos: carrito, checkout, login, buscador, ficha de producto.

Después de modificar Parámetros Avanzados > Rendimiento, revisa como mínimo:

• Home.
• Página de categoría.
• Ficha de producto con combinaciones.
• Añadir al carrito.
• Carrito.
• Checkout completo.
• Registro de cliente.
• Inicio de sesión.
• Aplicación de cupones.
• Cálculo de transportes.
• Pago en entorno de pruebas.
• Emails transaccionales si algún módulo depende de procesos dinámicos.
• Versión móvil real, no solo redimensionar el navegador.

Y revisa los logs. Siempre. Los logs son esos diarios íntimos donde la tienda confiesa lo que en pantalla intenta disimular.

Una respuesta honesta: ¿cuál es “la mejor” configuración?

La mejor configuración en Parámetros Avanzados > Rendimiento de PrestaShop es aquella que consigue tres cosas al mismo tiempo:

1. Reducir trabajo del servidor.
2. Mejorar la carga del navegador.
3. No romper el proceso de compra.

La tercera parece obvia, pero se olvida con una facilidad casi artística. Una tienda que carga en 700 milisegundos pero no permite pagar es una obra conceptual, no un ecommerce.

Para la mayoría de tiendas en producción, la configuración ganadora será:

• Smarty: caché activada y recompilación solo si hay cambios.
• CCC: CSS activado; JavaScript activado tras pruebas; HTML minificado si no hay conflictos.
• JavaScript al final: activado si el tema y módulos lo toleran.
• Optimización Apache: activada en servidores compatibles.
• Caché avanzada: Memcached, APCu o Redis solo con soporte real y pruebas.
• Funcionalidades opcionales: desactivar únicamente lo innecesario.

Y, por encima de todo, medir. Porque la velocidad no se declara: se demuestra. Cada tienda tiene su temperamento, sus manías, su pequeña meteorología interna. Optimizar PrestaShop es escucharla hasta distinguir el ruido del síntoma, el síntoma del problema y el problema de esa solución brillante que alguien instaló un viernes por la tarde.

Al final, una buena configuración de rendimiento no busca impresionar al administrador, sino desaparecer ante el cliente. Que la página cargue, que el producto se vea, que el carrito responda, que el pago fluya. Rápido. Limpio. Sin teatro. Como una puerta bien engrasada: nadie la celebra, pero todos agradecen que no chirríe. 🚀