{"id":19562,"date":"2026-10-05T20:31:30","date_gmt":"2026-10-05T18:31:30","guid":{"rendered":"https:\/\/xlogic.org\/blog\/?p=19562"},"modified":"2026-10-05T20:31:30","modified_gmt":"2026-10-05T18:31:30","slug":"sito-lento-solo-a-volte-cause","status":"publish","type":"post","link":"https:\/\/xlogic.org\/blog\/sito-lento-solo-a-volte-cause.html\/","title":{"rendered":"Sito lento solo a volte? 9 cause che rendono difficile trovare il problema"},"content":{"rendered":"<p>Un <strong>sito lento solo a volte<\/strong> \u00e8 spesso molto pi\u00f9 difficile da diagnosticare rispetto a un sito costantemente lento.<\/p>\n<p>Quando il problema \u00e8 permanente basta aprire una pagina, misurare i tempi di risposta e controllare PHP, database, cache e risorse. Quando invece il rallentamento compare soltanto per pochi secondi o alcuni minuti, pu\u00f2 essere gi\u00e0 scomparso nel momento in cui inizi l&#8217;analisi.<\/p>\n<p>Il sito pu\u00f2 essere veloce per ore, rallentare improvvisamente e poi tornare normale senza che venga effettuata alcuna modifica.<\/p>\n<p>Le cause possono essere molto diverse: cache scaduta, picchi di traffico, bot, cron WordPress, backup, query database, processi PHP occupati, API esterne lente oppure problemi temporanei di rete.<\/p>\n<p>Vediamo quindi le <strong>9 cause principali di un sito lento solo a volte<\/strong> e soprattutto quali dati raccogliere per riuscire a individuare un problema intermittente.<\/p>\n<h2>Sito lento solo a volte: perch\u00e9 \u00e8 cos\u00ec difficile trovare il problema?<\/h2>\n<p>Il motivo principale \u00e8 semplice:<\/p>\n<p><strong>quando inizi il controllo, il rallentamento potrebbe essere gi\u00e0 terminato.<\/strong><\/p>\n<p>Immaginiamo questa situazione:<\/p>\n<pre><code>14:30 \u2192 sito veloce\r\n14:32 \u2192 sito molto lento\r\n14:34 \u2192 sito nuovamente veloce\r\n14:40 \u2192 inizia il controllo tecnico\r\n14:40 \u2192 tutto appare normale<\/code><\/pre>\n<p>Se si osserva il server soltanto alle 14:40, CPU, RAM e database potrebbero sembrare perfettamente normali.<\/p>\n<p>Ma il dato realmente utile \u00e8 capire cosa stesse accadendo alle 14:32.<\/p>\n<p>Per diagnosticare correttamente un <strong>sito lento solo a volte<\/strong> servono quindi log, monitoraggio e soprattutto un orario preciso del problema.<\/p>\n<h2>1. Cache HIT e cache MISS possono cambiare completamente la velocit\u00e0<\/h2>\n<p>La cache \u00e8 una delle prime cose da verificare quando un <strong>sito lento solo a volte<\/strong> alterna risposte rapidissime a richieste molto pi\u00f9 lente.<\/p>\n<p>Quando una pagina viene servita direttamente dalla cache, il server pu\u00f2 evitare di eseguire nuovamente gran parte della logica applicativa.<\/p>\n<p>In molti casi non \u00e8 necessario interrogare nuovamente:<\/p>\n<ul>\n<li>WordPress;<\/li>\n<li>plugin;<\/li>\n<li>tema;<\/li>\n<li>PHP;<\/li>\n<li>database.<\/li>\n<\/ul>\n<p>La differenza pu\u00f2 essere notevole.<\/p>\n<pre><code>Cache HIT  \u2192 90 ms\r\nCache MISS \u2192 950 ms<\/code><\/pre>\n<p>Per il visitatore la stessa pagina pu\u00f2 quindi apparire velocissima una volta e molto pi\u00f9 lenta quella successiva.<\/p>\n<h2>Quando una pagina va in cache MISS?<\/h2>\n<p>Le cause dipendono dal sistema utilizzato, ma possono comprendere:<\/p>\n<ul>\n<li>cache appena svuotata;<\/li>\n<li>TTL scaduto;<\/li>\n<li>pagina appena modificata;<\/li>\n<li>aggiornamento plugin;<\/li>\n<li>aggiornamento tema;<\/li>\n<li>variazioni WooCommerce;<\/li>\n<li>utente autenticato;<\/li>\n<li>cookie che impediscono la cache;<\/li>\n<li>URL dinamico.<\/li>\n<\/ul>\n<p>Dopo un purge, le prime richieste devono spesso ricostruire il contenuto prima che possa essere nuovamente memorizzato.<\/p>\n<h2>WooCommerce: non tutte le pagine possono essere trattate allo stesso modo<\/h2>\n<p>Su un eCommerce \u00e8 normale avere comportamenti differenti tra una pagina pubblica e una pagina dinamica.<\/p>\n<p>Per esempio:<\/p>\n<pre><code>Homepage \u2192 cache \u2192 molto veloce\r\nCategoria \u2192 cache \u2192 veloce\r\nProdotto \u2192 cache \u2192 veloce\r\nCarrello \u2192 dinamico\r\nCheckout \u2192 dinamico\r\nArea cliente \u2192 dinamica<\/code><\/pre>\n<p>Testare soltanto la homepage pu\u00f2 quindi nascondere un problema che riguarda carrello, checkout o utenti autenticati.<\/p>\n<h2>2. Picchi di traffico che durano pochi minuti<\/h2>\n<p>Un sito pu\u00f2 funzionare perfettamente durante il normale traffico e rallentare soltanto durante un improvviso aumento delle richieste.<\/p>\n<p>Il picco pu\u00f2 essere provocato da:<\/p>\n<ul>\n<li>newsletter;<\/li>\n<li>campagna pubblicitaria;<\/li>\n<li>post diventato virale;<\/li>\n<li>promozione;<\/li>\n<li>lancio di un prodotto;<\/li>\n<li>crawler;<\/li>\n<li>bot;<\/li>\n<li>scanner automatici.<\/li>\n<\/ul>\n<p>Quando il traffico diminuisce, anche i tempi possono tornare rapidamente normali.<\/p>\n<h2>Non guardare soltanto il numero dei visitatori<\/h2>\n<p>Il numero di utenti non racconta necessariamente tutto.<\/p>\n<p>Migliaia di richieste servite dalla cache possono pesare meno di poche centinaia di richieste dinamiche particolarmente costose.<\/p>\n<p>Bisogna quindi distinguere tra:<\/p>\n<ul>\n<li>visitatori;<\/li>\n<li>richieste HTTP;<\/li>\n<li>URL visitate;<\/li>\n<li>pagine cacheabili;<\/li>\n<li>richieste verso PHP;<\/li>\n<li>query database generate.<\/li>\n<\/ul>\n<h2>3. Bot e crawler possono arrivare a ondate<\/h2>\n<p>Un visitatore reale apre normalmente poche pagine.<\/p>\n<p>Un crawler pu\u00f2 invece effettuare centinaia o migliaia di richieste in sequenza.<\/p>\n<p>Tra gli accessi automatici possono esserci:<\/p>\n<ul>\n<li>motori di ricerca;<\/li>\n<li>crawler AI;<\/li>\n<li>scanner di sicurezza;<\/li>\n<li>tool SEO;<\/li>\n<li>scraper;<\/li>\n<li>bot malevoli;<\/li>\n<li>monitor automatici.<\/li>\n<\/ul>\n<p>Anche bot legittimi possono generare carico se effettuano molte richieste in poco tempo.<\/p>\n<h2>Come capire se un bot coincide con il rallentamento?<\/h2>\n<p>Il punto fondamentale \u00e8 confrontare il momento esatto del problema con l&#8217;access log.<\/p>\n<p>Se il rallentamento si \u00e8 verificato alle 03:15, analizza per esempio:<\/p>\n<pre><code>03:10 \u2192 03:20<\/code><\/pre>\n<p>Cerca:<\/p>\n<ul>\n<li>IP con moltissime richieste;<\/li>\n<li>User-Agent ripetitivi;<\/li>\n<li>URL richieste continuamente;<\/li>\n<li>accessi a pagine dinamiche;<\/li>\n<li>scansioni di URL inesistenti;<\/li>\n<li>picchi improvvisi di richieste.<\/li>\n<\/ul>\n<p>Non conviene per\u00f2 bloccare automaticamente ogni crawler: bisogna prima capire chi \u00e8, cosa sta richiedendo e quale impatto sta realmente provocando.<\/p>\n<h2>4. WP-Cron e attivit\u00e0 pianificate<\/h2>\n<p>WordPress dispone di un sistema di pianificazione chiamato <strong>WP-Cron<\/strong>.<\/p>\n<p>Plugin e tema possono utilizzarlo per eseguire attivit\u00e0 come:<\/p>\n<ul>\n<li>invio email;<\/li>\n<li>pulizia cache;<\/li>\n<li>sincronizzazioni;<\/li>\n<li>aggiornamenti feed;<\/li>\n<li>generazione report;<\/li>\n<li>pulizia database;<\/li>\n<li>elaborazione code;<\/li>\n<li>controlli automatici.<\/li>\n<\/ul>\n<p>Se un task particolarmente pesante parte in determinati momenti, il sito pu\u00f2 rallentare soltanto durante la sua esecuzione.<\/p>\n<h2>Come controllare gli eventi WP-Cron<\/h2>\n<p>Con WP-CLI puoi visualizzare gli eventi programmati:<\/p>\n<pre><code>wp cron event list<\/code><\/pre>\n<p>Il comando permette di individuare eventi molto frequenti o attivit\u00e0 che non sembrano coerenti con il normale funzionamento del sito.<\/p>\n<p>Per approfondire puoi consultare anche la <a href=\"https:\/\/developer.wordpress.org\/plugins\/cron\/\" target=\"_blank\" rel=\"noopener\"><strong>documentazione ufficiale WordPress sul sistema Cron<\/strong><\/a>.<\/p>\n<h2>WP-Cron non \u00e8 automaticamente un problema<\/h2>\n<p>Le attivit\u00e0 pianificate fanno parte del normale funzionamento di WordPress.<\/p>\n<p>Il problema pu\u00f2 emergere quando:<\/p>\n<ul>\n<li>un task \u00e8 troppo pesante;<\/li>\n<li>un plugin registra migliaia di eventi;<\/li>\n<li>un processo rimane bloccato;<\/li>\n<li>molti job partono contemporaneamente;<\/li>\n<li>un evento viene eseguito troppo frequentemente.<\/li>\n<\/ul>\n<h2>5. Backup che utilizzano temporaneamente molte risorse<\/h2>\n<p>I backup sono indispensabili, ma la loro creazione comporta lavoro per il sistema.<\/p>\n<p>Durante un backup possono essere eseguite operazioni come:<\/p>\n<ul>\n<li>lettura di migliaia di file;<\/li>\n<li>compressione;<\/li>\n<li>dump del database;<\/li>\n<li>scrittura su disco;<\/li>\n<li>trasferimento remoto;<\/li>\n<li>calcolo di checksum.<\/li>\n<\/ul>\n<p>Se un <strong>sito lento solo a volte<\/strong> peggiora sempre nella stessa fascia oraria, una delle prime cose da verificare \u00e8 se in quel momento sia attivo un backup.<\/p>\n<h2>Backup corretto non significa backup senza costo<\/h2>\n<p>Il fatto che un backup utilizzi CPU o I\/O non significa necessariamente che il sistema sia configurato male.<\/p>\n<p>\u00c8 per\u00f2 utile valutare:<\/p>\n<ul>\n<li>durata;<\/li>\n<li>orario;<\/li>\n<li>quantit\u00e0 di dati;<\/li>\n<li>compressione;<\/li>\n<li>destinazione;<\/li>\n<li>impatto sul traffico reale.<\/li>\n<\/ul>\n<p>Quando possibile, le attivit\u00e0 pi\u00f9 pesanti vengono normalmente pianificate nei periodi di minore traffico.<\/p>\n<h2>6. Query database lente soltanto in determinate condizioni<\/h2>\n<p>Un database pu\u00f2 essere veloce quasi sempre e rallentare soltanto durante alcune operazioni.<\/p>\n<p>Per esempio:<\/p>\n<ul>\n<li>ricerche complesse;<\/li>\n<li>filtri WooCommerce;<\/li>\n<li>report;<\/li>\n<li>importazioni;<\/li>\n<li>query su tabelle molto grandi;<\/li>\n<li>lock;<\/li>\n<li>molte query contemporanee.<\/li>\n<\/ul>\n<p>Una homepage rapida non dimostra quindi che tutte le query del sito siano efficienti.<\/p>\n<h2>WooCommerce pu\u00f2 evidenziare rallentamenti molto specifici<\/h2>\n<p>Un negozio pu\u00f2 avere tempi differenti tra:<\/p>\n<ul>\n<li>homepage;<\/li>\n<li>pagina prodotto;<\/li>\n<li>ricerca;<\/li>\n<li>filtri;<\/li>\n<li>carrello;<\/li>\n<li>checkout;<\/li>\n<li>wp-admin;<\/li>\n<li>report;<\/li>\n<li>Action Scheduler.<\/li>\n<\/ul>\n<p>\u00c8 importante sapere esattamente quale URL fosse lenta.<\/p>\n<h2>Database lento solo durante alcune operazioni<\/h2>\n<p>Per diagnosticare correttamente il problema occorre correlare:<\/p>\n<ul>\n<li>orario;<\/li>\n<li>URL;<\/li>\n<li>query;<\/li>\n<li>carico database;<\/li>\n<li>processi contemporanei;<\/li>\n<li>eventuali lock.<\/li>\n<\/ul>\n<p>Senza questa correlazione \u00e8 molto facile attribuire il rallentamento al componente sbagliato.<\/p>\n<h2>7. Processi PHP temporaneamente occupati<\/h2>\n<p>Le pagine dinamiche richiedono processi PHP disponibili.<\/p>\n<p>Se tutti i processi stanno gi\u00e0 elaborando richieste lente, quelle successive possono dover attendere.<\/p>\n<p>In forma semplificata:<\/p>\n<pre><code>PHP 1 \u2192 occupato\r\nPHP 2 \u2192 occupato\r\nPHP 3 \u2192 occupato\r\nPHP 4 \u2192 occupato\r\n\r\nNuova richiesta \u2192 attesa<\/code><\/pre>\n<p>Quando uno dei processi termina, la situazione pu\u00f2 tornare normale quasi istantaneamente.<\/p>\n<h2>Aumentare i PHP worker non risolve necessariamente il problema<\/h2>\n<p>Se la causa \u00e8 una funzione che impiega 30 secondi, aumentare semplicemente il numero dei processi pu\u00f2 consentire a pi\u00f9 richieste lente di essere eseguite contemporaneamente.<\/p>\n<p>Prima bisogna capire:<\/p>\n<p><strong>perch\u00e9 i processi rimangono occupati cos\u00ec a lungo?<\/strong><\/p>\n<h2>CloudLinux e limiti temporanei delle risorse<\/h2>\n<p>Negli ambienti hosting che utilizzano sistemi di isolamento come CloudLinux possono esistere limiti specifici per account.<\/p>\n<p>Un sito potrebbe essere velocissimo quasi sempre e rallentare soltanto quando raggiunge temporaneamente un limite.<\/p>\n<p>Pochi minuti dopo, quando il consumo diminuisce, il problema pu\u00f2 non essere pi\u00f9 visibile.<\/p>\n<h2>8. API esterne e servizi di terze parti lenti<\/h2>\n<p>Non sempre il problema si trova sul server che ospita il sito.<\/p>\n<p>WordPress pu\u00f2 dipendere da servizi esterni come:<\/p>\n<ul>\n<li>gateway di pagamento;<\/li>\n<li>API di spedizione;<\/li>\n<li>CRM;<\/li>\n<li>servizi antispam;<\/li>\n<li>feed;<\/li>\n<li>licenze;<\/li>\n<li>mappe;<\/li>\n<li>marketing automation.<\/li>\n<\/ul>\n<p>Se PHP attende una risposta esterna prima di completare la pagina, un rallentamento del servizio remoto pu\u00f2 rallentare anche il tuo sito.<\/p>\n<h2>Il server pu\u00f2 essere veloce ma la pagina comunque lenta<\/h2>\n<p>Esempio:<\/p>\n<pre><code>PHP locale   \u2192 0,2 secondi\r\nDatabase     \u2192 0,1 secondi\r\nAPI esterna  \u2192 4,5 secondi\r\n\r\nTotale       \u2192 quasi 5 secondi<\/code><\/pre>\n<p>CPU e RAM locali potrebbero apparire perfettamente normali.<\/p>\n<p>Il collo di bottiglia si trova fuori dall&#8217;infrastruttura.<\/p>\n<h2>Timeout e servizi esterni<\/h2>\n<p>Il problema diventa ancora pi\u00f9 evidente quando l&#8217;API non risponde.<\/p>\n<p>Se il timeout \u00e8 impostato a 30 secondi, una singola richiesta potrebbe rimanere in attesa per tutto quel tempo.<\/p>\n<p>Questo pu\u00f2 far sembrare WordPress improvvisamente lentissimo anche con server scarico.<\/p>\n<h2>9. DNS, CDN, rete o routing intermittente<\/h2>\n<p>Non tutti i rallentamenti avvengono dentro WordPress.<\/p>\n<p>Il percorso reale \u00e8 pi\u00f9 simile a:<\/p>\n<pre><code>Browser\r\n   \u2193\r\nDNS\r\n   \u2193\r\nrete utente\r\n   \u2193\r\nCDN \/ proxy\r\n   \u2193\r\nrete datacenter\r\n   \u2193\r\nWeb server\r\n   \u2193\r\nPHP\r\n   \u2193\r\ndatabase<\/code><\/pre>\n<p>Un problema temporaneo in qualsiasi punto del percorso pu\u00f2 essere percepito come \u201csito lento\u201d.<\/p>\n<h2>Se il problema riguarda soltanto alcuni utenti<\/h2>\n<p>\u00c8 un indizio importante.<\/p>\n<p>Se la lentezza compare soltanto:<\/p>\n<ul>\n<li>da uno specifico provider Internet;<\/li>\n<li>da una determinata rete;<\/li>\n<li>da un Paese;<\/li>\n<li>tramite IPv6;<\/li>\n<li>da una particolare area geografica;<\/li>\n<\/ul>\n<p>\u00e8 opportuno analizzare anche rete, CDN e routing.<\/p>\n<h2>Sito lento solo da smartphone<\/h2>\n<p>Quando il problema viene segnalato soltanto da mobile bisogna separare:<\/p>\n<ul>\n<li>tempo del server;<\/li>\n<li>peso della pagina;<\/li>\n<li>JavaScript;<\/li>\n<li>immagini;<\/li>\n<li>latenza della rete;<\/li>\n<li>servizi esterni.<\/li>\n<\/ul>\n<p>Un server pu\u00f2 generare l&#8217;HTML in 200 millisecondi mentre il browser impiega molti secondi a scaricare ed elaborare una pagina molto pesante.<\/p>\n<h2>TTFB alto significa sempre server lento?<\/h2>\n<p>No.<\/p>\n<p>Il percorso che precede il primo byte pu\u00f2 comprendere pi\u00f9 fasi:<\/p>\n<ul>\n<li>DNS;<\/li>\n<li>connessione;<\/li>\n<li>TLS;<\/li>\n<li>proxy;<\/li>\n<li>rete;<\/li>\n<li>elaborazione lato server.<\/li>\n<\/ul>\n<p>Per questo \u00e8 utile separare i diversi tempi invece di guardare soltanto un numero finale.<\/p>\n<h2>PageSpeed \u00e8 veloce ma gli utenti segnalano rallentamenti<\/h2>\n<p>\u00c8 perfettamente possibile.<\/p>\n<p>Un test rappresenta soltanto il comportamento osservato in quel momento.<\/p>\n<p>Se il problema compare cinque minuti ogni due ore, PageSpeed potrebbe semplicemente non incontrarlo.<\/p>\n<p>Un test singolo non \u00e8 sufficiente per diagnosticare un problema intermittente.<\/p>\n<h2>Quando un sito lento solo a volte torna veloce il problema non \u00e8 necessariamente risolto<\/h2>\n<p>Questo \u00e8 uno degli errori di valutazione pi\u00f9 comuni.<\/p>\n<p>Il fatto che il sito sia tornato rapido pu\u00f2 semplicemente significare che:<\/p>\n<ul>\n<li>il backup \u00e8 terminato;<\/li>\n<li>il bot ha smesso di effettuare richieste;<\/li>\n<li>il cron \u00e8 finito;<\/li>\n<li>l&#8217;API esterna \u00e8 tornata disponibile;<\/li>\n<li>la cache \u00e8 stata ricostruita;<\/li>\n<li>il picco di traffico \u00e8 terminato.<\/li>\n<\/ul>\n<p>La causa pu\u00f2 quindi ripresentarsi.<\/p>\n<h2>Segna l&#8217;orario esatto del problema<\/h2>\n<p>Per diagnosticare un <strong>sito lento solo a volte<\/strong> \u00e8 fondamentale conoscere il momento esatto del rallentamento.<\/p>\n<p>Invece di:<\/p>\n<blockquote><p>Stamattina il sito era lento.<\/p><\/blockquote>\n<p>\u00e8 molto pi\u00f9 utile:<\/p>\n<pre><code>10:42:15 \u2192 prodotto lento\r\n10:42:30 \u2192 checkout lento\r\n10:44:00 \u2192 tutto normale<\/code><\/pre>\n<p>Con un timestamp preciso puoi confrontare access log, PHP, database, cron e monitoraggio.<\/p>\n<h2>Annota anche l&#8217;URL esatta<\/h2>\n<p>Dire:<\/p>\n<p><strong>\u201cil sito \u00e8 lento\u201d<\/strong><\/p>\n<p>fornisce poche informazioni.<\/p>\n<p>Meglio sapere:<\/p>\n<pre><code>\/ \u2192 veloce\r\n\/categoria\/ \u2192 veloce\r\n\/prodotto-x\/ \u2192 lento\r\n\/checkout\/ \u2192 lento\r\n\/wp-admin\/ \u2192 veloce<\/code><\/pre>\n<p>Se la lentezza riguarda soltanto determinate pagine, la diagnosi cambia radicalmente.<\/p>\n<h2>Frontend lento o wp-admin lento?<\/h2>\n<p>Un sito pu\u00f2 essere veloce per i visitatori e lento nel pannello amministrativo.<\/p>\n<p>Oppure il contrario.<\/p>\n<p>Se soltanto <code>\/wp-admin\/<\/code> \u00e8 lento, controlla in particolare:<\/p>\n<ul>\n<li>plugin;<\/li>\n<li>query amministrative;<\/li>\n<li>dashboard widget;<\/li>\n<li>cron;<\/li>\n<li>API;<\/li>\n<li>Action Scheduler;<\/li>\n<li>controlli aggiornamenti.<\/li>\n<\/ul>\n<h2>Sito lento dopo il login ma veloce da anonimo<\/h2>\n<p>Gli utenti autenticati possono bypassare la page cache.<\/p>\n<p>Pu\u00f2 quindi accadere:<\/p>\n<pre><code>Visitatore anonimo \u2192 cache HIT \u2192 100 ms\r\n\r\nUtente autenticato \u2192 PHP + database \u2192 1,5 s<\/code><\/pre>\n<p>In questo scenario la cache potrebbe nascondere un problema applicativo che appare soltanto agli utenti autenticati.<\/p>\n<h2>Sito lento dopo una modifica o un purge<\/h2>\n<p>Se il rallentamento compare dopo:<\/p>\n<ul>\n<li>aggiornamento pagina;<\/li>\n<li>modifica prodotto;<\/li>\n<li>svuotamento cache;<\/li>\n<li>aggiornamento WordPress;<\/li>\n<li>deploy;<\/li>\n<\/ul>\n<p>verifica se l&#8217;operazione invalida cache o altre risorse che devono successivamente essere ricostruite.<\/p>\n<h2>Sito lento sempre alla stessa ora<\/h2>\n<p>Questo \u00e8 uno degli indizi migliori.<\/p>\n<p>Se il rallentamento compare sistematicamente alle 03:00, cerca un&#8217;attivit\u00e0 pianificata nello stesso momento.<\/p>\n<p>Possibili cause:<\/p>\n<ul>\n<li>backup;<\/li>\n<li>cron;<\/li>\n<li>scanner malware;<\/li>\n<li>report;<\/li>\n<li>sincronizzazioni;<\/li>\n<li>importazioni;<\/li>\n<li>crawler programmati.<\/li>\n<\/ul>\n<p>Una periodicit\u00e0 regolare difficilmente \u00e8 casuale.<\/p>\n<h2>Anche bot, backup e cron possono spiegare perch\u00e9 il sito rallenta in fasce precise<\/h2>\n<p>Un <strong>sito lento solo a volte<\/strong> che peggiora sempre negli stessi intervalli dovrebbe essere analizzato confrontando gli orari con tutte le attivit\u00e0 automatiche.<\/p>\n<p>Una timeline pu\u00f2 essere estremamente utile:<\/p>\n<pre><code>02:59 \u2192 sito 180 ms\r\n03:00 \u2192 inizia backup\r\n03:01 \u2192 aumenta I\/O\r\n03:02 \u2192 sito 2,8 secondi\r\n03:06 \u2192 backup terminato\r\n03:07 \u2192 sito 190 ms<\/code><\/pre>\n<p>Una correlazione di questo tipo vale molto pi\u00f9 di una semplice impressione.<\/p>\n<h2>404 massive e scanner automatici<\/h2>\n<p>Uno scanner pu\u00f2 richiedere continuamente URL inesistenti.<\/p>\n<p>Se ogni 404 arriva fino a WordPress e viene generata dinamicamente, anche richieste apparentemente inutili possono utilizzare PHP e database.<\/p>\n<p>Controlla quindi anche la distribuzione dei codici HTTP:<\/p>\n<pre><code>200\r\n301\r\n403\r\n404\r\n500<\/code><\/pre>\n<h2>Non riavviare tutto prima di raccogliere i dati<\/h2>\n<p>Quando il sito rallenta, una reazione comune consiste nel riavviare immediatamente PHP, database o Web server.<\/p>\n<p>Il problema pu\u00f2 scomparire.<\/p>\n<p>Ma in questo modo rischi anche di perdere la condizione che volevi analizzare.<\/p>\n<p>Quando possibile:<\/p>\n<ol>\n<li>annota l&#8217;orario;<\/li>\n<li>controlla le risorse;<\/li>\n<li>salva i log;<\/li>\n<li>controlla processi e query;<\/li>\n<li>solo dopo intervieni.<\/li>\n<\/ol>\n<h2>Non disattivare tutti i plugin senza una strategia<\/h2>\n<p>La disattivazione dei plugin pu\u00f2 essere utile durante un test controllato.<\/p>\n<p>Ma se il problema compare una volta ogni sei ore, il fatto che non si ripresenti nei successivi venti minuti non dimostra nulla.<\/p>\n<p>Per problemi intermittenti bisogna cercare correlazioni ripetibili.<\/p>\n<h2>Come monitorare un sito lento intermittente<\/h2>\n<p>Quando il problema non \u00e8 facilmente riproducibile, il monitoraggio continuo pu\u00f2 essere molto pi\u00f9 utile di un test manuale.<\/p>\n<p>Puoi registrare periodicamente:<\/p>\n<ul>\n<li>HTTP status;<\/li>\n<li>DNS time;<\/li>\n<li>connect time;<\/li>\n<li>TLS time;<\/li>\n<li>TTFB;<\/li>\n<li>tempo totale;<\/li>\n<li>CPU;<\/li>\n<li>RAM;<\/li>\n<li>I\/O;<\/li>\n<li>PHP;<\/li>\n<li>database.<\/li>\n<\/ul>\n<p>In questo modo il rallentamento lascia una traccia anche se nessuno lo sta osservando direttamente.<\/p>\n<h2>curl pu\u00f2 aiutare a separare i vari tempi<\/h2>\n<p>Da terminale \u00e8 possibile misurare diverse fasi della richiesta.<\/p>\n<p>Questo permette di capire se il ritardo avviene:<\/p>\n<ul>\n<li>durante il DNS;<\/li>\n<li>durante la connessione;<\/li>\n<li>durante TLS;<\/li>\n<li>prima del primo byte;<\/li>\n<li>durante il trasferimento.<\/li>\n<\/ul>\n<p>Separare queste fasi evita di attribuire automaticamente ogni rallentamento a PHP o WordPress.<\/p>\n<h2>LiteSpeed e LSCache: cosa controllare<\/h2>\n<p>Negli ambienti che utilizzano LiteSpeed e LSCache \u00e8 utile distinguere le richieste:<\/p>\n<ul>\n<li>cache HIT;<\/li>\n<li>cache MISS;<\/li>\n<li>bypassate;<\/li>\n<li>non cacheabili;<\/li>\n<li>dinamiche.<\/li>\n<\/ul>\n<p>Una page cache efficace riduce notevolmente il lavoro necessario per molte richieste pubbliche, ma carrello, checkout, utenti autenticati e altre pagine dinamiche continuano a utilizzare PHP e database.<\/p>\n<h2>Prima di cambiare hosting identifica la causa<\/h2>\n<p>Un <strong>sito lento solo a volte<\/strong> non dimostra automaticamente che l&#8217;hosting sia insufficiente.<\/p>\n<p>Se il problema dipende da:<\/p>\n<ul>\n<li>plugin;<\/li>\n<li>API esterna;<\/li>\n<li>query;<\/li>\n<li>cron;<\/li>\n<li>bot;<\/li>\n<\/ul>\n<p>una migrazione potrebbe semplicemente trasferire lo stesso problema su un altro server.<\/p>\n<p>Prima di cambiare hosting per un <strong>sito lento solo a volte<\/strong>, conviene quindi raccogliere dati su PHP, database, cache, traffico e risorse.<\/p>\n<p>Se i rallentamenti diventano frequenti e l&#8217;infrastruttura risulta realmente insufficiente, puoi leggere anche la nostra guida su <a href=\"https:\/\/xlogic.org\/blog\/quando-cambiare-hosting-segnali.html\/\"><strong>quando cambiare hosting e quali segnali valutare<\/strong><\/a>.<\/p>\n<h2>Quando invece le risorse possono essere realmente insufficienti?<\/h2>\n<p>Se durante ogni rallentamento osservi contemporaneamente:<\/p>\n<ul>\n<li>CPU costantemente satura;<\/li>\n<li>processi disponibili esauriti;<\/li>\n<li>database congestionato;<\/li>\n<li>I\/O elevato;<\/li>\n<li>code crescenti;<\/li>\n<li>tempi di risposta sempre maggiori;<\/li>\n<\/ul>\n<p>allora il dimensionamento dell&#8217;ambiente pu\u00f2 essere realmente una parte della causa.<\/p>\n<p>La decisione dovrebbe per\u00f2 essere basata su misure raccolte durante il problema.<\/p>\n<h2>Checklist: 9 cause di un sito lento solo a volte<\/h2>\n<ul>\n<li>\u2611 cache HIT, MISS e purge;<\/li>\n<li>\u2611 picchi temporanei di traffico;<\/li>\n<li>\u2611 bot e crawler;<\/li>\n<li>\u2611 WP-Cron e task pianificati;<\/li>\n<li>\u2611 backup e operazioni I\/O;<\/li>\n<li>\u2611 query database intermittenti;<\/li>\n<li>\u2611 processi PHP o limiti delle risorse;<\/li>\n<li>\u2611 API esterne lente;<\/li>\n<li>\u2611 DNS, CDN, rete o routing.<\/li>\n<\/ul>\n<h2>Checklist: cosa annotare quando il sito diventa lento<\/h2>\n<ul>\n<li>\u2611 data e ora esatta;<\/li>\n<li>\u2611 URL interessata;<\/li>\n<li>\u2611 durata del rallentamento;<\/li>\n<li>\u2611 utente autenticato o anonimo;<\/li>\n<li>\u2611 rete e dispositivo;<\/li>\n<li>\u2611 cache HIT o MISS;<\/li>\n<li>\u2611 CPU;<\/li>\n<li>\u2611 RAM;<\/li>\n<li>\u2611 I\/O;<\/li>\n<li>\u2611 processi PHP;<\/li>\n<li>\u2611 query database;<\/li>\n<li>\u2611 access log;<\/li>\n<li>\u2611 error log;<\/li>\n<li>\u2611 cron attivi;<\/li>\n<li>\u2611 backup in corso.<\/li>\n<\/ul>\n<h2>Domande frequenti su un sito lento solo a volte<\/h2>\n<h3>Perch\u00e9 il mio sito \u00e8 lento soltanto ogni tanto?<\/h3>\n<p>Un <strong>sito lento solo a volte<\/strong> pu\u00f2 dipendere da cache MISS, picchi di traffico, bot, cron, backup, query database lente, processi PHP occupati, servizi esterni o problemi temporanei di rete.<\/p>\n<h3>Se il sito torna veloce significa che il problema \u00e8 risolto?<\/h3>\n<p>No. Un problema intermittente pu\u00f2 semplicemente essere terminato e ripresentarsi quando si verifica nuovamente la condizione che lo provoca.<\/p>\n<h3>PageSpeed pu\u00f2 trovare un rallentamento intermittente?<\/h3>\n<p>Soltanto se il problema \u00e8 presente durante il test. Per fenomeni che compaiono casualmente \u00e8 molto pi\u00f9 utile il monitoraggio continuo.<\/p>\n<h3>La cache pu\u00f2 far sembrare il sito veloce una volta e lento quella dopo?<\/h3>\n<p>S\u00ec. Una richiesta servita dalla cache pu\u00f2 essere molto pi\u00f9 rapida della stessa pagina quando deve essere generata da PHP e database.<\/p>\n<h3>Un bot pu\u00f2 rallentare WordPress?<\/h3>\n<p>S\u00ec. Un numero elevato di richieste automatiche pu\u00f2 aumentare il carico, soprattutto quando vengono richieste pagine dinamiche o URL che devono essere elaborate da WordPress.<\/p>\n<h3>I backup possono rallentare il sito?<\/h3>\n<p>Possono aumentare temporaneamente l&#8217;utilizzo di CPU, storage e I\/O. L&#8217;impatto dipende dall&#8217;infrastruttura e dal tipo di backup.<\/p>\n<h3>Il database pu\u00f2 essere lento soltanto in determinati momenti?<\/h3>\n<p>S\u00ec. Query concorrenti, lock, report, importazioni e attivit\u00e0 automatiche possono causare rallentamenti temporanei.<\/p>\n<h3>Aumentare il PHP memory_limit rende il sito pi\u00f9 veloce?<\/h3>\n<p>Non necessariamente. Il memory limit determina quanta memoria pu\u00f2 utilizzare un processo PHP, ma non \u00e8 un parametro generale di velocit\u00e0.<\/p>\n<h3>Se la CPU \u00e8 libera significa che il server non ha problemi?<\/h3>\n<p>No. Il collo di bottiglia potrebbe riguardare database, I\/O, processi PHP, API esterne, rete o un limite specifico dell&#8217;ambiente.<\/p>\n<h3>Cambiare hosting risolve sempre un sito lento solo a volte?<\/h3>\n<p>No. Se la causa \u00e8 un plugin, una query inefficiente, un cron o una API esterna, lo stesso problema pu\u00f2 continuare anche dopo la migrazione.<\/p>\n<h2>Conclusioni<\/h2>\n<p>Un <strong>sito lento solo a volte<\/strong> \u00e8 difficile da diagnosticare proprio perch\u00e9 il problema pu\u00f2 scomparire prima che qualcuno riesca ad analizzarlo.<\/p>\n<p>Dire semplicemente:<\/p>\n<p><strong>\u201cAdesso \u00e8 veloce\u201d<\/strong><\/p>\n<p>non significa necessariamente che tutto sia risolto.<\/p>\n<p>Bisogna ricostruire ci\u00f2 che stava succedendo nell&#8217;istante del rallentamento.<\/p>\n<p>Le principali aree da verificare sono:<\/p>\n<ul>\n<li>cache;<\/li>\n<li>traffico;<\/li>\n<li>bot;<\/li>\n<li>cron;<\/li>\n<li>backup;<\/li>\n<li>database;<\/li>\n<li>PHP e risorse;<\/li>\n<li>API esterne;<\/li>\n<li>rete e CDN.<\/li>\n<\/ul>\n<p>La cosa pi\u00f9 utile da fare quando il problema compare \u00e8 annotare immediatamente:<\/p>\n<p><strong>orario preciso, URL interessata e durata.<\/strong><\/p>\n<p>Con questi tre dati puoi confrontare nello stesso intervallo access log, error log, utilizzo delle risorse, cron, backup, query e traffico.<\/p>\n<p>\u00c8 cos\u00ec che un rallentamento apparentemente casuale pu\u00f2 diventare un problema misurabile e finalmente diagnosticabile.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Un sito lento solo a volte \u00e8 spesso molto pi\u00f9 difficile da diagnosticare rispetto a un sito costantemente lento. Quando il problema \u00e8 permanente basta aprire una pagina, misurare i tempi di risposta e controllare PHP, database, cache e risorse. Quando invece il rallentamento compare soltanto per pochi secondi o alcuni minuti, pu\u00f2 essere gi\u00e0 [&hellip;]<\/p>\n","protected":false},"author":4,"featured_media":19565,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"no","_lmt_disable":"","footnotes":""},"categories":[5],"tags":[],"class_list":["post-19562","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"modified_by":"Team tecnico Xlogic","_links":{"self":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/posts\/19562","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/comments?post=19562"}],"version-history":[{"count":3,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/posts\/19562\/revisions"}],"predecessor-version":[{"id":19572,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/posts\/19562\/revisions\/19572"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/media\/19565"}],"wp:attachment":[{"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/media?parent=19562"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/categories?post=19562"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/xlogic.org\/blog\/wp-json\/wp\/v2\/tags?post=19562"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}