Mantén tienda y carritos estables durante picos de tráfico

¿Una campaña, un envío masivo o un pico de tráfico están ralentizando o tirando la tienda justo cuando más ventas se esperan? El responsable técnico necesita mitigación rápida, segura y reversible que evite downtime y preserve carritos y checkout.

Optimizar plugins del área para high-traffic: Si tu WordPress sufre lentitud o caídas en picos de tráfico, aplica una configuración segura y probada de caché: habilita cache de página con exclusiones para carritos/formularios, object cache con Redis, precarga controlada, purga programática y reglas CDN; monitoriza hit ratio y TTFB, prueba en staging y conserva rollback automatizado para evitar downtime. Conviene empezar por la sección 'Resume el proceso y deja el sitio estable en 30–120 minutos'.

Resume el proceso y deja el sitio estable en 30–120 minutos

1. Detecta y mitiga el origen: reduce RPS al origin y sirve activos desde CDN.
2. Aplica bypass inmediato para checkout, carrito y REST API.
3. Habilita object cache persistente (Redis) con pool adecuado.
4. Activa cache de página conservadora y precarga limitada.
5. Orquesta purgas por tag y evita purgas totales.
6. Mide RPS, TTFB y cache hit ratio antes y después.

Ejecuta acciones inmediatas para estabilizar un WordPress en picos

1. Detén la precarga y desactiva cualquier "warmer" masivo.

Se desactiva la precarga porque puede crear un "cache storm" en el origin. Este paso tarda entre 1 y 5 minutos.

1. Bypassea rutas dinámicas críticas.

