?>

Core Web Vitals: perché il codice personalizzato ottiene 100 – e WordPress raramente supera 60

I Core Web Vitals di Google sono un fattore di ranking confermato. Ma ecco cosa la maggior parte degli sviluppatori non ti dirà: la piattaforma che scegli determina l’80% del tuo punteggio di base. Il PHP personalizzato può raggiungere 100 con il minimo sforzo. WordPress – anche con plugin di caching – di solito si colloca nell’intervallo 40–60. Ho costruito e ottimizzato entrambi. Lascia che ti mostri esattamente perché, con numeri reali, codice e risultati dei clienti.

Il business case per superare i Core Web Vitals

Prima di immergerti nel codice, comprendi l’impatto. I dati di Google mostrano:

• I siti che superano i Core Web Vitals registrano il 24% in meno di abbandono degli utenti.
• Un miglioramento di 0,5 s nel LCP può aumentare le conversioni del 12–15% (caso di studio Google).
• L'esperienza della pagina è ora un criterio di spareggio quando due pagine hanno rilevanza simile.

La scelta della piattaforma non riguarda solo la comodità dello sviluppatore – è un motore diretto di entrate e ranking.

I numeri reali: PHP personalizzato vs WordPress (stesso server)

Ho eseguito un test controllato su hosting identico (Hostinger VPS, 2 vCPU, 2 GB RAM, storage NVMe). Due siti web:

• Sito A: PHP/HTML personalizzato, nessun framework, CSS/JS minimo, ottimizzato manualmente.
• Sito B: WordPress 6.7 pulito + tema Astra + 5 plugin essenziali (Yoast SEO, LiteSpeed Cache, Contact Form 7, Social Snap, Smush).

Gli 847 KB di JavaScript sono il problema. WordPress carica jQuery, l’editor a blocchi, gli script dei plugin e le risorse del tema – anche se non li usi. Lighthouse di Google misura tutto, e ogni kilobyte si aggiunge a LCP e INP.

Core Web Vitals spiegati (soglie 2026)

Google ha confermato che l’esperienza della pagina è un segnale di ranking sia su mobile che su desktop. Nel 2026, le soglie sono:

• LCP (Largest Contentful Paint) – misura la velocità di caricamento. Buono: sotto 2,5 s.
• INP (Interaction to Next Paint) – misura la reattività. Buono: sotto 200 ms (ha sostituito FID nel 2024).
• CLS (Cumulative Layout Shift) – misura la stabilità visiva. Buono: sotto 0,1.
• TTFB (Time To First Byte) – risposta del server. Buono: sotto 600 ms (non ufficiale, ma Google lo usa).

Un sito che non supera queste metriche viene spinto al di sotto dei concorrenti più veloci – anche se ha più backlink.

Come il PHP personalizzato raggiunge un perfetto 100 (codice reale + tecniche avanzate)

Ecco esattamente cosa faccio su ogni build personalizzata per garantire un punteggio Lighthouse di 100.

1. Precarica le risorse critiche

Dì al browser cosa è più importante prima ancora che analizzi l'HTML.

<link rel="preload" href="hero.webp" as="image" fetchpriority="high">
<link rel="preload" href="critical.css" as="style">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

2. Includi CSS della parte superiore (riduci FCP della metà)

Estrai solo gli stili necessari per l’area visibile. Usa la scheda Coverage di Chrome per trovare CSS non utilizzati.

