La pagina lenta che conta non è la homepage

Riepilogo

Quando il tuo capo dice che il sito è lento, l'istinto è iniziare a comprimere le immagini e a scusarti con la homepage. La mossa più utile è decidere quale pagina vale davvero la pena velocizzare per prima. Questo articolo illustra un singolo scenario: un piccolo team di marketing a cui è stato chiesto di "sistemare la velocità" per un sito B2B di medie dimensioni. Copre la misurazione dei Core Web Vitals con dati sul campo, la scelta delle pagine in base all'impatto sul business e l'aggiunta di dati strutturati solo dopo le correzioni a basso costo. Il risultato è un piano breve e difendibile che ha senso anche per un capo non tecnico.

La pagina più lenta del tuo sito non è quella che PageSpeed Insights segnala. È la pagina che il tuo capo non ha mai aperto—quella legata a una campagna a pagamento, o sepolta in una sezione di prodotto dimenticata—ed è quella che determina davvero se il budget di questo mese produce qualcosa. Quando un dirigente dice "il sito è lento, sistematelo", non ha bisogno di un progetto di velocizzazione del sito. Ha bisogno di un esercizio di priorità.

Prendiamo uno scenario che molti di noi hanno vissuto. Sei l'intero team di marketing di una software house B2B di medie dimensioni. Il sito ha una homepage, un blog, un centro assistenza e cinque landing page legate a campagne pubblicitarie specifiche. Il tuo capo ha letto un articolo sui Core Web Vitals o ha sentito un reclamo da un cliente. L'istruzione è chiara: rendilo più veloce.

Il modo in cui rispondi nell'ora successiva decide se passerai il mese successivo a comprimere immagini o a fare un lavoro che cambia i numeri che contano.

Inizia dalla pagina che fa guadagnare, non da quella che imbarazza

Il principio: il lavoro sulla velocità ha un ritorno, e quel ritorno dipende dal traffico e dal valore di conversione. Una pagina a basso traffico ma ad alta conversione può contare più della homepage per il business, anche se è più lenta.

Quindi la prima mossa è fare un elenco di pagine dalle analytics, non dalla sitemap. Quali pagine ricevono denaro sotto forma di click pubblicitari? Quali pagine non sono state toccate dal lancio? In questo scenario, la landing page più importante—quella dietro a un annuncio di ricerca a pagamento attivo da due mesi—è stata costruita con grandi screenshot non ottimizzati. La homepage, al confronto, era già stata ottimizzata da un'agenzia un anno fa.

Non sistemi prima la homepage. Sistemi la pagina che fa guadagnare. Non è una scelta tecnica, è una scelta di business. Se un audit tecnico completo ti sembra la risposta giusta, resisti per un momento. Gli audit producono un elenco; non ti dicono da quale elemento iniziare. Un audit SEO tecnico ben definito è uno strumento decisionale, non una risposta dettata dal panico.

Spesso scoprirai che un piccolo numero di pagine genera la maggior parte del traffico e delle conversioni; le altre sono informative o vestigiali. Non è un motivo per ignorare per sempre le pagine informative lente. È un motivo per metterle in sequenza dopo le pagine che hanno un collegamento diretto con le entrate. La homepage può essere la più lenta di tutte, ma se l'obiettivo di business sono i lead, una visita alla homepage è solo un punto di partenza—la landing page è dove qualcuno converte davvero.

Dividi "veloce" in "misurato" e "percepito"

Il secondo passo è separare ciò che i test di performance dicono sulla tua pagina da ciò che gli utenti reali sperimentano. La documentazione di Google sui Core Web Vitals nomina tre metriche che contano per il posizionamento nei risultati di ricerca: Largest Contentful Paint (caricamento), Interaction to Next Paint (reattività) e Cumulative Layout Shift (stabilità visiva). Contano perché tracciano momenti che influenzano se qualcuno può effettivamente usare la pagina.

Nello scenario, apri la landing page in un tester di performance e ottieni un punteggio ragionevole. Ma quando confronti questo con i dati sul campo in Google Search Console—che riflettono le esperienze reali dei visitatori—la pagina risulta essere spesso lenta. Questo è il segnale che conta. I test di laboratorio sono ancora utili dopo una modifica, per confrontare prima e dopo. Ma i dati sul campo sono la verità di base per le persone che hanno cliccato sul tuo annuncio da una varietà di dispositivi e connessioni.

Invece di questo	Inizia con questo	Perché
Punteggio PageSpeed come numero unico	Dati sul campo dei Core Web Vitals	I dati sul campo provengono da utenti reali, non da un server di test
"Il sito è lento"	Quali pagine supportano gli obiettivi di business	Le pagine veloci ma inutili non generano lead
Ricostruire il CMS	Comprimere le immagini e ripulire gli script	Le correzioni a basso rischio offrono la maggior parte dei benefici

Se vuoi un riferimento più approfondito per dopo, una guida ai Core Web Vitals può accompagnarti attraverso ogni metrica. Ma per ora ti serve solo quanto basta per costruire il piano. La chiave è identificare quale delle tre metriche sta causando effettivamente il problema su quella specifica pagina. Se il testo appare tardi, guarda immagini e risposta del server. Se i pulsanti sembrano a scatti, guarda i lunghi task JavaScript. Se il layout salta, guarda gli spazi riservati a annunci e incorporamenti. Questa sfumatura è ciò che separa una correzione mirata da un'ottimizzazione casuale.

