Rendimiento de PrestaShop: mide, diagnostica y mejora tu tienda

Qué haríamos primero

La solución adecuada depende de la tienda existente: su tema, módulos, integraciones, datos del catálogo, alojamiento y tráfico. Dos tiendas con la misma puntuación de velocidad pueden necesitar cambios opuestos. Reproduciríamos la página lenta, separaríamos el tiempo del servidor del trabajo del navegador e identificaríamos las consultas, llamadas de módulos o scripts que consumen ese tiempo. Si domina SQL, prueba en preproducción un cambio concreto en una consulta o un índice antes de tocar los ajustes del servidor. Si la base de datos espera al almacenamiento o compite por la memoria, evalúa primero la carga del alojamiento. Si el documento llega pronto pero la página sigue tardando en poder usarse, trabaja en las imágenes, el CSS y el JavaScript.

La vía práctica es la misma para la mayoría de las correcciones: reproduce el problema en una copia de preproducción aislada con datos realistas, ensaya allí el cambio con una forma probada de volver atrás, despliégalo como un cambio planificado y repite las mismas mediciones en la tienda en producción. Compara solicitudes equivalentes antes y después de cada cambio, para poder atribuir cada resultado a ese cambio.

Elige la primera prueba según el síntoma

Pide a tu desarrollador una traza de la solicitud que identifique el trabajo costoso, su responsable, un cambio propuesto y la comparación del antes y el después. Una captura del tamaño de la base de datos o una única puntuación de velocidad no constituyen esas pruebas.

Si quieres que hagamos esa atribución para tu tienda, el PrestaShop Speed & Core Web Vitals Audit sigue solicitudes reales a través del servidor, la base de datos y el navegador y entrega un plan de correcciones ordenado por prioridad; los cambios de código, la configuración del servidor y la compra de alojamiento quedan fuera de su alcance y se presupuestan aparte.

Establece una referencia y lee las métricas adecuadas

Prueba la página de inicio, una categoría con mucho tráfico, un producto, el carrito y el proceso de compra, además de cualquier pantalla lenta del back office. Incluye la búsqueda y los filtros cuando sean importantes para tu tienda. Registra la URL, la versión del núcleo y de PHP, el tema, los módulos activos, el dispositivo, la ubicación, el perfil de conexión, el estado del cliente, el idioma, la moneda, el estado del consentimiento, el estado de la caché y las condiciones de tráfico.

Usa una copia de preproducción con datos de catálogo realistas para los cambios controlados y el análisis de rendimiento. Ejecuta varias pruebas comparables y conserva la mediana y la dispersión. Compara por separado un visitante nuevo, un navegador que vuelve y un cliente con sesión iniciada, e incluye solicitudes sin caché: un acierto rápido de la caché pública no demuestra que el carrito o el proceso de compra sean rápidos. Iniciar sesión en el back office no activa automáticamente el análisis de rendimiento ni acelera las solicitudes de la tienda.

Los objetivos actuales de Core Web Vitals son LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos, evaluados en el percentil 75 por separado para móvil y escritorio. INP sustituyó a FID en marzo de 2024.

LCP se refiere al mayor contenido visible que cumple los criterios, a menudo una imagen o un bloque de texto. INP mide la respuesta a las interacciones. CLS mide los movimientos inesperados del diseño. Diagnostica el elemento, evento o desplazamiento real en lugar de suponer una causa solo por la métrica.

La puntuación de rendimiento de Lighthouse es un indicador compuesto de laboratorio, no tu tasa de conversión ni una predicción de posicionamiento. Su auditoría de carga incluye Total Blocking Time; no puntúa directamente el INP de campo en una ejecución normal de carga de página. Accesibilidad, Buenas prácticas y SEO son categorías de auditoría separadas, no una certificación completa de esos temas. Lee la explicación de la puntuación y los hallazgos individuales.

La instalación estándar de GA4 no recopila automáticamente Core Web Vitals ni proporciona los antiguos informes de velocidad del sitio de Universal Analytics. Añade instrumentación explícita de web-vitals o RUM y los eventos e informes necesarios. Segmenta por tipo de página, dispositivo y mercado, con controles de privacidad adecuados.

Mantén las mediciones de negocio junto a las de velocidad. El informe minorista de 2017 de Akamai asoció un retraso de 100 milisegundos con una reducción de conversión del 7% en su estudio. Ese resultado histórico no es una fórmula para predecir la mejora de tu tienda.

Aísla la copia de preproducción y prepara una forma de volver atrás

Aísla la copia de preproducción antes de que se ejecuten la aplicación restaurada, sus procesos o las tareas programadas. Dale una base de datos independiente, destinos sandbox para pagos e integraciones, un buzón de pruebas y un acceso externo controlado. Restringe el acceso a los datos de clientes copiados, para que las pruebas de rendimiento y de caché no puedan disparar mensajes a clientes reales ni operaciones de negocio.

Antes de eliminar registros, añadir índices, reconstruir tablas o cambiar el motor o la configuración de la base de datos, haz copias coherentes de archivos y base de datos, prueba una restauración en preproducción y documenta la reversión. Ensaya el propio cambio, teniendo en cuenta los bloqueos, las necesidades de almacenamiento y la interrupción del servicio, para que el despliegue en producción siga un procedimiento conocido a una hora planificada. Pide al alojamiento que se encargue de la configuración cuando no controles el servidor.

Mantén la copia cerca de producción: las mismas versiones de PrestaShop, PHP y base de datos, el mismo tema y los mismos módulos, con datos representativos. El hardware de preproducción rara vez coincide con el del servidor en producción, así que úsalo para comparar el antes y el después y confirma después la mejora en la tienda en producción con las mismas solicitudes de referencia.

Separa el tiempo de conexión, el trabajo del servidor y el del navegador

El TTFB observado por el cliente incluye trabajo previo a la llegada del documento, como DNS, establecimiento de conexión, TLS, redirecciones y la ruta de solicitud/respuesta. No es un cronómetro directo de ejecución de PHP. Waiting de DevTools mide un intervalo diferente. Usa el desglose temporal de TTFB para interpretar la herramienta que utilizas.

Este ejemplo de shell obtiene una página e imprime tiempos acumulados de curl. Sustituye la URL del ejemplo por una URL real de la tienda:

