¿Cómo limpio correctamente la caché de PrestaShop?

Para limpiar correctamente la caché de PrestaShop, empieza en el back office: Advanced Parameters > Performance y haz clic en Clear cache. Eso basta para la mayoría de cambios de plantillas, traducciones y configuración.Página Performance - el botón Clear cache y los controles de caché.Cuando un cambio sigue sin aparecer, limpia las capas más profundas en el orden correcto: primero los archivos de PrestaShop, luego OPcache y después cualquier CDN, Varnish o caché de página completa situada delante de la tienda.# Run from the PrestaShop root. This deletes cache contents, not the cache directories themselves. find var/cache/prod -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + find var/cache/dev -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + # Older PS 1.6-style installs may also use these Smarty paths: find cache/smarty/compile -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + find cache/smarty/cache -mindepth 1 -maxdepth 1 -exec rm -rf -- {} + # Reset web OPcache by reloading the PHP service: sudo systemctl reload php8.2-fpm # Apache/mod_php alternative: sudo systemctl reload apache2No confíes en un comando opcache_reset() solo por CLI a menos que sepas que CLI y PHP web comparten el mismo pool de OPcache. En un hosting PHP-FPM normal, recargar PHP-FPM es el reinicio fiable. Después de una limpieza a nivel de servidor, asegúrate de que el usuario del servidor web puede volver a escribir en los directorios de caché; una propiedad incorrecta tras una limpieza como root es una causa común de nuevos errores 500.El error habitual es limpiar solo la caché del back office y asumir que OPcache o un proxy inverso harán lo mismo. No lo hacen. Si quieres calentamiento de caché y purga de CDN automatizados en lugar de hacerlo a mano, Performance Revolution incluye calentamiento de caché y lógica de purga de CDN, e Redis Dashboard & Key Manager ayuda a gestionar un backend de caché Redis.

¿Cuánta RAM necesita PrestaShop?

Aquí hay dos números separados y confundirlos es el error más común.PHP memory_limit (por solicitud). Esto es lo que PrestaShop consume realmente por carga de página o acción admin. La documentación oficial de PrestaShop 9 recomienda al menos 512 MB. PrestaShop 8 funcionaba bien con 256 MB; el salto en PS 9 refleja el stack Symfony más pesado del back office. Import/export, instalaciones de módulos, actualizaciones masivas de productos y el asistente de migración necesitan este techo más alto, si lo pones más bajo, tendrás pantallas en blanco o errores fatales "Allowed memory size exhausted".RAM del servidor (host). Es la memoria total del VPS o servidor dedicado, compartida entre workers PHP-FPM, MySQL/MariaDB, servidor web, Redis o Memcached, cron jobs y el SO. Bases prácticas:Menos de 1 000 SKUs, tráfico ligero: 2 GB es el suelo realista.Catálogo medio (1 000 a 20 000 SKUs), caché activada: 4 GB es cómodo.Catálogo grande (50 000+ SKUs) o multitienda: 8 GB+ y una pasada dedicada de ajuste de MariaDB.Importaciones masivas, regeneración de imágenes, grandes trabajos de migración: añade margen o mueve las tareas pesadas a cron CLI.Si la tienda va lenta, la RAM rara vez es lo primero que arreglar, empieza por full-page cache, Redis, OPcache y un tema más ligero. Consulta nuestra guía de optimización de rendimiento de PrestaShop para el orden real de operaciones.Una comprobación útil de capacidad no es simplemente memory_limit x max_children, porque no todos los workers alcanzan el límite a la vez, pero la fórmula te dice si el host es imposible sobre el papel:PHP-FPM workers x realistic worker memory + MariaDB buffer pool + Redis/OPcache + OS headroomPor ejemplo, diez workers PHP ocupados con un techo de 512 MB necesitan más que un VPS de 2 GB una vez incluida MariaDB, aunque la mayoría de solicitudes usen menos que el techo. Mantén límites CLI altos para regeneración de imágenes e importaciones, pero evita dejar demasiados workers PHP-FPM ejecutándose en un servidor pequeño. Si el Linux OOM killer empieza a matar PHP o MariaDB, bajar el recuento de workers y corregir la presión de caché/base de datos suele ser mejor que solo subir memory_limit.

¿Qué datos de monitorización puede almacenar el módulo?

