Velocità del sito per principianti: cosa migliora davvero i tempi di caricamento

Cosa significa davvero “velocità del sito"

Quando si dice “il mio sito è lento” di solito si intende una di due cose:

• La pagina impiega troppo ad iniziare a mostrare qualcosa, oppure
• Sembra pronta ma è comunque poco reattiva (i pulsanti ritardano, le immagini compaiono dopo, la pagina salta).

“Tempo di caricamento” non è un unico numero cronologico. Una pagina si carica per fasi: il browser richiede file (HTML, immagini, font, script), li scarica e poi li trasforma in una pagina utilizzabile. Puoi pensarci come aprire un negozio: sbloccare la porta, accendere le luci, sistemare gli scaffali e infine essere pronto a servire i clienti.

Perché la velocità conta (oltre al “fa piacere”)

La velocità influisce su:

• Utenti: le pagine lente sono stressanti su mobile e connessioni instabili. Le persone se ne vanno prima e si fidano meno del sito.
• SEO: Google usa segnali legati alla velocità (inclusi i Core Web Vitals) come parte dell’esperienza della pagina. Un sito più veloce non scala automaticamente in cima, ma uno lento può ostacolarti.
• Conversioni: ogni ritardo aggiunge attrito—meno iscrizioni, meno acquisti, meno invii di form.

Aspettative: i maggiori miglioramenti vengono da poche aree

Non servono 50 micro-ottimizzazioni. Per la maggior parte dei siti per principianti, i miglioramenti più grandi arrivano da una breve lista: immagini, troppo JavaScript/CSS, widget di terze parti e tempo di risposta del server/hosting.

Cosa coprirà (e cosa no) questa guida

Questa guida si concentra su passi pratici e a basso rischio che migliorano il tempo di caricamento nel mondo reale, specialmente su mobile. Non entrerà in argomenti avanzati come riscrivere l’architettura dell’app, costruire layer di caching personalizzati o budget di prestazioni per grandi team di ingegneria. L’obiettivo è aiutarti a fare cambiamenti che puoi effettivamente finire—e verificare—senza rompere il sito.

Metriche chiave di velocità da conoscere (senza gergo)

Quando si dice “il mio sito è lento” spesso si intende una di tre cose: il contenuto principale appare tardi, la pagina è laggosa quando si tocca, o il layout continua a saltare. I Core Web Vitals di Google mappano bene queste lamentele.

I tre Core Web Vitals

LCP (Largest Contentful Paint): quanto tempo impiega il più grande elemento “principale” (spesso un’immagine hero o un blocco titolo) ad apparire. Se l’LCP è alto, gli utenti guardano una pagina per lo più vuota.

INP (Interaction to Next Paint): quanto velocemente la pagina risponde dopo un’interazione dell’utente (tap, clic, digitazione). Se l’INP è alto, il sito sembra appiccicoso—i pulsanti reagiscono in ritardo, i menu si aprono con delay.

CLS (Cumulative Layout Shift): quanto salta la pagina durante il caricamento. Se il testo si sposta e premi per errore un pulsante, quello è CLS.

TTFB: il tempo della “prima risposta”

TTFB (Time to First Byte) è quanto tempo impiega il server (e tutto ciò che c’è in mezzo) per iniziare a inviare qualcosa. Un TTFB lento ritarda tutto il resto: le immagini non possono iniziare a scaricarsi, i font non possono caricarsi e l’LCP di solito peggiora. I problemi di TTFB spesso indicano hosting, lavoro backend pesante o cache mancanti.

Test di laboratorio vs. dati reali degli utenti

I test di laboratorio (come Lighthouse) simulano un caricamento in condizioni prestabilite. Sono ottimi per il debug e per confronti prima/dopo.

I dati reali degli utenti (detti anche “field data”, come CrUX nei report di PageSpeed Insights) riflettono ciò che i visitatori sperimentano davvero su dispositivi e reti diverse. Questo è ciò che conta davvero per la domanda: “Si percepisce veloce per le persone reali?”