url='https://example.com/'
curl --silent --show-error --output /dev/null   --write-out 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n'   "$url"

Estos valores se miden desde el inicio de la transferencia; no son duraciones independientes que debas sumar. Comprueba las redirecciones por separado o regístralas explícitamente. Repite con estados de caché y ubicaciones geográficas controlados.

Un script del navegador obtenido después del primer byte del documento no puede retrasar ese primer byte. Puede retrasar el renderizado, las interacciones o las solicitudes posteriores. Un módulo PHP que consulta una API remota antes de enviar HTML puede retrasar la respuesta del servidor. Una cascada del navegador por sí sola no puede identificar ese módulo PHP.

Usa el analizador de rendimiento adecuado

Para el análisis de rendimiento heredado de PrestaShop, activa _PS_DEBUG_PROFILING_ en config/defines.inc.php en una copia de preproducción de acceso restringido:

define('_PS_DEBUG_PROFILING_', true);

Carga los tipos de página pertinentes e inspecciona el tiempo SQL, las llamadas repetidas, los hooks y la memoria dentro de la cobertura del informe. Después vuelve a establecer el indicador en false. _PS_MODE_DEV_ es un interruptor separado de desarrollo e informes de errores. No es el interruptor del análisis de rendimiento heredado ni la política de compilación de Smarty.

La barra de Symfony cubre las solicitudes gestionadas por su kernel. Su panel Doctrine no demuestra una cobertura completa del SQL de Db heredado. Confirma las rutas de base de datos y hooks instrumentadas antes de atribuir todo el trabajo a un módulo.

Una comprobación de URL pública puede evaluar la accesibilidad y los tiempos del navegador. Los recuentos internos de consultas, las tasas de aciertos de caché y los tiempos de módulos requieren acceso autorizado o instrumentación. Incluso una obtención normal de página puede crear registros, analítica o entradas de caché, así que acuerda el alcance de las pruebas y el volumen de solicitudes.

Revisa los ajustes de producción sin confundirlos

En Parámetros avanzados → Rendimiento, revisa cada ajuste por separado y prueba su efecto. Mantén desactivados el modo de desarrollo y el análisis de rendimiento en la tienda pública de producción.

El JavaScript diferido/asíncrono y los recursos remotos pueden quedar fuera de la combinación CCC normal. Las etiquetas directas emitidas por un hook pueden eludir la gestión de recursos. Cuando un cambio de CCC rompe el comportamiento, aísla el paquete o la dependencia afectados en preproducción y corrige su registro; no mantengas en funcionamiento un proceso de compra averiado.

Desactiva módulos sospechosos en preproducción y compara las mediciones. Las comprobaciones de ejecución del núcleo excluyen los hooks normales de los módulos desactivados. Desinstala solo los módulos que realmente no necesites tras revisar su comportamiento de desinstalación y conservar los ajustes o datos necesarios.

Elige un PHP compatible e inspecciona OPcache y el alojamiento

Usa una rama de PHP mantenida y compatible con tu versión exacta de PrestaShop, el tema y los módulos. La matriz actual de PrestaShop 9 recomienda PHP 8.4 para 9.0 y PHP 8.5 para 9.1. Comprueba también las fechas de mantenimiento de PHP. PHP 8.1 dejó de recibir soporte del proyecto el 31 de diciembre de 2025. No pases PrestaShop 1.7.8 a PHP 8 como solución genérica de velocidad.

Confirma que OPcache está activo para PHP web, no solo para el binario de línea de comandos. Almacena bytecode compilado para que las solicitudes repetidas eviten volver a analizar archivos PHP. JIT es una opción separada; no supongas que explica el rendimiento de tu tienda ni que deba activarse.

1. Inspecciona la memoria usada/libre, las cadenas internadas, los scripts en caché y las claves bajo una carga representativa.
2. Comprueba cache_full, la memoria desperdiciada y los contadores de reinicios por falta de memoria, hash y reinicios manuales mediante opcache_get_status() cuando el alojamiento lo permita.
3. Dimensiona la memoria y la capacidad de scripts a partir de esas lecturas. Una caché llena puede dejar de admitir scripts y programar un reinicio; no funciona como una caché simple que expulsa continuamente entradas individuales.
4. Documenta el comportamiento del despliegue. Con opcache.validate_timestamps=1, la comprobación de marcas de tiempo sigue su configuración, incluido opcache.revalidate_freq. Con la validación desactivada, los archivos modificados requieren invalidación explícita o un restablecimiento/reinicio de la caché de PHP web correspondiente.

Un restablecimiento desde CLI normalmente no vacía el OPcache del servidor web. Esperar sesenta segundos no es un procedimiento universal de restablecimiento. Usa los ajustes de OPcache y los campos de estado para definir una política controlada, y mantén privados los endpoints de diagnóstico.

Para PHP-FPM, inspecciona los procesos ocupados, las colas, pm.max_children, la memoria por proceso y los registros de tiempos de espera. Más procesos pueden empeorar la presión de memoria o la contención de la base de datos. Comprueba la carga de CPU y el tiempo robado, el intercambio a disco, la espera de E/S y la latencia de la base de datos en horas punta. Herramientas como free -m, vmstat 1 5 e iostat -xz 1 5 pueden ayudar a tu administrador a correlacionar síntomas.

No dimensiones el alojamiento solo por los pedidos diarios. Importan la navegación simultánea del catálogo, los filtros, las importaciones, las tareas cron, las combinaciones y el trabajo del proceso de compra. Compara el uso de recursos y los tiempos de respuesta bajo la carga máxima prevista antes de cambiar de alojamiento o añadir capacidad. Consulta alojamiento para PrestaShop.

Cuando las pruebas apuntan a límites de capacidad o de recuperación, el PrestaShop Hosting & Infrastructure Audit revisa la carga y emite un dictamen por escrito sobre mejorar el alojamiento actual o migrar; el trabajo en el servidor y la propia migración son aparte. Elige la vía de migración a partir de los módulos, integraciones, tema y datos existentes. Para un cambio de alojamiento que conserve la configuración actual, prueba una copia aislada en el nuevo alojamiento. Si la evaluación aconseja reconstruir la tienda, la vía segura habitual es una instalación de destino limpia en preproducción, componentes compatibles y una migración de datos ensayada. Planifica la sincronización final de datos y el cambio a producción, y documenta cómo conservaría la reversión los pedidos realizados después del lanzamiento.