Performance Revolution almacena datos técnicos de monitorización de tu tienda, pero no todas las tablas de monitorización tienen el mismo perfil de privacidad. Las filas RUM se basan en tiempos, URL, tipo de dispositivo y contexto de la tienda, no en campos de perfil del cliente; el registro de consultas lentas es distinto porque guarda texto SQL sin procesar y contexto de stack trace, así que trátalo como datos de diagnóstico potencialmente sensibles si tus consultas contienen identificadores de cliente, carrito o pedido.En concreto, el módulo conserva estas tablas:Métricas de rendimiento - mediciones temporizadas con tipo de métrica, valor y contexto JSON, usadas para representar cómo se comporta la tienda a lo largo del tiempo.Métricas agregadas - valores resumidos por hora, día, semana y mes, incluyendo suma, media, mínimo, máximo y recuento, para que los paneles sigan siendo útiles en rangos de fechas largos.Consultas lentas - hash de consulta, texto SQL, tiempo de ejecución, controlador, stack trace, recuento de ocurrencias y marcas de primera/última aparición. El esquema puede contener marcadores extra, pero la ruta del profiler registra esos campos en lugar de filas examinadas o filas enviadas.Real-user monitoring (RUM) - datos de tiempos del navegador de visitas muestreadas: TTFB, FCP, LCP, CLS, FID e INP, además de campos de tiempos DOM, resumen de resource timing, URL, tipo de dispositivo y tienda.Agregados RUM - recuentos de muestras y medias por hora, por URL y por dispositivo para las métricas RUM. El esquema agregado incluye una columna p75_lcp, pero la consulta de agregación actual no la rellena.Error habitual: tratar todos los datos de monitorización como si tuvieran el mismo bajo riesgo. RUM son diagnósticos de tiempos/dispositivo, pero las filas de consultas lentas pueden exponer lo que estuviera presente en la sentencia SQL. Restringe el acceso a esos diagnósticos igual que restringirías el acceso a logs de base de datos.Los valores predeterminados son deliberadamente conservadores. La caché de fragmentos está activada con un TTL de 3600 segundos, la caché de consultas está activada, las métricas están activadas, el umbral de consulta lenta es por defecto 0.1 segundos, la retención de métricas es por defecto 30 días, el profiling está desactivado por defecto y el muestreo RUM es por defecto 0.1, es decir, se mide aproximadamente el 10 por ciento de las páginas vistas elegibles. En una tienda con poco tráfico, esa tasa de muestreo puede hacer que los gráficos RUM parezcan escasos hasta que se hayan medido suficientes visitantes.El script frontal recoge tiempos del navegador con las Performance APIs, luego los envía con sendBeacon cuando está disponible y recurre a XHR si no. El controlador RUM acepta datos JSON POST, valida que exista una URL, almacena campos de tiempos/recursos saneados y devuelve una respuesta 204 con cabeceras no-store/noindex. El controlador también elimina cabeceras Set-Cookie, por lo que el endpoint beacon en sí no crea cookies de cliente.Para la limpieza, el profiler de consultas registra SQL lento por hash y actualiza el recuento de ocurrencias y la última aparición cuando se repite la misma consulta. Los datos RUM sin procesar pueden agregarse en resúmenes por hora y las filas antiguas se eliminan tras la agregación, manteniendo útiles los paneles a largo plazo sin almacenar para siempre cada beacon individual. La limitación importante es que la agregación RUM actual guarda medias y recuentos, no un percentil 75 de LCP calculado.

La caché de PrestaShop está causando problemas. ¿Debería desactivarla?

En una tienda en producción, mantenga la caché activada. Es uno de los principales motivos por los que PrestaShop va rápido: apagarla de forma permanente ralentiza todas las páginas para todos los visitantes y no corrige la causa del problema. Desactivar temporalmente una capa de caché sí es un paso de diagnóstico legítimo. Apague una capa a modo de prueba cuando necesite confirmar si un síntoma procede realmente de la caché, casos típicos: cambios de plantilla o de diseño que no aparecen en la tienda; precios, stocks o bloques desactualizados que sobreviven a una recarga normal; un ajuste de un módulo que tras guardarse parece no tener efecto. Hágalo de forma controlada: cambie una sola capa cada vez, preferiblemente en una copia de staging o en un momento tranquilo; anote qué desactivó y vuelva a activarlo en cuanto termine la prueba. Si el síntoma desaparece con la capa apagada, ya sabe dónde viven los datos desactualizados: la solución es vaciar o reparar esa capa, o corregir el módulo o la plantilla defectuosos, no dejar la caché apagada. En la mayoría de los casos se trata simplemente de caché desactualizada, y una limpieza correcta lo resuelve. Siga los pasos de ¿Cómo limpio correctamente la caché de PrestaShop? antes de plantearse medidas más drásticas.

¿Cómo gestiona el módulo el caché edge de Cloudflare?