Sistema le cose economiche prima di quelle costose

Il terzo principio: non lasciare che un progetto di performance si trasformi in una riprogettazione. La maggior parte dei miglioramenti che incidono davvero sull'esperienza utente sono poco appariscenti ed economici.

Guarda la landing page e nomina i colpevoli evidenti. Le immagini sono screenshot a piena risoluzione. C'è uno script di terze parti sulla pagina che nessuno sa più identificare. Un font web blocca il rendering del testo. Sono problemi familiari.

In un mondo perfetto, passeresti una settimana a riscrivere la pagina con un framework moderno. In pratica, inizi con attività da mezza giornata: comprimi le immagini, posticipa lo script inutilizzato, precarica l'immagine hero. Puoi testare queste modifiche in un pomeriggio e non richiedono un comitato di approvazione.

Avvertenza: la velocità non è sempre così semplice. Alcune pagine sono lente a causa di un server, di un database o di una dipendenza di terze parti che non controlli. Ma se non hai verificato le correzioni economiche, non puoi ancora giustificare quelle costose. Molti team spendono un budget in una ricostruzione perché non hanno mai compresso gli screenshot. C'è un'umiltà che vale la pena mantenere: un punteggio di performance è un sintomo, non una diagnosi. Le correzioni economiche sono di per sé diagnostiche. Dopo aver compresso le immagini, impari se il collo di bottiglia era il tuo contenuto o la tua infrastruttura.

Aggiungi dati strutturati mentre sei già nel codice

Questo è il livello che sorprende il capo. Dopo aver fatto le correzioni economiche, sei già dentro la pagina. È il momento giusto per aggiungere qualcosa che non è affatto velocità: i dati strutturati.

I dati strutturati sono markup che aiutano i motori di ricerca a capire cosa contiene una pagina. È lo stesso HTML che può portare a risultati di ricerca più ricchi e a una migliore visibilità—e sta diventando sempre più rilevante man mano che la ricerca si sposta verso risposte generate dall'IA. Per un piccolo team, questa è una leva poco utilizzata perché non richiede di scrivere nuovi contenuti. Stai etichettando ciò che già esiste.

Nello scenario, aggiungi uno schema orientato ai servizi alla landing page. Il tipo esatto dipende da ciò di cui parla la pagina: una pagina di servizio, un articolo, un prodotto. Non devi aggiungere tutti i tipi in una volta. Aggiungerne uno con cura è meglio che aggiungerne dieci in modo approssimativo. Nessun risultato è garantito; Google decide cosa mostrare. Ma il rischio è basso e il potenziale vantaggio è reale. Se decidi di approfondire, una guida all'implementazione dei dati strutturati copre i passi pratici.

Traduci le correzioni in "ha fatto guadagnare?"

La parte difficile non è il lavoro tecnico. È il modo in cui lo presenti a un capo non tecnico.

Il tuo capo ha chiesto una cosa sola: rendere il sito più veloce. Se dici "abbiamo migliorato l'LCP sulla landing page", potresti ricevere uno sguardo vuoto. Invece, traduci il lavoro in conseguenze di business.

In questo scenario, la landing page è la destinazione di una campagna a pagamento. Ogni secondo di attesa è un secondo in cui un visitatore potrebbe andarsene prima che appaia l'invito all'azione. Quindi spieghi: abbiamo rimosso gli attriti evidenti sulla pagina in cui il denaro cambia di mano. Non puoi promettere un salto di posizionamento specifico—chiunque lo faccia sta tirando a indovinare—ma puoi fare un argomento ragionevole e onesto. Puoi anche collegare questo al budget che il tuo capo già comprende. La stessa spesa pubblicitaria compra una visita; la differenza è se quella visita ha la possibilità di diventare un lead.

Un semplice rapporto mensile funziona meglio di una dashboard piena di gergo. Mostra tre cose: quale pagina hai scelto, quale metrica hai misurato e cosa hai cambiato. Se la metrica migliora, è una validazione. Se non migliora, hai comunque un esperimento chiaro da rivalutare. Non inseguire un singolo punteggio di mese in mese; i Core Web Vitals fluttuano con il mix di traffico, i tipi di dispositivo e persino la regione geografica. Riporta la tendenza, non il numero.

Cosa fare lunedì prossimo

La lezione dello scenario: non sistemi "il sito web". Sistemi una pagina specifica, basandoti sui dati, e finisci con un processo ripetibile piuttosto che un progetto una tantum. Quando qualcuno con autorità dice "rendilo più veloce", la risposta più utile è una singola domanda chiarificatrice: quale pagina, e per chi?

Poi misura i dati sul campo, sistema le cose economiche, aggiungi dati strutturati se sei già nel codice e riferisci in linguaggio semplice. I risultati potrebbero non essere drammatici. Ma saprai esattamente quale pagina è diventata più veloce, perché l'hai scelta e cosa fare dopo. Questo è un risultato migliore di un progetto vago che è iniziato con un punteggio di velocità ed è finito in una riprogettazione che nessuno ha capito.