Encuentra SQL lento e interpreta EXPLAIN correctamente

Pide al administrador de la base de datos que registre primero el motor y la versión exactos: los ajustes de MySQL y MariaDB no son intercambiables. Usa la supervisión de consultas existente cuando esté disponible. Si no, activa el registro de consultas lentas de la base de datos con un umbral elegido a partir de los tiempos de las solicitudes y la carga. Por ejemplo, una ventana breve de diagnóstico podría empezar con:

[mysqld]
slow_query_log = 1
long_query_time = 0.5

Pide al administrador de la base de datos que configure un destino de registro permitido, un límite de almacenamiento, la rotación, el control de acceso y una fecha de retirada. El texto de las consultas puede contener datos personales. Recoge tráfico y trabajo programado representativos del periodo de mayor actividad correspondiente, en lugar de una duración fija para todas las tiendas, y detén o ajusta después el registro detallado según convenga. Registrar las consultas sin índices y los filtros de filas mínimas examinadas puede ayudar, pero también puede generar ruido y trabajo adicional o excluir consultas pequeñas relevantes; recorrer una tabla pequeña no es automáticamente un fallo. Consulta el comportamiento del registro de la base de datos para tu versión.

Resume un registro con mysqldumpslow o pt-query-digest cuando las herramientas estén instaladas y admitan tu formato de registro. Sustituye la ruta por el archivo real y guarda los informes en una ubicación restringida:

mysqldumpslow -s t -t 20 /path/to/slow-query.log
pt-query-digest /path/to/slow-query.log

Ordena por tiempo total, número de llamadas, filas examinadas y tiempo de bloqueo, además de por la ejecución individual más lenta: una consulta modesta repetida puede costar más en una página o en un periodo de mucha actividad que una sola consulta más lenta. Lee el modo de ordenación del resumen antes de interpretar su clasificación, porque una lista ordenada por duración media responde a una pregunta distinta de otra ordenada por tiempo acumulado. Captura la consulta exacta, los parámetros, el volumen de datos y el contexto de la tienda antes de ajustar nada, y anonimiza los informes antes de compartirlos.

El umbral de captura también oculta trabajo: las consultas repetidas por debajo de él pueden no aparecer aunque su coste conjunto importe. Por ejemplo, cada consulta de reseñas puede terminar por debajo del umbral pero volver a ejecutarse en cada ficha de producto, mientras que una exportación programada aporta una única consulta lenta sin relación con esa página. Relaciona la solicitud lenta con el análisis de rendimiento de la aplicación, con una captura acotada en lugar de un registro sin límites, y atribuye ambos patrones a quien los invoca antes de decidir qué cambio mejorará la solicitud del cliente.

Usa la consulta real de la solicitud lenta, con su contexto de tienda, idioma y cliente, e inspecciona su plan en una copia de preproducción con datos representativos. Este ejemplo de categoría de solo lectura usa el prefijo predeterminado, la tienda 1, el idioma 1 y la categoría 42. Muestra la forma, no la consulta que genera tu módulo de listados o de filtros instalado. Lee el precio y el estado propios de la tienda desde product_shop y limita los datos traducidos a la misma tienda:

EXPLAIN SELECT p.id_product, pl.name, ps.price
FROM ps_product p
JOIN ps_product_shop ps ON ps.id_product = p.id_product
JOIN ps_product_lang pl ON pl.id_product = p.id_product
  AND pl.id_shop = ps.id_shop
JOIN ps_category_product cp ON cp.id_product = p.id_product
WHERE ps.id_shop = 1 AND pl.id_lang = 1
  AND cp.id_category = 42 AND ps.active = 1
ORDER BY ps.date_add DESC;

El EXPLAIN normal estima un plan sin ejecutar la consulta. Los comandos de análisis basados en la ejecución sí pueden ejecutarla; confirma el comportamiento del comando para tu motor y versión antes de usarlo.

Revisa los índices existentes antes de añadir uno. Elige el orden del índice compuesto según los predicados de igualdad, los rangos, la ordenación y la reutilización del prefijo izquierdo. Poner primero la columna más selectiva no es una regla universal. Los índices añadidos ocupan espacio y suponen trabajo de escritura, así que compara el beneficio en lectura con el coste en escritura. Mide los cambios de esquema en preproducción, ensaya tanto la instalación como la reversión y planifica los bloqueos y el espacio temporal.

Una tabla de reseñas consultada por producto, estado de aprobación y orden de visualización muestra por qué el diseño de índices necesita el patrón de acceso completo. Un índice adecuado para esa consulta de la tienda puede no servir para una lista de administración filtrada por tienda. Pide planes medidos para ambos casos, y el efecto sobre las importaciones de reseñas y las escrituras de moderación, antes de aprobar el índice.

Investigación paso a paso: una categoría filtrada lenta

1. Guarda los filtros seleccionados, el orden, la tienda, el idioma, la moneda y el estado del cliente. Reproduce la solicitud sin caché con datos representativos en pruebas.
2. Identifica las consultas de selección de productos, recuentos de facetas, cálculo de precios y añadidos de módulos. Separa las llamadas repetidas de las consultas costosas individualmente.
3. Revisa las uniones, restricciones, índices existentes y el plan reales del patrón costoso. El ejemplo de categoría anterior solo muestra la sintaxis; son las propias consultas del módulo de filtros las que deciden este caso.
4. Propón un cambio en esa consulta, un índice candidato o una modificación del trabajo repetido del módulo responsable. Ensáyalo con la copia de seguridad coherente y el plan de reversión ya preparados.
5. Repite las mismas acciones de filtrado y ordenación. Compara duración de solicitudes, frecuencia de consultas y planes; verifica después los productos obtenidos, los recuentos de facetas y los precios del cliente.

Investiga los precios, las facetas y las consultas repetidas

Precios específicos y reglas del carrito

La selección de precios específicos depende del producto, la combinación, la tienda, la moneda, el país, el grupo, el cliente, el carrito, la cantidad y las fechas, con reglas de prioridad y de orden. Un tramo de cantidad debe aplicarse a la cantidad solicitada; from_quantity >= 1 no es una prueba de selección correcta. Escribe entre comillas las columnas de fecha reservadas como `from` y `to` en el SQL de diagnóstico. Analiza la llamada nativa de cálculo de precios en lugar de sustituir su selección por una búsqueda incompleta, y no copies en producción una consulta o un índice de precios de otra tienda: un ejemplo incompleto puede producir un resultado de negocio erróneo.

