Migrare un sito senza perdere prestazioni: checklist per cambio di hosting, tema o CMS

Cambiare hosting, passare a un nuovo tema, rifare il sito, trasferirlo da un CMS a un altro: sono progetti in cui l’attenzione si concentra su ciò che si vede, cioè grafica, contenuti, funzionalità, e su ciò che fa paura, come la perdita di posizioni nei motori di ricerca. Le prestazioni restano spesso sullo sfondo, date per scontate. Ed è proprio in questi momenti che molti siti le perdono: una cache che non viene riconfigurata, una compressione che sparisce, un tema nuovo più pesante del precedente, un server in un’altra regione.

Il problema è che queste perdite si vedono tardi. I dati di campo che Google usa sono calcolati su 28 giorni, e una regressione introdotta il giorno della migrazione emerge nei rapporti settimane dopo, quando è difficile collegarla alla causa. In questo articolo proponiamo un metodo in tre fasi, prima, durante e dopo, per migrare un sito senza perdere prestazioni, o per accorgersene subito se succede.

Prima: fotografare il punto di partenza

Il passo più importante, e il più trascurato, è misurare lo stato attuale prima di toccare qualsiasi cosa. Dopo la migrazione il vecchio sito non esisterà più, e senza una fotografia precisa sarà impossibile dire se il nuovo è migliore o peggiore, e dove.

• Dati di campo. I valori delle Core Web Vitals dal Chrome UX Report per l’intera origine e per le pagine più importanti, possibilmente con le serie storiche della CrUX History API, e lo stato dei gruppi di URL nel rapporto di Search Console. Se esiste un sistema di Real User Monitoring, i valori giornalieri per modello di pagina.
• Test di laboratorio ripetibili. Per ogni modello di pagina principale, un test con uno strumento che permetta di ripetere le stesse condizioni, come WebPageTest con località, dispositivo e connessione fissi, salvando i risultati e i waterfall. Tre esecuzioni per pagina, per ridurre la variabilità.
• Configurazione tecnica. Le intestazioni di risposta di HTML, fogli di stile, script e immagini: cache, compressione, protocollo. Versione di PHP e del database, tipo di cache di pagina e degli oggetti, CDN, impostazioni del DNS.
• Pagine dinamiche. Il TTFB di carrello, checkout, ricerca, area riservata e bacheca di amministrazione, che dipendono interamente dal server e sono le prime a peggiorare con un hosting inadeguato.
• Reindirizzamenti e indirizzi. L’elenco degli indirizzi esistenti e dei reindirizzamenti attivi, necessario sia per la SEO sia per evitare catene di reindirizzamenti che aggiungono tempo prima del primo byte.

Un semplice script può raccogliere in un file le intestazioni principali delle pagine chiave, da confrontare poi con quelle del nuovo ambiente:

#!/usr/bin/env bash
# Salva intestazioni e tempi delle pagine chiave in un file per il confronto
for url in / /categoria/scarpe/ /prodotto/scarpa-trail/ /carrello/ /blog/; do
	echo "== $url"
	curl -so /dev/null -H 'Accept-Encoding: br, gzip' \
		-w 'ttfb=%{time_starttransfer}s http=%{http_version}\n' "https://esempio.it$url"
	curl -sI -H 'Accept-Encoding: br, gzip' "https://esempio.it$url" \
		| grep -iE '^(cache-control|content-encoding|x-cache|server|alt-svc):'
done > prima-della-migrazione.txt

Durante: verificare la parità

Il nuovo ambiente va verificato prima di ricevere il traffico reale, su un indirizzo di prova. L’obiettivo minimo è la parità: tutto ciò che il vecchio sito faceva bene, il nuovo deve continuare a farlo. Le perdite più frequenti riguardano sempre gli stessi punti.