Target “sufficientemente buoni” per principianti

• LCP: punta a ≤ 2.5s (fino a 4.0s richiede interventi)
• INP: punta a ≤ 200ms (fino a 500ms richiede interventi)
• CLS: punta a ≤ 0.10 (sopra 0.25 è un problema)
• TTFB: punta a ≤ 0.8s (sopra 1.8s spesso si percepisce lento)

Come misurare il sito prima di cambiare qualsiasi cosa

Se inizi a “ottimizzare” senza una linea di base, è facile perdere tempo—o rendere il sito più lento accidentalmente. Prenditi 20 minuti per misurare prima, così saprai quali cambiamenti hanno aiutato.

Esegui PageSpeed Insights (controllo rapido della realtà)

Usa PageSpeed Insights per uno snapshot veloce. Riporta dati reali degli utenti (quando disponibili) e dati di laboratorio. Fai attenzione a:

• Risultati mobile vs desktop (di solito il problema è il mobile)
• La lista “Opportunities” (utile per idee, non una lista di cose da fare rigida)
• Se il test ha dati reali per il tuo URL

Per test di laboratorio più approfonditi, esegui Lighthouse in Chrome:

1. Apri DevTools → Lighthouse
2. Scegli Mobile e Performance
3. Esegui 2–3 volte e tieni il risultato intermedio (i test variano)

Usa WebPageTest per la “waterfall”

Quando vuoi vedere cosa sta ritardando la pagina, WebPageTest è uno degli strumenti più chiari. La vista a cascata mostra ogni file che si carica in ordine—HTML, immagini, font, script e tag di terze parti—e dove il browser sta aspettando.

Inizia con una pagina chiave (homepage o pagina di atterraggio principale) e testa:

• First View (cache fredda) e Repeat View (cache)
• Un profilo dispositivo mobile quando possibile

Registra le condizioni del test (così i risultati significano qualcosa)

Annota per ogni test:

• Dispositivo (il tuo laptop, uno smartphone di fascia media, ecc.)
• Rete (Wi‑Fi, 4G, impostazioni throttle)
• Posizione (regione di test in WebPageTest)
• URL esatto (inclusi parametri)

Crea una semplice checklist prima/dopo

Crea un piccolo registro (va bene un foglio di calcolo): data, strumento usato, URL, risultati e cosa è cambiato. Cambia solo una o due cose alla volta, poi ritesta nelle stesse condizioni.

Se stai iterando su un’app (non solo un sito statico), è utile avere un modo sicuro per distribuire ed eventualmente annullare esperimenti di prestazioni. Piattaforme come Koder.ai (che può generare e ospitare app React/Go da un workflow in chat) sono utili perché puoi prendere snapshot, testare modifiche e rollback velocemente se una “correzione di velocità” peggiora l’esperienza utente.

Le ragioni più comuni per cui le pagine si caricano lentamente

Le pagine lente raramente sono causate da un unico problema misterioso. Di solito sono il risultato di alcuni problemi comuni di “peso e ritardo” che si sommano—soprattutto su mobile.

1) Immagini più grandi del necessario

Le immagini sono spesso la parte più pesante di una pagina. Una singola immagine hero esportata nelle dimensioni sbagliate (o in un formato vecchio) può aggiungere megabyte e secondi.

Colpevoli comuni:

• Caricare una foto larga 4000px quando il sito la mostra a 1200px
• Usare PNG per foto invece di formati moderni come WebP/AVIF
• Servire la stessa immagine grande sia a desktop che a mobile

2) Troppo JavaScript (e troppi plugin)

Il JavaScript può ritardare quanto rapidamente una pagina diventa utilizzabile. Anche se la pagina “si vede”, può risultare lenta mentre gli script si scaricano, parsano ed eseguono.

Gli script di terze parti sono spesso i peggiori: widget di chat, popup, heatmap, tool di A/B testing, tag pubblicitari e embed social. Ognuno può aggiungere chiamate di rete extra e può ritardare lavori critici del browser.