Revisa las promociones inactivas o caducadas según tu política comercial. Las selecciones pertinentes de reglas del carrito del núcleo ya filtran por estado activo y fechas, por lo que no hacen falta tanto la desactivación como una fecha pasada solo para excluir una regla. Conserva las reglas aún necesarias para pedidos, informes o campañas válidas.

Mide la evaluación de las reglas con carritos representativos. Antes de unificar reglas que se solapan, pide al comerciante que confirme las combinaciones previstas y el comportamiento de caducidad y vuelve a probar después los descuentos y los totales con carritos que cumplen y que no cumplen las condiciones.

Recuentos de facetas y búsqueda

Analiza la implementación de búsqueda por facetas instalada y sus consultas de recuento reales. No deduzcas una consulta por cada valor de filtro posible. Compara los recuentos solicitados con los filtros que los clientes usan realmente y prueba si ayuda reducir las facetas sin uso, corregir un índice o usar la propia caché de la integración. Quitar un filtro útil solo para mejorar una prueba de rendimiento cambia el recorrido de compra.

Usa la operación de indexación compatible cuando necesites reconstruir el índice. PrestaShop 9.1 añadió un comando de búsqueda con opciones de reconstrucción completa y ámbito de tienda:

php bin/console prestashop:search:index --full --shop-id=1

Consulta la ayuda del comando instalado antes de usarlo en otra versión. La indexación de búsqueda desde el back office es la alternativa para versiones sin ese comando. Un motor de búsqueda externo puede seguir teniendo consumidores nativos o alternativas de respaldo; no trunques las tablas de búsqueda nativas solo porque haya otro motor instalado.

Trabajo N+1

Un hook de listado que consulta reseñas una vez por producto repite trabajo a medida que crece el resultado. Cuando la función lo permita, reúne los ID de producto, obtén los datos agregados en una consulta con el ámbito correcto y reutilízalos durante el renderizado. Incluye condiciones de pertenencia a la tienda y visibilidad, valida los ID y gestiona una lista vacía. Compara el resultado mostrado además del número de consultas.

Pide una propuesta de agrupación por lotes que explique cómo se reúnen los ID de producto de la lista, cómo reutiliza los resultados el hook de visualización y por qué esa reutilización no puede mezclar tiendas ni valores específicos de cada cliente. Comprueba el hook exacto y los datos de producto disponibles para el módulo y la versión instalados. Mantén la corrección en el módulo responsable o en sus puntos de extensión admitidos, para que sobreviva a las actualizaciones. El número de productos, reglas o módulos instalados no es un motivo automático para eliminar o sustituir nada.

En el trabajo con API remotas, compara primero el tiempo de base de datos con las esperas de la API externa: una llamada lenta a un proveedor o ERP necesita una corrección distinta de un índice que falta. Registra el comportamiento ante tiempos de espera y fallos. Guarda en caché y actualiza los datos fuera de la solicitud del visitante cuando sus requisitos de actualidad lo permitan. Las tarifas del proceso de compra, el stock o las comprobaciones de pago pueden necesitar datos actuales, así que no elimines comprobaciones en tiempo real necesarias solo para mejorar una prueba de rendimiento.

Ajusta la memoria y la durabilidad de la base de datos según las mediciones

El buffer pool de InnoDB guarda en caché las páginas de datos e índices. Dimensiónalo junto con el sistema operativo, los procesos PHP, Redis y los búferes de conexión de la base de datos: un pool más grande puede perjudicar a la tienda si el resto del servidor empieza a usar el intercambio a disco. Un servidor de base de datos dedicado y un servidor web y de base de datos combinado necesitan presupuestos distintos, no un porcentaje fijo de la memoria instalada. El tamaño de la base de datos por sí solo no demuestra que quepa el conjunto de datos activo.

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW GLOBAL STATUS LIKE 'Slow_queries';
SHOW GLOBAL STATUS LIKE 'Created_tmp_tables';
SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables';
SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Max_used_connections';

Toma dos muestras a lo largo de un intervalo representativo. Usa la diferencia entre muestras para los contadores acumulados de lecturas del buffer pool, consultas lentas y tablas temporales. Lee Threads_connected como el número actual de conexiones y Max_used_connections como el máximo de conexiones simultáneas desde el arranque o el reinicio correspondiente; sus diferencias no miden la carga de conexiones. Si la variación de solicitudes de lectura no es cero, hit_ratio_percent = (1 - delta_reads / delta_read_requests) * 100, donde delta_reads es la variación de Innodb_buffer_pool_reads y delta_read_requests la variación de Innodb_buffer_pool_read_requests. Descarta los intervalos que incluyan un reinicio del servidor o de los contadores y compara cargas equivalentes en lugar de totales acumulados desde fechas de reinicio distintas. Una tasa alta puede convivir con consultas costosas, y una tasa más baja no justifica automáticamente más RAM. Relaciona las lecturas físicas, la latencia del almacenamiento y la presión de memoria; una caché más grande puede mejorar las lecturas repetidas sin resolver una escritura de larga duración ni una espera de bloqueo.

Mantén innodb_flush_log_at_trx_commit=1 como el ajuste duradero normal. Ponerlo a 2 puede hacer que se pierdan transacciones confirmadas recientemente tras un fallo del sistema operativo o un corte de corriente. No sacrifiques la durabilidad de los pedidos por una mejora de ajuste sin medir; cualquier propuesta de debilitar el volcado en cada confirmación necesita una decisión de negocio explícita sobre la pérdida de datos y la recuperación.

Usa una configuración específica para cada versión. MySQL 8 eliminó la caché de consultas. MariaDB conserva su propia implementación, pero prueba la contención y el beneficio para tu carga antes de activarla, y no cambies de motor solo por velocidad. MariaDB 10.6 eliminó innodb_buffer_pool_instances. MySQL 8.0.30 introdujo innodb_redo_log_capacity en lugar de la práctica anterior de dimensionar el redo log; usa la documentación actual del redo log y las variables admitidas por tu servidor.

