Errori cache (Cloudflare/Varnish) vs origin

Cache HTTP (Cloudflare, Varnish, nginx fastcgi_cache) e application cache (Redis, Memcached) possono mascherare errori origin o esserne la causa. Vediamo come WP Error Monitor aiuta a distinguere e fixare.

Cache che maschera errori

Caso tipico: aggiornamento plugin rompe homepage, ma utenti loggati vedono pagina ok perchè edge cache restituisce versione precedente. Solo utenti nuovi (cache miss) vedono l’errore. WP Error Monitor cattura tutti gli errori origin: anche se molti utenti non li vedono, il problema esiste e va fixato prima che la cache scada.

Cache che genera errori

Caso opposto: Varnish con TTL troppo lungo serve pagina obsoleta che richiama URL ora 404. Oppure object cache (Redis) corrotto restituisce null su get e WP tratta come 'opzione non esistentè. Per identificare: WPEM_TRACK_CACHE=true logga ogni operazione cache miss/hit/error. Cache_error spike suggerisce Redis down o saturo.

Strategia anti-mascheramento

1) Configura webhook origin: ogni 5xx dall’origin triggera notifica indipendente da cache; 2) Synthetic monitoring con cache bypass: ogni 5min un'agente fa request con header 'Pragma: no-cachè per testare origin; 3) Heatmap cache hit ratio: trend in calo improvviso indica problema cache.

Cache invalidation patterns

Cache invalidation è uno dei due hard problems in CS. Patterns: 1) TTL-based (cache scade dopo X), semplice ma stale data, 2) Event-based (cache invalidata quando dato cambia), accurato ma complesso, 3) Tag-based (cache marca con tag, invalidi per tag), best of both. Per WordPress: Cloudflare Cache Tag con plugin che aggiunge tag su response (es. post-123, category-news), purge selettiva su update post.

Object cache fallback strategy

Se Redis va down, applicazione non deve crashare. Configurazione robust: object-cache.php drop-in con try/catch su connection, fallback in-memory cache per richiesta singola. WP Error Monitor traccia Redis status: se eventi 'redis_connection_failed’ aumentano, scatta alert. Diagnosi rapida: redis-cli ping da SSH per check status.

Multi-layer cache strategy

Setup ottimale ha multipli layer di cache: 1) Browser cache (max-age su asset statici) - elimina request, 2) CDN edge cache (Cloudflare) - serve da edge geografico, 3) Reverse proxy cache (Varnish o nginx fastcgi_cache) - serve da server senza colpire PHP, 4) Application cache (object cache Redis) - serve query DB cached, 5) PHP opcode cache (OPcache) - evita re-parse PHP. Ogni layer aumenta TTFB di magnitudo. Senza layer DB cache, sito serve da edge in 50ms, con tutti layer 5ms. WP Error Monitor monitora hit ratio di ogni layer per ottimizzazione continua.

Cache warming dopo deploy

Dopo un deploy, le cache sono vuote: prossimi utenti pagano latenza piena. Cache warming pre-emptivo: lancia script che colpisce le top 100 URL più visitate, popolando cache prima che utenti reali arrivino. Strumenti: wget mirror sitemap, custom script con curl, plugin tipo 'WP Rocket Cache Preload’. Setup script in deploy pipeline: post-deploy, lancia cache warm in background. Tempo tipico: 2-10 minuti per sito medio. WP Error Monitor traccia 'origin requests after deploy' come metric: spike significa cache non warmed, consider tuning script.

Cache hit ratio targets

Cache hit ratio targets per tipologia di sito: blog statico >95% (la maggior parte delle pagine cachable), ecommerce con catalogo >85% (alcune pagine dinamiche per stock), portale dinamico (forum, social) >70%. Misura con WP Error Monitor cache analytics. Se sei sotto target, indaga: TTL troppo bassi? Page Rules sbagliate? Cookie che bypassano cache inutilmente? Ottimizzazione cache hit ratio del 10% riduce origin load del 50%+ tipicamente: investment time/effort altissimo ROI. Strategia: review mensile metrics, A/B test cambi config in staging, applica vincenti in prod.

Procedura passo-passo

1. Setta WPEM_TRACK_CACHE=true in wp-config.php.
2. Configura monitor synthetic verso /health-check?nocache=1 ogni 5 minuti.
3. Verifica metric cache_hit_ratio in WP Error Monitor dashboard.
4. Imposta alert se cache_hit_ratio scende sotto 80%.
5. Cross-check errori origin con cache status header.
6. Per Redis down, aggiungi fallback graceful in object cache.
7. Per Varnish stale, riduci TTL su path dinamiche.
8. Documenta cache invalidation strategy per ogni deploy.
9. Setup Cache Tag per invalidation selettiva.
10. Configura object-cache fallback graceful.

Errori comuni e come risolverli

• Redis down genera 500 ovunque: Configura object cache con fail open: se Redis irraggiungibile, fallback a no-cache.
• Varnish serve pagine vecchie: TTL troppo alto: riduci e attiva BAN dopo deploy.
• Cloudflare cache HTML troppo aggressiva: Verifica Page Rule 'Cache Level: Cache Everything' non sia attivo su path dinamiche.
• Cache invalidation tardiva: Webhook update non triggera purge: verifica hook on_post_update.
• Redis fallback non attivato: Drop-in object-cache.php non installato: verifica versione plugin.

Domande frequenti

D: Posso vedere se errore proviene da cache?
R: Sì, WP Error Monitor mostra cache hit/miss in ogni evento.

D: Object cache utile in produzione?
R: Sì, riduce DB query 60-80%. Ma serve fallback robusto.

D: Cloudflare cache HTML rotto da plugin?
R: Sì, verifica plugin che alterano response (es. lazy load, optimizers).

D: Quanto durano TTL ottimali?
R: Pagine statiche 24h, listing 1h, dynamic content 5-15min.

D: Redis cluster necessario?
R: Per traffico alto sì, single Redis bottleneck a circa 100k ops/sec.

Hai bisogno di aiuto?

Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.