3) Hosting lento o lavoro server pesante

A volte il browser aspetta il server prima di poter iniziare a caricare la pagina. Questo si percepisce come una risposta iniziale lenta (TTFB). Cause comuni: hosting sottodimensionato, database occupati, temi/plugin non ottimizzati o pagine costruite dinamicamente a ogni visita.

4) Nessuna cache + troppe richieste

Se il sito obbliga ogni visita a partire da zero, i visitatori di ritorno ne risentono. Senza caching, il server ricostruisce le pagine e il browser riscarica file che raramente cambiano.

Inoltre, molti file piccoli (font, script, stili, tracker) creano “overhead di richieste”. Anche se ogni file è piccolo, il tempo di attesa combinato cresce.

La buona notizia: queste cause sono correggibili—e di solito ottieni i maggiori guadagni affrontandole in quest’ordine.

Immagini: la vittoria di velocità più rapida e affidabile

Se devi fare una sola cosa per le prestazioni, fallo sulle immagini. Su molti siti per principianti, le immagini rappresentano la maggior parte del “peso” scaricato della pagina—soprattutto su mobile. La parte positiva: le correzioni sulle immagini sono solitamente sicure, rapide e non richiedono di cambiare il design.

1) Ridimensiona le immagini alla dimensione visualizzata

Un errore comune è caricare una foto enorme (es. 4000px) e mostrarla a 800px. Il browser scarica comunque il file grande.

Esporta le immagini vicino alla dimensione massima a cui appariranno realmente. Ad esempio, se l’area dei contenuti del blog è larga 800px, non caricare immagini da 3000–4000px “per sicurezza”.

2) Usa formati moderni (WebP/AVIF) quando possibile

JPEG e PNG funzionano ancora, ma i formati moderni spesso offrono la stessa qualità visiva a dimensioni molto inferiori.

• WebP è ampiamente supportato ed è una buona scelta di default.
• AVIF può essere ancora più leggero, ma la codifica è più lenta e il supporto varia.

Se il tuo CMS o plugin immagini può servire automaticamente WebP/AVIF con fallback, è l’ideale.

3) Comprimi le immagini e rimuovi i metadata inutili

La compressione è dove avvengono la maggior parte dei guadagni immediati. Un’immagine “visivamente identica” può spesso essere ridotta del 30–70%.

Rimuovi anche i metadata non necessari (info della fotocamera, dati di posizione). Non cambiano l’aspetto dell’immagine, ma aggiungono byte.

Regola pratica: comprimi finché noti un calo visibile di qualità, quindi torna indietro di un livello.

4) Usa immagini responsive (srcset) per mobile vs desktop

Gli utenti mobile non dovrebbero scaricare immagini per desktop. Le immagini responsive permettono al browser di scegliere la dimensione giusta in base alla larghezza dello schermo.

Se il tuo sito genera più dimensioni automaticamente, assicurati che il tema le usi correttamente. Cerca nell’HTML della pagina qualcosa come srcset (più versioni) invece di un unico file enorme.

Checklist rapida

Prima di passare ad ottimizzazioni più avanzate (come minificare il codice), controlla le immagini principali:

• Sono dimensionate per dove appaiono?
• Sono servite come WebP/AVIF quando possibile?
• Sono compresse in modo sensato?
• I dispositivi mobili ricevono versioni più piccole?

Fai queste quattro cose con costanza e la velocità del tuo sito e i tempi di caricamento miglioreranno di solito immediatamente—spesso abbastanza da muovere i Core Web Vitals nella direzione giusta.

Lazy loading e priorità above-the-fold

Il lazy loading significa che la pagina ritarda il download di alcune immagini (e a volte iframe) finché non sono vicino a comparire sullo schermo. Questo può ridurre il caricamento iniziale perché il browser non cerca di prendere tutto subito—utile su pagine lunghe con molte immagini sotto la piega.

Quando il lazy loading aiuta

Il lazy loading è più utile per:

