Tienes un Magento con Varnish Caché, pero no vuela. Te paras a analizar un poco el percal:

• Cargas un producto. Tarda la vida. 🐢
• Recargas la misma página. Vuela. Genial, Varnish está funcionando! 👏
• Te vas a por un café, vuelves a los 10 minutos y cargas otra vez. ¡TTFB de 2 segundos! ¡Fuck! ¡Pero si estaba en caché hace un momento!

Si te sientes identificado y estás a un paso de tirar el servidor por la ventana, esta extensión es para ti 👉 Sigue leyendo.

¿Qué demonios está pasando con tu full page cache?

Seamos sinceros: la gestión de caché nativa de Magento es como ordenar tirando todo lo que hay encima de la mesa a la basura porque «así terminas antes». 🧹

Lo que ocurre es que Magento prioriza que los datos que ve el usuario estén totalmente actualizados «al instante». Me explico…

Imagina que toda tu tienda (home, categorías, productos…) está perfectamente cacheada. La web va como un tiro, las Core Web Vitals están en verde. Pero de repente, vas al backoffice y cambias un bloque estático del footer para actualizar el año del copyright, que estaba en 2018 (un clásico). Pones 2026 📅, le das a guardar y ¡pum!, los ventiladores del servidor empiezan a sonar como un Boeing 747 despegando. La web se arrastra y los de atención al cliente te colapsan el Slack porque generar una factura tarda más que el desarrollo de GTA VI. 🎮

¿Qué ha pasado? El drama de la invalidación masiva 💣

Magento ha hecho ni más ni menos que lo que le han pedido… Magento es listo (a ratos), pero muy dramático. Sabe que el bloque del footer sale en TODAS las páginas y, como su lema es «antes muerta que desactualizada», lanza una purga de caché masiva de absolutamente todas las URLs que contienen ese bloque. Resultado: toda tu tienda se va por el retrete en un segundo. 🚽

¿Es correcto? 👉 Sí
¿Es óptimo? Menos que intentar apagar un incendio con pistolas de agua 🔫🔥

¿Quieres más ejemplos? Vamos allá…

Cuando entra un pedido, el stock cambia. Quizá el producto que me han comprado se agota y hay que quitar el botón de «Añadir al carrito», o quizá muestra que me quedan 232 unidades pero realmente ya solo tengo 231. Magento entra en pánico nuclear: «¿Ah, sí? Pues borro la página del producto, las diez categorías donde aparece y, ya que estamos, la home por si acaso». 🤯

Si encima sincronizas el stock con un ERP cada 5 minutos… felicidades, tienes una caché que no sirve para nada. El TTFB (Time To First Byte) de tu web pasará de 300ms a 3 segundos porque el procesador está más estresado que un desarrollador el viernes a las cinco de la tarde. 😫

¿Y esto de que esté actualizado, no es lo que queremos?

Hombre, pues sí claro. Pero igual invalidar toda la caché para que el copyright que llevaba mal tres se actualice, no es lo más óptimo. Queremos que todo esté actualizado, pero hay mejores formas de hacerlo.

El problema principal es que Magento invalida la caché de un producto (o de mil) y ese producto ya no está en caché hasta que otro usuario lo visita… y por tanto quién paga la regeneración de esa página son tus usuarios.

Vale, me has convencido… ¿y cómo mejoramos el rendimiento? 🛠️

La clave para una tienda online rápida no es solo invalidar (borrar), sino regenerar.

Si un producto cambia, no lo borres y esperes a que un pobre usuario llegue y se coma los 4 segundos de carga. Bórralo y regenéralo tú en segundo plano. Así, cuando llegue el cliente, la página ya está lista y fresquita. Esto se llama Cache Warming (o calentamiento de caché para los que no quieren postureo técnico). 🍞🔥

Características de la extensión ByDN Improved Page Cache ✨¡

Estrategia de Refresco Inteligente: Intercepta las purgas masivas y las pone en cola. Nada de picos de CPU, solo orden y concierto. 🎼