Performance Revolution permite que Cloudflare cachee sus páginas HTML completas para visitantes anónimos: una vez que una página se ha cargado en la caché edge, las visitas repetidas pueden servirse directamente desde Cloudflare. Los fallos de caché, la primera petición, las entradas caducadas y todo el tráfico con sesión o con carrito. Siguen llegando a su origen; es por tanto una capa edge por delante de PHP, no una garantía de que las peticiones nunca lo toquen. Trabaja solo en el lado servidor, sin trucos de JavaScript.Qué hace en cada petición:Para un visitante anónimo en una página cacheable (inicio, categoría, producto, CMS, buscador y similares), envía las cabeceras que indican a Cloudflare que conserve el HTML durante el TTL que usted fije.Los visitantes con sesión iniciada y cualquiera con carrito reciben cabeceras de bypass, para que las páginas personalizadas lleguen siempre frescas desde el origen.Elimina Set-Cookie de las respuestas anónimas, porque un CDN se niega a cachear una página que fija una cookie.Adjunta cabeceras Cache-Tag / Surrogate-Key: al editar un producto o categoría puede purgar solo las páginas afectadas en vez de todo el sitio.La purga se adapta automáticamente a su plan de Cloudflare: las zonas Business y Enterprise purgan directamente por tag en una sola llamada, mientras que las zonas free y Pro (que solo admiten purga por URL) ven sus tags resueltos a URLs exactas y purgados en los lotes de 30 URLs que exige Cloudflare. También hay una comprobación de estado de zona que lee sus ajustes de Cloudflare, Rocket Loader, Brotli, HTTP/3, Always Online, modo SSL, TTL de caché del navegador, y señala lo mal configurado.Dos límites honestos. Primero, debe aportar un zone ID y un token de API de Cloudflare para que la purga por API funcione; sin ellos el módulo sigue emitiendo cabeceras de caché pero no puede purgar de forma activa. Segundo, el caché edge está desactivado por defecto y solo afecta al tráfico anónimo. Es deliberado, para no servir nunca el carrito de un cliente a otro.

¿Cuál es el número máximo de productos que PrestaShop puede manejar?

PrestaShop no establece un límite oficial de productos ni detiene la tienda al superar un umbral fijo. En la práctica, la capacidad la deciden sus datos y su infraestructura, mucho más que el número de productos en sí. Combinaciones y volumen de datos: muchos atributos, combinaciones y características multiplican los registros mucho más allá del número de productos, y ese volumen es el que la base de datos debe sostener. Base de datos y búsqueda: la navegación por facetas, la ordenación y el índice de búsqueda crecen con el catálogo; las consultas lentas y la reindexación suelen ser el primer cuello de botella. Importaciones y exportaciones: los feeds grandes requieren importaciones programadas y por lotes; una importación completa del catálogo exige más que la navegación diaria. Hosting y recursos: el procesador, la memoria, la velocidad de disco y la configuración de la base de datos marcan el techo; un catálogo grande en un hosting escaso irá lento sea cual sea el software. Caché, tema y módulos: una caché eficaz absorbe casi todo el efecto del tamaño del catálogo, pero un tema pesado o un módulo mal escrito puede anularla. La respuesta honesta para su tienda sale de la medición: haga una prueba de carga en una copia de staging con su catálogo y su tráfico reales. Para los pasos concretos de optimización, consulte nuestra guía de rendimiento de PrestaShop.

¿Se puede limitar la depuración de rendimiento?

Sí. Cuando activas el profiler de front office en MPR Performance Revolution, decides quién puede verlo: dejar el panel completamente apagado o mostrarlo pero restringirlo a empleados con sesión iniciada para que los clientes nunca vean tus tiempos.La depuración puede acotarse desde la configuración del módulo en lugar de activar diagnósticos amplios.Uno de los consejos de rendimiento más útiles en PrestaShop es perfilar la tienda real, no una copia de prueba limpia, tráfico real, módulos reales, datos reales. El profiler añade una pequeña barra que muestra el recuento y tiempo de consultas SQL de cada página, y lista las consultas más lentas y los hooks de módulo más lentos, para que veas exactamente dónde gasta tiempo una página antes de cambiar nada.El error común es dejar un profiler visible al público: filtra detalles internos y añade sobrecarga a cada solicitud. Mantenlo solo para empleados, apágalo cuando hayas encontrado el cuello de botella y actúa según lo que muestra, normalmente un hook de módulo pesado o una consulta sin índice. El módulo también gestiona caché de objetos Redis, diferido de assets y calentamiento de caché OPcache/Smarty, así que las correcciones viven en el mismo lugar que el diagnóstico.Los ajustes relevantes son dos interruptores: profiler_panel_enabled activa el panel de front office, y profiler_employees_only lo mantiene detrás de una sesión activa de empleado de back office. El ajuste solo empleados está activado por defecto, mientras que el panel en sí está desactivado por defecto. Cuando empieza el profiling, el módulo inicializa instrumentación pronto en la solicitud y luego inyecta el panel antes de solo si el collector está activado y pasa la puerta de empleado.Para atribución SQL y de hooks más profunda, el módulo incluye overrides opcionales que registran cada consulta de base de datos y el tiempo de hook por módulo, y el profiler de consultas registra consultas lentas por encima del umbral configurado, que por defecto es 0.1 segundos. Instálalos solo cuando necesites ese nivel de visibilidad, porque añaden deliberadamente sobrecarga de instrumentación. Un buen flujo es: activar profiler solo empleados, reproducir una URL lenta, capturar totales de consultas/hooks, desactivarlo y luego hacer el cambio mínimo de caché, índice o módulo que corrige el cuello de botella medido.