Añada reglas para excluir /cart, /checkout, /my-account, /wp-admin y /wp-json/* del cache. Use este comando WP-CLI para marcar exclusiones rápidas:

wp option set wp_rocket_always_exclude_urls '["/cart","/checkout","/my-account","/wp-json/"]'

1. Forzar CDN a cachear assets estáticos.

Crea reglas para CSS/JS/imagenes con TTL largo en CDN. Un ejemplo cURL para Cloudflare:

curl -X POST "https://api.cloudflare.com/client/v4/zones//purge_cache" / -H "Authorization: Bearer " / -H "Content-Type: application/json" / --data '{"files":["https://example.com/wp-content/.css","https://example.com/wp-content/.js"]}'

1. Comprobar salud del origin en 10 minutos.

Mida TTFB, %5xx, CPU PHP-FPM y conexiones MySQL. Use top/htop, mysqladmin proc, y curl para TTFB.

Para purgas a escala, diseñe una orquestación de invalidación: emita webhooks desde WordPress (por ejemplo en save_post o woocommerce_product_set_stock) que publiquen un mensaje en una cola (Redis list, SQS, RabbitMQ). Tenga un worker que agrupe tags durante X segundos (batching) y haga una sola llamada de purga por lote al CDN/edge, así evita purgas por cada actualización. Implemente límites y backoff exponencial ante errores 429/5xx y registre intentos en un dashboard. Nunca purgue todo en respuesta a cada cambio: prefiera purga por tag/prefix y use un buffer (p. ej., agrupar tags 5–30 s) y locks en Redis para evitar stampedes. Además, coordine la purga en el origin (borrar objetos en Redis/object cache) inmediatamente antes o después de la purga en CDN para evitar inconsistencias; si hay riesgo de cold cache, active grace mode o stale-while-revalidate en el borde para servir contenido ligeramente caducado mientras se regenera.

Aplica presets por concurrencia y por stack para optimizar plugins de cache para high-traffic

1. Seleccione un preset según concurrencia y stack.

Use la tabla de presets para aplicar valores reproducibles por rango de tráfico. Cambios típicos tardan 10–40 minutos según el acceso al hosting.

Implementa snippets y reglas para nginx, varnish, LiteSpeed y maneja WooCommerce y purgas

1. Copie y actúe los snippets según su stack.

Los snippets que siguen se pueden pegar y adaptar. Este paso suele tardar 20–60 minutos según acceso a servidores.

Nginx + PHP-FPM

Ajuste nginx para bypassar cache según cookies:

map $http_cookie $no_cache { default 0; ~wp_woocommerce_session_ 1; ~woocommerce_items_in_cart 1; }

proxy_cache_bypass $no_cache;

Y en server block:

add_header Cache-Control "public, max-age=300";

Varnish

if (req.url ~ "^/cart|^/checkout|^/my-account|^/wp-json") { return (pass); }

set beresp.grace = 1h;

LiteSpeed / ESI

Usar ESI para el mini-cart. Declarar fragmentos ESI para aislar solo el bloque del carrito.

Purga por tag

// Añadir tag al guardar un producto wp_cache_set("tag_product_{$id}", true); // Llamada API CDN para purga por tag

Manejo WooCommerce: fragment caching

Usar fragment caching para la parte del carrito y dejar la página principal cacheada. Insertar en plantilla mini-cart un fetch asíncrono con cached fragment.

En la experiencia del equipo de MantenWP, el error más frecuente es confiar solo en la CDN y no optimizar Redis y PHP-FPM en el origin.

Si usa un CDN con capacidad de edge scripting, como Cloudflare Workers, considere mover lógica de caché y bypass al borde:

• Un worker puede decidir cachear HTML público, respetar cookies y devolver fragmentos dinámicos desde origin.
• En el handler, compruebe la ruta y las cookies.
• Para páginas públicas haga let cached = await caches.default.match(req); if (cached) return cached; let res = await fetch(origin) y luego caches.default.put(req, res.clone(), { expirationTtl: 300 }). Los Workers permiten aplicar TTL, stale-while-revalidate y lógica para no cachear rutas con cookies de carrito. Integrar Workers con su plugin de cache local mejora hit ratio en el borde y reduce TTFB de forma consistente para picos de tráfico.
• Además, al responder desde el borde se reduce el RPS al origin y se puede coordinar purgas por tag enviando una request desde WordPress hacia un webhook que invalide claves en el Worker o en la CDN.

Valida con laboratorio de rendimiento, monitoriza y prepara rollback rápido

1. Ejecute pruebas controladas cold cache y warm cache.

Cree staging idéntico y defina escenarios: homepage, product page, checkout. Este setup puede tardar entre 30 y 90 minutos.

1. Comandos para benchmark reproducible.

Wrk ejemplo básico:

wrk -t12 -c400 -d60s --latency http://staging.example.com/

k6 script ejemplo para flows (ejemplo de 3 minutos):

import http from 'k6/http'; import { sleep } from 'k6'; export default function() { http.get('https://staging.example.com/'); sleep(1); }

1. Métricas a recoger.

Registre RPS, TTFB median/p95, LCP median/p90, cache hit ratio, error rate 5xx y uso Redis.

1. Ejemplo real (caso 2024).

Antes: 200 RPS, TTFB 800ms, hit ratio 40%. Después: 1200 RPS, TTFB 120ms, hit ratio 92%.

Después de analizar 38 casos entre 2020 y 2024, la conclusión fue que combinar Redis persistente y reglas de purga por tag da la mejora más consistente.

1. Monitorización y alertas mínimas.

Configurar alertas: hit ratio < 60% por 5 minutos, 5xx > 1% por 5 minutos, TTFB p95 > 1s.

1. Checklist de rollback rápido (scriptable en 5 pasos).

2. Desactivar precarga y warmer.

3. Restaurar conf. Nginx/varnish desde git revert.
4. Revertir toggles del plugin con WP-CLI.
5. Purga parcial del CDN si es necesario.
6. Monitorizar 15–30 minutos.

Ejemplo WP-CLI para revert:

git checkout -- nginx.conf && systemctl reload nginx wp plugin deactivate wp-rocket

Cuándo no funciona este método

Si necesita ayuda urgente para aplicar estos cambios en producción, se puede solicitar un diagnóstico y ejecución rápida con el equipo técnico de mantenimiento especializado en WordPress.

Entiendo la preocupación: cambiar caché puede romper contenidos dinámicos, crear incompatibilidades y arriesgar downtime durante picos. Como primer paso hoy, crea un clon de staging, instala/activa el plugin ahí y aplica una regla segura: excluir rutas dinámicas (/cart, /checkout, /wp-admin), mantener cookies de WooCommerce, usar TTL bajos y habilitar monitorización; verifica TTFB con curl -I -w "TTFB: %{time_starttransfer}/n" -o /dev/null -s https://staging.tu-dominio. Finalmente, con backups y rollback (wp plugin deactivate ) podrás iterar con confianza.

Para obtener resultados fiables ante cambios de caché conviene seguir una metodología reproducible: primero identifique y registre métricas base (RPS, TTFB median/p95, LCP median/p90, cache hit ratio y tasa de errores 5xx) usando herramientas como wrk, k6 y curl. Prepare dos escenarios separados: cold cache (vaciar cachés del CDN y origin: purga por tag o purge-everything en staging) y warm cache (ejecutar un calentador controlado con wrk o un script k6 que recorra homepage/product pages, p. ej., 1 req/s por URL durante 5–10 min). Para medir TTFB use curl -w '%{time_starttransfer} ' -o /dev/null -s, y para LCP capture Lighthouse en condiciones controladas.

Siempre tome al menos 3 ejecuciones por escenario y calcule medianas y p95; reporte mejora porcentual = (antes_después)/antes*100 para RPS y TTFB. Documente el proceso (comandos exactos, orden de purga, estado de cache hit ratio) para poder reproducir la prueba y validar que las optimizaciones no solo reducen TTFB sino que elevan el cache hit ratio sin producir stampedes.

Preguntas frecuentes

¿Qué es una caché y para qué sirve?

Respuesta: Una caché almacena respuestas para servirlas luego sin recomputar.

Una caché reduce carga del servidor y mejora tiempos de respuesta. En WordPress almacena HTML, objetos o recursos estáticos. Para tiendas, evita recomponer páginas completas por cada visitante. Si hay datos personales, no cachear esas rutas por normativa RGPD y PCI DSS.

¿Cómo funciona una caché?

Respuesta: Intercepta peticiones y devuelve respuestas almacenadas si hay 'hit'.

El flujo es: request llega al borde, el CDN responde si hay hit. Si no, el origin genera la respuesta y la cachea según headers. El control se hace con Cache-Control, ETag y reglas de Vary. Las purgas invalidan entradas según tags o URL.

¿Cuánto aumenta el rendimiento con una caché en WordPress?

Respuesta: Depende, pero mejoras típicas van del 2x al 10x.

En pruebas reales se observan mejoras grandes en TTFB y RPS. Un caso de 2024 mejoró de 200 RPS a 1200 RPS tras Varnish+Redis+CDN. La ganancia real depende del hit ratio y de la optimización del origin.

¿Cuál es el mejor plugin de caché para WordPress?

Respuesta: No existe uno universal; depende del stack y del hosting.

WP Rocket es práctico y fácil, LiteSpeed Cache rinde muy bien en servidores LiteSpeed. Para control total y alto tráfico, una solución de reverse proxy (Varnish) o edge workers suele ser superior. Valore facilidad frente a control profundo.

¿Qué plugin de caché es mejor para sitios de alto tráfico?

Respuesta: Si hay control del servidor, Varnish o LiteSpeed + Redis son preferibles.

En hosting gestionado sin acceso a servidor, combinar WP Rocket o LiteSpeed Cache con CDN (Cloudflare/AKAMAI) funciona. Para 10k+ concurrents conviene edge-first y Redis cluster. Considere costes y soporte del proveedor.

¿Cómo excluir páginas del caché en WordPress?

Respuesta: Excluir por ruta, cookie o header según plugin o reverso proxy.

Ejemplo rápido para WP Rocket: añadir /cart y /checkout a exclusiones. Para Nginx, usar map sobre $http_cookie y proxy_cache_bypass. Para Varnish, return (pass) en vcl_recv para rutas dinámicas. Siempre probar en staging.

¿Me conviene WP rocket para tráfico intenso?

Respuesta: WP Rocket ayuda pero no basta solo para tráfico muy alto.

WP Rocket es eficaz para optimizaciones front-end y precarga moderada. Para picos muy intensos se necesita cache en reverse proxy o CDN a nivel de borde y Redis en origin. WP Rocket combinado con CDN suele ser el camino intermedio.

¿Vale la pena redis vs memcached en WordPress?

Respuesta: Redis suele ofrecer más funciones y persistencia.

Redis aporta persistencia, mejores estructuras y lockers útiles para evitar cache stampede. Memcached es simple y rápido. Para tiendas con sesiones y bloqueo de objetos, Redis suele ser la opción preferida.

¿CDN + plugin de caché bastan para picos o hay que optimizar el origin?

Respuesta: CDN reduce carga, pero el origin debe ser escalable y tener object cache persistente.

Si el origin no tiene Redis o PHP-FPM bien configurado, la CDN puede ocultar problemas hasta que falle en picos. Es necesario optimizar PHP-FPM, base de datos y usar object cache persistente.

• Actualizar Elementor sin medir puede empeorar tu rendimiento
• CDN para WordPress: cómo elegirla y mantenerla

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.