Cinque settimane di lavoro su un sito di servizio per la comunità italiana nel Regno Unito, contenuti verticali sulle leggi UK post-Brexit, sulla healthcare NHS, sulle scuole. Migrazione su nodo dedicato in regione UK, ricostruzione del rendering critico per il mobile, sitemap pulita, hreflang per la versione italiana parallela. LCP mobile p75 da 4,1s a 219ms, TTFB UK p75 da 1,7s a 95ms, bounce mobile p75 in calo del 34% in 60 giorni. Vedi gli altri post di Fieldwork per casi simili.
Il cliente in 100 parole
Un editore italiano che gestisce un sito di servizio rivolto alla comunità italiana che vive e lavora nel Regno Unito. Audience verticale: lavoratori, famiglie, professionisti che si sono trasferiti prima e dopo Brexit. Contenuti di servizio (visti, BRP, residency, NHS, scuole, fiscalità UK-Italia) con cadenza redazionale settimanale e picchi sui cambi normativi. Redazione piccola, due persone fisse più collaboratori esterni, focus su contenuti evergreen che vengono ri-aggiornati legalmente quando cambia la normativa britannica. Sito storico WordPress su hosting condiviso in regione EU, infrastruttura non gestita dall’editore, performance mobile sotto pressione perché il 78% del traffico arriva da smartphone Android di gamma bassa-media.
Il problema
Il referente del cliente l’ha messa così, parafrasando: le pagine sui visti BRP arrivano spesso in cima a Google UK quando un nostro lettore cerca informazioni, ma quando ci atterrano da mobile aspettano oltre quattro secondi prima di vedere il titolo, e il 40% se ne va prima ancora di leggere la prima riga. L’audit conferma il quadro: LCP mobile p75 a 4,1 secondi su Lighthouse field data, TTFB misurato da nodo Londra a 1,7 secondi, total page weight medio sopra 3,2 MB con immagini hero non ottimizzate e font web caricati da terze parti senza preconnect. Il sito è veloce in ufficio, dove gira su connessione fibra in Italia: è lento dove serve, sui mobile dei lettori a Londra, Manchester, Birmingham, Edinburgh.
C’è una seconda dimensione del problema, meno tecnica e più strategica: la versione italiana parallela del sito (per chi ancora vive in Italia e sta valutando il trasferimento) condivide molti contenuti tradotti, ma non c’è hreflang configurato. Google sta servendo a volte la versione italiana a utenti UK e viceversa, perdendo intent.
Il metodo
L’intervento si articola su quattro assi.
Asse uno: nodo dedicato in regione UK. Migrazione dal hosting condiviso EU a una VM Hetzner in regione fsn1 per ridondanza intra-UE più una seconda VM frontale in regione UK (Falkenstein UK edge, peering CDN Cloudflare). Il TTFB UK si abbatte semplicemente perché il primo byte non deve più attraversare un ocean cable di andata e ritorno. Stack server: Debian 12, nginx con micro-cache fastcgi 60s sui contenuti pubblici, PHP 8.3 con OPcache, Redis come object cache di WordPress, MariaDB tuning standard (innodb_buffer_pool_size sul 60% della RAM disponibile, query cache disattivato).
Asse due: LCP optimization mobile-first. Lavoro chirurgico sul rendering critico:
- Hero image preload con
<link rel="preload" as="image" fetchpriority="high">e responsive sources in AVIF + WebP fallback, dimensioni esplicite per evitare CLS. - Font system stack (san-francisco/segoe/roboto) per il body, web font solo per il logo wordmark e con
font-display: optional. Niente Google Fonts, niente preconnect a domini esterni in critical path. - JavaScript di analytics e consensi messo in
defer, nienteasyncsu quello che blocca il parsing dell’header. - CSS critico inline per la above-the-fold (template per tipo di pagina: archivio, single, pagina di servizio), il resto in
<link rel="stylesheet">conmedia="print" onload. - Lazy loading nativo (
loading="lazy") su tutte le immagini below-the-fold, eager solo sull’hero.
Asse tre: header e footer come componenti react-light renderizzati server-side. Il tema legacy aveva header con tre livelli di menu generati da plugin custom, con query MySQL al render, una matrioska di hook che pesava ~180ms a request. Ricostruito come componenti React-light (Preact build, ~10kb) renderizzati server-side via WordPress block.json e idratati lato client solo per le interazioni del menu mobile. HTML servito già completo, niente flash, niente shift.
Asse quattro: sitemap pulita e hreflang. Il sito aveva tre sitemap concorrenti generate da plugin diversi (SEO plugin storico, plugin di traduzione legacy, sitemap nativa di WordPress 5.5+), tutte parzialmente disallineate. Riconciliate in una sola sitemap principale con sub-sitemap per tipo di contenuto, hreflang configurato sia in HTTP header sia in <link rel="alternate"> sia nella sitemap stessa. Disambiguazione en-GB per la versione UK e it-IT per la versione italiana parallela. Coppie speculari, fallback x-default sulla UK.
Cosa abbiamo scartato
Due strade ragionate e respinte, le scrivo perché in Fieldwork le scelte di non fare contano quanto quelle di fare.
Full SPA (Next.js o simili). Il cliente rendendizzava già con WordPress block-editor, la redazione lavorava su Gutenberg, i contenuti erano testo-immagine senza componenti interattivi pesanti. Una migrazione full SPA avrebbe richiesto sei mesi di refactoring, nuovo workflow editoriale, perdita di familiarità per la redazione, e un rischio reale di sbagliare il primo render statico generato (ISR) sulle pagine legali che si aggiornano. Tradeoff sproporzionato rispetto al guadagno di performance, che era già raggiungibile con WordPress + nginx + LCP optimization mirata. Scelta: no SPA, ottimizzazione chirurgica del rendering esistente.
Caching CDN aggressivo. Cloudflare offre cache rules molto aggressive sulle pagine HTML, con TTL lunghi a livello edge. Per un sito di marketing andrebbe bene. Per un sito di servizio post-Brexit no: i contenuti legali (visti, residency, BRP) si aggiornano quando la normativa britannica cambia, e un cache aggressivo sull’edge tiene online versioni vecchie per ore o giorni dopo il deploy redazionale. Abbiamo scelto micro-cache fastcgi 60s a livello nginx (regola interna) e bypass su cookie loggato; CDN Cloudflare attivo solo come reverse proxy + WAF + ottimizzazione asset statici, niente cache HTML aggressivo. Il purge resta interno, non dipende dall’edge esterno.
I numeri
Misurazioni prese su 60 giorni post-cutover, due strumenti: Lighthouse field data lato mobile UK e WebPageTest da nodo Londra (Vodafone 4G profile, tre run, mediana). Confronto contro baseline pre-migrazione (giorno zero):
| Metrica | Baseline | Post-migrazione | Delta |
|---|---|---|---|
| LCP mobile p75 (UK) | 4,10 s | 219 ms | -94,7% |
| TTFB p75 (Londra) | 1,70 s | 95 ms | -94,4% |
| CLS p75 (mobile) | 0,18 | 0,02 | -88,9% |
| Total page weight homepage | 3,2 MB | 720 KB | -77,5% |
| Bounce rate mobile (60gg) | 58% | 38% | -34% |
| Traffic organic Google UK (60gg) | baseline | +18% | +18% |
| Pagine indicizzate corrette (hreflang) | parziali | tutte | n/a |
Numeri che reggono perché il TTFB lo decide la regione del nodo (UK to UK invece di Italy to UK), il LCP lo decide il preload della hero più i font system, il CLS si chiude con dimensioni esplicite e font con font-display: optional. Niente magia, igiene applicata bene.
Voce del cliente
Quello che non avevamo capito per anni è che il sito non era lento per noi, redazione italiana che lo apriva da Italia. Era lento per i nostri lettori veri, le famiglie italiane a Londra e Manchester che ci leggevano sul telefono in metro o in pausa pranzo. Quando ci hanno mostrato i numeri di TTFB misurati da Londra abbiamo capito che il problema l’avevamo davanti da anni e non lo vedevamo. Da quando il sito gira sul nodo UK i nostri lettori restano sulla pagina, e questo si vede nei commenti che riceviamo: domande più approfondite, conversazioni più lunghe, meno grazie ma sono uscito perché era lento.
(Citazione parafrasata, autorizzata dal referente del cliente, attribuita in modo generico al direttore editoriale.)
Cosa stiamo costruendo dopo
Il prossimo cantiere, già aperto, è una versione localizzata per un’altra comunità italiana storica nel nord Europa (Belgio, Lussemburgo, Olanda). Stessa logica architetturale: nodo dedicato nella regione di destinazione, contenuti di servizio verticali, hreflang strutturato. Cambia il copy, cambia la regione legale di riferimento, non cambia l’approccio tecnico. Dimostrazione interna che il template sito di servizio per comunità italiana fuori Italia è replicabile su AI Multisite come tenant orizzontale, con costi di onboarding di un nuovo paese stimabili in 2-3 settimane invece di 5.
Cosa ci portiamo dietro per i prossimi cantieri di servizio
Tre cose che sono diventate parte del template interno di Romiltec dopo questo lavoro.
Prima. La regione del nodo, su un sito di servizio rivolto a una comunità geograficamente concentrata, è la prima decisione architetturale e va presa al kickoff, non in fase di tuning. Il cliente storico aveva il sito in regione EU per un motivo amministrativo ragionevole (la fatturazione del fornitore era italiana), ma la latenza fra Italia e UK era invisibile in ufficio e visibilissima sui telefoni dei lettori. Su Fieldwork futuri, la prima slide del kickoff include una mappa di traffico geografico aggregato, non più solo la lista dei plugin attivi.
Seconda. Sui contenuti di servizio (legali, sanitari, fiscali) il caching aggressivo edge è un’arma a doppio taglio che va calibrata caso per caso. Quando un contenuto è una guida ai visti BRP e la normativa cambia per delibera del Home Office, una cache edge da 24 ore può servire informazioni obsolete a un lettore che sta prendendo una decisione amministrativa. La regola interna è: micro-cache fastcgi 60s, cache CDN solo sugli asset statici, purge controllato dal CMS. È meno performante di un cache everything, ma è compatibile con il dovere editoriale di un sito di servizio.
Terza. Hreflang è un investimento di setup, non di tuning. Mezz’ora di diagnosi sull’header HTTP più la mappa speculare it/en-GB risolve mesi di intent persi su Google. Si prevede di default sui prossimi tenant AI Multisite con audience multi-paese, indipendentemente dal volume iniziale.
Box laterale
Stack: WordPress 6.x + nginx con micro-cache fastcgi + nodo dedicato Hetzner (regione UK edge) + AVIF/WebP responsive + Cloudflare reverse proxy/WAF + AI Multisite come orchestratore tenant. Durata: 5 settimane (audit 4 giorni, migrazione + rebuild header/footer 2 settimane, hreflang + sitemap 1 settimana, tuning + monitoraggio 1 settimana e mezzo). Team Romiltec: 1 dev senior frontend/devops + Rocco sul piano e DevOps.