¿Qué backends de caché están disponibles en configuración?

En el ajuste “Cache Backend” puede elegir Detección automática (recomendada), Redis, APCu o caché en archivos.La detección automática elige la mejor opción disponible en el orden Redis → APCu → archivos: no necesita saber qué admite su servidor, si no hay Redis ni APCu, entra la caché en archivos, que siempre funciona. Elija un backend concreto solo para forzarlo; si no está disponible, el módulo registra un aviso y vuelve a la detección automática, así la caché nunca queda desactivada por error.Con Redis obtiene los campos de conexión esperados: host, puerto, contraseña, número de base de datos y un prefijo de claves (útil cuando varias tiendas comparten una instancia Redis). Configúrelos según el servicio Redis de su alojamiento.Forma parte de Performance Revolution. Si no gestiona su propio Redis pero quiere controlarlo desde el back office, vea Redis Dashboard & Key Manager.

¿Qué base de datos debo usar con PrestaShop, MySQL o MariaDB?

PrestaShop usa MySQL o MariaDB como motor de base de datos. Según los requisitos de sistema oficiales actuales de PrestaShop 8 y PrestaShop 9, ambos listan soporte SQL mínimo como MySQL 5.7 o MariaDB 10.2, con una versión reciente recomendada.Para una tienda de producción nueva o actualizada, trata esos valores como mínimos, no como objetivos ideales. MySQL 8.0 o una versión MariaDB LTS actual es una mejor elección que un host MySQL 5.7 antiguo, especialmente para catálogos más grandes, tablas de búsqueda, combinaciones, carritos e historial de pedidos. Usa tablas InnoDB, mantén suficiente memoria de buffer pool disponible y asegúrate de que las copias de seguridad y pruebas de restauración formen parte del plan de hosting.PrestaShop 9 también tiene expectativas de plataforma mayores que instalaciones antiguas; los requisitos oficiales recomiendan más memoria PHP por script que PrestaShop 8. La compatibilidad de base de datos por sí sola no basta: versión PHP, extensiones, límite de memoria, permisos de sistema de archivos y compatibilidad de módulos también deben comprobarse antes de actualizar.Si estás en hosting compartido, pregunta al proveedor la versión exacta de MySQL/MariaDB y si puedes activar el slow query log o recibir informes de consultas lentas. Eso importa más en el rendimiento diario de PrestaShop que el nombre de marca del servidor de base de datos.En hosting nuevo, pide el motor y versión exactos, no solo "compatible con MySQL". Algunos hostings gestionados ejecutan MariaDB detrás de una etiqueta MySQL, y normalmente está bien, pero sigues necesitando una versión que cumpla el requisito de PrestaShop y una configuración capaz de manejar tu catálogo. Para rendimiento, los puntos importantes suelen ser tamaño de InnoDB buffer pool, latencia de disco, índices, visibilidad de consultas lentas y si la base de datos compite con PHP en un servidor compartido muy pequeño.Durante la migración, exporta e importa con el conjunto de caracteres correcto, conserva el mismo prefijo de tablas salvo que lo cambies deliberadamente, y prueba búsqueda, guardado de producto, creación de pedido y grids de back office después de importar. Las tiendas antiguas pueden arrastrar tablas MyISAM o índices obsoletos de versiones muy antiguas de PrestaShop; convertir a InnoDB y limpiar índices debe hacerse deliberadamente con una copia de seguridad, no como un botón ciego del panel de hosting.

¿El cache warming se ejecuta automáticamente por defecto?

No. En Performance Revolution, el precalentamiento programado de la caché de origen está desactivado por defecto, el indicador cache_warming_enabled arranca en false, y el warmer por cron simplemente informa de «disabled» y no hace nada hasta que usted lo activa.De fábrica, por tanto, nada lanza el warmer por usted. Tiene la maquinaria, lista para usar:Una entrada cron que, una vez activada, recorre sus URLs para que OPcache de PHP, las plantillas Smarty y el CSS/JS combinado se compilen antes de que lleguen visitantes reales.Controles de precalentamiento manual en el Back Office para una pasada bajo demanda.Ajustes de concurrencia y de tiempo máximo de ejecución, para que una pasada no sature un servidor en frío.Un ajuste sí viene activado: cache_warming_post_deploy_enabled es true, lo que solo permite que el comando CLI posterior al despliegue ejecute una pasada completa tras una publicación. Autoriza ese comando, por sí mismo no programa nada. El precalentamiento edge de Cloudflare (cdn_edge_warm_enabled) también está desactivado por defecto.Error habitual: activar el indicador de cron pero no enganchar nunca un cron real (ni el hook posterior al despliegue) que lo invoque. El interruptor dice «permitido»; un planificador todavía tiene que dispararlo.

