¿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
- Detecta y mitiga el origen: reduce RPS al origin y sirve activos desde CDN.
- Aplica bypass inmediato para checkout, carrito y REST API.
- Habilita object cache persistente (Redis) con pool adecuado.
- Activa cache de página conservadora y precarga limitada.
- Orquesta purgas por tag y evita purgas totales.
- Mide RPS, TTFB y cache hit ratio antes y después.
Apunte: si hay dudas, primero aplicar el bypass para /checkout y servir una página estática breve.
- 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.
- 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/"]'
- 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"]}'
- 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.
⚠️ No cambie TTL global ni habilite precarga masiva en producción sin pruebas: ese es el error típico que provoca downtime.
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
- 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.
| Concurrentes |
TTL página |
Redis pool |
Precarga |
Notas |
| ~50 |
60s |
Redis 128MB |
Off o 1 req/s |
Ideal para tiendas pequeñas |
| ~200 |
120–300s |
Redis 512MB |
Rate-limit 1–2 req/s |
Varnish o CDN recomendado |
| ~1000 |
300–600s |
Redis 1–2GB |
5 req concurrents |
Usar grace mode en Varnish |
| 10k+ |
600–3600s |
Redis cluster 4GB+ |
Throttled warming |
Edge-first y autoscaling |
Dato práctico: para WooCommerce, mantener el TTL en endpoints sensibles entre 30 y 120 segundos suele reducir errores.
1. Request usuario
2. Edge CDN (cache)
3. Origin (PHP-FPM, Redis)
El edge responde si hay cache hit. Si hay miss, el edge solicita al origin. El origin usa Redis para objetos y devuelve contenido con headers Cache-Control. La purga se orquesta por tag.
⚠️ No aplique TTL largo en páginas con sesiones; el error típico que rompe carritos es cachear endpoints dinámicos.
Implementa snippets y reglas para nginx, varnish, LiteSpeed y maneja WooCommerce y purgas
- 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.
⚠️ Evite purgas globales tras cada producto actualizado; purgue por tag y limite la frecuencia para no saturar 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
- 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.
- 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);
}
- Métricas a recoger.
Registre RPS, TTFB median/p95, LCP median/p90, cache hit ratio, error rate 5xx y uso Redis.
- 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.
- Monitorización y alertas mínimas.
Configurar alertas: hit ratio < 60% por 5 minutos, 5xx > 1% por 5 minutos, TTFB p95 > 1s.
-
Checklist de rollback rápido (scriptable en 5 pasos).
-
Desactivar precarga y warmer.
- Restaurar conf. Nginx/varnish desde git revert.
- Revertir toggles del plugin con WP-CLI.
- Purga parcial del CDN si es necesario.
- Monitorizar 15–30 minutos.
Ejemplo WP-CLI para revert:
git checkout -- nginx.conf && systemctl reload nginx
wp plugin deactivate wp-rocket
⚠️ Si el rollback falla, apague la precarga y sirva una página estática temporal mientras se investiga.
Cuándo no funciona este método
⚠️ Cuándo esto NO es la mejor opción
No aplica si el sitio tiene tráfico muy bajo y la complejidad no compensa. Tampoco sirve cuando se usa headless/API-first donde los plugins de caché de WordPress no intervienen. Tampoco si el hosting gestiona íntegramente caching y no permite ajustes: en ese caso coordinar con soporte del host es la vía correcta.
Cloudflare, AWS y proveedores de CDN recomiendan purga por tag y evitar purgas totales frecuentes.
⚠️ Si su hosting no permite cambiar Redis o Varnish, este playbook sólo sirve parcialmente.
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.
