Come rendere il tuo sito web più veloce: checklist pratica

Per rendere un sito più veloce, misuralo prima con PageSpeed Insights, poi correggi la causa principale che indica — di solito immagini troppo grandi, troppo JavaScript, font pesanti o script di terze parti. Punta agli obiettivi "buoni" dei Core Web Vitals di Google: contenuto principale visibile entro 2,5 secondi, risposta ai tocchi entro 200 millisecondi e quasi nessun salto del layout. La maggior parte dei siti ci arriva con una manciata di modifiche, non con una riscrittura.

Misura prima di cambiare qualsiasi cosa

Indovinare fa perdere tempo. Due strumenti gratuiti coprono quasi tutti i casi:

PageSpeed Insights (pagespeed.web.dev) — incolli un URL attivo. Mostra i dati sul campo di utenti Chrome reali (se il sito ha abbastanza traffico) e i dati di laboratorio di un caricamento simulato, più un elenco di problemi specifici.
Lighthouse negli strumenti per sviluppatori di Chrome — lo stesso test di laboratorio, eseguibile su qualsiasi pagina che puoi aprire, anteprima compresa. Esegui il test in modalità mobile; i telefoni con reti più lente sono dove i problemi emergono.

I numeri che contano sono i Core Web Vitals di Google. Ad oggi (settembre 2026), la documentazione di Google su web.dev indica queste soglie "buone", misurate al 75° percentile dei caricamenti di pagina:

Metrica	Cosa misura	Buono
Largest Contentful Paint (LCP)	Quanto presto compare il contenuto principale (immagine principale, titolo)	2,5 s o meno
Interaction to Next Paint (INP)	Quanto rapidamente la pagina reagisce a clic, tocchi e digitazione	200 ms o meno
Cumulative Layout Shift (CLS)	Quanto si sposta il layout durante il caricamento	0,1 o meno

INP ha sostituito la vecchia metrica First Input Delay nel 2024. Se uno strumento riporta ancora FID, è obsoleto.

Annota i valori di partenza. Dopo ogni correzione, ripeti il test così sai cosa ha aiutato.

Dove se ne va il tempo: opzioni e compromessi

Ogni causa comune ha una soluzione, e ogni soluzione ha un costo. Parti da quelle in cima: sono le più economiche e le più frequenti.

Causa	Correzione tipica	Compromesso
Immagini grandi	Ridimensionale alla dimensione visualizzata, comprimi, usa WebP o AVIF	Lieve perdita di qualità se compresse troppo
Immagini caricate nell'ordine sbagliato	Lazy-load per le immagini sotto la piega; dai priorità alta all'immagine principale	Nessuno, se l'immagine principale non è lazy
Troppo JavaScript	Dividi il codice per pagina, rimuovi le librerie inutilizzate	Un po' di refactoring
Rendering solo lato client	Prerenderizza o renderizza lato server le pagine pubbliche	Più configurazione di build o server
Font web	Meno famiglie e pesi, precarica quello principale, `font-display: swap`	Meno varietà tipografica
Script di terze parti	Rimuovi quelli inutilizzati, carica gli altri dopo la pagina	Perdere un widget o un tracker
Risposta lenta del server	Cache, una CDN, hosting statico per le pagine di contenuto	Da considerare l'invalidazione della cache

Immagini

Le immagini sono il problema più comune e il più facile da risolvere. Una foto di 4.000 pixel mostrata a 800 pixel di larghezza costringe ogni visitatore a scaricare cinque volte più di ciò che vede.

Servi le immagini alla dimensione con cui vengono visualizzate, con dimensioni srcset responsive per telefoni e desktop.
Usa formati moderni (WebP o AVIF) e una compressione sensata.
Imposta width e height su ogni immagine così il browser riserva lo spazio. Questo da solo risolve la maggior parte dello spostamento del layout.
Applica il lazy-load alle immagini sotto la piega con loading="lazy".
Non applicare mai il lazy-load all'immagine principale in cima alla pagina. La guida di Google sull'LCP è categorica: il lazy-load dell'immagine LCP la ritarda sempre. Usa invece fetchpriority="high".