Acelere las tiendas PrestaShop con mucho tráfico con caché Redis, APCu o de archivos y optimización de recursos

Performance Revolution - Caché Redis y optimización de velocidad para PrestaShop

Performance Revolution - Reducir las ventas perdidas por páginas lentas

Performance Revolution - Actuar rápidamente ante problemas de caché

Performance Revolution, Redis Cache & Speed for PrestaShop - Asset Deferral Settings

Performance Revolution - vaciar y precalentar la cache de PrestaShop con un clic

Performance Revolution - HTML de la tienda optimizado con recursos minificados y diferidos

Acelere las tiendas PrestaShop con mucho tráfico con caché Redis, APCu o de archivos y optimización de recursos

Performance Revolution

Name: Performance Revolution
Brand: mypresta.rocks
SKU: mprperformancerevolution
Price: 299.00 EUR
Availability: InStock

Módulo de caché en PrestaShop, caché de página completa y Redis, reglas de Cloudflare e invalidación automática

Sin reseñas

PrestaShop 1.6 – 9.0PHP 7.1+Versión 1.5.8Publicado 24/12/2025Actualizado 26/05/2026

299,00 €

Impuestos excluidos

MPR Performance Revolution es un módulo de rendimiento para tiendas PrestaShop que mide la rapidez durante visitas reales, localiza el trabajo que provoca la espera y acelera la tienda desde una sola zona de administración. La instalación aplica un perfil inicial prudente y deja cada opción más intensa disponible por separado.

Cloudflare es un servicio mundial opcional de entrega de páginas con un plan gratuito y planes de pago. Su red acerca las páginas públicas aptas a los visitantes, mientras la cuenta de Cloudflare muestra la zona del sitio, el plan elegido y la actividad de la red. El módulo conecta el servicio con PrestaShop, reconoce el plan, detecta reglas incompatibles y presenta el estado de la conexión en la administración de la tienda.

El módulo también prepara copias reutilizables de las páginas públicas en el servidor de la tienda, separadas por idioma, moneda, país y dispositivo cuando esos datos cambian lo que ve el comprador. El carrito, el proceso de compra, la cuenta del cliente y las visitas con sesión iniciada siempre pasan por la tienda activa. Un cambio de producto, precio, stock, categoría, moneda o impuesto renueva automáticamente las páginas relacionadas.

Eliges las direcciones excluidas, el horario de preparación y cada mejora de las imágenes o del trabajo del navegador. Las imágenes de productos, categorías, tema y módulos reciben versiones WebP y AVIF creadas dentro de la tienda, las visitas reales aíslan las páginas lentas por dispositivo, el análisis de la base señala la causa y el mantenimiento retira carritos abandonados, datos antiguos de visitas e imágenes sin uso tras un resumen claro.

El resultado es menos espera hasta completar el pedido, datos comerciales actuales y privados, pruebas para decidir la siguiente mejora, páginas más ligeras y mantenimiento periódico desde el mismo lugar.

Descarga inmediata tras la compra

Demo en vivo instantánea Tienda real, lista en aprox. 1 min

5 instalaciones de demo disponibles · se repone cada 48h

Solicitar presupuesto

Licencia de por vida por dominio, tuya para siempre. Incluye 3 meses de soporte y actualizaciones. Más información

La demo es el módulo completo: cómprelo cuando quiera y active la misma instalación, sin reinstalar ni perder nada. Abra la pestaña Licencia del módulo y haga clic en «Activar desde mypresta.rocks» (o pegue su clave); sus ajustes y datos se conservarán intactos. Las actualizaciones se instalan con un clic desde la pestaña Actualización.

Soporte y actualizaciones

3 months Gratis 6 months +39,00 € 9 months +65,00 € 12 months +89,00 €

Renovación automática del soporte

+29,90 €/mes

Servicios adicionales

Configuración profesional Configuramos completamente el módulo según tus necesidades: todas las opciones establecidas, probadas y verificadas en 1 día hábil. +29,00 €

Integración visual Ajustes de CSS y plantillas para adaptarse a tu tema: incluye verificación en múltiples dispositivos y revisión de capturas de pantalla. +49,00 €

Total de opciones: 0,00 €

Total seleccionado: 299,00 €

¿Cómo acelera un solo módulo toda la tienda?

MPR Performance Revolution mide la rapidez durante visitas reales, relaciona las esperas con la base de datos, los módulos y las plantillas de página, y aplica mejoras a páginas públicas, imágenes y trabajo del navegador desde la misma administración de PrestaShop.

