El primer visitante siempre paga la cuenta: El problema oculto del caché en CS-Cart

La primera vez que me dolió de verdad el rendimiento de un e-commerce fue un martes de noviembre. Habíamos lanzado una campaña masiva de correo para una tienda con más de 18,000 productos. Todo parecía perfecto. El servidor estaba holgado, el diseño era limpio y las pruebas de velocidad en la página de inicio daban números excelentes. Pero a los tres minutos de enviar el correo, el servidor se cayó por completo. La CPU se clavó en el 100% y no volvió a respirar en media hora.

No fue un ataque de denegación de servicio. Tampoco fue un error de código de algún add-on de terceros. El culpable real fue el sistema de generación de imágenes por demanda de cs cart. Un comportamiento nativo que, si ustedes no lo controlan a tiempo, destruye la experiencia del usuario y mata sus ventas en los momentos más críticos.

El visitante sacrificado

Para ahorrar espacio en disco y agilizar las subidas de catálogo, la plataforma no genera todos los tamaños de miniaturas cuando ustedes suben una imagen de producto. En su lugar, espera. Espera a que un usuario real entre a una categoría, busque un producto o filtre una lista. En ese preciso milisegundo, el servidor toma la imagen original, la redimensiona, la recorta, la comprime y la guarda en el caché antes de mostrársela al cliente.

¿El problema? Que el primer visitante de esa categoría tiene que pagar la cuenta de esa operación. Si la página muestra 40 productos nuevos y ninguno tiene sus miniaturas generadas, esa persona va a esperar 8, 10 o hasta 15 segundos frente a una pantalla en blanco mientras su servidor trabaja a marchas forzadas. La mayoría de la gente no espera tanto; simplemente cierra la pestaña y se va a comprar a otra parte.

El laberinto de las búsquedas perdidas

Hace un tiempo, analizando los reportes de tráfico de una tienda que administrábamos, me di cuenta de lo confuso que puede ser el comportamiento del usuario cuando una página tarda en cargar. Revisando la Search Console, veíamos clics absurdos. El buscador a veces asocia el término cs cart con las cosas más disparatadas del mundo.

Nos llegaba gente buscando información sobre el club de fútbol costarricense, el cs cartaginés, o haciendo preguntas básicas como cs cartagines de donde es. Teníamos impresiones de fanáticos buscando el clásico de la liga tica cs cartaginés vs municipal pérez zeledón o intentando comprar entradas a través de cs cartaginés com boleteria para asistir al estadio en la provincia de cs cartago. Por si fuera poco, el algoritmo también nos mezclaba con búsquedas de salud pública en España, como el cs cartagena oeste o el cs cartagena este, y hasta con adolescentes buscando música de la banda mexicana cs cartel de santa.

Ese tráfico basura es normal en la web. Lo que no es normal es que cuando un cliente real —alguien que de verdad buscaba un alternador o una playera en nuestra tienda— hacía clic en un enlace legítimo, se encontraba con un sitio congelado. Estábamos perdiendo dinero real por culpa de un servidor que prefería procesar imágenes en tiempo real en lugar de despachar páginas de forma instantánea.

La mentira de "comprar más hardware"

La reacción instintiva de muchos dueños de tiendas es subir de plan en el hosting. Pasan de un VPS de 20 dólares a un servidor dedicado de 150 dólares al mes. No lo hagan. Es tirar el dinero a la basura.

Incluso un procesador de última generación sufre si tiene que procesar 50 imágenes pesadas en paralelo bajo la petición de un solo usuario. La solución real no es más potencia; es el sentido común. Las imágenes deben estar listas antes de que llegue el primer humano. Necesitamos precalentar el caché.

Cómo solucionar esto ustedes mismos

Para resolver esto, la estrategia es simple pero requiere disciplina técnica. Tienen que construir un script que actúe como un visitante fantasma. Este script debe recorrer la tienda de forma sistemática y silenciosa durante la madrugada, obligando al sistema a generar todas las miniaturas pendientes.

El flujo básico que yo utilizo es el siguiente:

Primero, extraigan todas las URL de categorías y productos directamente de la base de datos o del sitemap de la tienda. No usen rastreadores web externos que saturen el ancho de banda; vayan directo a la fuente de datos interna.

Segundo, ejecuten un proceso en segundo plano (un cron job) que visite cada una de esas URL utilizando comandos curl ligeros. La clave aquí es simular la visita de manera controlada: una petición cada dos o tres segundos para no estresar la base de datos ni saturar la memoria RAM.

Al hacer esto, el motor del e-commerce procesará las miniaturas que falten y las dejará guardadas en la carpeta de caché del servidor. Cuando sus clientes reales entren por la mañana, la página cargará en menos de un segundo porque el servidor solo tendrá que entregar archivos estáticos que ya están listos en el disco duro.

Zapatero a tus zapatos

Hacer esto bien requiere tiempo de desarrollo, pruebas para no tirar el sitio mientras el script corre y mantenimiento constante cada vez que actualizan la versión de la plataforma. Si ustedes tienen un programador interno con tiempo libre, esta es la ruta que deben seguir hoy mismo.

Pero si prefieren enfocarse en vender, en mejorar su logística y en hacer crecer su negocio sin pelearse con el código ni con servidores que se caen en las horas pico, nosotros podemos encargarnos de todo el trabajo pesado de optimización y mantenimiento. En GuardLabs desarrollamos un sistema automatizado y optimizado específicamente para este problema: nuestro servicio de Прогрев кэша миниатюр в CS-Cart se encarga de mantener su catálogo pregenerado y volando las 24 horas del día, sin que ustedes tengan que mover un solo dedo.