<style>
  /* Only styles for visible content – typically 3-8KB */
  body { font-family: 'Inter', sans-serif; background: #0a0a0a; margin:0; }
  .hero { min-height: 100vh; display: flex; align-items: center; }
  .btn { background: #3b82f6; padding: 12px 28px; border-radius: 40px; }
</style>
<link rel="preload" href="full-styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="full-styles.css"></noscript>

3. Servi immagini responsive con srcset e WebP

La maggior parte dei siti invia immagini di dimensioni da desktop ai dispositivi mobili – una grande penalità per LCP. Usa `srcset` per servire immagini di dimensioni appropriate.

<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
     width="1200" height="630"
     loading="eager"
     alt="Hero image">

4. Ottimizza la risposta del server (TTFB)

Uso PHP‑FPM con OPcache abilitato, compressione GZIP e indicizzazione del database. Nessun overhead di `wp_query` di WordPress significa che le query restituiscono risultati in 5–15 ms, non 150 ms. Modifiche aggiuntive:

• Abilita Keep‑Alive e HTTP/2.
• Usa una CDN (Cloudflare o Bunny.net) per memorizzare nella cache le risorse statiche.
• Sposta il database su un server separato o usa Redis per la cache degli oggetti se necessario.

5. Elimina gli spostamenti di layout (CLS = 0,01)

Ogni immagine, video e spazio pubblicitario riceve attributi espliciti `width` e `height`. Riserva spazio per i font con `font-display: swap`.

/* In CSS */
@font-face {
  font-family: 'Inter';
  font-display: swap;
  /* ... */
}

6. Posticipa JavaScript non critico

Usa `defer` o `async` su tutti gli script esterni e sposta le analisi in modo che vengano caricate dopo l’interazione dell’utente.

<script defer src="analytics.js"></script>
<script>
  window.addEventListener('load', function() {
    // Load non‑critical JS here
  });
</script>

7. Usa `loading="lazy"` per le immagini sotto la piega

Le immagini non visibili inizialmente dovrebbero essere caricate in modo lazy. Questo fa risparmiare larghezza di banda e accelera LCP.

Perché WordPress non può facilmente eguagliare questi numeri

• Ogni plugin aggiunge il proprio CSS/JS, spesso senza `async` o `defer`. Anche i plugin "ottimizzati" aggiungono overhead.
• L'editor a blocchi carica oltre 500 KB di JavaScript anche se stai usando solo una pagina semplice. Questo è mezzo megabyte di codice inutilizzato.
• I plugin di cache aiutano, ma non possono rimuovere il gonfiore sottostante – memorizzano solo nella cache l’output già gonfio.
• I temi di terze parti includono interi framework (Bootstrap, Tailwind) – 90% di CSS inutilizzato che continua a bloccare il rendering.

Anche se temporaneamente ottieni un 90 su Lighthouse, un aggiornamento di un plugin o un nuovo tema può farlo crollare a 45 dall’oggi al domani. Con PHP personalizzato, le tue prestazioni sono deterministiche – non cambiano se non le cambi tu.

Due trasformazioni reali di clienti

Caso di studio 1: Negozio di gioielli WooCommerce → PHP personalizzato

Un negozio di gioielli aveva un sito WooCommerce con un punteggio di 43 su Lighthouse (mobile). Avevano 12 plugin attivi, un tema gonfio e tempi di caricamento di 4,2 s. Dopo la migrazione a un negozio PHP personalizzato con Stripe Checkout:

• Punteggio Lighthouse: 43 → 98.
• Tempo di caricamento mobile: 4,2 s → 0,9 s.
• Tasso di conversione: 1,8% → 3,4% (+89%).
• Il valore medio dell’ordine è aumentato del 22% (un checkout più rapido ha incoraggiato gli upgrade).

Caso di studio 2: Sito immobiliare con oltre 500 pagine

Un’agenzia immobiliare aveva un sito WordPress con tempi di caricamento delle pagine di 3,5 secondi e un CLS di 0,28 (scarso). Abbiamo ricostruito il front‑end come un sito PHP personalizzato utilizzando un modello leggero, CSS critico inline e immagini hero precaricate.

• LCP: 3,1 s → 0,9 s.
• CLS: 0,28 → 0,02.
• La frequenza di rimbalzo è scesa dal 58% al 37%.
• Le invii del modulo di contatto sono aumentati del 41% entro 60 giorni.

Il costo nascosto dei costruttori di pagine: Wix, Squarespace, Shopify

Non è solo WordPress. Tutte le piattaforme drag‑and‑drop soffrono di impostazioni predefinite scadenti:

• Wix/Squarespace: Stili inline ovunque, dimensioni DOM enormi e nessun controllo sul CSS critico. Punteggio medio Lighthouse mobile: 30–50.
• Shopify: Meglio di Wix, ma i temi caricano JavaScript pesante e font esterni. Punteggio medio: 60–75.
• Webflow: Può essere ottimizzato, ma richiede conoscenze esperte e produce comunque codice gonfio rispetto al PHP scritto a mano.

Solo il PHP personalizzato ti dà il controllo completo su ogni byte che raggiunge il browser.

Come iniziare (anche se non sei uno sviluppatore)

Non devi scrivere tutto da zero. Costruisco ogni sito web manualmente, così ottieni una base di codice 100% su misura. Il risultato: un punteggio Lighthouse che puoi screenshotare e usare come segnale di fiducia. Puoi anche iniziare con un generatore di siti statici (Hugo, Eleventy) e successivamente aggiungere PHP per funzionalità dinamiche.

Piano d’azione: porta il tuo sito a 100 oggi

1. Testa il tuo sito attuale su PageSpeed Insights (mobile). Annota LCP, INP, CLS.
2. Risolvi i problemi facili: comprimi le immagini, abilita la cache, rimuovi i plugin inutilizzati.
3. Se sei al di sotto di 70, prendi in considerazione una migrazione della piattaforma. Il ROI di un sito PHP personalizzato spesso si ripaga in 6–12 mesi grazie a conversioni più elevate e minori costi di hosting.
4. Oppure assumi me. Ti costruirò un sito PHP personalizzato che ottiene 100 – garantito.

Riepilogo finale: la scelta della piattaforma è l’80% della battaglia

Puoi ottimizzare qualsiasi sito, ma iniziare con PHP personalizzato ti dà un enorme vantaggio. WordPress richiede una lotta costante contro la sua stessa architettura. Wix e Squarespace ti bloccano in modelli lenti. Il PHP personalizzato ti mette in pieno controllo. I numeri parlano da soli.

Se vuoi un sito web che ottenga nativamente 96–100 su Lighthouse e superi i costruttori di pagine, parliamone.

Tutti i dati dei test sono stati raccolti su Hostinger VPS (2 vCPU, 2 GB RAM) utilizzando Lighthouse 12.0 (simulazione mobile). I tuoi risultati possono variare in base al contenuto e all’hosting.