• Griglie di prodotti, post del blog e landing page con molto contenuto sotto la prima schermata
• Video/incorporamenti di mappe non immediatamente necessari
• Visitatori mobile su connessioni lente

Usato bene, riduce il lavoro iniziale e aiuta la pagina a sembrare più veloce.

Non fare lazy-load dell’hero (proteggi l’LCP)

La tua immagine più grande above-the-fold è spesso l’hero. Se la carichi in lazy, il browser potrebbe aspettare troppo a richiederla, danneggiando la Largest Contentful Paint (LCP).

Regola pratica: mai fare lazy-load dell’immagine hero o di qualsiasi elemento critico nella prima schermata (immagine del titolo, foto principale del prodotto, banner top).

Previeni i layout shift con width/height

Il lazy loading può far “saltare” il layout quando le immagini compaiono. Per evitare layout shift (CLS), riserva sempre lo spazio:

• Imposta width e height sulle immagini, oppure
• Usa CSS con un rapporto d’aspetto fisso

In questo modo il layout resta stabile mentre le immagini si caricano.

Preload di ciò che conta davvero

Se un’immagine o un font above-the-fold è essenziale per la prima impressione, considera di preloadarlo in modo che il browser lo prenda subito. Usa il preload con parsimonia—preloadare troppo può avere l’effetto contrario competendo per la banda.

Se vuoi un approccio checklist, abbina questo al passo di misurazione in blog/how-to-measure-site-speed-before-you-change-anything.

Fondamenti di caching: rendi le visite ripetute molto più rapide

La cache è il modo del browser per dire: “Ho già scaricato questo—posso riutilizzarlo?” Invece di riscaricare logo, CSS o bundle JavaScript a ogni visualizzazione, il browser conserva una copia locale per un po’. Questo rende le visite successive notevolmente più veloci e riduce l’uso di dati—soprattutto su mobile.

Caching del browser, in parole semplici

Quando il tuo sito invia un file (come styles.css o app.js), può anche inviare istruzioni su quanto tempo quel file può essere riutilizzato. Se al browser è permesso conservarlo, per esempio, 30 giorni, alla visita successiva quei file si caricano istantaneamente dal dispositivo invece che dal server.

Questo non accelera la prima visita, ma può velocizzare molto:

• La seconda pagina che un utente clicca
• Le visite ripetute nei giorni/settimane successivi
• Utenti con connessioni instabili

Imposta intestazioni di cache per i file “statici”

I file statici sono cose che non cambiano ogni minuto: immagini, CSS, JavaScript, font. Sono candidati perfetti per tempi di cache più lunghi.

Concettualmente desideri:

• CSS/JS/immagini: cache lunga (settimane/mesi)
• Pagine HTML: cache con attenzione (spesso breve), perché i contenuti possono cambiare

Il tuo host, CMS o framework potrebbe offrire un’opzione semplice per “static asset caching”. Se lavori con uno sviluppatore, chiedi di impostare intestazioni Cache-Control appropriate per gli asset.

Usa nomi di file versionati così gli aggiornamenti non restano bloccati

Una preoccupazione comune è: “Se cacheiamo i file per un mese, come fanno gli utenti a ottenere l’aggiornamento domani?” La soluzione sono i nomi di file versionati.

Invece di riutilizzare app.js per sempre, il processo di build (o lo sviluppatore) può generare qualcosa come:

• app.3f2a1c.js
• styles.a81b09.css

Quando il contenuto cambia, cambia anche il nome del file, quindi il browser lo scarica immediatamente—pur mantenendo la cache delle versioni vecchie al sicuro.

Nota sui service worker (avanzato)

I service worker possono portare il caching oltre, permettendo al sito di controllare cosa conservare e quando, abilitando a volte comportamenti offline. Possono però causare problemi di “contenuto obsoleto” se implementati male. Se sei un principiante, considera i service worker come un’opzione avanzata—ottimi quando hai obiettivi chiari e qualcuno esperto che li mantenga.

CDN spiegato: quando aiutano (e quando no)

