Sito lento su Aruba: come capire dove sta il problema e risolverlo

Apri il sito e la pagina resta bianca un paio di secondi prima di comparire, soprattutto alla prima visita della mattina o sulle pagine che nessuno apre da giorni. Su Aruba è uno dei problemi che mi segnalano più spesso, e quasi mai la causa è una sola.

Qui trovi l’ordine in cui controllo un sito WordPress lento su Aruba: cosa misurare prima di toccare qualsiasi cosa, cosa attivare dal pannello e quando il problema non si risolve restando sul piano che hai.

La colpa è di Aruba o del sito?

Prima di cambiare impostazioni misuro il TTFB (il tempo che il server impiega a mandare il primo byte della pagina), perché è il numero che separa i problemi del server da quelli del sito. Se il TTFB è alto la causa sta sul server, cioè cache, versione di PHP o risorse del piano; se è basso ma la pagina impiega comunque molto a comparire, l’hosting c’entra poco e il peso sta nelle immagini e negli script che il sito carica.

Per misurarlo:

1. Apri la pagina in una finestra in incognito, così non sei loggato.
2. Apri gli strumenti per sviluppatori con F12, vai nella scheda Network e ricarica la pagina.
3. Clicca sulla prima riga, quella del documento HTML, e nella scheda Timing guarda la voce Waiting for server response.
4. Ricarica una seconda volta e confronta i due valori.

Google considera buono un TTFB entro 0,8 secondi (web.dev, guida al TTFB, consultata a ottobre 2026). Se anche al secondo caricamento resti sopra il secondo, la cache non è attiva oppure non sta servendo quella pagina, e il passo successivo è sistemare quella.

Come attivo HiSpeed Cache?

È la cache lato server di Aruba e, secondo le pagine dei piani consultate a ottobre 2026, è inclusa sia negli Hosting Linux sia in quelli per WordPress. Salva le pagine già generate e, a detta di Aruba, anche i risultati delle query al database tramite Redis, così il server non deve ricostruire tutto a ogni visita.

Rispetto a un plugin di cache il vantaggio è che la pagina la consegna direttamente il server, senza passare da PHP, ed è il motivo per cui su Aruba la attivo sempre per prima. Per attivarla:

1. Entra nel pannello di controllo del tuo hosting e apri la sezione dedicata alla cache.
2. Attivala sul dominio: può volerci qualche minuto prima che sia operativa.
3. In WordPress installa il plugin gratuito Aruba HiSpeed Cache, che svuota la cache da solo quando pubblichi o modifichi un contenuto.
4. Ripeti la misura del TTFB: al secondo caricamento il valore deve scendere in modo netto.

Attenzione: Con la cache di Aruba attiva non installare un secondo plugin di cache di pagina, come WP Super Cache o W3 Total Cache. Due cache sovrapposte di solito producono pagine vecchie che non si aggiornano, senza nessun guadagno di velocità in cambio.

Un limite da conoscere: la cache vale solo per chi non è loggato. Se il sito ti sembra lento solo mentre lavori in bacheca è normale fino a un certo punto, perché da loggato ogni pagina viene generata da zero e la misura che conta è quella fatta in incognito.

Quale versione di PHP devo usare?

PHP è il linguaggio con cui WordPress costruisce le pagine, e a ottobre 2026 la 8.1 non riceve più aggiornamenti mentre la 8.2 riceve solo correzioni di sicurezza fino al 31 dicembre 2026 (php.net, Supported Versions). Se sei ancora su una 7.x o sulla 8.0, l’aggiornamento è quasi sempre l’intervento che rende di più a costo zero: io punto alla 8.3 o alla 8.4, quando tema e plugin le supportano.

1. Aggiorna prima WordPress, tema e plugin all’ultima versione disponibile.
2. Fai un backup completo di file e database.
3. Nel pannello Aruba apri Gestione PHP, scegli la versione dal menu e conferma.
4. Controlla la home, il modulo contatti e la bacheca: se vedi una pagina bianca o un errore critico, torna alla versione precedente dallo stesso menu.

Importante: Il motivo più comune per cui un sito si rompe dopo il cambio di PHP è un plugin abbandonato. Prima di aggiornare controlla quali plugin non ricevono aggiornamenti da più di due anni, e valuta di sostituirli con alternative mantenute.

Mi servono ancora le regole Gzip e cache nel .htaccess?

Prima di aggiungere qualcosa controlla se la compressione è già attiva: negli strumenti per sviluppatori, sulla riga del documento HTML, cerca l’intestazione content-encoding nella risposta, e se trovi gzip o br sei a posto.

Se manca, basta questo blocco, da mettere nel file .htaccess nella cartella principale del sito sopra la riga # BEGIN WordPress, così WordPress non lo tocca quando riscrive le sue regole.

# Compressione
<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/css text/xml
  AddOutputFilterByType DEFLATE application/javascript application/json application/xml
  AddOutputFilterByType DEFLATE application/rss+xml image/svg+xml font/ttf font/otf
</IfModule>

Per la cache del browser il ragionamento è lo stesso: questo blocco dice al browser di tenere in memoria immagini e font per un anno, CSS e JavaScript per un mese, così chi torna sul sito non li scarica di nuovo.

# Cache del browser
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/avif "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"
  ExpiresByType font/woff2 "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

Consiglio: Scarica una copia del .htaccess via FTP prima di modificarlo. Un errore di sintassi in questo file manda tutto il sito in errore 500, e rimettere la copia originale lo risolve in un minuto.

Cosa rallenta il sito anche con la cache attiva?

La cache accorcia l’attesa del server, ma non alleggerisce quello che il browser deve scaricare dopo. Le cause che trovo più spesso sono queste:

• Foto caricate direttamente dal telefono, da 3 o 4 MB l’una, che ridimensionate alla larghezza reale e convertite in WebP di solito scendono sotto i 200 KB.
• Page builder e plugin che caricano i loro script su ogni pagina, anche dove non servono: in questi casi mi trovo bene con Perfmatters, un plugin che permette di spegnere quegli script pagina per pagina, così restano attivi solo dove servono.
• Slider e video in cima alla pagina, che ritardano il primo contenuto visibile e pesano anche sulla SEO.

Un’opzione che sconsiglio è unire tutti i CSS e i JavaScript in un unico file, che molti plugin di ottimizzazione offrono ancora: sui server attuali di solito non fa guadagnare nulla e rompe il layout più spesso di quanto sembri.

Quando conviene cambiare piano o hosting?

Qui nessun plugin aiuta. I piani Hosting Linux di Aruba sono condivisi, quindi processore e memoria sono divisi tra molti siti, e un e-commerce con tanti utenti loggati li esaurisce in fretta.

Se dopo cache e PHP aggiornato il TTFB resta sopra il secondo sulle pagine che non possono stare in cache, come carrello e checkout, il limite è il piano. Aruba propone Hyper Hosting con risorse dedicate da 199 euro più IVA il primo anno; l’alternativa è spostare il sito su un altro provider.

Per un sito vetrina con poche pagine e la cache attiva, invece, il piano base di solito basta e cambiare hosting non ti serve.

Il primo passo resta la misura: prendi il TTFB di tre pagine diverse, prima e dopo aver attivato la cache, e annota i valori, perché senza quei numeri ogni intervento è un tentativo alla cieca.

Se preferisci che sia io a controllare il sito e a sistemarlo, trovi i dettagli nel servizio di gestione sito WordPress.