Cuando una tienda online responde con lentitud, conviene revisar qué trabajo está haciendo el servidor. Entre el 6 y el 7 de octubre de 2026, en LiveCommerce analizamos la carga de ShopinCloud y actuamos sobre un problema concreto: peticiones de rastreadores a operaciones de carrito y creación de sesión. Las pruebas documentadas confirmaron que el filtro desplegado evitaba ejecutar PHP en las solicitudes rechazadas. El efecto sobre la velocidad global de las tiendas todavía necesita mediciones comparables.

Cuando el rastreo llega al carrito

Una tienda necesita que sus categorías y fichas de producto puedan consultarse. Pero el servidor también recibe solicitudes a funciones que realizan otro tipo de trabajo: iniciar una sesión, consultar un carrito o intentar añadir un artículo.

En el análisis encontramos peticiones a esas operaciones que se identificaban como rastreadores. Atenderlas podía activar lógica de aplicación, consultas y gestión de sesiones sin aportar el valor de una visita interesada en comprar.

La investigación también detectó tareas de fondo y otros posibles focos de carga. Por eso, el trabajo se centró en aislar una parte evitable y comprobable, manteniendo abierta la revisión del resto del sistema.

Una muestra concreta: 595 peticiones en diez minutos

En una ventana completa de diez minutos de una tienda de la plataforma se analizaron 3.023 peticiones . De ellas, 595 coincidían con la regla propuesta , al combinar la operación solicitada con el identificador de rastreador declarado por el cliente:

  • 290 se dirigían a añadir productos al carrito.
  • 289 consultaban el carrito.
  • 16 solicitaban crear una sesión.

Ese conjunto representaba aproximadamente el 19,7 % de las peticiones de aquella muestra . La cifra ayudó a dimensionar el trabajo que se quería filtrar. Su alcance es una tienda y un intervalo de diez minutos; no mide una reducción de CPU ni una mejora del 19,7 % en la velocidad del ecommerce.

Los registros describen solicitudes y respuestas. Por sí solos tampoco demuestran que cada intento terminara añadiendo un producto al carrito. Esa precisión permite decidir con datos sin atribuir al tráfico efectos que no se han comprobado.

Rechazar la petición antes de ejecutar la aplicación

La medida aplicada fue un filtro en Apache, el servidor web que ya atendía las tiendas. Cuando una petición coincidía con el ámbito, la operación y el agente definidos, Apache devolvía una respuesta breve de rechazo antes de ejecutar PHP, el componente que procesa la lógica de ShopinCloud.

La forma de responder también importaba. Se utilizó un mensaje directo para evitar que la propia página de error volviera a poner en marcha la aplicación. En los registros revisados se comprobó que las peticiones rechazadas no utilizaban el manejador PHP.

El resultado demostrado es evitar ese trabajo de aplicación en las peticiones cubiertas por la regla. La conexión y el servidor web siguen consumiendo recursos, por lo que el coste de atenderlas no desaparece por completo.

El filtro se delimitó a determinadas operaciones de carrito y sesión. Las categorías y fichas públicas quedaron fuera de ese bloqueo, y las pruebas incluyeron comprobar que las solicitudes de rastreadores al catálogo seguían recibiendo respuesta.

Probar el cambio y ensayar cómo retirarlo

La intervención comenzó con un alcance limitado y se amplió después a los frontales compartidos del SaaS. Antes de confirmar cada activación, se comprobó también la retirada automática del cambio mediante un temporizador.

Esta preparación permitía volver a la configuración anterior si el ensayo no se confirmaba. Se conservaron los archivos originales y se añadieron configuraciones independientes, con validación antes de recargar el servicio.

Las comprobaciones incluyeron navegación, sesión y carrito en muestras concretas. Durante el piloto también se contrastaron precios de diez productos entre los dos recorridos de prueba. No se realizaron pedidos ni pagos , y las comprobaciones no equivalen a validar todas las operaciones de todas las tiendas.

Se ensayó además un proxy privado con Nginx. Al cierre del informe quedó detenido y no atendía a compradores en producción. La protección que se confirmó durante esta intervención fue la de Apache.

Qué sabemos del rendimiento y qué falta medir

Las respuestas de rechazo registradas fueron breves y evitaron el paso por PHP. Sin embargo, las muestras anteriores y posteriores tenían peticiones, tamaños y condiciones distintos. Compararlas directamente no permite calcular cuánto más rápida se volvió una tienda.

Las comprobaciones externas mostraron tiempos variables. El resultado funcional documentado y el impacto general sobre la experiencia del comprador deben evaluarse por separado.

Para medir ese impacto, el informe propuso recoger datos bajo tráfico comparable: tiempos de respuesta por operación, esperas del servidor, errores y comportamiento de las tareas de fondo. También conviene observar las respuestas más lentas, porque una media aceptable puede ocultar esperas importantes en parte de las visitas.

Esta primera protección tiene otro límite: el nombre que declara un rastreador puede modificarse. La propia documentación de Apache sobre control de acceso explica por qué ese dato no acredita su identidad. Los controles basados en comportamiento y frecuencia quedaron como trabajo posterior.

Las siguientes mejoras deben partir de lo que se mide

El análisis dejó varias líneas de trabajo pendientes: revisar la concurrencia de importaciones y otras tareas PHP, investigar errores de caché, localizar consultas lentas y estudiar los recursos compartidos del servidor.

Para quien dirige una tienda, la pregunta útil es qué operación consume tiempo y cómo se comprobará la mejora. En cada intervención conviene acordar:

  • Un objetivo concreto: reducir esperas en búsqueda, fichas o carrito, o evitar trabajo de aplicación innecesario.
  • Una comparación válida: medir en condiciones similares y distinguir visitas normales de pruebas y rechazos.
  • Controles de negocio: comprobar sesión, precios y carrito, y vigilar que stock y catálogo sigan actualizados.
  • Una forma de volver atrás: delimitar el cambio y ensayar su retirada antes de ampliarlo.

Para profundizar con tu equipo técnico, puedes consultar nuestro artículo sobre diagnóstico de rendimiento en Linux . Otra parte del rendimiento se aborda en el sistema de proxy y caché de imágenes de ShopIn CDN .

Este caso documenta una primera reducción de trabajo evitable y un método para introducir cambios con pruebas y retorno preparado. La medición posterior debe determinar cuánto beneficia al conjunto de la plataforma.

¿Tu tienda acumula esperas o tiene dificultades al trabajar con un catálogo amplio? Escríbenos a LiveCommerce para estudiar tu operativa y localizar qué conviene medir y mejorar.

Caso basado en el informe técnico de los días 6 y 7 de octubre de 2026. Describe las verificaciones de ese periodo. Imagen de cabecera: ilustración conceptual.