Un CDN (Content Delivery Network) è un insieme di server distribuiti in diverse regioni che possono consegnare i file del tuo sito da una posizione più vicina al visitatore. Invece di far viaggiare ogni richiesta fino al tuo server singolo, molte richieste sono gestite “vicino a loro”.

Cosa fa realmente un CDN

I CDN sono ottimi per velocizzare gli asset statici—cose che non cambiano a ogni richiesta—come immagini, CSS, JavaScript, font e video. Questi file possono essere copiati sui server del CDN e riutilizzati per molti visitatori.

Chi ne beneficia di più: siti con visitatori in più città/paesi, siti ricchi di media e attività di marketing con traffico da tutto il mondo.

Come i CDN riducono la latenza per visitatori globali

La distanza aggiunge ritardo. Se il tuo server è in un paese e il visitatore in un altro continente, ogni richiesta impiega più tempo. Un CDN riduce quel ritardo servendo file da un edge server più vicino al visitatore, migliorando di solito il tempo di caricamento e aiutando i Core Web Vitals—specialmente su connessioni mobile.

Asset statici vs pagine dinamiche

• Asset statici: ottimi per il CDN. Cacheali aggressivamente.
• Pagine dinamiche (carrello, area account): spesso non possono essere cacheate in modo sicuro, o solo in parte. Alcuni CDN offrono “dynamic acceleration”, ma è più avanzato e non sempre utile.

Insidie comuni da monitorare

Intestazioni di cache mal configurate possono impedire la cache del tutto (o fare il contrario, ossia cacheare troppo). Il problema opposto è la cache obsoleta: aggiorni un file ma i visitatori vedono ancora la versione vecchia. Per evitarlo, usa nomi di file con cache-busting (es. app.1234.js) e impara la funzione di “purge” del tuo CDN.

Un CDN non sostituisce la correzione di immagini pesanti, script gonfi o hosting lento—ma può essere un forte moltiplicatore quando le basi sono a posto.

Riduci CSS e JavaScript senza rompere il sito

CSS e JavaScript sono spesso il “peso invisibile” che rallenta una pagina. A differenza delle immagini, il problema non è sempre visibile—but il browser deve comunque scaricare, parsare ed eseguire questi file prima che la pagina risulti pronta.

Minifica CSS e JavaScript (cosa cambia e cosa no)

La minificazione rimuove spazi extra, commenti e formattazione. Di solito riduce le dimensioni dei file e accelera il download.

Cosa cambia: la dimensione del file.

Cosa non cambia: quanto lavoro il browser deve fare per parsare ed eseguire il codice. Se i tuoi script fanno troppo al caricamento, la minificazione non risolverà quel problema—quindi considera la minify come una vittoria rapida, non una soluzione completa.

Rimuovi il CSS inutilizzato e invia solo ciò che la pagina richiede

Molti siti caricano un foglio di stile “one size fits all” che include regole per pagine e componenti che la pagina corrente non usa. Quel CSS in più viene comunque scaricato e può rallentare il rendering.

Un approccio pratico:

• Se usi un page builder o un tema grande, cerca opzioni come “load assets per page” o “only load used CSS”.
• Se hai uno sviluppatore, chiedi del “critical CSS” (stili minimi necessari per la prima schermata) e del caricamento ritardato del resto.

L’obiettivo è semplice: la homepage non dovrebbe portare il peso dell’intero sito.

Defer o async per JavaScript non critico

Alcuni script bloccano la pagina dall’essere interattiva perché il browser si ferma per eseguirli.

• defer è solitamente la scelta migliore per i tuoi script che possono aspettare che l’HTML sia parsato.
• async è migliore per script indipendenti (spesso di terze parti) che non dipendono da altro codice.

Se non sei sicuro, comincia deferendo tutto ciò che non è richiesto per la prima schermata (menu, animazioni, slider, tracking extra).

Limita librerie pesanti e framework ingombranti quando possibile

Librerie grandi possono aggiungere centinaia di KB (o più). Prima di aggiungere un plugin o un framework, chiediti:

