Caso studio · Performance · Wonder Channel
Un sito più veloce non serve a vincere un test. Serve a far aspettare meno le persone.
In questo progetto ho lavorato sulle performance del magazine Wonder Channel intervenendo su richieste HTTP, file CSS e JavaScript, immagini, compressione e caricamento delle risorse. Dopo gli interventi ho osservato anche miglioramenti su alcune keyword importanti, ma la velocità non era l’unica attività SEO in corso.
Ridurre il peso e i tempi di caricamento del sito senza trattare il punteggio di un tool come un obiettivo fine a se stesso.
Soglia “buona” attuale.
Risposta alle interazioni.
Stabilità visiva.
Il progetto
Il problema non era ottenere 100 su PageSpeed Insights. Era rendere il magazine più rapido e stabile.
Wonder Channel è un magazine ricco di immagini, articoli e risorse. Una struttura di questo tipo può accumulare facilmente CSS, JavaScript, immagini pesanti, richieste di rete e script di terze parti.
Nel progetto originale avevo concentrato il lavoro sulla riduzione delle richieste HTTP, sulla minimizzazione dei file, sul caricamento asincrono delle risorse, sull’ottimizzazione delle immagini e sulla compressione.
Oggi aggiungerei una precisazione importante.
La performance va misurata dal punto di vista dell’utente. Un punteggio di laboratorio aiuta a trovare problemi, ma ciò che succede su dispositivi e connessioni reali può essere diverso.
Un sito può ottenere un buon voto in laboratorio e offrire comunque un’esperienza mediocre ad alcuni utenti. Per questo oggi guarderei sempre insieme dati reali, Core Web Vitals e diagnostica tecnica.
Core Web Vitals nel 2026
Tre metriche per leggere caricamento, interattività e stabilità.
I Core Web Vitals attuali sono LCP, INP e CLS. Google consiglia di valutare queste soglie al 75° percentile delle visite, separando mobile e desktop.
LCP
Misura quanto tempo impiega a comparire il contenuto principale più grande visibile nella viewport. Può peggiorare per server lento, immagini hero pesanti, risorse bloccanti o caricamento tardivo dell’elemento principale.
INP
Misura la reattività alle interazioni. JavaScript eccessivo, task lunghi sul main thread e componenti complessi possono far percepire il sito come lento anche dopo che la pagina è già visibile.
CLS
Misura gli spostamenti inattesi del layout. Immagini senza dimensioni, banner inseriti dopo il caricamento, font e contenuti dinamici possono far saltare testi e pulsanti mentre l’utente sta leggendo.
Puoi approfondire le soglie nella documentazione ufficiale Web Vitals di Google →
Il lavoro tecnico
Ridurre il tempo perso tra richiesta della pagina e possibilità di usarla.
La velocità percepita dipende da più passaggi. Per questo non basta installare un plugin di cache e considerare il lavoro finito.
Server e TTFB
Hosting, cache, CDN e tempi di risposta iniziali possono condizionare ciò che avviene dopo.
Risorse critiche
CSS e JavaScript bloccanti possono ritardare il rendering del contenuto visibile.
Immagini
Dimensioni, compressione, formati moderni e priorità di caricamento incidono molto sulle pagine visuali.
JavaScript
Script pesanti e task lunghi possono peggiorare la reattività e quindi l’INP.
Stabilità
Spazi riservati a immagini, embed e banner aiutano a evitare spostamenti del layout.
Le immagini del progetto
Test, performance e risultati osservati sul magazine.
Ho mantenuto le immagini disponibili nel vecchio caso studio, senza duplicarle.
Come misurerei oggi il progetto
Dati di laboratorio e dati reali rispondono a domande diverse.
PageSpeed Insights può mostrare dati di laboratorio generati da Lighthouse e, quando disponibili, dati reali provenienti dal Chrome UX Report.
Lighthouse
Simula il caricamento in condizioni controllate. È molto utile per diagnosticare risorse bloccanti, JavaScript pesante, immagini, main thread e altre opportunità tecniche. Il risultato può cambiare tra un test e l’altro e non rappresenta da solo l’esperienza di ogni utente.
CrUX
Raccoglie dati anonimizzati da utenti Chrome reali quando esiste un campione sufficiente. PageSpeed Insights usa una finestra mobile di 28 giorni per mostrare LCP, INP e CLS sul campo.
Per controllare una pagina userei prima Google PageSpeed Insights → e poi approfondirei i problemi con Lighthouse, Search Console e gli strumenti del browser.
Cosa ottimizzerei oggi
La lista è più ampia di “minificare CSS e JavaScript”.
LCP e risorsa hero
Verificherei quale elemento genera l’LCP, quando viene scoperto dal browser, il peso dell’immagine e l’eventuale presenza di CSS o richieste che ne ritardano il rendering.
JavaScript e INP
Riduzione degli script non necessari, suddivisione dei task lunghi e controllo degli script di terze parti che occupano il main thread durante le interazioni.
Immagini e media
Dimensioni corrette, compressione, formati moderni, responsive images e lazy loading per ciò che si trova fuori dalla prima schermata, evitando di ritardare l’immagine LCP.
CLS e layout
Dimensioni dichiarate per immagini ed embed, spazi riservati agli elementi dinamici e controllo del caricamento dei font per ridurre spostamenti inattesi.
Cache, CDN e backend
Analisi di TTFB, cache delle pagine e degli oggetti, database, CDN e configurazione server quando la risposta iniziale rallenta l’intera catena.
Terze parti
Tag marketing, chat, video, advertising e widget possono pesare molto. Li valuterei in base al valore che producono e al costo in termini di performance.
Performance e SEO
I Core Web Vitals contano. Ma non sostituiscono pertinenza e qualità del contenuto.
Nel vecchio caso studio avevo scritto che la velocità era il fattore di ranking più importante. Oggi non lo scriverei.
Contenuto
La pagina deve prima rispondere bene alla ricerca e avere un motivo per essere mostrata.
Esperienza
Google considera segnali legati alla page experience, tra cui i Core Web Vitals.
Performance
Una pagina rapida e stabile riduce frizioni per chi legge, naviga o interagisce.
Misurazione
Un punteggio perfetto non garantisce la prima posizione e non dovrebbe diventare l’unico obiettivo.
Priorità
Gli interventi vanno scelti in base ai problemi reali della pagina e al loro impatto sugli utenti.
È anche la posizione espressa oggi da Google nella documentazione sulla page experience →
Cosa insegna questo progetto
Tre lezioni che terrei anche oggi.
La performance è esperienza utente prima che SEO
Se una pagina carica lentamente, risponde tardi o si sposta mentre la persona sta interagendo, il problema esiste anche senza pensare a Google.
I dati reali contano più del numero verde in un test
Lighthouse è prezioso per diagnosticare. CrUX e i Core Web Vitals sul campo aiutano invece a capire come stanno vivendo il sito gli utenti reali.
Un miglioramento SEO non va attribuito automaticamente alla velocità
Nel caso Wonder Channel alcune keyword migliorarono dopo gli interventi, ma erano presenti anche altre attività SEO. Il dato è interessante senza trasformarlo in una causalità che non possiamo dimostrare.
Una precisazione sul vecchio caso studio
Nel 2026 lo racconterei in modo diverso rispetto al 2023.
La velocità resta importante. Ma oggi separerei nettamente tre concetti: performance tecnica, esperienza reale degli utenti e ranking.
Google conferma che i Core Web Vitals vengono utilizzati dai suoi sistemi di ranking, ma chiarisce anche che una buona page experience comprende più aspetti e che ottenere ottimi punteggi non garantisce di apparire ai primi posti.
Per questo questo caso studio non vuole dimostrare che “un sito veloce sale automaticamente su Google”. Mostra invece il lavoro necessario per rendere un sito più rapido e il miglioramento SEO osservato nello stesso periodo.
Se vuoi capire se performance e problemi tecnici stanno limitando il tuo sito puoi partire da una analisi del sito web →
Vuoi vedere gli altri progetti?
Vai a tutti i casi studio →Vuoi approfondire il lavoro SEO?
Vai alla consulenza SEO →Il tuo sito è lento?
Prima misuriamo dove perde tempo. Poi decidiamo cosa vale la pena ottimizzare.
Possiamo controllare Core Web Vitals, PageSpeed, risorse, immagini, JavaScript, server e comportamento reale delle pagine per individuare le priorità.