¿Cuál es la mejor configuración en “Parámetros Avanzados > Rendimiento” de PrestaShop? ⚙️🚀
La pestaña Parámetros Avanzados > Rendimiento de PrestaShop parece, a primera vista, una sala de mandos: botones, cachés, compilaciones, compresiones, servidores multimedia, depuración. Uno entra buscando velocidad y puede salir con el carrito roto. Hermosa paradoja: el lugar creado para acelerar una tienda también puede convertirla en una carreta si se toca con entusiasmo y poca cautela.
La buena noticia es que sí existe una configuración recomendable. La menos cómoda es que no hay una única receta universal. Una tienda PrestaShop con 80 productos, tema clásico y hosting decente no respira igual que un catálogo con 80.000 referencias, combinaciones infinitas, multitienda, ERP conectado y un checkout adornado con módulos como árbol de Navidad en diciembre.
Así que vamos a hacer lo sensato: configurar para producción, explicar qué hace cada opción, cuándo activarla, cuándo desconfiar de ella y cómo medir si realmente mejora. Porque optimizar sin medir es como afinar un piano con guantes de boxeo: mucho gesto, poca música.
Contenido rápido
- Configuración recomendada para producción
- Smarty: compilación, caché y plantillas
- Modo depuración y overrides
- Funcionalidades opcionales: combinaciones, características y grupos
- CCC: combinar, comprimir y cachear CSS/JavaScript
- Servidores multimedia y CDN
- Sistema de caché: APCu, Memcached, Redis y compañía
- Cómo probar sin romper la tienda
- Preguntas frecuentes
La configuración recomendada para una tienda en producción 🛒
Si tienes una tienda PrestaShop publicada, con clientes reales, pedidos reales y ese sudor frío tan real cuando algo falla en el checkout, esta es una base profesional y segura para empezar.
| Sección | Opción | Recomendación en producción | Comentario profesional |
|---|---|---|---|
| Smarty | Compilación de plantillas | Nunca recompilar si la tienda es estable; Recompilar si los archivos han sido actualizados si despliegas cambios con frecuencia | La opción más rápida suele ser “Nunca recompilar”, pero exige limpiar caché tras cambios de tema o módulos. |
| Smarty | Caché | Sí | Imprescindible. Desactivarlo en producción es pedirle a PrestaShop que piense demasiado en cada visita. |
| Smarty | Tipo de caché | Sistema de archivos | Es lo habitual y estable para plantillas. Asegúrate de que el disco sea rápido, idealmente SSD/NVMe. |
| Smarty | Limpiar caché | Nunca limpiar automáticamente en tiendas estables; limpiar manualmente tras cambios | La limpieza automática es cómoda, pero la comodidad, en rendimiento, a veces cobra intereses. |
| Modo depuración | Modo debug | No | Jamás activo en producción salvo diagnóstico puntual y controlado. |
| Modo depuración | Desactivar módulos no desarrollados por PrestaShop | No | Solo para pruebas. Activarlo puede apagar pagos, envíos, analítica o integraciones. |
| Modo depuración | Desactivar overrides | No | Solo para diagnosticar conflictos. Muchos módulos dependen de overrides. |
| Funcionalidades opcionales | Combinaciones | Desactivar solo si no usas variantes | Si vendes tallas, colores o formatos, no lo toques. |
| Funcionalidades opcionales | Características | Desactivar si no las usas | Puede mejorar consultas y administración, pero afecta filtros y fichas técnicas. |
| Funcionalidades opcionales | Grupos de clientes | Desactivar solo en tiendas muy simples | Cuidado con precios especiales, B2B, impuestos, descuentos y módulos de fidelización. |
| CCC | Smart cache para CSS | Sí, tras probar diseño | Reduce peso y peticiones, aunque algunos temas mal hechos protestan como puerta vieja. |
| CCC | Smart cache para JavaScript | Sí, tras probar carrito y checkout | Es útil, pero puede romper scripts dependientes del orden de carga. |
| CCC | Minificar HTML | Sí | Suele ser seguro. Mejora modesta, pero suma. |
| CCC | Comprimir JavaScript en HTML | Sí, con pruebas | Revisar especialmente módulos de pago, consentimiento de cookies y píxeles publicitarios. |
| CCC | Mover JavaScript al final | Sí, si el tema lo soporta | Puede mejorar la carga percibida, pero algunos módulos antiguos necesitan JS en cabecera. |
| CCC | Optimización de Apache | Sí si usas Apache con .htaccess |
En Nginx no aplica igual; la configuración se hace en el servidor. |
| Servidores multimedia | Media server 1, 2, 3 | Vacío, salvo CDN o subdominios bien configurados | No inventes subdominios: deben apuntar correctamente a los archivos estáticos. |
| Caché | Usar caché | Sí solo si tienes APCu, Memcached o Redis bien configurado | Una caché lenta es como un camarero que anota rápido y sirve mañana. |
Resumen ejecutivo: en una tienda PrestaShop estable, activa caché Smarty, usa compilación mínima, activa CCC con pruebas, deja debug desactivado, no uses servidores multimedia salvo CDN real y habilita caché avanzada únicamente si el servidor la soporta con solvencia.
Smarty: donde PrestaShop convierte plantillas en páginas visibles 🎭
Smarty es el motor de plantillas que PrestaShop ha utilizado durante años para construir la parte visual de la tienda. Dicho de forma sencilla: toma archivos de tema, variables de producto, módulos, precios, imágenes, textos y los convierte en HTML que el navegador puede mostrar.
Sin caché, PrestaShop repite trabajo. Con caché, recuerda. Y en comercio electrónico, recordar con inteligencia es vender con menos fricción.
Compilación de plantillas
Esta opción controla cuándo PrestaShop recompila los archivos de plantilla. Las alternativas pueden variar ligeramente según la versión, pero normalmente encontrarás algo parecido a esto:
- Nunca recompilar los archivos de plantilla: máxima velocidad en producción. Ideal si no estás modificando el tema constantemente.
- Recompilar las plantillas si los archivos han sido actualizados: opción equilibrada. Algo menos agresiva, pero más cómoda en tiendas con cambios frecuentes.
- Forzar compilación: útil en desarrollo. En producción, mejor evitarla salvo diagnóstico puntual.
La configuración más rápida es “Nunca recompilar”. Pero tiene una condición: cada vez que cambies el tema, instales ciertos módulos, actualices plantillas o modifiques archivos .tpl, deberás limpiar la caché manualmente. Si no, puedes terminar mirando una tienda que vive en el pasado, como esos relojes de estación que se quedaron detenidos y aun así parecen importantes.
Recomendación práctica: si tienes una tienda muy estable, usa “Nunca recompilar”. Si tu equipo hace cambios frecuentes en tema o módulos, usa “Recompilar si los archivos han sido actualizados” hasta estabilizar el proyecto.
Caché Smarty
Aquí no hay mucho drama: debe estar activada en producción. Desactivar la caché Smarty en una tienda real suele aumentar el tiempo de respuesta del servidor y cargar innecesariamente CPU y disco. Puede ser útil durante desarrollo, pero en producción es una invitación al cansancio.
La caché funciona como una despensa bien organizada: no cocina desde cero cada vez que alguien tiene hambre. Sirve lo que ya está preparado cuando puede hacerlo.
Tipo de caché: sistema de archivos
En la mayoría de instalaciones PrestaShop, el tipo de caché de Smarty más habitual y recomendable es el sistema de archivos. Es estable, simple y suficientemente rápido si el hosting usa discos SSD o NVMe.
Ahora bien, si la tienda está en un alojamiento saturado, con I/O lento, permisos mal configurados o carpetas de caché gigantescas, el sistema de archivos puede transformarse en un pequeño pantano. No por culpa de Smarty, sino por la infraestructura. La tecnología, pobre, a veces carga con pecados ajenos.
Limpiar caché: automático o manual
PrestaShop permite limpiar caché automáticamente cuando algo cambia o no limpiarla nunca salvo intervención manual. Para rendimiento puro, la opción más eficiente suele ser no limpiar automáticamente. Pero exige disciplina.
Si tu tienda cambia poco, perfecto. Si instalas módulos cada dos días, ajustas banners, tocas plantillas y pruebas campañas como quien cambia de sombrero, quizá prefieras una opción más conservadora durante un tiempo.
- Tienda estable: no limpiar caché automáticamente; limpiar manualmente tras despliegues.
- Tienda en evolución: limpiar cuando haya modificaciones puede evitar incoherencias visuales.
- Entorno de desarrollo: forzar recompilación y limpiar caché con frecuencia.
Modo depuración: medicina fuerte, no bebida diaria 🧪
El modo debug de PrestaShop es maravilloso cuando algo falla. Muestra errores, avisos, trazas, problemas de módulos, conflictos de overrides y otros detalles que en producción deberían estar tan ocultos como la contabilidad creativa de algunos imperios.
En producción debe estar desactivado. No solo por rendimiento, sino por seguridad. Un error visible puede revelar rutas internas del servidor, nombres de módulos, consultas, clases PHP o pistas que un atacante agradecería con una sonrisa.
Desactivar módulos no desarrollados por PrestaShop
Esta opción sirve para diagnosticar si un problema viene de módulos externos. No es una optimización normal. Si la activas en producción, puedes dejar inactivos módulos de pago, transporte, facturación, SEO, analítica, píxeles de conversión o integraciones con ERP.
Es un bisturí, no una escoba.
Desactivar todos los overrides
Los overrides permiten modificar comportamientos internos de PrestaShop. Muchos módulos los han usado históricamente para añadir funciones. Desactivarlos ayuda a detectar conflictos, pero también puede alterar procesos importantes.
Mi recomendación es clara: mantén esta opción desactivada salvo en pruebas controladas. Y si necesitas activar algo así, hazlo en una copia de staging, no en la tienda que está facturando mientras tú “solo miras una cosa”. Esa frase ha precedido a más incendios digitales que cualquier otra.
Funcionalidades opcionales: lo que no usas también pesa 🧱
PrestaShop es generoso. Ofrece combinaciones, características, grupos de clientes, descuentos, reglas de catálogo, multitienda, multidioma, multi casi todo. Esa abundancia es una bendición y una carga. La antítesis es brutal: flexibilidad para vender mejor, complejidad para cargar más lento.
En la sección de funcionalidades opcionales puedes desactivar partes del sistema que no utilizas. Bien hecho, esto reduce consultas, simplifica lógica y mejora administración. Mal hecho, puede amputar funciones necesarias.
Combinaciones de productos
Las combinaciones son necesarias si vendes productos con variantes: talla, color, capacidad, material, pack, formato, etc. Si vendes una camiseta en cinco tallas y ocho colores, las necesitas. Si vendes libros, piezas únicas o productos sin variantes, podrías desactivarlas.
El impacto puede ser importante en catálogos grandes. Las combinaciones multiplican registros y consultas. Un producto simple es una piedra; un producto con cientos de combinaciones es una cantera.
Cuidado: no desactives combinaciones si algún producto las usa. Antes revisa catálogo, filtros, tema, módulos de importación y sincronizaciones externas.
Características
Las características permiten mostrar datos técnicos: composición, dimensiones, compatibilidad, potencia, año, material, etc. También suelen alimentar filtros de navegación facetada.
Si tu tienda no usa características, puedes desactivarlas. Si dependes de filtros por atributos técnicos, comparadores, fichas enriquecidas o módulos SEO que las leen, déjalas activas.
Grupos de clientes
Los grupos de clientes permiten precios distintos, descuentos, reglas B2B, condiciones especiales, visualización diferenciada y segmentación. En una tienda muy simple podrían no ser necesarios. Pero en muchas instalaciones están conectados con impuestos, precios específicos, módulos de fidelización o reglas comerciales.
Mi consejo: no los desactives sin auditar antes. Es una opción seductora porque promete ligereza, pero puede tocar nervios profundos del negocio.
CCC: combinar, comprimir y cachear CSS y JavaScript ⚡
CCC significa Combine, Compress and Cache: combinar, comprimir y cachear. Es una de las zonas más famosas de la pestaña de rendimiento de PrestaShop, y también una de las más propensas a generar supersticiones.
Antes de HTTP/2, reducir peticiones era casi religión. Con HTTP/2 y HTTP/3, el navegador maneja múltiples recursos mejor que antes, así que combinar archivos ya no siempre es una victoria automática. Aun así, minificar y cachear CSS/JS sigue siendo útil en muchas tiendas PrestaShop, especialmente si el tema y los módulos generan demasiados archivos.
Smart cache para CSS
Normalmente conviene activarlo. Reduce y agrupa archivos CSS, lo que puede mejorar tiempos de carga y puntuaciones en herramientas como PageSpeed Insights, Lighthouse o WebPageTest.
Después de activarlo, revisa:
- Página de inicio.
- Categorías.
- Ficha de producto.
- Carrito.
- Checkout.
- Mi cuenta.
- Formularios y popups.
- Versión móvil.
Un CSS mal combinado puede desordenar una página con la elegancia de un gato cruzando una mesa puesta.
Smart cache para JavaScript
También suele ser recomendable, pero requiere más prudencia. JavaScript depende mucho del orden de carga. Si un módulo espera que jQuery esté disponible antes de ejecutarse y la combinación altera ese orden, aparecerán errores silenciosos. Y los errores silenciosos son los peores: no gritan, solo dejan de vender.
Tras activar la caché inteligente de JavaScript, prueba especialmente:
- Añadir al carrito.
- Actualizar cantidades.
- Seleccionar combinaciones de producto.
- Aplicar cupones.
- Elegir transportista.
- Completar pago.
- Aceptar cookies.
- Validar formularios.
- Eventos de analítica y píxeles.
Minificar HTML
Activarlo suele ser seguro. Elimina espacios, saltos y comentarios innecesarios del HTML. No esperes milagros; es más una lima fina que un martillo. Pero en rendimiento web, las pequeñas mejoras acumuladas cuentan.
Comprimir JavaScript dentro del HTML
Puede activarse, pero con pruebas. Algunos módulos insertan scripts inline para pagos, seguimiento, chat, consentimiento de cookies o personalización. Si la minificación es demasiado agresiva, pueden aparecer errores.
Mover JavaScript al final
Esta opción puede mejorar la carga percibida porque permite que el HTML y parte del contenido visual aparezcan antes de ejecutar scripts. En términos de experiencia de usuario, es valioso: el visitante siente que la página responde antes.
Pero no todos los temas antiguos lo toleran. Algunos scripts fueron escritos en una época en la que el JavaScript vivía en la cabecera como un aristócrata, y bajarlo al sótano puede ofenderlo.
Recomendación: activa “Mover JavaScript al final” solo después de probar producto, carrito, checkout y módulos críticos. Si algo falla, desactívalo antes de culpar al servidor.
Optimización de Apache
Esta opción añade o ajusta reglas en el archivo .htaccess para mejorar compresión, caché de navegador y gestión de recursos estáticos, siempre que el servidor use Apache y permita esas directivas.
Si tu tienda funciona sobre Nginx, LiteSpeed o una arquitectura con proxy inverso, esta opción puede no tener efecto o ser insuficiente. En Nginx, por ejemplo, las reglas equivalentes se configuran en el bloque del servidor, no en .htaccess.
En un entorno profesional, además de tocar esta opción, conviene revisar:
- Compresión Gzip o Brotli.
- Cabeceras
Cache-Controlpara imágenes, CSS, JS y fuentes. - HTTP/2 o HTTP/3.
- Expiración de recursos estáticos.
- Configuración de CORS para fuentes si usas CDN.
Servidores multimedia: útiles si existen, peligrosos si se improvisan 🌐
PrestaShop permite definir servidores multimedia, normalmente subdominios como:
static1.tudominio.comstatic2.tudominio.comcdn.tudominio.com
La idea original era distribuir recursos estáticos —imágenes, CSS, JavaScript— en dominios diferentes para aumentar descargas paralelas y servir archivos sin cookies. En la era de HTTP/1.1 tenía mucho sentido. Con HTTP/2 y HTTP/3, el beneficio puede ser menor, y en algunos casos incluso contraproducente si introduces DNS extra, certificados mal configurados o latencia adicional.
¿Cuándo usarlos?
- Cuando tienes un CDN real como Cloudflare, Fastly, BunnyCDN, Akamai, Amazon CloudFront u otro proveedor bien configurado.
- Cuando los subdominios apuntan correctamente al mismo contenido estático.
- Cuando todos funcionan con HTTPS válido.
- Cuando las fuentes, imágenes y recursos no generan errores CORS.
- Cuando has medido mejora real en TTFB, LCP o tiempo de descarga.
¿Cuándo dejarlos vacíos? En la mayoría de tiendas pequeñas o medianas sin CDN específico. Poner subdominios porque “suena rápido” es como pegarle un alerón a una bicicleta: llamativo, sí; aerodinámico, no necesariamente.
Sistema de caché: APCu, Memcached, Redis y el mito de la velocidad instantánea 🧠
En la parte inferior de la pestaña de rendimiento, muchas versiones de PrestaShop ofrecen activar un sistema de caché adicional. Según versión, instalación y módulos, puedes encontrar opciones como APC/APCu, Memcached o soluciones basadas en Redis mediante módulos o configuración adicional.
Conviene aclarar algo importante: esta caché no sustituye automáticamente a una caché de página completa. No convierte PrestaShop en un sitio estático. Ayuda a guardar ciertos datos y resultados para reducir trabajo repetido, pero el impacto depende mucho del servidor, del catálogo, de los módulos y del tráfico.
APCu
APCu es una caché en memoria local para PHP. Suele funcionar bien en servidores de una sola máquina. Es rápida porque vive cerca del proceso PHP, como una libreta en el bolsillo.
Es recomendable cuando:
- La tienda está en un único servidor.
- APCu está instalado y habilitado para PHP-FPM o el handler correspondiente.
- Hay memoria suficiente.
- No estás en un hosting compartido excesivamente limitado.
Memcached
Memcached es un sistema de caché en memoria que puede vivir en el mismo servidor o en otro nodo. Es útil en arquitecturas más complejas, aunque no siempre más rápido si está mal instalado o demasiado lejos.
Recomendable cuando:
- Tienes tráfico considerable.
- El servidor Memcached está en la misma red privada o máquina.
- Hay monitorización de memoria, conexiones y evictions.
- Tu equipo técnico sabe mantenerlo.
Redis
Redis no siempre aparece como opción nativa en todas las versiones de PrestaShop desde el panel clásico, pero es común verlo mediante módulos, adaptaciones o configuraciones avanzadas. Puede ser excelente para caché, sesiones, colas o integraciones, pero requiere criterio.
Redis es veloz, sí. También es una navaja afilada. En buenas manos corta fino; en malas, deja marcas.
¿Activar “Usar caché” siempre?
No. Esta es una de esas respuestas que parecen decepcionantes hasta que salvan una tienda.
Actívala si el sistema de caché está correctamente instalado, es estable y mejora métricas reales. No la actives si:
- No sabes si APCu, Memcached o Redis están disponibles.
- El hosting compartido no garantiza memoria suficiente.
- Memcached está en un servidor remoto con latencia alta.
- No puedes revisar logs ni errores PHP.
- La tienda empieza a mostrar datos inconsistentes.
Importante: no confundas la caché de PrestaShop con OPcache. OPcache es una caché de código PHP a nivel de servidor y debería estar activada prácticamente siempre en producción. No se configura desde esta pestaña, pero es fundamental para el rendimiento.
OPcache, PHP y servidor: lo que la pestaña no puede arreglar 🛠️
Hay una ironía frecuente en proyectos PrestaShop: se afinan con devoción las opciones del back office mientras el servidor corre una versión de PHP antigua, sin OPcache, con memoria justa y base de datos fatigada. Es como encerar un coche sin motor.
La pestaña Parámetros Avanzados > Rendimiento importa, mucho. Pero no hace magia. Para una optimización PrestaShop seria, revisa también:
- Versión de PHP compatible: usa una versión soportada por tu versión exacta de PrestaShop. PrestaShop 1.7, 8 y futuras ramas tienen matrices de compatibilidad distintas.
- OPcache activado: esencial para reducir compilación repetida de PHP.
- Memoria PHP suficiente: muchas tiendas necesitan 256 MB, 512 MB o más según módulos y catálogo.
- Base de datos optimizada: índices, tablas limpias, consultas lentas monitorizadas.
- Disco rápido: SSD o NVMe, especialmente para caché y muchas imágenes.
- HTTP/2 o HTTP/3: mejora entrega de recursos.
- Compresión Brotli o Gzip: reduce transferencia de HTML, CSS y JS.
- Imágenes optimizadas: WebP o AVIF cuando sea posible, tamaños correctos, lazy loading.
- Módulos auditados: un solo módulo mal programado puede arruinar una configuración perfecta.
Una tienda rápida no nace de un interruptor. Nace de una suma de decisiones pequeñas, casi humildes, como gotas que terminan llenando un depósito.
Cómo probar la configuración sin convertir clientes en conejillos de Indias 📊
Antes de tocar nada, crea una copia de seguridad. Sí, es obvio. También es obvio mirar antes de cruzar y aun así las ambulancias siguen trabajando.
El método profesional sería este:
- Crear un entorno de staging o copia de pruebas.
- Anotar la configuración actual con capturas o documentación interna.
- Medir antes de cambiar: TTFB, LCP, INP, CLS, peso total, número de peticiones y tiempo de carga.
- Cambiar una opción cada vez. No cinco. Una.
- Limpiar caché de PrestaShop, navegador y CDN si existe.
- Calentar caché visitando páginas clave varias veces.
- Probar flujos críticos: navegación, búsqueda, producto, carrito, pago, registro, emails.
- Comparar métricas con herramientas fiables.
- Revisar logs de PHP, servidor web y PrestaShop.
- Aplicar en producción en horario de bajo tráfico.
Herramientas útiles
- PageSpeed Insights: útil para Core Web Vitals y recomendaciones generales.
- Lighthouse: práctico desde Chrome DevTools.
- WebPageTest: excelente para cascadas de carga y comparación avanzada.
- GTmetrix: visual y cómodo para seguimiento.
- Chrome DevTools: imprescindible para errores JavaScript y red.
- Blackfire, New Relic o Tideways: para profiling PHP profesional.
- Slow query log de MySQL/MariaDB: para detectar consultas lentas.
No te obsesiones solo con la puntuación. Mira la experiencia real. Una tienda puede tener un 96 en laboratorio y aun así un checkout lento como domingo de agosto. Lo importante es que el usuario pueda navegar, entender, comprar y pagar sin esperar a que envejezca la sesión.
Configuración recomendada según escenario 🎯
| Escenario | Configuración sugerida | Precauciones |
|---|---|---|
| Desarrollo local | Forzar compilación, caché Smarty desactivada o flexible, debug activado | No copiar esta configuración a producción. |
| Tienda nueva en pruebas | Recompilar si hay cambios, caché Smarty activa, CCC en pruebas | Validar tema y módulos antes del lanzamiento. |
| Tienda estable en producción | Nunca recompilar, caché Smarty activa, CCC activo, debug desactivado | Limpiar caché tras actualizaciones. |
| Tienda con muchos módulos | Activar CCC gradualmente, probar JavaScript con cuidado | El checkout y pagos son prioridad absoluta. |
| Catálogo grande | Desactivar funciones no usadas, caché avanzada si el servidor lo permite | Revisar base de datos, filtros, índices y consultas lentas. |
| Multitienda o alto tráfico | Caché avanzada bien diseñada, CDN, OPcache, monitorización | No improvisar Memcached o Redis sin supervisión técnica. |
Errores comunes al optimizar PrestaShop 🧯
- Activar todo sin probar: la velocidad no premia la temeridad.
- Dejar debug activo: perjudica rendimiento y expone información sensible.
- Usar servidores multimedia inexistentes: genera errores, latencia y recursos rotos.
- Ignorar el checkout: una home rápida no compensa un pago roto.
- No limpiar caché tras cambios: provoca diseños antiguos, traducciones que no aparecen o módulos que parecen fallar.
- Confundir caché con solución universal: si una consulta SQL tarda tres segundos, esconderla bajo una alfombra no arregla el suelo.
- Instalar módulos de optimización sin criterio: algunos ayudan; otros añaden peso con una sonrisa comercial.
- No revisar imágenes: muchas tiendas son lentas no por PHP, sino por servir fotografías gigantes como si cada cliente tuviera fibra óptica celestial.
Preguntas frecuentes sobre rendimiento en PrestaShop ❓
¿Cuál es la mejor configuración de Smarty en PrestaShop?
Para producción, lo habitual es activar la caché Smarty, usar sistema de archivos y seleccionar “Nunca recompilar” si la tienda está estable. Si haces cambios frecuentes en plantillas, puedes usar “Recompilar si los archivos han sido actualizados” hasta terminar el desarrollo.
¿Debo activar CCC en PrestaShop?
Sí, normalmente conviene activar CCC para CSS, JavaScript y HTML, pero siempre probando la tienda completa. La combinación y minificación de JavaScript puede causar conflictos en temas antiguos o módulos mal desarrollados.
¿La caché de PrestaShop mejora mucho la velocidad?
Puede mejorarla, especialmente en tiendas con tráfico y consultas repetidas, pero depende del servidor. APCu, Memcached o Redis mal configurados pueden empeorar el rendimiento. Además, no sustituyen una buena configuración de PHP, OPcache, base de datos y servidor web.
¿Puedo dejar el modo debug activo si no se ven errores?
No. El modo debug debe estar desactivado en producción. Aunque no muestre errores visibles, puede afectar rendimiento y exponer información técnica si ocurre un fallo.
¿Conviene usar CDN con PrestaShop?
Sí, especialmente en tiendas con tráfico internacional, muchas imágenes o campañas de alto volumen. Pero debe configurarse bien: HTTPS, caché correcta, purgado, CORS para fuentes y compatibilidad con módulos. Un CDN mal configurado solo reparte el desorden más lejos.
¿Qué hago si al activar CCC se rompe el diseño?
Desactiva primero la opción problemática, limpia caché y revisa errores en la consola del navegador. Después identifica si el conflicto viene del tema, de un módulo concreto o del orden de carga. No sigas activando opciones esperando que el caos se ordene por vergüenza.
La configuración ganadora: rápida, prudente y medible 🏁
La mejor configuración en Parámetros Avanzados > Rendimiento de PrestaShop no es la que activa más interruptores, sino la que reduce trabajo inútil sin romper funciones esenciales. Esa es la diferencia entre optimizar y jugar a la ruleta con el carrito.
Para una tienda en producción, el camino sólido es este: Smarty cache activada, compilación mínima, modo debug desactivado, funciones opcionales apagadas solo si no se usan, CCC activado con pruebas, servidores multimedia únicamente con CDN real y caché avanzada solo si el servidor está preparado.
La velocidad no es un adorno técnico. Es confianza. Es conversión. Es ese instante casi invisible en el que un cliente decide seguir navegando en lugar de cerrar la pestaña. Y en comercio electrónico, a veces, medio segundo es la frontera entre una venta y un silencio.