• La funzione può essere fatta con codice più semplice?
• Posso rimuovere una libreria usata solo in una pagina?

Meno script significano meno sorprese—soprattutto per le prestazioni mobile, dove il tempo CPU conta tanto quanto la dimensione del download.

Script di terze parti: piccoli widget, grandi rallentamenti

Gli script di terze parti sono tutto ciò che il tuo sito carica dai server di un’altra azienda. Sono popolari perché aggiungono funzionalità rapidamente—ma possono anche essere alcune delle cause più grandi e imprevedibili di rallentamenti.

Colpevoli comuni (e perché fanno male)

Molti rallentamenti provengono da categorie come:

• Analytics e tracking (Google Analytics, pixel, tag manager)
• Widget di chat (live chat, chatbot)
• Pubblicità e retargeting (network pubblicitari, header bidding)
• Embed (video YouTube, post social, mappe, widget recensioni)

Questi script spesso scaricano file extra, eseguono molto JavaScript e a volte bloccano il browser dal finire il caricamento della pagina.

Come individuare “long tasks” e script che bloccano

Apri Chrome DevTools → Performance, registra un caricamento della pagina e cerca:

• Long tasks (blocchi lunghi sul main thread). Di solito significano che JavaScript tiene la pagina dal rispondere.
• Script che girano presto (prima di poter scrollare o cliccare) e ritardano il rendering.

Puoi anche eseguire Lighthouse (Chrome DevTools → Lighthouse) e controllare le raccomandazioni relative a “Reduce JavaScript execution time” e “Eliminate render-blocking resources.”

Rendi meno dannosi gli script di terze parti

Alcune vittorie facili per principianti:

• Carica dopo l’interazione quando possibile: non inizializzare chat, recensioni o embed video fino a quando l’utente non clicca, scorre o apre un pannello.
• Ritarda i tag non essenziali: se uno script non serve per la prima vista, non eseguirlo nel momento critico di caricamento.

Sostituisci embed pesanti con anteprime leggere

Invece di caricare un embed completo di YouTube/Facebook/Map alla prima vista, mostra un’anteprima semplice (thumbnail + pulsante play). Carica il vero embed solo quando l’utente clicca.

Questo mantiene la pagina veloce per tutti—soprattutto su mobile—senza togliere la funzionalità.

Hosting e prestazioni server: il TTFB in parole semplici

TTFB (Time to First Byte) è il tempo che impiega il server a iniziare a rispondere dopo che il browser ha richiesto una pagina. Pensalo come “quanto tempo prima che la cucina inizi a cucinare”, non quanto tempo prima che il pasto sia servito.

Un sito bello può comunque sembrare lento se il TTFB è alto—soprattutto su reti mobili dove ogni ritardo è più evidente.

Cosa rallenta tipicamente il TTFB

Il TTFB riguarda principalmente il lavoro server-side prima che venga inviato qualcosa:

• Tempo di elaborazione server: il codice del sito deve girare, costruire la pagina e assemblare la risposta.
• Ritardi del database: ogni query (soprattutto molte piccole) aggiunge tempo.
• Cache miss: se nulla è cacheato, il server deve fare la “build completa” per ogni richiesta.

Anche se immagini e script sono ottimizzati, una risposta server lenta può lasciare il browser a guardare uno schermo vuoto.

La vittoria più semplice: caching server-side per pagine dinamiche

Se il tuo sito è costruito con un CMS o genera pagine dinamicamente, il caching lato server è spesso l’improvviso miglioramento più grande per il TTFB. Invece di ricostruire la stessa pagina per ogni visitatore, il server può conservare una versione pronta da servire.

Esempi pratici:

• Cachea post del blog e pagine marketing che non cambiano ogni minuto.
• Usa il page caching o “full-page cache” dove la piattaforma lo supporta.
• Se gestisci un negozio o un sito con area personale, cachea ciò che puoi (pagine di categoria, pagine non loggate) e sii selettivo per le pagine personalizzate.

Non dimenticare la compressione (Brotli/Gzip)

