Il 22 febbraio 2026 abbiamo pubblicato il primo articolo su SEOCodice e — prima ancora di promuoverlo — abbiamo aperto PageSpeed Insights. Il punteggio era 91/100 su mobile. Per un blog appena nato, già un risultato straordinario. Ma non era abbastanza: l’obiettivo era dimostrare che un WordPress costruito con la metodologia Infrastructure-First SEO può competere con qualsiasi framework statico. Questo è il diario tecnico di come siamo arrivati a 100/100 in meno di 24 ore, senza plugin di cache, senza CDN, senza magie.
Indice dei contenuti
- Qual era il punto di partenza e cosa mostrava il report?
- Come funziona la diagnosi Infrastructure-First SEO sulla performance?
- Fix 1: Come abbiamo eliminato il problema della cache in 10 righe di Apache?
- Fix 2: Cos’è il preload LCP e perché riduce il tempo di 1,9 secondi?
- Fix 3: Perché il CSS esterno blocca il rendering e come evitarlo?
- Cos’è il CSS inline e perché funziona come una pagina statica?
- Cos’è il CLS e perché era causato dalla scrollbar di Windows?
- Quali sono i risultati finali dopo ogni ottimizzazione?
- Cosa dimostra questo case study sulla metodologia Infrastructure-First SEO?
- FAQ — Domande frequenti su PageSpeed e WordPress
- È possibile raggiungere 100/100 su PageSpeed con WordPress?
- Il CSS inline penalizza il caching del browser?
- Perché il CLS era 0,183 anche con le immagini dimensionate correttamente?
- Questi fix funzionano su qualsiasi tema WordPress?
Qual era il punto di partenza e cosa mostrava il report?
Il primo report PageSpeed Insights registrava questi valori su dispositivi mobili:
| Metrica | Valore iniziale | Soglia Google “Buono” | Stato |
|---|---|---|---|
| First Contentful Paint | 0,8 s | < 1,8 s | ✅ |
| Largest Contentful Paint | 3,0 s | < 2,5 s | 🔴 |
| Total Blocking Time | 0 ms | < 200 ms | ✅ |
| Cumulative Layout Shift | 0,183 | < 0,1 | 🔴 |
| Speed Index | 0,8 s | < 3,4 s | ✅ |
| Punteggio Performance | 91 | 90–100 | 🟡 |
Tre problemi principali emergevano dalla sezione Approfondimenti:
- LCP 3,0s: l’immagine in evidenza non era precaricata
- Cache browser assente: nessun header di scadenza sulle risorse statiche (349 KiB sprecati ad ogni visita)
- CSS render-blocking: il foglio di stile bloccava il rendering per ~130ms
Come funziona la diagnosi Infrastructure-First SEO sulla performance?
Prima di toccare il codice, abbiamo applicato il protocollo diagnostico dell’Infrastructure-First SEO: analisi layer per layer, dal più esterno al più interno.
- Layer rete: DNS, TTFB, cache
- Layer rendering: risorse bloccanti, ordine di caricamento
- Layer visuale: LCP element, CLS sources
- Layer codice: asset inutili, richieste esterne
Questo approccio — infrastruttura prima, contenuto dopo — è esattamente ciò che separa un’ottimizzazione sistematica da una serie di tentativi casuali.
Fix 1: Come abbiamo eliminato il problema della cache in 10 righe di Apache?
Il sito non aveva un file .htaccess ottimizzato. Ogni visita scaricava le stesse immagini, gli stessi font, lo stesso CSS da zero. La soluzione: un .htaccess con tre blocchi precisi. GZIP/Deflate per comprimere HTML, CSS, JS, JSON, SVG in transito (~70% di risparmio sui file di testo). Cache-Control headers via mod_headers:
- Immagini e font:
max-age=31536000(1 anno) - CSS e JavaScript:
max-age=2592000(1 mese) - HTML:
max-age=3600(1 ora, per aggiornamenti rapidi)
WebP automatico: se il browser supporta WebP e il file .webp esiste nella cartella uploads, Apache lo serve al posto del JPEG/PNG originale — senza PHP, senza JavaScript, direttamente a livello server. Risultato immediato: le 349 KiB segnalate da Google come “risparmio stimato” azzerata alla seconda visita.
Fix 2: Cos’è il preload LCP e perché riduce il tempo di 1,9 secondi?
L’immagine in evidenza è quasi sempre l’elemento LCP (Largest Contentful Paint) di un articolo. Il problema: il browser la scopre solo dopo aver scaricato e analizzato l’HTML completo. La soluzione è il <link rel="preload"> con fetchpriority="high" inserito nel <head> — prima di qualsiasi altro tag. In questo modo il browser avvia il download dell’immagine in parallelo con il parsing dell’HTML, invece di aspettare. Abbiamo implementato una funzione PHP che:
- Rileva automaticamente se la pagina è un articolo singolo
- Recupera l’ID dell’immagine in evidenza
- Genera il tag preload con
imagesrcseteimagesizes="100vw"per il corretto responsive
Effetto: LCP da 3,0s → 1,1s. Una riduzione del 63%.
Fix 3: Perché il CSS esterno blocca il rendering e come evitarlo?
Per impostazione predefinita, WordPress carica il foglio di stile del tema con un tag <link rel="stylesheet">. Il browser, quando incontra questo tag, si ferma: non può renderizzare nulla finché il CSS non è completamente scaricato e analizzato. Esistono tre approcci per risolverlo:
- Non-blocking con preload + onload: tecnica consolidata, ma il CSS arriva comunque in ritardo
- Critical CSS inline + async per il resto: ottima performance, alta complessità di manutenzione
- CSS completamente inline nel
<head>: massima semplicità, effetto pagina statica
Abbiamo scelto la terza via.
Cos’è il CSS inline e perché funziona come una pagina statica?
L’idea — apparentemente controintuitiva — è stata del founder di SEOCodice: “non è un modo per garantire che il CSS venga iniettato direttamente in ogni articolo come se fosse una pagina statica?” Risposta: sì, esattamente. Ed è quello che fanno Astro, Hugo, Next.js e tutti i generatori statici moderni che vedete con punteggi 98-100. La funzione PHP legge style.css, rimuove il commento-header del tema, minifica collassando spazi e newline, e lo inietta come <style id="uu-seo-critical"> nel <head> con priorità 2 — prima di qualsiasi altra risorsa. Risultato:
- Nessuna richiesta HTTP extra per il CSS
- Nessun flash di pagina non stilizzata (FOUC)
- Tutti gli stili applicati dal frame 1 assoluto
Il GZIP del server comprime il CSS inline (~20KB) di circa l’80%, riducendo l’impatto a ~4KB extra per risposta HTML — un compromesso largamente accettabile.
Cos’è il CLS e perché era causato dalla scrollbar di Windows?
Il Cumulative Layout Shift misura quanto il contenuto si sposta visivamente durante il caricamento senza interazione dell’utente. Google considera “buono” un CLS inferiore a 0,1. Il nostro 0,183 era attribuito all’elemento body.wp-singular — l’intera pagina si spostava. Un’analisi più attenta ha rivelato la causa: la scrollbar verticale di Windows. La sequenza del problema:
- La pagina inizia a caricarsi → nessun contenuto scrollabile → nessuna scrollbar → viewport = 1366px
- Il contenuto carica completamente → la pagina diventa scrollabile → la scrollbar appare → viewport = 1349px (-17px)
- Tutto il corpo della pagina si sposta di 17px a sinistra → Google registra CLS = 0,183
La soluzione è una singola riga CSS aggiunta all’elemento html:
overflow-y: scroll;Questo forza la scrollbar a occupare sempre il suo spazio, anche quando non è necessaria. Il viewport non cambia mai larghezza → CLS = 0. Ma con il CSS inline, il beneficio è doppio: overflow-y: scroll è attivo al primo frame, prima ancora che il contenuto venga dipinto sullo schermo. Non c’è nemmeno una finestra temporale in cui il comportamento può essere sbagliato.
Quali sono i risultati finali dopo ogni ottimizzazione?
| Metrica | Inizio | Dopo .htaccess | Dopo LCP preload | Dopo CSS inline |
|---|---|---|---|---|
| Prestazioni | 91 | 92 | 92 | 100 |
| LCP | 3,0 s | 3,0 s | 1,4 s | 1,1 s |
| CLS | 0,183 | 0,183 | 0,183 | 0 |
| FCP | 0,8 s | 0,8 s | 0,8 s | 0,8 s |
| TBT | 0 ms | 0 ms | 0 ms | 0 ms |
| SEO | 100 | 100 | 100 | 100 |
Il punteggio finale: 100 / 96 / 100 / 100 su dispositivi mobili, con una connessione 4G lenta emulata da Lighthouse 13.0.1 su Moto G Power.
Cosa dimostra questo case study sulla metodologia Infrastructure-First SEO?
Tre cose concrete. Prima: la performance non è un problema di hosting o di CDN. È un problema di architettura del codice. Lo stesso hosting, lo stesso server, lo stesso dominio: da 91 a 100 cambiando solo il tema e la sua logica PHP. Seconda: WordPress può competere con i framework statici. Non è una questione di piattaforma, è una questione di come si costruisce su quella piattaforma. CSS inline, LCP preload, zero richieste esterne: sono scelte di progettazione, non di infrastruttura. Terza: la diagnostica sistematica batte l’ottimizzazione a tentativi. Ogni fix ha affrontato un problema specifico identificato dal report. Nessun plugin installato “per sicurezza”, nessuna ottimizzazione generica. Questo è l’Infrastructure-First SEO applicato alla performance: infrastruttura analizzata, problemi prioritizzati, soluzioni mirate.
FAQ — Domande frequenti su PageSpeed e WordPress
È possibile raggiungere 100/100 su PageSpeed con WordPress?
Sì, come dimostra questo case study. È necessario eliminare le richieste esterne non necessarie, gestire il CSS in modo non bloccante (o inline), e ottimizzare il percorso critico di rendering. Non servono plugin di cache o CDN se il tema è costruito correttamente.
Il CSS inline penalizza il caching del browser?
Il CSS inline non viene cachato separatamente, ma con la compressione GZIP il suo impatto sull’HTML è di circa 4KB per risposta. Per un blog editoriale con pagine che si aggiornano spesso, il compromesso è favorevole: nessun FOUC, nessun render-blocking, CLS zero garantito dal frame 1.
Perché il CLS era 0,183 anche con le immagini dimensionate correttamente?
Perché il CLS era causato dalla scrollbar di Windows, non dalle immagini. Anche con attributi width e height corretti sull’<img>, il viewport si restringeva di 17px quando la scrollbar appariva. La soluzione è overflow-y: scroll sull’elemento html.
Questi fix funzionano su qualsiasi tema WordPress?
I principi sì, il codice esatto dipende dall’architettura del tema. Il file .htaccess funziona su qualsiasi installazione Apache. Il preload LCP e il CSS inline richiedono di intervenire su functions.php o nei file del tema. Non sono compatibili con builder come Elementor o Divi, che aggiungono decine di richieste CSS e JS indipendenti.