Pubblicato il 11 Gennaio 2026 · Aggiornato il 4 Ottobre 2026 · di Ismail Nasry

In breve: Un punteggio alto non spiega da solo perché una pagina è lenta. L'ottimizzazione SEO tecnica parte dai colli di bottiglia misurabili e dall'esperienza reale degli utenti.

Il punteggio non è la diagnosi

Un test di performance restituisce un numero. Quel numero orienta, ma non spiega che cosa rallenta una pagina. Non mostra nemmeno quali utenti siano più penalizzati.

La SEO tecnica non dovrebbe ridursi all’inseguimento di un punteggio. Il lavoro utile collega una misura a un problema osservabile. Per esempio, il contenuto principale appare tardi. Un’interazione risponde con ritardo. Il layout cambia. Oppure il server avvia la risposta troppo lentamente.

I Core Web Vitals aiutano a leggere questi problemi. Non sostituiscono l’analisi del percorso completo. Il percorso va dalla richiesta del documento al momento in cui l’utente può usare la pagina senza attriti.

Leggere le metriche come segnali

Ogni metrica descrive una parte dell’esperienza. L’LCP misura quando appare l’elemento principale. L’INP misura la reattività dopo un’interazione. Il CLS misura gli spostamenti inattesi del layout.

Le soglie “buone” indicate dalla documentazione ufficiale sono queste: LCP entro 2,5 secondi, INP entro 200 millisecondi e CLS fino a 0,1. La valutazione usa il 75° percentile delle visite e separa almeno dispositivi mobili e desktop. Le soglie “scarse” sono: oltre 4 secondi per LCP, oltre 500 millisecondi per INP e oltre 0,25 per CLS.

La distinzione più utile è tra segnale e causa. Una metrica fuori obiettivo dice che c’è un’esperienza da esaminare. Non indica da sola se la causa sia il server, JavaScript, un’immagine, un font, una pubblicità o una scelta di layout.

Conta anche il tipo di misurazione. Un test di laboratorio usa condizioni riproducibili. Serve a confrontare una modifica con la precedente. I dati sul campo mostrano invece il comportamento su dispositivi, reti e percorsi diversi. Le due prospettive possono divergere. È un’indicazione su dove approfondire.

Il rendering cambia il problema da risolvere

Prima di ottimizzare una pagina conviene capire come arriva il contenuto al browser.

Con il rendering lato server, una parte del documento può essere preparata prima della risposta. Con il rendering lato client, il browser deve eseguire codice e recuperare dati prima di completare l’interfaccia. Un approccio statico può consegnare risorse già pronte. I componenti dinamici possono richiedere richieste successive. Molti siti combinano queste modalità.

Questa distinzione non stabilisce quale architettura sia migliore. Aiuta a formulare ipotesi. Se il contenuto principale dipende da una lunga catena di script e richieste, il problema potrebbe essere nella sequenza di esecuzione. Se la risposta iniziale è lenta, l’indagine dovrebbe partire da server, dati e rete. Se la pagina cambia posizione, l’attenzione va a dimensioni riservate, font, immagini e componenti inseriti in ritardo.

La domanda operativa non è quindi “quale tecnologia usa il sito?”. È “quale passaggio impedisce all’utente di vedere o usare ciò che gli serve?”.

Un metodo per trovare il collo di bottiglia

Un audit utile parte da poche pagine rappresentative. Non serve iniziare da un elenco indistinto di URL. La selezione può includere una pagina informativa, una pagina con molte risorse e una pagina con interazioni rilevanti. La scelta dipende dalla struttura del sito e dall’azione che si vuole osservare.

Per ogni pagina, il percorso può seguire questo ordine:

1. Definire l’azione che conta. Leggere il contenuto, aprire un menu e inviare un modulo sono esigenze diverse. La performance va interpretata in relazione all’azione richiesta.
2. Separare il sintomo dalla causa. Un caricamento lento può dipendere dalla risposta iniziale, dalla scoperta delle risorse, dagli script o dal disegno.
3. Osservare la sequenza. La cascata delle richieste mostra risorse bloccanti, dipendenze inutili e file caricati troppo presto.
4. Misurare prima e dopo. Senza una condizione iniziale e una modifica isolabile, è difficile capire se l’intervento abbia risolto il problema.
5. Dare priorità all’impatto. Una correzione piccola su una pagina molto usata può valere più di una rifinitura su una pagina marginale.

Questo metodo non richiede di ottimizzare tutto insieme. Interventi simultanei su server, codice, immagini e layout rendono più difficile attribuire il risultato.

Scenario ipotetico: un punteggio alto con una pagina ancora scomoda

Immaginiamo una pagina aziendale che supera un test automatico. Su una rete mobile, però, il testo principale appare dopo una lunga attesa. Un banner viene inserito dopo il caricamento e sposta il contenuto.

Il team potrebbe ridurre ancora il peso delle immagini. Il collo di bottiglia principale, però, potrebbe essere nella risposta iniziale o nel componente dinamico.

Questo è uno scenario ipotetico. La lezione non è che una singola tecnica risolva ogni caso. Il punteggio va ricondotto a una sequenza concreta: che cosa vede l’utente, quando lo vede, con quale dispositivo e dopo quali richieste.

Schema markup e performance sono problemi diversi

Lo schema markup descrive le informazioni della pagina in un formato interpretabile dai sistemi che le elaborano. Può aiutare a comprendere il contenuto. Non rende però più veloce il rendering e non sostituisce l’analisi delle risorse.

Anche qui serve separare gli obiettivi. Se il problema riguarda un’entità o la struttura del contenuto, si valuta il markup pertinente e la sua correttezza. Se l’interfaccia è lenta, si analizzano risposta, risorse, script, immagini e layout. Aggiungere dati strutturati a una pagina con un percorso tecnico fragile non risolve quel percorso.

Quando fermarsi

Non ogni differenza misurata merita una riscrittura dell’architettura. Un intervento può aumentare la complessità, introdurre regressioni o rendere più difficile la manutenzione. Prima di procedere conviene stimare il beneficio atteso, il rischio e la capacità del team di verificare il risultato.

Le soglie e le indicazioni dei motori di ricerca possono cambiare. Anche strumenti, browser, dispositivi e reti evolvono. Un audit non dovrebbe quindi essere una fotografia definitiva. Un risultato positivo non dovrebbe diventare una promessa di posizionamento.

La decisione tecnica migliore spesso elimina il collo di bottiglia più rilevante con il minor aumento di complessità. Il punteggio resta utile come segnale. La diagnosi nasce dal rapporto tra metrica, percorso dell’utente e causa verificabile.