Calentamiento de la caché (Cache Warmer): Calienta la Home, categorías o productos cuando te dé la gana. Ideal para después de un deploy o una importación masiva de catálogo. ⚡

Gestión de Prioridades: Lo que debe refrescarse va a antes. Lo que todavía no está en caché, después.

Procesamiento en Paralelo: Puedes configurar cuántas páginas se regeneran a la vez. No te flipes, que no queremos freír el servidor. 🍳

Monitorización desde el Admin: Un panel tipo grid para ver qué se está cociendo en la cola, cuánto tarda y si algún proceso ha petado. 📊

Instalación

Puedes bajarlo de mi GitHub aquí, pero si eres una persona de bien, lo harás por Composer:

composer require bydn/improved-page-cache
./bin/magento module:enable Bydn_ImprovedPageCache
./bin/magento setup:upgrade

Configuración

En tu backoffice, vete aquí:

Stores => Configuration => AI Extensions (by DN) => Improved Page Cache.

Verás que no hay mucho que configurar porque la extensión lo hace casi todo solita…

Habilitado: Esta opción te permite activar o mandar a paseo (desactivar) la extensión por completo.

Nivel de Concurrencia: Configura el número de peticiones paralelas simultáneas durante el proceso de warming. Por defecto son 5, no te flipes poniéndole 50 si no quieres que tu servidor empiece a echar humo.

Limpieza de Registros Antiguos (Días): Borra automáticamente los registros de warming que tengan más días de los que especifiques (por defecto: 7). Mantén la base de datos limpia, que luego nos quejamos de que Magento va lento.

Configuración de Varnish: El toque maestro 🎩

Para que esta mejora de velocidad en Magento sea 100% efectiva, añade esto al principio de tu vcl_recv en Varnish:

Fragmento de código

if (req.http.X-Magento-Cache-Refresh) {
    set req.hash_always_miss = true;
}

Esto le dice a Varnish: «Oye, cuando este módulo te pida algo, no me des lo que tienes guardado, vete a buscar la versión nueva y actualízala». Sin dramas. 😎

Modo Consola para los que no sueltan el teclado ⌨️

La extensión te trae dos comandos principales para que gestiones la cola de warming a mano. Uno permite encolar items para calentar. El otro permite procesar la cola del calentador a mano (aunque eso ya lo hace también un cron cada minuto).

Encolando items

Usa bydn:cache:enqueue para meter páginas en la cola de precalentado. Aquí tienes unos ejemplos para que no te pierdas:

• Calentar la Home de la tienda 1: php bin/magento bydn:cache:enqueue --stores 1 --type home
• Calentar TODOS los productos de la tienda 1 con prioridad máxima (el modo «ansioso»): php bin/magento bydn:cache:enqueue --stores 1 --type products --ids all --priority 5
• Calentar categorías específicas (pásale los IDs separados por comas y a correr): php bin/magento bydn:cache:enqueue --stores 1 --type categories --ids 10,11,12
• Calentar una URL concreta (porque te apetece y punto): php bin/magento bydn:cache:enqueue --stores 1 --type url --url "https://tu-tienda.com/pagina-especial"

Procesando la cola

Normalmente, los cron jobs se encargan de esto mientras tú te tomas un café, pero si tienes prisa y quieres disparar el proceso manualmente:

php bin/magento bydn:cache:warm

Y si solo quieres procesar lo importante (prioridad 3 o superior), puedes filtrar así:

php bin/magento bydn:cache:warm --priority 3

📊 Monitorización en el backoffice

Puedes ver el progreso del calentamiento de caché o los items que hay pendientes en:

System => Tools => Cache Warming.

¿Y si algo va mal? 😩

Me puedes escribir al formulario de contacto. Si el problema es interesante y no me pillas en medio de una crisis existencial con un bug de CSS, probablemente te conteste con una solución. 📩.

Y si necesitas que te lo instale, lo personalice para tu tienda online o le ponga un lacito para regalo porque tu cliente es muy exigente… también podemos hablar de negocios. 💸💼