Abilita Brotli (preferito) o Gzip per file testuali come HTML, CSS e JavaScript. Questo riduce la quantità di dati da trasferire, migliorando la velocità percepita—specialmente per caricamenti ripetuti e utenti mobile.

Quando passare a un hosting migliore

Un hosting migliore può ridurre il TTFB, ma è più intelligente risolvere prima i problemi front-end evidenti (immagini enormi, troppi script di terze parti, JavaScript pesante). Se il browser scarica megabyte di roba, un hosting più veloce non farà sembrare la pagina veramente rapida.

Una volta risolte le basi, l’upgrade dell’hosting (più CPU/RAM, database ottimizzato, runtime migliore) può essere il passo finale che rende il sito costantemente reattivo.

Se stai costruendo un nuovo prodotto e vuoi meno variabili di hosting fin da subito, considera una piattaforma managed che incorpora default sensati. Per esempio, Koder.ai ospita app su AWS globalmente e supporta deploy, domini custom e rollback degli environment—utile quando testi cambi di performance across regioni o hai requisiti di residenza dei dati.

Un piano pratico di 1 settimana per principianti

Non serve un progetto enorme per migliorare la velocità. Serve un ordine di operazioni semplice, un modo per confermare di non aver peggiorato le cose e la preferenza per correzioni che riducono davvero il tempo di caricamento.

Ordine per 1 settimana: misura → immagini → caching → riduci JavaScript

Giorno 1: misura (prima di toccare nulla).

Scegli 2–3 pagine importanti (homepage, landing principale, post del blog/prodotto popolare). Esegui:

• PageSpeed Insights (concentrati sui Core Web Vitals)
• Chrome DevTools Lighthouse

Annota la baseline per mobile e desktop. Se puoi, testa anche su un telefono reale (anche il tuo) in 3G/4G — spesso rivela problemi che i test di laboratorio non mostrano.

Giorni 2–3: sistema le immagini (la vittoria più rapida e affidabile).

Priorità:

• Comprimi immagini grandi e servi formati moderni quando possibile (WebP/AVIF)
• Ridimensiona le immagini alla dimensione massima in cui sono effettivamente mostrate
• Assicurati che l’immagine principale “hero” venga caricata velocemente

Ritesta dopo aver aggiornato solo alcune immagini per vedere l’effetto.

Giorni 4–5: sistema il caching (rendere le visite ripetute molto più veloci).

Abilita il caching del browser e il caching server/pagina dove appropriato. L’obiettivo è: non rigenerare o riscaricare gli stessi asset a ogni visita. Dopo aver abilitato la cache, verifica che il ritorno sulla pagina sia notevolmente più veloce.

Giorni 6–7: riduci JavaScript (spesso il guadagno più grande a lungo termine).

Cerca:

• Plugin/caratteristiche non usate (rimuovile invece di “ottimizzarle”)
• Slider/animazioni pesanti che non aiutano le conversioni
• Tag di tracking extra che non servono più

Piccoli cambiamenti qui possono migliorare molto l’interattività e i Core Web Vitals, specialmente su mobile.

Controlli di regressione semplici dopo ogni modifica

Dopo ogni modifica importante (immagini, caching, script), fai tre controlli rapidi:

1. Esegui gli stessi test sulle stesse pagine e confronta i numeri con la baseline del Giorno 1.
2. Naviga il sito come un visitatore (form, checkout, menu). I miglioramenti di velocità non valgono se rompono l’usabilità.
3. Controlla prima il mobile: se è veloce solo su desktop, non è veramente veloce.

Quando chiedere aiuto

Se hai ottimizzato immagini e caching e vedi ancora TTFB persistentemente alto, di solito è l’hosting/configurazione server, un database lento o lavoro backend pesante. Considera aiuto anche se il sito è una app complessa (siti a membership, marketplace, molta personalizzazione) dove “cache everything” non è semplice.

Se vuoi una guida più approfondita sul tempo di risposta del server, vedi blog/ttfb-explained.