Visitas reales: los resultados por página, dispositivo y periodo convierten una sensación general en una tarea precisa.
Páginas públicas seguras: las páginas aptas quedan preparadas en el servidor de la tienda y mediante Cloudflare, mientras los datos privados siguen activos.
Información actual: catálogo, precios, stock, monedas e impuestos renuevan únicamente las páginas afectadas.
Entrega más ligera: archivos reducidos, imágenes de carga diferida y versiones WebP y AVIF locales reducen el trabajo del navegador.
Diagnóstico y mantenimiento: operaciones lentas, construcción de páginas, datos antiguos e imágenes sin uso se convierten en tareas concretas.
Inicio sencillo, control profundo: un perfil recomendado funciona tras instalar y cada decisión importante permanece ajustable.

Pantalla del panel de administración: ¿Cómo acelera un solo módulo toda la tienda?

¿Qué páginas hacen esperar de verdad a los clientes?

El módulo registra durante las visitas el tiempo de la primera respuesta y del contenido principal, la reacción a los gestos y la estabilidad de la composición. Los datos permanecen en la tienda y se organizan por dirección, teléfono, tableta u ordenador y periodo elegido.

Una página de producto lenta en teléfono aparece así como esa página y ese grupo de dispositivos. El periodo actual se sitúa junto al anterior, por lo que el efecto de un cambio de tema, imágenes o entrega se refleja en visitas posteriores y no depende de una única prueba realizada en condiciones ideales.

Performance Revolution – métricas de usuarios reales, aplazamiento de recursos y calentamiento de caché

¿Cómo siguen rápidas las páginas preparadas sin compartir un carrito?

Las páginas públicas aptas están listas en el servidor de la tienda antes de iniciar toda la construcción del escaparate. Las copias separadas conservan la tienda, el idioma, la moneda, el país y el dispositivo correctos cuando estos datos cambian la página. Carrito, compra, cuenta, visitas con sesión iniciada, datos privados de sesión y peticiones dudosas siempre pasan por la tienda activa.

Cloudflare aporta la red mundial con un plan gratuito y planes de pago. MPR Performance Revolution reconoce el plan elegido, crea reglas adecuadas, elimina conflictos y mantiene disponibles las páginas públicas ya validadas durante un problema temporal del servidor. Eliges exclusiones adicionales y horarios de preparación, mientras las protecciones integradas de las zonas privadas permanecen siempre activas.

Los cambios de productos, categorías, páginas informativas, fabricantes, proveedores, stock, precios, combinaciones, monedas e impuestos renuevan las copias relacionadas sin tocar el resto de páginas preparadas.

¿Qué llega al comprador en una forma más ligera?

Las imágenes de productos, categorías, fabricantes, proveedores, tema activo y módulos instalados reciben versiones WebP y AVIF creadas dentro de la tienda cuando el servidor admite esos formatos. Los originales permanecen, las imágenes nuevas se procesan automáticamente y las existentes se procesan de forma conjunta, sin entregar el catálogo a un servicio externo.

Eliges por separado la reducción y unión de archivos, el aplazamiento del trabajo secundario, la retirada de reglas visuales sin uso y la carga posterior de imágenes. La pantalla presenta el tamaño inicial y el resultado, de modo que primero actúan las opciones prudentes y cada intervención más fuerte se evalúa por separado.

Ajustes del back office para el aplazamiento de recursos con los interruptores de optimización de CSS y JavaScript

¿Qué tareas lentas y datos antiguos necesitan atención?

Las operaciones lentas de la base aparecen con duración, frecuencia y zona de la tienda que las llamó. El análisis detallado señala lecturas completas, índices ignorados y ordenaciones innecesarias, mientras la medición protegida de la página atribuye el tiempo de construcción a módulos y plantillas. La agencia recibe una causa y un lugar concretos.

El mantenimiento cuenta carritos abandonados, sesiones de invitados, historial de conexiones y estadísticas antiguas antes de retirarlos, y después trata los grupos elegidos en el momento o según un horario. También mantiene las tablas seleccionadas e identifica imágenes sin referencias para una eliminación protegida, mostrando primero la reducción estimada de registros y espacio.

¿Con qué rapidez empieza la optimización y hasta dónde llega la configuración?

La instalación aplica un perfil recomendado para medición, reutilización segura, archivos más ligeros e imágenes de carga diferida. La entrega de páginas públicas y los cambios más intensos del navegador siguen siendo decisiones expresas, así los primeros beneficios llegan sin activar todos los mecanismos a la vez.

Eliges las direcciones públicas, patrones de exclusión, alcance y ritmo de preparación, formatos de imagen, plazos de conservación, umbral de las operaciones lentas y cada mejora del navegador. Un modo temporal guarda los ajustes activos, los suspende durante el trabajo técnico y recupera el estado anterior al terminar.

La pantalla de configuración de Performance Revolution en el back office de PrestaShop

Referencia

mprperformancerevolution
Disponible