• Cache. La cache di pagina del vecchio hosting, spesso a livello di server e invisibile nel pannello di WordPress, non viene trasferita con il sito. Sul nuovo ambiente va configurata da capo, con le stesse esclusioni. Lo stesso vale per la cache degli oggetti.
• Compressione e protocolli. Brotli o Zstandard, HTTP/2 e HTTP/3 dipendono dal server: vanno verificati con le intestazioni e con i DevTools, come spiegato negli articoli sulla compressione e su HTTP/3.
• Cache del browser. Le intestazioni di scadenza delle risorse statiche, spesso configurate nel vecchio server, vanno replicate, insieme alle regole di riconvalida viste nell’articolo su HTTP 304.
• Immagini. Conversione nei formati moderni, dimensioni responsive e servizi di ottimizzazione, spesso legati al vecchio hosting o a plugin configurati con chiavi e percorsi specifici.
• Software. Versione di PHP e del database almeno pari a quelle precedenti, OPcache attivo, limiti di memoria adeguati.
• Capacità. Un test di carico sull’ambiente nuovo, come descritto nell’articolo sui picchi di traffico, verifica che regga il traffico reale, soprattutto sulle pagine dinamiche.

Se la migrazione include un nuovo tema o un rifacimento grafico, alla parità tecnica si aggiunge un confronto del front-end: peso delle pagine, numero di richieste, JavaScript, dimensione del DOM, elemento LCP per ogni modello di pagina. È il momento ideale per fissare un budget di prestazioni: il nuovo sito non deve pesare più del vecchio, a meno di una decisione consapevole.

Qualche giorno prima del passaggio conviene abbassare il TTL dei record DNS che verranno modificati, per esempio a cinque minuti, così che il cambio di indirizzo si propaghi rapidamente e un eventuale ritorno al vecchio ambiente sia altrettanto veloce. Dopo la migrazione, a situazione stabile, il TTL torna ai valori abituali, come spiegato nell’articolo su DNS, TLS e connessioni.

Il giorno del passaggio

Il passaggio va programmato in un momento di traffico basso, lontano da campagne e periodi di vendita, con le persone necessarie disponibili. Subito dopo il cambio del DNS, alcune verifiche vanno fatte immediatamente: che le pagine principali rispondano correttamente e dal nuovo server, che la cache di pagina funzioni, che i reindirizzamenti portino alla destinazione finale in un solo passaggio, che i moduli, il carrello e i pagamenti funzionino. Preriscaldare la cache visitando le pagine più importanti evita che i primi utenti trovino un sito lento perché tutte le pagine devono essere generate.

Va preparato anche un piano di ritorno: cosa fare, e in quanto tempo, se il nuovo ambiente mostra problemi gravi. Con il TTL basso e il vecchio ambiente ancora attivo per qualche giorno, tornare indietro è questione di minuti.

Dopo: confrontare e sorvegliare

Nei giorni successivi si ripetono esattamente gli stessi test della prima fase, con le stesse condizioni, e si confrontano i risultati. Le intestazioni raccolte dallo script, i tempi, i waterfall: ogni differenza va spiegata. Un TTFB più alto sulle pagine in cache indica una cache non funzionante o un server più lontano; una dimensione trasferita maggiore per gli stessi file indica una compressione diversa; nuove richieste nel waterfall indicano script o risorse aggiunti.

I dati degli utenti reali sono il controllo decisivo, ma arrivano con tempi diversi a seconda della fonte. Un sistema di monitoraggio proprio mostra l’effetto il giorno dopo; i dati del Chrome UX Report e di Search Console, calcolati su 28 giorni, si spostano gradualmente e mostrano l’effetto completo solo dopo un mese.

Per questo, se non esiste un sistema di monitoraggio degli utenti reali, la migrazione è una buona occasione per attivarlo alcune settimane prima: permette di confrontare i valori giornalieri prima e dopo e di intervenire subito. In mancanza, la CrUX History API, con dati settimanali, offre almeno una visione più rapida del rapporto di Search Console.

Migrazioni di CMS e di dominio

Alcune migrazioni hanno complicazioni aggiuntive. Il passaggio da un CMS a un altro, o da un sito tradizionale a un’architettura con front-end separato, cambia completamente il modo in cui le pagine vengono generate e servite: il confronto per modello di pagina diventa ancora più importante, e conviene prestare attenzione al comportamento delle metriche nelle architetture a pagina singola, come abbiamo visto nell’articolo sulle Single Page Application. Il cambio di dominio, invece, fa ripartire da zero i dati del Chrome UX Report per la nuova origine: per alcune settimane i dati di campo saranno scarsi o assenti, e il monitoraggio proprio diventa l’unica fonte affidabile.

