Un comerciante muestra 80.000 referencias de productos, de las cuales 15.000 están activas en línea. La página de categorías tarda ocho segundos en mostrarse. La agencia recomienda un servidor dedicado con 32 GB de RAM. Excepto que el perfil muestra algo más: una consulta SQL de cuatro segundos, un módulo de filtro que une seis tablas y un caché Smarty deshabilitado "para facilitar la depuración". La verdadera limitación no era PrestaShop en sí, sino la arquitectura de listado en un catálogo denso.
Este escenario se repite en las tiendas que han ido creciendo paulatinamente. El back office muestra correctamente decenas de miles de registros, lo que tranquiliza al equipo de ventas. Sin embargo, el cliente no consulta a la administración: navega por categorías, inicia búsquedas, compara variaciones. Aquí es donde se concentra la carga, mucho antes de que el procesador del host alcance su límite máximo.
Entonces, la pregunta útil no es "¿cuántos productos admite PrestaShop?" ". Es más concreto: ¿qué solicitud espera primero su visitante y cuál lo ralentiza: la base de datos, un módulo, la ausencia de caché o, finalmente, la infraestructura?
Dónde aparece el límite en la práctica
En un catálogo grande, los cuellos de botella se dividen en distintas capas. La base de datos MySQL primero sufre en los listados de productos y en la administración cuando faltan índices o las tablas ps_product* crecen sin mantenimiento. La búsqueda nativa se vuelve penalizadora tan pronto como las facetas multiplican las uniones. El Smarty o caché de objetos, si está ausente o se invalida incorrectamente, deja un tiempo de respuesta elevado incluso cuando el servidor parece disponible.
Los módulos de terceros amplifican el problema: filtros facetados mal optimizados, extensiones de marketing que se ejecutan en cada página de categoría, importaciones CSV sincrónicas que bloquean la tienda durante el horario comercial. Las imágenes que no son entregadas por una CDN pueden consumir una porción significativa del ancho de banda sin tener en cuenta ocho segundos de latencia por sí solas, pero empeoran la experiencia percibida.
| Área | Síntoma | Palanca |
|---|---|---|
| Base de datos MySQL | Listado lento, administrador de producto | Índice, limpieza, lectura de réplicas |
| Búsqueda nativa | Tiempo de espera o búsqueda lenta | Elasticsearch, Algolia |
| Sabelotodo / caché | Tiempo de respuesta constantemente alto | Caché de página, Redis |
| Módulos facetados | Pico del procesador en categorías | Refactor o servicio dedicado |
| Fotos | Ancho de banda saturado | CDN, formatos modernos |
| Importaciones CSV | Bloqueo de tiendas | Cola asincrónica, horas valle |
Un catálogo grande expone uniones mal pensadas, no la marca PrestaShop en sí.
Hosting: más allá del número de núcleos de procesador
Comparar hosts basándose únicamente en el número de procesadores virtuales oculta los criterios que realmente importan para PrestaShop. E/S de disco determina la velocidad de las consultas en tablas grandes: el almacenamiento NVMe local o equivalente es mejor que un disco compartido lento. La RAM debe dimensionar el grupo de buffers de MySQL; ocho gigabytes suelen representar el umbral de comodidad para un catálogo pesado con caché activo.
Redis sirve tanto para sesiones como para Smarty o caché de objetos cuando la aplicación está configurada correctamente. En el lado de PHP, busque la versión 8.1 o superior, active OPcache y ajuste max_execution_time para las importaciones programadas. Un cron confiable es esencial para la indexación, la limpieza de caché y las colas. Finalmente, un entorno de preproducción le permite probar importaciones y módulos sin bloquear la producción.
Compartido rara vez es adecuado para un catálogo pesado con filtros avanzados. Un VPS o una nube dedicada a la tienda es más realista en cuanto los listados superan los pocos segundos a pesar de una base de datos optimizada. Para comparar ofertas orientadas a empresas, consulte nuestro directorio de hosting y la guía MySQL para sitio dinámico.
Optimizaciones de aplicaciones antes de pasar a un nivel superior
Antes de aumentar la factura del hosting, consulte las ganancias de aplicaciones más frecuentes. Faltan índices en atributos filtrados, id_category y active a veces convierten una consulta de seis segundos en unos cientos de milisegundos. Deshabilite los módulos de listado uno por uno midiendo el tiempo de generación de la página: el método es tedioso, pero a menudo identifica al culpable en una mañana.
Habilite el caché con una estrategia de invalidación documentada: sin una regla clara, intercambia lentitud por datos obsoletos. Subcontrate la búsqueda tan pronto como las consultas de listado SQL superen varios cientos de milisegundos a pesar de los índices. Un CDN para imágenes de productos reduce el peso percibido de la página, a menudo alrededor del setenta por ciento del peso total. Programe importaciones nocturnas con un modo de mantenimiento parcial para evitar saturar la base de datos durante el día.
Si duda entre las pilas de comercio electrónico, la guía Magento no es un WordPress pesado le ayudará a posicionar PrestaShop frente a otras soluciones de catálogo.
Señales de que el anfitrión se ha convertido en el techo.
La infraestructura se convierte en el factor limitante cuando la optimización de la aplicación ya se ha realizado y los síntomas persisten. Un procesador utilizado a menos del cuarenta por ciento mientras la espera de E/S del disco permanece permanentemente alta indica un cuello de botella en el disco, no un cuello de botella en el procesador. Un registro de consultas MySQL lento que se llena a pesar de los índices correctos sugiere memoria o tamaño de disco insuficientes. La memoria llena por un grupo de búfer que es demasiado pequeño fuerza lecturas repetidas del disco. La alta latencia de red para una base de datos administrada remotamente penaliza cada página.
En estos casos, tiene sentido pasar a un nivel superior o acercar la aplicación y la base. Mientras la creación de perfiles muestre una consulta SQL dominante, un servidor más potente sólo pagará más por la misma lentitud.
La cumbre: el catálogo revela la deuda de los módulos
Magento y WooCommerce no son los únicos que sufren el enorme catálogo. PrestaShop es más ligero en teoría, pero más sensible a módulos de terceros en los listados. La comparación con otras pilas solo tiene sentido si mide la misma página de categoría, no el mismo número de referencias en la base.
Decide y avanza sin puntos ciegos
Comience por crear un perfil de una página de categoría representativa y búsqueda interna, con los mismos filtros que sus visitantes utilizan con más frecuencia. Luego audite los módulos que afectan el listado y las facetas, en preproducción si es posible. Active la caché de objetos y Redis si aún no lo ha hecho, luego dimensione MySQL en la memoria y los índices antes de considerar un cambio de host. Construya la infraestructura únicamente después de la prueba cifrada: tiempo de consulta, carga del procesador, espera del disco. Busque hosts orientados al comercio electrónico en nuestro directorio y la comparación según estas métricas, no una recomendación genérica de "servidor más grande".
Preguntas frecuentes
¿Cuántos productos puede gestionar PrestaShop?
No hay un tope oficial. Las tiendas funcionan con más de 100.000 referencias de productos cuando se adapta la arquitectura. Sin caché, índices SQL y módulos optimizados, los problemas suelen comenzar entre 5.000 y 20.000 referencias activas, especialmente con filtros de facetas pesados.
¿Qué RAM mínima para un catálogo grande?
Permita 4 GB para una tienda promedio bien optimizada y 8 GB o más con búsqueda externa, numerosos módulos o importaciones frecuentes. El intercambio compartido rara vez resulta suficiente más allá de unos pocos miles de productos con filtros avanzados.
¿Se requiere Elasticsearch?
No, pero la búsqueda SQL nativa se vuelve lenta en catálogos grandes con facetas. Elasticsearch o Algolia se vuelven relevantes cuando las consultas de listado superan varios cientos de milisegundos a pesar de la indexación.
¿Cómo identificar si el problema proviene de los módulos?
Desactive temporalmente los módulos de marketing, filtros y SEO en preproducción y luego compare el tiempo para generar una página de categoría. Un módulo mal codificado en el listado sigue siendo una de las causas más comunes en catálogos densos.
Con 80.000 referencias, la pregunta no es "¿qué anfitrión?" - es "¿qué consulta SQL espera primero su cliente?" »