La maggior parte dei consigli sulle prestazioni si concentra su ciò che accade quando il traffico aumenta, come la pianificazione della capacità, il pre-caricamento della cache e lo scaling. Per la maggior parte dei siti WordPress, la storia comune va nella direzione opposta: un periodo di calo del traffico quando l’attività torna alla normalità dopo la fine di una campagna, il superamento di un picco stagionale o il lancio di un prodotto.
Quando il traffico diminuisce, potresti pensare che la situazione del tuo hosting migliori perché le risorse sono meno sollecitate. In pratica, può accadere il contrario. Capire il perché rivela molte cose sul funzionamento della maggior parte degli ambienti di hosting.
Perché le prestazioni dell’hosting non dovrebbero dipendere dagli schemi del traffico
Per un utente finale, l’hosting condiviso offre spesso un rapporto qualità-prezzo migliore, ma comporta un rischio maggiore di problemi di sicurezza e prestazioni incoerenti. La tentazione di un provider di hosting condiviso è quella di utilizzare lo spazio del server per ottenere il massimo guadagno possibile.
Un approccio comune è quello dell'”overselling”. Questo avviene quando un provider assegna ai clienti più risorse di quante ne esistano fisicamente sul server. Funziona in modo simile al funzionamento delle banche: generano interessi prestando il denaro depositato da altri clienti. Il sistema funziona a patto che tutti non cerchino di ritirare il proprio denaro in una volta sola.
Gli ambienti di hosting condiviso mettono centinaia o migliaia di siti sullo stesso server fisico, quindi quando la domanda aumenta, spesso non ci sono abbastanza risorse da distribuire.
È qui che entra in gioco l'”allocazione dinamica delle risorse”, che dà priorità ai siti attivi rispetto a quelli inattivi. Un traffico maggiore per il tuo sito significa che riceve più risorse rispetto ai siti con meno visitatori. Il modello dà effettivamente la priorità ai siti ad alto traffico e assegna meno risorse a quelli a basso traffico.
Tuttavia, questo ha niente a che fare con i livelli dei piani. Il server decide semplicemente in tempo reale dove indirizzare le risorse disponibili. Le prestazioni diventano dipendenti dal traffico piuttosto che dall’infrastruttura.
Il cliente di Kinsta Cosmick Media ha riscontrato sintomi simili. L’agenzia ha avuto problemi di downtime intermittente e di velocità delle pagine con i precedenti fornitori di hosting. Questi problemi sono comparsi solo quando il team ha aumentato la propria base di clienti, quando i limiti delle risorse dell’infrastruttura condivisa sono diventati più difficili da ignorare.
Il throttling nascosto che si verifica durante le normali operazioni
Il throttling nell’hosting condiviso assume diverse forme e aiuta a spiegare come vengono razionate le risorse tra i siti:
- I limiti della CPU limitano la potenza di elaborazione che un sito può utilizzare in qualsiasi momento.
- L’allocazione della RAM limita la quantità di memoria che un sito può utilizzare.
- I limiti di I/O controllano la velocità con cui un sito legge e scrive su disco.
Quando il traffico è elevato, il tuo sito tende a consumare oltre i limiti di risorse disponibili. Quando l’attività cala, le risorse condivise vengono rapidamente utilizzate da altri siti sul server. La conseguenza visibile è il degrado del front-end, ma la conseguenza meno visibile (e spesso più dannosa) è ciò che accade alle operazioni in background.
WP-Cron avvia attività in background come l’ottimizzazione del database, il controllo degli aggiornamenti dei plugin, la pubblicazione programmata e la pulizia transitoria di WordPress. Queste attività vengono eseguite in background ma competono per le stesse risorse limitate. In un server sovraccarico, diventano inaffidabili: vengono eseguite in ritardo, falliscono silenziosamente o non vengono eseguite affatto.
Il degrado delle prestazioni si accumula nel tempo
Il costo reale del throttling è cumulativo: ogni attività mancata si somma alla successiva:
- Le finestre di ottimizzazione del database non eseguite si aggiungono al volume che rallenta le query ad ogni richiesta successiva.
- Le attività in background fallite lasciano dei vuoti nel ciclo di manutenzione che non si ripristinano automaticamente quando il traffico si riprende.
- Le operazioni di amministrazione lente ritardano la manutenzione di routine (aggiornamenti dei plugin, modifiche dei contenuti e attività di configurazione) che mantengono un sito WordPress stabile e sicuro.
Le revisioni dei post, i transient e le opzioni caricate automaticamente sono tutti archiviati nel database di WordPress. Senza un’ottimizzazione regolare, le tabelle si ingrandiscono e le query rallentano. Su un server con risorse costanti, la pulizia viene eseguita in modo regolare. Tuttavia, su un server condiviso con limitazioni, viene eseguita solo quando sono disponibili risorse sufficienti. Durante i periodi di traffico limitato, queste attività di pulizia possono essere eseguite molto meno spesso.
Il risultato è un ciclo di feedback in cui il calo delle prestazioni rende più difficile la manutenzione, producendo un sito meno sano. Il peggioramento delle prestazioni può accelerare la diminuzione del traffico organico attraverso il rallentamento del caricamento delle pagine e l’indebolimento dei punteggi Core Web Vitals.
Come l’architettura a container di Kinsta elimina le prestazioni dipendenti dal traffico
Ogni sito WordPress su Kinsta viene eseguito all’interno di un container Linux isolato e non condivide la sua allocazione con altri siti della piattaforma. Inoltre, non ci sono code di priorità per determinare quali siti ricevono più risorse.
Un sito che esce dal picco di una campagna continua a funzionare con le stesse risorse allocate durante il picco. L’infrastruttura non riassegna le risorse quando il numero di visitatori diminuisce.
Questo è importante perché, anche se i livelli Kinsta più alti ospitano un maggior numero di visite mensili, tutti funzionano con lo stesso modello di container isolato e le stesse garanzie di risorse. I piani invece determinano i limiti di capacità, come la larghezza di banda/visite mensili e le risorse disponibili. Questo influisce anche sul modo in cui Kinsta utilizza i thread PHP per migliorare le prestazioni complessive del tuo sito.
Per WP-Cron in particolare, ciò significa che le attività programmate hanno a disposizione risorse costanti per essere eseguite in modo affidabile. Il debito tecnico che si accumula negli ambienti con strozzatura (come le mancate pulizie, le attività in background non riuscite, le tabelle gonfie e altro ancora) non si accumula in questo caso perché le risorse necessarie per evitarlo rimangono sempre disponibili.
La cache multistrato funziona in modo identico sia in caso di traffico elevato che di traffico ridotto
Lo stack di caching di Kinsta opera su quattro livelli, ciascuno indipendente dal volume di traffico. Insieme riducono il lavoro che il tuo container deve svolgere e mantengono le risorse libere per le operazioni di amministrazione e le attività in background:
- La cache edge serve il sito direttamente dalla rete globale di Cloudflare prima che la richiesta raggiunga il tuo server di origine. Le percentuali di accesso alla cache rimangono elevate sia durante i picchi di traffico che nei periodi più tranquilli. Le pagine in cache non scadono semplicemente perché il traffico è diminuito, quindi un sito post-campagna continua a essere servito dall’edge proprio come nel periodo di picco.
- La cache a livello di server gestisce le richieste dinamiche che bypassano l’edge, riducendo il carico del database all’origine. Per i siti in cui gli utenti loggati o i contenuti dinamici impediscono il caching dell’intera pagina sull’edge, questo livello mantiene i tempi di risposta prevedibili.
- Il CDN di Kinsta serve risorse statiche (immagini, CSS, JavaScript e font) da postazioni edge distribuite. La velocità di consegna è la stessa, indipendentemente dal volume delle richieste, il che li esclude completamente dal tuo container.
Inoltre, non trascurare la cache degli oggetti Redis a bassa latenza di Kinsta. Questa funzione memorizza i risultati delle query del database in modo che WordPress non ripeta le stesse query ad ogni caricamento di pagina. Per i siti ricchi di contenuti, i negozi WooCommerce e le piattaforme di iscrizione in cui le stesse query vengono eseguite ripetutamente, ciò si traduce in risposte più veloci e un carico del database più leggero.
Perché l’hosting premium ha senso per un traffico stabile
L’ipotesi che un traffico inferiore giustifichi il calo dell’hosting considera l’infrastruttura come uno strumento di scalabilità che si espande per i picchi e si contrae nei periodi di calma. Tuttavia, non tiene conto di ciò che l’hosting di un sito WordPress fa tra una campagna e l’altra.
Sebbene molti piani di hosting basino i prezzi sul volume di traffico, quest’ultimo e la qualità dell’infrastruttura sono due cose diverse. Un sito che riceve meno visite durante un periodo successivo alla campagna ha comunque bisogno di un’infrastruttura affidabile per mantenere la manutenzione in funzione, gli strumenti di amministrazione reattivi e le attività in background puntuali.
La complessità dell’applicazione WordPress non diminuisce con il traffico
Attività come le operazioni sui plugin, la manutenzione del database, le scansioni di sicurezza e la pubblicazione programmata non si fermano durante un periodo di calma. Considera le esigenze di un’agenzia che gestisce il sito di un cliente tra una campagna e l’altra:
- Ambienti di staging che rispecchino la produzione in modo abbastanza fedele da poter individuare i problemi prima della distribuzione.
- Accesso SSH e WP-CLI per le operazioni sul database, la gestione dei plugin e gli script personalizzati.
- Tempi di risposta dell’admin che reggano durante la modifica dei contenuti e la gestione del sito.
- Backup programmati e scansioni di sicurezza puntuali.
Se gestisci flussi di lavoro di sviluppo, il passaggio delle modifiche da staging a live, l’esecuzione di aggiornamenti di plugin e la migrazione di database richiedono prestazioni di hosting affidabili. Lavorare sul sito di un cliente durante un mese tranquillo richiede comunque le stesse prestazioni dei processi di distribuzione e degli ambienti di staging.
Per un’agenzia che gestisce più siti di clienti in fasi diverse del ciclo di traffico, un’infrastruttura condivisa può rendere più difficile la gestione dei siti più tranquilli perché il server indirizza le risorse verso quelli più trafficati. Su un’infrastruttura container isolata, ogni sito si comporta allo stesso modo indipendentemente da ciò che fanno gli altri.
Prestazioni costanti consentono una pianificazione sicura a lungo termine
In poche parole, un’infrastruttura prevedibile cambia il modo di lavorare. Quando sai che le attività di manutenzione si completano in modo affidabile, che WP-Cron si attiva nei tempi previsti e che le operazioni di amministrazione rispondono in modo coerente, la pianificazione diventa più semplice. I vantaggi pratici sono molteplici:
- Riduzione del carico di lavoro dell’assistenza, perché i problemi di prestazioni radicati nella contesa delle risorse non generano i ticket di assistenza che devono essere esaminati.
- Cicli di pianificazione più affidabili, perché non si tiene conto del rischio di un ambiente di hosting che si comporta in modo diverso nei mesi di calma.
- Meno congetture sull’infrastruttura quando scegli l’hosting in base ai modelli di traffico. L’aggiornamento per le campagne e il successivo downgrade comportano rischi e spese di gestione a ogni transizione.
Vale la pena soffermarsi su quest’ultimo punto. Un hosting che richiede una gestione attiva in base all’andamento del traffico lavora contro la tua pianificazione invece di affiancarla. Un sito dovrebbe essere in grado di entrare in un periodo di tranquillità senza modificare le modalità di hosting e di uscirne nello stesso stato in cui è nato.
L’infrastruttura di hosting deve supportare la crescita del business, non le curve del traffico
Lo schema che danneggia i siti WordPress durante i cali di traffico non è complicato. Un’infrastruttura sovraccarica riduce la priorità dei siti meno trafficati, le attività in background subiscono ritardi e il debito tecnico cumulativo cresce nel tempo.
Un modello di hosting che considera i periodi di minor traffico come un motivo per ridurre le risorse disponibili, alla fine va contro i siti che dovrebbe supportare.
Se stai valutando la tua attuale configurazione di hosting, fai delle domande. Ad esempio, le attività in background possono essere eseguite in modo affidabile durante i periodi di silenzio? Gli strumenti di amministrazione sono reattivi anche quando il traffico è ridotto? Più in generale, chiedi se il modello di risorse del tuo fornitore di hosting considera una pausa post-campagna alla stessa stregua di un picco di traffico o se il livello del tuo piano determina, dietro le quinte, la quantità di server che puoi utilizzare.
L’hosting per WordPress gestito di Kinsta si basa su container isolati, uno stack di caching multilivello e risorse dedicate che non fluttuano in base ai livelli di traffico. Ciò significa che il tuo sito ha le stesse prestazioni alla fine di una campagna come al suo apice.
Hai altre domande? Contatta il nostro team in qualsiasi momento.
