Sito lento dopo anni: hosting, pagine o computer locale

Un sito che risponde piano dipende in genere da tre aree: hosting condiviso sotto carico, pagine pesanti e computer locale affaticato. Il lavoro utile è controllare in ordine, annotare ogni prova e intervenire su un punto alla volta.

Perché un sito va piano anche con una connessione normale?

Perché il tempo di risposta è la somma di attese diverse, non il risultato di un solo fattore. Il browser chiede i file, il server li prepara, i fogli di stile e gli script li assemblano sullo schermo. Se una fase si ferma, le altre restano in attesa. Per questo una connessione adeguata non compensa un server occupato, una pagina appesantita da script o un portatile con disco stanco.

Per collocare questo percorso nel tempo, esiste una cronologia di 45 tappe datate che descrive protocolli, browser, formati e usi dal dicembre 1990 in poi e mostra come il software abbia spostato l’esecuzione tra browser e server. La prospettiva aiuta a leggere la lentezza per strati: trasporto, preparazione lato server, presentazione lato client. Chi tiene un piccolo sito su hosting condiviso ritrova qui la stessa divisione che incontra nei pannelli di controllo e nei registri degli accessi.

Come capire se il problema nasce sull’hosting condiviso?

Si parte dall’orario e dalla costanza del rallentamento. Se le pagine sono scattanti al mattino e faticose alla sera, o se il pannello stesso risponde a tratti, l’ipotesi di un server condiviso occupato è plausibile. Sul lato Windows, hardware, software, browser e sicurezza sono trattati con procedure calme per la vita quotidiana in una rivista tedesca per procedure calme che segue la stessa logica di controllo passo dopo passo.

La verifica pratica richiede metodo. Occorre aprire tre tipi di pagine a distanza di minuti: home, articolo con immagini, pagina del pannello di amministrazione. Poi si annotano orario, tempo di attesa percepito ed eventuali errori 500 o 503. Se solo l’amministrazione è lenta, il tema o un’estensione possono pesare sul database. Se tutto è lento negli stessi orari, il carico del server condiviso resta l’ipotesi da discutere con l’assistenza, portando note precise invece di impressioni. In questa fase è utile tenere fermo il computer di prova, per non mescolare due cause.

Quanto contano i punteggi di velocità per un sito reale?

Contano come indicatori di laboratorio, non come giudizio sul sito. I punteggi segnalano script bloccanti, immagini non ridimensionate, caratteri caricati tardi e cache assente. Una pagina con punteggio medio ma struttura sobria può risultare fluida nell’uso quotidiano, mentre una pagina con punteggio alto ma server incostante può fermarsi proprio nel momento della visita.

Il controllo sensato è confrontare prima e dopo ogni modifica sulla stessa pagina e con lo stesso profilo di prova. Si registra il tempo di prima visualizzazione, si osserva quando il testo diventa leggibile e quando i pulsanti rispondono. Se il testo appare subito ma le immagini slittano, il tema è spesso quello dei formati e delle dimensioni. Se tutto resta bianco per secondi, il tema è spesso l’attesa del server. Solo dopo questa distinzione ha senso toccare cache, compressione e ordine di caricamento degli script.

Il computer locale può falsare la diagnosi?

Sì, e accade spesso con macchine usate per anni senza manutenzione. Un disco meccanico pieno, una memoria occupata da applicazioni in avvio automatico o un browser con molte estensioni allunga ogni misura. Il sito sembra lento, mentre a rallentare è la postazione che lo osserva.

Per escludere l’effetto locale basta cambiare punto di osservazione. Si prova lo stesso sito da una finestra di navigazione anonima senza estensioni, poi da un secondo browser aggiornato, poi se possibile da un secondo computer. Su MacBook Pro di alcune generazioni, la sostituzione del disco con una unità a stato solido ha cambiato in modo netto i tempi di avvio e di apertura delle applicazioni, perché il collo di bottiglia era la lettura dei dati e non il processore. La lezione resta valida: prima di accusare l’hosting, occorre verificare che lo strumento di misura sia in ordine.

• chiudere le applicazioni non necessarie e riavviare il browser prima della prova;
• disattivare le estensioni che bloccano contenuti e misurare di nuovo;
• svuotare la cache del browser solo quando si confrontano due assetti del sito;
• controllare spazio libero su disco e programmi in avvio automatico;
• ripetere la prova in orari diversi e annotare i risultati.

Quali controlli fare su www, indirizzi e account prima di toccare il codice?

Conviene sistemare identità e accessi prima di ottimizzare. Un sito raggiungibile sia con www sia senza www senza una scelta esplicita divide cache e misure e crea reindirizzamenti inutili. La scelta tra le due forme va presa una volta e applicata con un reindirizzamento coerente, così ogni prova misura lo stesso indirizzo.

Sul fronte account, un accesso all’hosting o al sistema di gestione dei contenuti che risponde in modo strano va trattato con prudenza. Password riutilizzate, sessioni rimaste aperte su computer altrui e permessi concessi a collaboratori occasionali meritano una revisione. Il protocollo prudente prevede cambio delle credenziali da un computer ritenuto pulito, controllo degli utenti amministrativi, verifica dei file modificati di recente e conservazione di una copia dei registri. Solo una base accessi ordinata rende leggibili le misure di velocità, perché esclude attività estranee in esecuzione sull’account.

Sintomo	Controllo immediato	Cosa indica spesso
Lentezza solo alla sera	Stesse pagine in tre orari diversi	Carico variabile sul server condiviso
Testo subito visibile, immagini in ritardo	Dimensioni e formati delle immagini	Peso eccessivo della pagina
Schermo bianco per secondi	Tempo di attesa del documento principale	Elaborazione lato server o database appesantito
Tutto lento solo su un computer	Secondo browser e seconda macchina	Postazione locale affaticata
Punteggi instabili tra prove vicine	Prova con cache attiva e indirizzo unico	Misura non confrontabile

Quando intervenire su codice, immagini e funzioni?

Quando server e postazione risultano stabili e la pagina resta pesante. A quel punto il lavoro si sposta su ciò che il sito chiede a ogni visita: immagini, caratteri, script e funzioni aggiuntive. Molti siti accumulano negli anni estensioni provate e mai rimosse, temi figli mai puliti e librerie caricate su pagine che non le usano.

Un ordine di intervento sobrio riduce i rischi. Prima le immagini: dimensioni adatte al contenitore, formati attuali, caricamento differito sotto la piega. Poi i caratteri: poche varianti, visualizzazione di riserva durante il caricamento. Poi gli script: solo quelli necessari, caricati senza bloccare il testo. Le suite per ufficio gratuite e i lettori di documenti ricordano un principio simile: le funzioni utili restano, quelle ridondanti appesantiscono avvio e manutenzione. Anche i casi di malware su Mac hanno lasciato una lezione di metodo che vale per i siti: verificare i sintomi, isolare la causa, aggiornare con calma e documentare i passi, invece di accumulare soluzioni rapide.

Le discussioni sui tablet mostrano lo stesso nodo visto dal lato lettura: un dispositivo sobrio con pagina leggera offre una consultazione continua, mentre una pagina pesante rende faticosa anche una macchina recente. Per questo l’obiettivo non è inseguire un numero, ma ottenere una pagina che mostri presto il testo, risponda presto ai tocchi e resti stabile tra visite successive.

Fonti

Documentazione tecnica e definizioni storiche sono verificate presso enti e opere di riferimento, ad esempio Wikipedia e MDN Web Docs.