No copies en todos los servidores tamaños universales de hilos de E/S, conexiones, búferes de ordenación o tablas temporales. Las asignaciones por conexión y la concurrencia pueden agotar la memoria, y subir a la vez los búferes y los límites de conexiones multiplica ese riesgo bajo carga. Mantén Performance Schema disponible para el diagnóstico salvo que limitaciones medidas justifiquen un cambio; ajusta la instrumentación en lugar de desactivarla como norma general en producción. Usa sus consultas de supervisión solo cuando la instrumentación necesaria esté disponible. Revisa Table_locks_waited junto con los diagnósticos de bloqueos propios del motor; no es una medida completa de las esperas por bloqueos de fila de InnoDB.

Para cada cambio propuesto, pide al alojamiento el ajuste actual, la limitación medida, el valor propuesto, el beneficio esperado y el procedimiento de reversión. En un servidor compartido con PHP, un aumento del buffer pool debe dejar espacio para los procesos PHP ocupados y las importaciones. En un servidor de base de datos dedicado, siguen importando la latencia del almacenamiento, las conexiones simultáneas y el trabajo de las copias de seguridad.

Limpia tablas solo con una política de conservación acordada

Mide el crecimiento y la conservación de las tablas por separado del ajuste de consultas, y revisa el crecimiento junto con el coste real de las consultas y el tamaño de las copias de seguridad. La actividad de los visitantes y la creación de carritos dependen de las funciones activadas y del comportamiento. Ya existen algunas vías de limpieza específicas, como la limpieza de páginas de conexión. Usa la guía de mantenimiento de la base de datos para conservar carritos, invitados y registros teniendo en cuenta sus dependencias.

Los datos de visitas antiguos, las búsquedas, los registros de correo, los carritos abandonados y las reglas de precios caducadas pueden ser candidatos, pero comprueba primero las dependencias de informes, atención al cliente, recuperación de carritos e integraciones, y acuerda qué conservar con las personas que usan esos registros. Un carrito antiguo sin pedido no es automáticamente seguro de eliminar. La conservación es una decisión de negocio, no un número universal de días.

Con las copias de seguridad, una ejecución probada en preproducción y la reversión preparadas, Database Cleanup ofrece áreas seleccionables, periodos de conservación, una vista previa de filas y una simulación antes de eliminar. No toca los pedidos, las cuentas de clientes, los productos activos ni los carritos vinculados a pedidos, y limita la limpieza multitienda a las tiendas seleccionadas. Si el problema incluye también imágenes huérfanas y archivos sin uso, Cleanup Revolution añade esas áreas, limpiadores con vista previa, ajustes de conservación y un límite de filas por ejecución. Las imágenes que elimina siguen siendo recuperables en una papelera fechada durante el periodo elegido, lo que no es una promesa de recuperación de todos los registros eliminados, y las cuentas sin pedidos necesitan una doble confirmación aparte. Elige la herramienta según el alcance del mantenimiento en lugar de instalar ambas por defecto.

Previsualiza los candidatos exactos, aprueba un primer lote controlado y comprueba después el comportamiento de la tienda, el número de candidatos y el historial de ejecuciones antes de programar más. Las áreas protegidas de un limpiador no sustituyen tu propia copia de seguridad. InnoDB puede reutilizar el espacio eliminado, pero borrar filas no devuelve necesariamente espacio al sistema operativo, y reconstruir una tabla puede necesitar espacio adicional y bloqueos. Un OPTIMIZE TABLE rutinario tras cada limpieza es innecesario, y truncar el índice de búsqueda no es mantenimiento; si la búsqueda necesita reconstruirse, usa la operación de indexación admitida en tu versión.

Reduce el trabajo de imágenes, hojas de estilo y JavaScript

Inspecciona el elemento LCP real y la cadena de solicitudes. Adapta las dimensiones de las imágenes generadas al tamaño mostrado, la densidad del dispositivo y las necesidades de zoom. No hay un límite universal de tamaño de imagen original ni un ahorro garantizado por formato. Reserva las dimensiones de las imágenes para reducir desplazamientos y deja que las imágenes visibles prioritarias carguen pronto, mientras difieres las imágenes adecuadas fuera de pantalla.

Regenera las miniaturas afectadas después de cambiar los tipos de imagen. Haz primero una copia de seguridad de las imágenes. En PrestaShop 9.1+, php bin/console prestashop:thumbnails:regenerate products --delete elimina las miniaturas de producto existentes antes de reconstruirlas. Ejecuta las reconstrucciones grandes fuera de horas punta. Para reanudar una ejecución interrumpida, omite --delete para conservar los archivos existentes y generar los que faltan. Las versiones anteriores necesitan su herramienta compatible del back office o una herramienta proporcionada por separado. El guardado en WebP empezó en 8.0; la generación de varios formatos, incluido AVIF, llegó en 8.1 como función experimental. Confirma la compatibilidad del servidor y del tema e inspecciona el formato entregado al navegador. Consulta optimización de imágenes.

El CSS crítico es el conjunto de estilos necesario para la ventana visible inicial. Genéralo para páginas y estados adaptables representativos, inserta en línea el subconjunto validado y carga adecuadamente el CSS restante. Conserva los estilos de respaldo y prueba menús, banners de consentimiento, variantes de idioma y contenido insertado dinámicamente. Una extracción incompleta puede provocar parpadeos, desplazamientos o controles ausentes.

Reduce el CSS y JavaScript sin uso mediante mediciones en todos los estados necesarios. La cobertura de una sola ventana inicial no demuestra que sea seguro eliminar un selector. Compara un carrusel con una imagen principal estática cuando su comportamiento aporte poco valor, y después prueba el resultado real.

Para scripts externos clásicos, defer pospone la ejecución hasta que finaliza el análisis conservando el orden de los scripts diferidos; async sirve para trabajo independiente cuyo orden de finalización puede variar. Ninguno elimina el coste de ejecución. La opción de registro de JavaScript de PrestaShop está en plural:

['position' => 'bottom', 'priority' => 200, 'attributes' => 'defer']

Pasa estas opciones a registerJavascript() al registrar un recurso propio. Regístralo solo en las páginas que lo necesiten. Prueba las dependencias y todas las interacciones afectadas tras cambiar el orden o los tiempos. Unifica los rastreadores duplicados y condiciona correctamente los servicios no esenciales.