JavaScript

Molti siti costruiti con l'AI sono single-page app (SPA): il browser scarica un bundle JavaScript e solo dopo disegna la pagina. Più grande è il bundle, più lunga è la schermata bianca. Le soluzioni, in ordine di sforzo:

Rimuovi ciò che non usi. Chiedi un elenco delle dipendenze ed elimina le librerie aggiunte una volta e dimenticate — una libreria di date per una sola data, un intero pacchetto di icone per cinque icone.
Dividi per percorso. Carica il codice della dashboard di amministrazione solo quando qualcuno la apre, non nella home page.
Prerenderizza le pagine pubbliche. Una pagina di marketing che arriva come HTML reale appare prima che parta qualsiasi JavaScript. Questo aiuta anche i motori di ricerca; vedi SEO per siti web costruiti con l'AI.

Un INP lento di solito significa un'attività lunga che blocca la pagina — filtrare un elenco enorme a ogni pressione di tasto, o ridisegnare un'intera tabella quando cambia una cella. Il pannello Performance degli strumenti per sviluppatori di Chrome mostra quale.

Font

Ogni famiglia di font e ogni peso è un altro file. Due famiglie e tre o quattro pesi di solito bastano. Precarica il font usato sopra la piega, usa font-display: swap così il testo appare subito, e ospita i font da te se il servizio di font esterno è lento per i tuoi visitatori.

Script di terze parti

Widget di chat, analytics, mappe di calore, pixel pubblicitari, video incorporati e feed social caricano codice da altri server. Ognuno sembra piccolo; insieme spesso sono la parte più lenta della pagina. Tieni quelli che guardi davvero. Carica gli altri dopo che la pagina è interattiva, e sostituisci gli incorporamenti pesanti (un player YouTube, una mappa) con un'anteprima leggera che carica quello vero al clic.

Risposta del server