Un esempio

Un sito di servizi passa da un hosting condiviso a un VPS più potente, con l’obiettivo di migliorare i tempi di risposta. I test di laboratorio sul nuovo ambiente mostrano un TTFB delle pagine dinamiche dimezzato, e la migrazione viene considerata un successo. Tre settimane dopo, Search Console segnala un peggioramento dell’LCP da mobile. Il confronto delle intestazioni raccolte prima e dopo rivela la causa: il vecchio hosting serviva le pagine da una cache a livello di server, che sul VPS non è stata configurata, e comprimeva le risorse con Brotli, mentre il nuovo server usa solo Gzip. Le pagine in cache, cioè la grande maggioranza delle visite, sono diventate più lente, anche se il server è più potente. Con la cache configurata e Brotli attivato, i valori tornano migliori di prima. Con le misure giuste raccolte prima e un monitoraggio giornaliero dopo, il problema sarebbe emerso il giorno stesso.

Gli errori più comuni

Ricorrono sempre gli stessi errori. Il primo è misurare solo la home page, che è quasi sempre in cache e raramente rappresentativa: le regressioni si nascondono nelle schede prodotto, negli articoli, nelle pagine dinamiche. Il secondo è confrontare test eseguiti in condizioni diverse, da località, dispositivi o strumenti differenti, e attribuire alla migrazione differenze che dipendono dal test. Il terzo è dimenticare le configurazioni esterne al sito: regole della CDN, intestazioni aggiunte dal vecchio server, reindirizzamenti gestiti a livello di hosting, record DNS. Il quarto è considerare conclusa la migrazione il giorno del passaggio, senza un periodo di sorveglianza attiva.

Le persone da coinvolgere

Una migrazione tocca competenze diverse, e le prestazioni stanno spesso nel mezzo. Chi gestisce l’hosting conosce la configurazione del server e della cache; chi sviluppa il tema conosce il front-end; chi si occupa di SEO conosce indirizzi, reindirizzamenti e Search Console; chi gestisce il marketing sa quali script e quali campagne sono attivi. Conviene stabilire fin dall’inizio chi è responsabile delle prestazioni nel progetto, con il compito di raccogliere le misure iniziali, verificare la parità e seguire i dati nelle settimane successive, e conviene che il fornitore del nuovo hosting sia informato degli obiettivi, non solo dei requisiti tecnici.

La lista in breve

1. Attivare il monitoraggio degli utenti reali qualche settimana prima.
2. Salvare dati di campo, test di laboratorio ripetibili e intestazioni per ogni modello di pagina.
3. Configurare sul nuovo ambiente cache, compressione, protocolli, cache del browser e immagini, e verificarle una per una.
4. Eseguire un test di carico sulle pagine dinamiche.
5. Abbassare il TTL del DNS, preparare il piano di ritorno, scegliere un momento di basso traffico.
6. Dopo il passaggio, ripetere gli stessi test, confrontare, sorvegliare i dati giornalieri e verificare Search Console dopo un mese.

In sintesi

Le migrazioni sono uno dei momenti in cui i siti perdono più facilmente prestazioni, per configurazioni che non vengono trasferite, temi più pesanti o infrastrutture diverse. Il metodo per evitarlo è semplice ma richiede disciplina: fotografare il punto di partenza con dati di campo, test ripetibili e configurazione tecnica; verificare la parità sul nuovo ambiente prima del passaggio; ripetere gli stessi test dopo e sorvegliare i dati degli utenti reali giorno per giorno.

I dati di Google arriveranno con settimane di ritardo e confermeranno il risultato; il lavoro vero si fa prima, con le misure che permettono di confrontare, e subito dopo, con un monitoraggio che permette di intervenire. Una migrazione ben preparata non è solo neutra per le prestazioni: è spesso l’occasione per migliorarle.