Audita las fuentes, los iconos y el tema

1. Filtra Network por Font con la caché del navegador desactivada. Registra los archivos, tamaños transferidos y hojas de estilo que los solicitan.
2. Inspecciona los estilos calculados y Coverage en distintos tipos de página e interacciones para identificar las familias, pesos, estilos e iconos utilizados.
3. Busca en los recursos registrados del tema activo, sus importaciones CSS y sus plantillas. Los temas basados en Classic normalmente usan templates/_partials/head.tpl; los temas personalizados pueden diferir.
4. Elimina los recursos innecesarios mediante el código fuente mantenido del tema o un tema hijo. Comprueba todos los idiomas admitidos, los símbolos de moneda y el contenido dinámico.

Classic y Hummingbird incluyen declaraciones de la fuente Material Icons. Inspecciona el CSS entregado antes de suponer que alguno de los temas ha eliminado las fuentes de iconos. Inspecciona la versión exacta y las bibliotecas añadidas por módulos. Un subconjunto o unos iconos SVG seleccionados pueden reducir los recursos sin uso, pero conserva los símbolos necesarios y las etiquetas accesibles.

Solicita solo los pesos y caracteres de fuente que uses. WOFF2 y los subconjuntos elegidos con cuidado pueden reducir las transferencias; el ahorro depende de la fuente y los idiomas. Una pila de fuentes del sistema evita descargas adicionales de fuentes web. Por ejemplo:

font-family: system-ui, -apple-system, "Segoe UI", sans-serif;

Para las fuentes que conserves, elige una política de font-display adecuada. swap muestra texto de respaldo mientras carga la fuente, pero las métricas pueden cambiar y causar desplazamientos. Iguala las métricas de respaldo cuando sea posible y prueba el diseño. Para Google Fonts, solicita display=swap explícitamente cuando lo desees e inspecciona el CSS devuelto; no es universal en todas las URL de la API. Consulta la guía de Fonts API.

Autoalojar archivos de fuentes con licencia evita la solicitud de fuentes a ese proveedor remoto y permite reutilizar la conexión con tu origen. La carga remota sigue necesitando una evaluación de privacidad adecuada. El caso de Google Fonts de Múnich de enero de 2022 otorgó una indemnización civil de EUR 100, no una multa administrativa, como explica la autoridad de Baja Sajonia.

Para comparar temas, usa los mismos datos y ajustes de preproducción, un tema predeterminado compatible y estados de caché registrados. Un cambio de tema también cambia funciones y la presentación de módulos, así que la diferencia es un experimento, no un cálculo exacto de todo el coste del tema. Desactiva efectos, fuentes o componentes individuales para acotar más. Conserva los cambios mantenidos en un tema hijo cuando corresponda.

En una traza de Performance, inspecciona las tareas largas de JavaScript y sus pilas de llamadas. Usa los eventos Layout/Recalculate Style y los diagnósticos de recálculo forzado para detectar recálculos repetitivos del diseño. Las marcas rojas por sí solas no lo demuestran. Usa la referencia de rendimiento de DevTools al interpretar la traza.

Audita lo que los módulos ejecutan y cargan realmente

Crea un inventario por página del CSS/JS de los módulos, su tamaño transferido y decodificado, solicitudes, llamadas a consultas, ejecución del servidor y widgets que necesitan esos recursos. El registro de hooks o el número de módulos por sí solos no indican el coste.

En un contexto de tienda única, Diseño → Posiciones muestra los registros de hooks. Activa Mostrar los hooks no posicionables para incluir hooks de acción como actionFrontControllerSetMedia junto a hooks de visualización como displayHeader. El núcleo admite excepciones de controlador para registros de hooks, y un módulo puede registrar recursos condicionalmente. Un hook sin HTML visible puede seguir realizando una inicialización necesaria.

Filtrar Network por /modules/ es un buen comienzo. Omite los recursos agrupados por CCC o por el tema, los recursos remotos y los archivos generados dinámicamente. Rastrea los iniciadores y el contenido de los paquetes; desactiva temporalmente CCC en preproducción para una prueba de diagnóstico cuando sea necesario.

1. Encuentra recursos costosos y llamadas al servidor en la página lenta.
2. Comprueba dónde aparecen sus funciones. Las reseñas y los botones de lista de deseos pueden necesitar legítimamente recursos en listados de categoría.
3. Bloquea una URL de recurso con una coincidencia precisa para un experimento de navegador y después inspecciona el comportamiento que falla. Bloquear el dominio compartido de la tienda no aísla un módulo.
4. Desactiva un módulo sospechoso en preproducción y repite las mismas pruebas. Bloquear en el navegador no elimina el trabajo de los hooks del servidor; desactivar un módulo también cambia el comportamiento de la página.
5. Prefiere corregir el registro condicional dentro del módulo. Usa excepciones de hooks o lógica de anulación y nuevo registro solo tras comprobar las dependencias y la inicialización.
6. Vuelve a comprobar las interacciones de producto, categoría, cuenta, carrito, compra, consentimiento y móvil.

Mantén operativas las funciones útiles mientras reduces su trabajo innecesario. No existe un presupuesto universal de diez milisegundos por módulo ni un porcentaje de ahorro garantizado por una auditoría.

Elige la capa de caché y prueba los criterios de inclusión y la invalidación

Añade caché donde las mediciones muestren trabajo repetido que pueda reutilizarse con seguridad. Una caché nueva cambia la carga de trabajo; no elimina la necesidad de medir y de mantener sana la ruta sin caché.

Integración de Redis

Instala un servicio Redis real, el soporte PHP necesario y el adaptador que conecte la ruta de caché prevista. El ajuste ps_caching debe indicar un adaptador de caché de aplicación instalado; no configura el almacenamiento de sesiones. Un adaptador personalizado usado con Performance Revolution se llama MPRCacheRedis; usa el procedimiento de instalación compatible con esa implementación.

Configura por separado el almacenamiento de sesiones de PHP o Symfony, incluidas sus políticas de bloqueo y fallos. Las cookies de clientes y las sesiones PHP son mecanismos distintos, y cambiar a Redis no elimina por sí mismo los bloqueos.