Il Time to First Byte (TTFB) — quanto impiega il server a iniziare a rispondere — sta sotto tutte le altre metriche. Le pagine statiche servite da una CDN (una rete di server vicini ai tuoi visitatori; vedi cos'è una CDN) sono veloci quasi ovunque. Le pagine costruite da un server a ogni richiesta dipendono da quel server e dal suo database. La cache del lavoro ripetuto e gli indici del database per le query lente sono le soluzioni tipiche.

Prompt che funzionano

Sii specifico: indica la pagina, la metrica e il vincolo. Incolla i risultati di PageSpeed Insights se li hai.

PageSpeed Insights segnala un LCP di 4,8 s su mobile per la home page, e l'elemento LCP è l'immagine principale. Ridimensiona e converti in WebP l'immagine principale, servi dimensioni responsive, imposta width e height, dai fetchpriority="high" e assicurati che non sia lazy-loaded. Applica il lazy-load a ogni immagine sotto la piega. Non cambiare il design.

Verifica le dipendenze di questa app. Elenca ogni pacchetto, cosa lo usa e più o meno quanto aggiunge al bundle. Rimuovi quelli inutilizzati e dividi le rotte /admin e /settings in blocchi separati che si caricano solo quando visitate.

La casella di ricerca su /products sembra lenta. Applica un debounce al filtro, evita di ridisegnare l'intero elenco a ogni pressione di tasto e impagina o virtualizza l'elenco se ha più di 200 elementi.

Passo dopo passo

Testa la pagina attiva in PageSpeed Insights su mobile. Annota LCP, INP e CLS e i tre problemi principali elencati.
Correggi prima le immagini: dimensioni, formati, dimensioni dei dati, lazy-load sotto la piega, priorità per l'immagine principale.
Taglia gli script di terze parti che non usi, e rinvia gli altri.
Riduci i font a ciò che il design richiede.
Riduci il JavaScript: rimuovi i pacchetti inutilizzati, dividi per rotta.
Prerenderizza le pagine pubbliche se sono ancora renderizzate lato client e l'LCP è ancora lento.
Controlla il server: cache, indici del database, hosting statico per i contenuti che cambiano raramente.
Pubblica di nuovo e ripeti il test. I dati sul campo in PageSpeed Insights si aggiornano nelle settimane successive man mano che arrivano visite reali, quindi giudica i primi risultati dai dati di laboratorio.

Errori comuni

Testare solo su un laptop veloce. I tuoi visitatori usano telefoni di fascia media e connessioni mobili instabili. Testa in modalità mobile.
Inseguire un 100 perfetto. Il punteggio di laboratorio è una guida. Una volta che i Core Web Vitals sono nella fascia buona, contenuto e usabilità contano più degli ultimi punti.
Applicare il lazy-load a tutto, compresa l'immagine principale. Così l'LCP peggiora.
Aggiungere un plugin o una libreria per la velocità. Togliere peso batte quasi sempre aggiungere codice per gestirlo.
Ottimizzare l'anteprima, non il sito live. Le anteprime di sviluppo girano con build non ottimizzate. Misura l'URL pubblicato.
Sistemare la velocità una sola volta. Ogni nuovo widget, immagine e funzione aggiunge peso. Ripeti il test dopo le modifiche importanti.

Checklist della velocità

LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 su mobile
Immagini ridimensionate, compresse, in formato moderno, con width e height
Immagine principale senza lazy-load; immagini sotto la piega con lazy-load
Nessuna libreria JavaScript inutilizzata; rotte pesanti separate
Due famiglie di font o meno, font principale precaricato
Solo gli script di terze parti che usi davvero, caricati in ritardo
Pagine pubbliche prerenderizzate o statiche dove possibile
Ritestato sull'URL live dopo la pubblicazione

Velocità e layout mobile vanno di pari passo; vedi come rendere un sito web responsive per il mobile. Per un controllo completo prima del lancio, come portare un prototipo AI in produzione copre il resto.

La velocità su Mythex

Su Mythex fai queste modifiche chiedendole in chat, oppure nell'editor di codice con Pro. Controlla l'URL pubblicato, non l'Anteprima, perché l'Anteprima usa un server di sviluppo. I front-end statici vengono distribuiti come siti statici alla pubblicazione (siti statici), il che si adatta ai contenuti. Le app con un server si ridimensionano a zero: vanno in pausa quando sono inattive e si riattivano alla visita successiva, quindi la prima richiesta dopo un periodo di calma è più lenta, e un database collegato va in pausa dopo 5 minuti di inattività (limiti di hosting). Se una pagina pubblica è lenta solo alla prima visita, è la causa probabile. Tenere statiche le pagine di marketing aiuta. Dopo le modifiche, pubblica di nuovo e fai un aggiornamento forzato.

Domande

Qual è un buon tempo di caricamento della pagina?

I Core Web Vitals di Google danno gli obiettivi più chiari: il contenuto principale dovrebbe comparire entro 2,5 secondi (LCP), la pagina dovrebbe rispondere all'input entro 200 millisecondi (INP) e lo spostamento del layout dovrebbe restare a 0,1 o meno (CLS), misurati al 75° percentile delle visite reali.

La velocità del sito influisce sulla SEO?

Sì, un po'. Google usa segnali di esperienza di pagina tra cui i Core Web Vitals, ma i contenuti pertinenti contano molto di più. La velocità incide di più sui visitatori, che abbandonano le pagine lente prima di leggere qualcosa.

Perché il punteggio di PageSpeed Insights cambia ogni volta?

Il punteggio di laboratorio deriva da un singolo caricamento simulato, quindi i tempi di rete e del server variano tra un'esecuzione e l'altra. Esegui il test più volte e guarda l'andamento, e dai più peso alla sezione dei dati sul campo, che proviene da utenti Chrome reali.

Cosa rallenta di più la maggior parte dei siti?

Di solito immagini troppo grandi, troppo JavaScript, font web e script di terze parti come widget di chat, pixel pubblicitari e incorporamenti. Una risposta lenta del server o un backend che si avvia a freddo aggravano tutto il resto.