2147483647 Artículos
Compatibilidad PrestaShop

PS 1.7 – 9.x
Modelo de precio

Compra única
Tipo de módulo

Front & Back-office
Relevante para RGPD

No
Objetivo comercial

Optimizar operaciones
Cuenta externa necesaria

No
Complejidad del módulo

Solución completa
Etapa del recorrido del cliente

Gestionar la tienda
Funciona con plataforma

Sin plataforma externa

Qué dicen nuestros clientes de nosotros

Reseñas de empresa

5.0 ★ ★ ★ ★ ★ (4 reseñas)

Cargando reseñas de clientes...

Aún no hay reseñas del producto

Sé la primera persona en compartir tu experiencia con este módulo.

Escribir una reseña

Su calificación *

★ ★ ★ ★ ★

Evalúe aspectos específicos (opcional)

Calidad

★ ★ ★ ★ ★

Relación calidad-precio

★ ★ ★ ★ ★

Estabilidad

★ ★ ★ ★ ★

Compatibilidad

★ ★ ★ ★ ★

Soporte

★ ★ ★ ★ ★

Tu nombre *

Tu correo *

Título de la reseña

Su reseña *

Añadir fotos (máx. 3)

Haga clic para cargar o arrastre y suelte

Ofrece un centro completo de control de rendimiento para PrestaShop: caché Redis/APCu/archivo, caché de fragmentos Smarty, caché de consultas, optimización de assets, lazy loading, generación AVIF/WebP, cabeceras de caché de página CDN para visitantes anónimos, calentamiento de caché y un panel para el cache hit ratio, consultas lentas, Core Web Vitals, memoria y estado del backend de caché.

Leer la documentación completa Descargar PDF

¿Tiene alguna pregunta sobre este producto? Nuestros expertos están aquí para ayudarle. Pregunte sobre instalación, compatibilidad o especificaciones.

1321 preguntas

9 categorías

2014 creando módulos desde

1.6–9 versiones de PrestaShop

Ver todas las preguntas

v1.5.152026-05-27

AddedFinalize performance endpoint SEO cleanup
AddedRetain generated assets across cache clears
AddedFlip CDN cache from whitelist to blacklist — cache all pages by default

Funciona bien con Performance Revolution

Los módulos que nuestro equipo combina realmente con este, y por qué cada uno encaja en la misma configuración.

Acelere las páginas de PrestaShop añadiendo carga diferida y atributos de decodificación a las imágenes de la tienda

Automatic SEO Images Lazy Tags

69,00 €

★ ★ ★ ★ ★

Complement

Performance Revolution da a tu equipo amplios controles de velocidad, caché, precalentamiento, gestión de assets y análisis de cuellos de botella, , pero la entrega de imágenes en el front-end en páginas cargadas de imágenes es una palanca específica que se beneficia de un tratamiento propio, no solo de la caché general.

Automatic SEO Images Lazy Tags cubre eso, añadiendo loading="lazy" y, opcionalmente, decoding="async" a las imágenes de productos, listados y contenidos editables sin tocar el tema. Complementa la suite de rendimiento: uno gestiona la caché y los cuellos de botella del back-end, el otro aplaza las imágenes fuera de pantalla para que el navegador priorice lo que los compradores ven primero, cada uno en su área.

Juntos abordáis la velocidad desde el servidor y el navegador a la vez. Performance Revolution se ocupa de la caché y los cuellos de botella de assets mientras la carga diferida aligera las páginas ricas en imágenes en el lado del cliente, de modo que una página de categoría o de producto se beneficia tanto de una caché bien gestionada detrás como de una carga de imágenes más ligera delante del comprador, reduciendo la probabilidad de que las páginas lentas pierdan tráfico.

Limpie carritos, registros, búsquedas y correos antiguos de su base de datos de PrestaShop

Database Cleanup

0,00 €

★ ★ ★ ★ ★

Ver detalles

Complement

Performance Revolution se centra en la caché, el precalentamiento, la gestión de assets y el análisis de cuellos de botella, la capa de rendimiento en vivo de tu tienda. Con el tiempo, sin embargo, los datos operativos acumulados, como carritos obsoletos, registros antiguos y entradas caducadas, lastran la administración diaria, algo que queda fuera de lo que resuelve el ajuste de la caché.

Database Cleanup cubre ese mantenimiento con una pantalla controlada en el Back Office para eliminar carritos obsoletos, estadísticas de búsqueda, precios específicos caducados, registros, conexiones, registros de invitados y correos antiguos, con una vista previa antes de borrar. Complementa la suite de rendimiento ocupándose de la higiene de datos, una cuestión distinta de la caché en tiempo de ejecución.