Las API de escritura en base de datos del núcleo pueden invocar la invalidación del adaptador cuando la caché está activada. El SQL directo, las importaciones externas y las cachés propias de los módulos pueden seguir otras vías. Prueba las actualizaciones de precios, stock, productos, categorías y configuración por cada vía de escritura que uses. Redis por sí mismo no sabe qué páginas de PrestaShop o resultados de consultas han quedado obsoletos. Prueba también la caducidad, las solicitudes simultáneas y el comportamiento cuando falla el servicio Redis.

La página de ayuda de Redis Cache Manager & Monitor cubre las comprobaciones de conexión, la gestión de claves y los interruptores independientes para datos almacenados, sesiones y páginas de invitados. Hace falta un servicio Redis operativo; prueba en preproducción cada integración activada, la invalidación y el comportamiento ante fallos.

Caché de página completa

Un visitante nuevo con un navegador sin caché puede recibir un acierto de una caché compartida de páginas ya preparada. Los aciertos que cumplen los criterios pueden evitar trabajo costoso de base de datos y reducir el TTFB, aunque la ruta de consultas subyacente sea lenta. Los fallos de caché y las solicitudes excluidas/privadas siguen necesitando una aplicación sana.

Un módulo de aplicación sigue ejecutando PHP en su ruta de caché. Un proxy inverso externo o una caché FastCGI bien configurados pueden evitar PHP en los aciertos. Trata sus tiempos como mediciones distintas. Establece una política explícita de inclusión que cubra el método de solicitud, el controlador resuelto, los parámetros de consulta, el host/tienda, el idioma, la moneda y todos los factores que afecten al contenido público.

Excluye el carrito, la compra, la cuenta, el inicio de sesión, el back office, la API, AJAX y las respuestas personalizadas salvo que un mecanismo de aislamiento diseñado específicamente las gestione. Respeta las respuestas private/no-store y el comportamiento de establecimiento de cookies. Una lista de exclusión de fragmentos de URL en inglés omite rutas traducidas y controladores en cadenas de consulta.

Prueba con dos navegadores y distintos estados de cliente. Verifica las claves de caché, las variaciones de consentimiento y que el contenido privado nunca pase de un visitante a otro. Prueba la invalidación para ediciones de productos, precios, stock, cambios de categoría, inicio/fin de promociones e importaciones externas. Un TTL es una tolerancia deliberada a datos obsoletos, no una invalidación completa.

La purga basada en etiquetas y los fragmentos dinámicos pueden ayudar cuando están implementados. ESI, la hidratación en el navegador y la sustitución de marcadores en PHP son técnicas distintas. Para la caché de aplicación compatible, los marcadores del lado del servidor, los objetivos de CSS crítico y la cobertura del análisis de rendimiento, consulta la página de ayuda de Performance Revolution. El módulo también mide la velocidad real de las páginas para los clientes y puede servir las páginas públicas aptas a través de Cloudflare de forma opcional, con copias públicas que varían por idioma, moneda, país y dispositivo y con las páginas afectadas renovadas cuando cambian los precios o el stock; los carritos, el proceso de compra, las cuentas y las visitas con sesión iniciada usan la tienda en producción. Confirma en preproducción que encaja con tu caché, tu tema y tus integraciones a medida existentes.

Lista de comprobación para aceptar la caché

• Precalienta una página de producto pública apta y cambia después su precio y su stock por las vías de actualización normales de la tienda, incluidas las importaciones del ERP o masivas cuando se usen. Comprueba cuándo se actualiza la copia pública.
• Cambia idioma, moneda y país de destino. Prueba precios por grupo de clientes y visualizaciones de precios personalizadas; excluye las páginas o contextos cuya variación no puedas demostrar de forma segura.
• Añade al carrito, inicia sesión y abre las páginas de cuenta y proceso de compra. Comprueba que el contenido personal sea correcto para cada visitante y que no se reutilicen respuestas privadas.
• Ensaya en preproducción la caducidad, los fallos de caché simultáneos y la caída del servicio de caché. Confirma que la alternativa sigue siendo correcta y que la recuperación no satura el origen.
• Registra qué capa gestiona cada respuesta en caché y cómo invalidarla. Confirma que otro proxy o CDN no pueda conservar una copia después de renovar la caché de la aplicación.

Caché estática y precalentamiento

Las entradas vigentes de la caché del navegador pueden evitar un viaje de ida y vuelta por la red. La validación ETag normalmente realiza una solicitud condicional. Usa periodos largos de vigencia solo con una estrategia adecuada de despliegue de recursos versionados; una limpieza del servidor no puede borrar la caché del navegador de todos los visitantes. Una CDN puede servir recursos públicos cerca de los visitantes, pero verifica TLS, CORS para fuentes, las cabeceras de caché y la invalidación.

Vacía solo las capas afectadas mediante herramientas compatibles. Precalienta las páginas importantes que cumplan los criterios tras un despliegue con concurrencia y carga limitadas. No supongas que activar la caché de plantillas renderizadas traslada a Redis los archivos PHP de plantillas compiladas. Precalentar el origen y los nodos de la CDN son tareas separadas, y el precalentamiento puede añadir carga. Compara ejecuciones deliberadamente frías y calientes en lugar de ocultar la diferencia.

La guía de caché de página completa, Redis y CDN trata estas capas con más detalle.

Gestiona las combinaciones y la lentitud del back office

La capacidad del catálogo depende de las combinaciones, asociaciones, imágenes, características, filtros, precios e importaciones, además del número de productos. No existe un único límite práctico de productos para todas las tiendas. Haz pruebas de carga en una copia de preproducción con datos y tráfico realistas.

Seis tallas, ocho colores y cinco acabados producen 240 combinaciones si se generan todas. Inspecciona los conjuntos más grandes con estas consultas de solo lectura, sustituyendo el prefijo predeterminado según sea necesario:

SELECT id_product, COUNT(*) AS combinations
FROM ps_product_attribute
GROUP BY id_product
ORDER BY combinations DESC
LIMIT 20;

SELECT id_product, COUNT(*) AS stock_rows
FROM ps_stock_available
WHERE id_product_attribute <> 0
GROUP BY id_product
ORDER BY stock_rows DESC
LIMIT 20;

La consulta de filas de stock cuenta las filas almacenadas en sus distintos ámbitos; no es un total de stock aislado por tienda. Revisa la pertenencia a tienda/grupo al interpretarla.

