WordPress non è morto. Ma i Core Web Vitals lo stanno condannando

WordPress fa girare il 43% del web. È una statistica che torna fuori ogni volta che qualcuno dichiara che WordPress è morto, come argomento definitivo a chiudere la discussione.

Ma la quota di mercato non misura la qualità dell’esperienza utente. La misura Google, con i Core Web Vitals — e qui il confronto diventa scomodo.

Cosa sono i Core Web Vitals (e perché contano davvero)

Dal 2021 Google ha inserito tre metriche nel suo algoritmo di ranking:

LCP (Largest Contentful Paint) — quanto ci vuole per renderizzare l’elemento principale della pagina. Soglia buona: sotto 2,5s.
INP (Interaction to Next Paint) — latenza tra un’interazione utente e la risposta visiva. Soglia buona: sotto 200ms.
CLS (Cumulative Layout Shift) — spostamenti di layout durante il caricamento. Soglia buona: sotto 0,1.

Non sono metriche teoriche. Impattano il ranking SEO e la conversion rate. Amazon ha stimato che ogni 100ms di latenza in più costa l’1% delle vendite. Un WordPress lento non è solo un problema tecnico — è un problema di business.

Il problema strutturale di WordPress

WordPress è un monolite PHP del 2003 che fa tutto: gestisce il contenuto, costruisce le pagine, serve l’HTML, esegue plugin, interroga il database — tutto nello stesso processo, per ogni singola richiesta.

Il flusso tipico di una pagina WordPress:

Richiesta HTTP
  → PHP avvia l'esecuzione
  → WordPress carica il core (~50 file)
  → Attiva tutti i plugin (~20-60 plugin tipici)
  → Query al database (anche 30-50 query per pagina)
  → Template engine costruisce l'HTML
  → Risposta HTML al browser

Ogni passaggio aggiunge latenza. Il TTFB (Time to First Byte) medio di un WordPress non ottimizzato è tra 800ms e 2s. Una Astro o Next.js statica risponde in 20-80ms da un CDN edge.

Il plugin di caching aiuta, ma è un rattoppo: nasconde il problema senza risolverlo, e si rompe non appena un contenuto cambia o il cache si invalida.

Headless: separare chi scrive da chi serve

L’architettura headless spezza quel monolite in due responsabilità distinte:

CMS (WordPress, Contentful, Sanity) — gestisce solo i contenuti, espone un’API REST o GraphQL.
Frontend (Astro, Next.js, Nuxt) — consuma l’API, genera HTML statico al build time, distribuisce su CDN.

L’utente finale non tocca mai PHP, mai MySQL, mai i plugin. Riceve HTML pre-generato dal nodo CDN più vicino a lui — che in Europa può voler dire 5-15ms di TTFB invece di 800ms.

Il confronto numerico su un progetto reale che ho migrato:

Metrica	WordPress + WooCommerce	Headless (Astro + WP API)
TTFB	1,2s	38ms
LCP	4,1s	1,1s
CLS	0,18	0,02
PageSpeed (mobile)	41	94

Non è un test di laboratorio. È produzione, stesso contenuto, stesso hosting base.

Quando WordPress ha ancora senso

L’architettura headless non è gratis. Aggiunge complessità:

Build time che può diventare lungo su siti con migliaia di pagine
Preview dei contenuti più difficile da gestire
Deploy pipeline da configurare
Costo infrastrutturale più alto se non si usano servizi managed

Per un blog personale, un sito istituzionale semplice, o un cliente che vuole gestire tutto da solo senza toccare mai una console: WordPress con un tema leggero e un CDN davanti rimane una scelta ragionevole.

Per un e-commerce, un sito editoriale, qualsiasi cosa dove la performance influisce sul fatturato: i numeri parlano chiaro.

Conclusione

WordPress non è morto. Ma l’idea che sia ancora la soluzione predefinita per qualsiasi progetto web è quella che dovrebbe morire.

La scelta dell’architettura è una decisione tecnica che ha conseguenze SEO, UX e business misurabili. I Core Web Vitals hanno tolto quell’argomento dal piano delle preferenze personali e lo hanno messo sul piano dei numeri — e i numeri non mentono.