Usados juntos, tu tienda se mantiene rápida en ejecución y ligera en sus datos almacenados. Performance Revolution mantiene las páginas rápidas de servir mientras Database Cleanup ayuda a evitar que las tablas operativas se hinchen con registros que ya no necesitas, de modo que la administración sigue siendo manejable, con cada herramienta responsable de un aspecto distinto de la salud de la tienda.

Configure la caché Redis en PrestaShop desde el Back Office y pruebe la conexión al instante

Redis Cache Manager & Monitor

99,00 €

★ ★ ★ ★ ★

Complement

Performance Revolution puede usar Redis entre sus capas de caché y ofrece precalentamiento y análisis de cuellos de botella, pero una tienda cuidadosa a menudo quiere una forma dedicada de verificar y mantener la propia conexión de Redis, separada del panel de rendimiento más amplio.

Redis Dashboard & Key Manager proporciona eso: un panel en el Back Office para configurar host, puerto, contraseña, base de datos y prefijo de claves, probar la conexión a través de la extensión PHP redis y ver métricas en vivo como versión, tiempo de actividad y memoria. Complementa Performance Revolution al concentrarse en la verificación y limpieza de Redis como tarea propia.

Juntos obtienes una gestión amplia del rendimiento más una vista clara y enfocada de tu backend Redis. Performance Revolution se ocupa de la estrategia de caché y los cuellos de botella mientras Redis Dashboard & Key Manager hace que la capa Redis sea fácil de comprobar y limpiar, de modo que es menos probable que te sorprenda un backend de caché mal configurado, cubriendo cada herramienta una porción distinta del mismo objetivo de velocidad.

Acelere su tienda PrestaShop con una auditoría de profiling de PHP, consultas, caché y Core Web Vitals

PrestaShop Speed & Core Web Vitals Audit

490,00 €

★ ★ ★ ★ ★

Measurement

Performance Revolution te da los controles para actuar sobre la velocidad, pero saber cuáles importan más para tu tienda concreta, y si el verdadero cuello de botella es PHP, las consultas, los assets o el alojamiento, a menudo requiere una lectura externa basada en evidencias.

Performance Audit aporta eso: perfila tu sitio en producción en PHP, consultas lentas, caché y CCC, Core Web Vitals, el flujo de imágenes, los assets del tema, el alojamiento y el CDN, y luego clasifica cada cuello de botella según su impacto en el tiempo de carga y las conversiones. Complementa el módulo diagnosticando en lugar de configurar.

La ventaja es que tu ajuste va guiado. Conservas Performance Revolution para aplicar cambios de caché y assets mientras la auditoría te dice, por orden de prioridad, dónde están las ralentizaciones reales en tu tienda real, de modo que el esfuerzo va al cuello de botella con mayor recompensa en vez de repartirse entre todos los ajustes disponibles.

Ver todos los problemas conocidos

14 Implementado

14 solicitudes

Cargando solicitudes de funciones...

Ver la hoja de ruta completa

30 días de devolución
Devolución fácil - sin preguntas

Módulos Plug & Play
Instalar, configurar y beneficiarse

Soporte ante todo
Prioridad en ayuda y satisfacción

También podría interesarle

Ayude a los clientes de PrestaShop a encontrar productos al instante con la búsqueda AJAX de autocompletado

Smart Search Revolution

299,00 €

★ ★ ★ ★ ★

Explore los medios de producto con galerías Swiper, vídeos y una lightbox PhotoSwipe en PrestaShop

Gallery Revolution

299,00 €

★ ★ ★ ★ ★

Acelere la búsqueda por facetas de su tienda PrestaShop con URLs de filtro limpias y páginas SEO

Filter Revolution

299,00 €

★ ★ ★ ★ ★

Muestre vistas recientes y señales de venta en las páginas de producto de su tienda PrestaShop

Product Sales & Views Live Stats

149,00 €

★ ★ ★ ★ ★

Cookie	Proveedor	Finalidad	Duración
PrestaShop-*	PrestaShop	Gestión de sesión y funcionalidad del carrito	Sesión
PHPSESSID	PHP	Identificador de sesión PHP	Sesión
mprcr_consent	MPR Cookies Revolution	Almacena las preferencias de consentimiento de cookies	365 día(s)
mprcr_version	MPR Cookies Revolution	Rastrea la version de la configuración del consentimiento	365 día(s)

Cookie	Proveedor	Finalidad	Duración
TawkConnectionTime	Tawk.to	Rastrea el tiempo de conexión de la sesión de chat	Sesión
__tawkuuid	Tawk.to	Identifica a los visitantes recurrentes del chat	6 mes(es)

Cookie	Proveedor	Finalidad	Duración
_ga	Google Analytics	Distingue usuarios únicos asignando un número generado aleatoriamente	2 año(s)
_ga_*	Google Analytics	Utilizado para mantener el estado de la sesión entre solicitudes de página	2 año(s)
_gid	Google Analytics	Distingue usuarios únicos durante 24 horas	24 hora(s)