Elimina variantes imposibles, reduce dimensiones innecesarias o divide un producto muy grande cuando encaje con el comportamiento de compra. Las opciones que no necesitan stock o precio independiente pueden encajar mejor como personalizaciones o en un configurador. Revisa las consecuencias para URL, imágenes, precios y stock antes de cambiar el modelo.

Los formularios e importaciones grandes pueden alcanzar max_input_vars, post_max_size, la memoria o los tiempos de espera de las solicitudes. Divide la sincronización de stock y las importaciones en lotes y reconstruye los índices de búsqueda/facetas afectados mediante herramientas compatibles tras cambios importantes.

Analiza las pantallas de administración por separado. Si solo va lento el panel, prueba sus estadísticas, feeds y widgets opcionales. Si va lento Module Manager, inspecciona los metadatos y las solicitudes a servicios remotos. Las integraciones de Marketplace dependen de la versión y la instalación; Marketplace no se incluye en el proyecto de código abierto desde la versión 8.

Si tanto la tienda como el back office van lentos, inspecciona los recursos compartidos de PHP, base de datos y alojamiento. Ese síntoma no demuestra un exceso de datos en la base de datos. Comprueba los directorios de caché con permisos de escritura, las reconstrucciones repetidas, OPcache, las colas de procesos, la latencia de la base de datos y los hooks de módulos pertinentes antes de eliminar datos.

Amplía las operaciones según la carga medida

Controla por separado la infraestructura, la precisión del inventario y la carga del personal. El número mensual de pedidos no determina una categoría de alojamiento ni hace obligatoria la caché de página completa. Las proporciones de tráfico por pedido y la concurrencia en picos varían.

Cronometra las tareas recurrentes: gestión de estados, preparación, envío, mensajes de clientes, devoluciones y exportaciones contables. Como ejemplo de planificación, 100 pedidos mensuales de seis minutos cada uno consumen diez horas de personal al mes. Usa tus propios tiempos medidos e incluye la gestión de excepciones antes de decidir qué automatizar.

Mantén separados el estado de pedido nativo, las notificaciones a clientes y el estado interno del flujo de trabajo de cualquier módulo. Advanced Order Fulfilment puede vincular eventos a sus propios pasos de flujo de trabajo, equipos y recordatorios; verifica por separado las transiciones de estado nativas y los emails de envío a los clientes.

Usa el flujo nativo de Servicio al cliente para los mensajes que realmente recibe. Un módulo de formularios independiente puede guardar sus propios envíos y notificaciones, así que confirma cualquier integración con el sistema de soporte. Para el enrutamiento propio de formularios, consulta la página de ayuda de Better Contact Form.

Concilia el stock entre pedidos, devoluciones y otros canales de venta. Revisa las acciones masivas de pedidos y las exportaciones filtradas, incluidos los permisos y su efecto sobre las notificaciones. Da cuentas individuales con acceso adecuado a su función a preparadores, personal de soporte y administradores.

Separa los servidores de base de datos y web solo cuando las mediciones justifiquen recursos independientes. Ten en cuenta la latencia de red, la conectividad segura, las copias de seguridad/restauración, los ajustes de conexión y las pruebas de despliegue. Un cambio de configuración por sí solo no es un plan completo de migración. Incluye personal, software, infraestructura, comisiones y devoluciones al evaluar el margen de pedidos adicionales.

Mantén una rutina de supervisión y despliegue

• Registra pruebas de laboratorio repetibles y métricas de usuarios reales para tipos de página representativos, junto al comportamiento de aciertos y fallos de caché.
• Supervisa la disponibilidad, los errores, las colas de procesos PHP, CPU, memoria, E/S, latencia de consultas, conexiones y capacidad de caché. Establece alertas según tu referencia.
• Revisa los resúmenes de consultas lentas, el crecimiento de tablas y la conservación. Usa herramientas como PMM o un panel de base de datos cuando encajen con tus necesidades operativas; las sugerencias automáticas siguen necesitando pruebas con tu carga.
• Tras un cambio de módulo, de tema o de catálogo, una importación grande o un cambio en el tráfico, compara los recursos, las llamadas, la carga de consultas y las interacciones con la referencia. Conserva los informes completos y un registro breve de cambios.
• Durante el despliegue, vacía las capas de PrestaShop afectadas, aplica la política documentada de OPcache web, invalida los recursos modificados y precalienta solo dentro de límites controlados.
• Comprueba de principio a fin los errores del navegador, la visualización de imágenes, la navegación, los filtros, el carrito, el pago y la confirmación, y confirma que los precios, el stock y las integraciones siguen funcionando como antes.
• Revisa las tendencias de campo cuando se hayan acumulado datos suficientes. No juzgues un informe de campo con ventana móvil por una única prueba de laboratorio o unos pocos días.

Elige el siguiente cambio según el coste medido, el riesgo y el impacto en el cliente. Vuelve a probar después y conserva una vía de reversión. Una prueba de rendimiento más rápida solo es útil si el catálogo, los precios, las decisiones de privacidad y el proceso de compra siguen funcionando correctamente.

Preguntas que se hacen los propietarios antes de pagar por trabajo de velocidad

¿Deberíamos comprar primero más memoria o un plan mayor? Pregunta qué espera medida eliminaría y qué necesitan los demás servicios del servidor. Más memoria no corrige una consulta lenta, una llamada externa ni el trabajo del navegador.

¿Una tabla grande necesita otro índice? Solo si un patrón de acceso real se beneficia lo suficiente como para justificar el coste de almacenamiento y de escritura. Prueba el candidato con la carga real en preproducción.

¿Deberíamos limpiar primero la base de datos? Solo donde un coste medido apunte en esa dirección, como una tabla que crece dentro de una consulta lenta o una ventana de copias de seguridad, y solo con una política de conservación acordada.

¿Podemos empezar por la caché? Evalúala cuando las mediciones muestren una oportunidad en el trabajo público repetido. Mantén correctos los recorridos privados, prueba la invalidación y conserva una vía sin caché aceptable; el orden de cambios depende de las pruebas.

¿Cuándo deberíamos repetir la revisión? Tras cambios relevantes de módulos o del catálogo, importaciones, cambios en el tráfico o un empeoramiento en los recorridos registrados. Mantén la supervisión suficiente para detectar ese cambio.