Un sito in italiano rivolto a persone che vivono nel Regno Unito deve essere leggibile sui loro dispositivi e corretto rispetto alla loro situazione. Per lavorare sulla performance, partirei dalle pagine e dalle reti dei lettori, separando velocità del server, rendering e qualità del contenuto.
Questa è una guida al metodo di audit. Nella revisione ho rimosso dalla versione precedente risultati numerici e una testimonianza per cui non erano disponibili report verificabili. Senza la misura originale, un “prima e dopo” non è una prova utilizzabile, né per il lettore né per un potenziale cliente.
Comincia da un campione che rappresenti il sito
La home non basta. Seleziona una guida molto letta, un articolo con immagini, un archivio e una pagina con elementi interattivi. Annota template, peso, richieste di terze parti e presenza di contenuti personalizzati.
Per ciascuna pagina raccogli due tipi di dati. I dati reali descrivono l’esperienza di un insieme di utenti; i test di laboratorio consentono di ripetere condizioni controllate e diagnosticare un problema. Non sono intercambiabili.
PageSpeed Insights mostra dati CrUX riferiti a una finestra di 28 giorni quando il campione è sufficiente e usa Lighthouse per l’analisi di laboratorio. Verifica se il dato riguarda la singola URL o l’origine: un valore aggregato del dominio non dimostra il risultato di uno specifico articolo.
TTFB e LCP misurano due passaggi diversi
Il TTFB riguarda l’arrivo del primo byte; il Largest Contentful Paint riguarda la visualizzazione dell’elemento di contenuto più grande nella parte visibile. Un server rapido può ancora consegnare una pagina che mostra tardi l’immagine principale.
Per trovare il collo di bottiglia osserverei il waterfall e l’elemento LCP: quanto tempo passa prima dell’HTML, quando il browser scopre la risorsa principale, quanto impiega a scaricarla e quando riesce a disegnarla. La guida all’ottimizzazione LCP è utile proprio perché separa queste fasi.
Da lì le modifiche diventano mirate: ridurre lavoro PHP sulle pagine cacheabili, rendere disponibile presto l’immagine necessaria, usare dimensioni adeguate e togliere blocchi al rendering. Non applicherei preload a tutte le immagini: le priorità hanno senso quando sono selettive.
La geografia si misura, non si deduce dal nome del fornitore
Per un pubblico concentrato nel Regno Unito proverei accessi da quella zona. Confronterei origine, CDN e cache usando lo stesso contenuto e dichiarando le condizioni. Un nodo europeo può offrire un buon risultato; un nodo vicino può essere lento per PHP, database o saturazione.
Nel testo precedente compariva “Falkenstein UK”. Falkenstein è in Germania, come risulta dalle località dei datacenter Hetzner. Un edge CDN nel Regno Unito e un’origine in Germania sono componenti distinti e vanno descritti come tali.
La cache deve seguire il lavoro editoriale
Per una guida che cambia spesso, il punto non è vietare la cache HTML. È verificare che l’aggiornamento editoriale arrivi alle copie servite ai lettori. Una cache con invalidazione corretta può essere adatta; una micro-cache senza un controllo del risultato può comunque mostrare testo vecchio.
Proverei l’aggiornamento di una pagina di test e controllerei il contenuto pubblico da un client esterno. Separerei pagine anonime, utenti autenticati e risposte personalizzate. Il TTL massimo accettabile dipende dal servizio e dalla capacità di invalidare le copie interessate.
Hreflang: italiano in UK non significa inglese
hreflang descrive varianti linguistiche e, se necessario, regionali di pagine equivalenti. Una pagina scritta in italiano non diventa en-GB soltanto perché si rivolge a chi vive a Londra. Una variante italiana specifica per il Regno Unito può usare it-GB, se esiste davvero una struttura di alternative che lo richiede.
Le indicazioni di Google sulle versioni localizzate richiedono coerenza fra le alternative e collegamenti reciproci. Si può scegliere un metodo supportato, come HTML o sitemap: ripetere tutto anche negli header HTTP non è un requisito né un vantaggio automatico.
Se esiste una sola versione italiana della guida, non inventerei traduzioni o varianti regionali per aggiungere markup. Prima vanno chiariti contenuto, pubblico e URL equivalenti.
Come presentare un risultato credibile
| Dato | Contesto da conservare |
|---|---|
| LCP o INP reale | Fonte, periodo, percentile, URL o origine, dispositivo |
| Test di laboratorio | Rete simulata, località, numero di prove e stato cache |
| Traffico organico | Query, paese, intervallo e possibili cambiamenti editoriali |
| Aggiornamento contenuti | Versione pubblicata e verifica delle copie in cache |
Un miglioramento di velocità non dimostra da solo la causa di una crescita organica. In un report terrei distinti interventi, misure tecniche e risultati di ricerca. Per i contenuti di servizio renderei visibili autore, fonti e aggiornamenti: una pagina rapida che lascia dubbi sulla validità delle informazioni ha risolto soltanto metà del problema.