gmbapi: LCP da 5 a 1,9 secondi in una sola call

 Power hour · gmbapi
LCP da 5 a 1,9 secondi, sistemato in una sola callUn'azienda di local SEO con un sito Next.js nuovo di zecca, veloce su desktop e lento su mobile.
1,9sLCP su CrUX, era 5s
150msINP su mobile, era 220ms
700msrisposta del server, era 3s
0,00CLS su CrUX, era 0,08
Clientegmbapi, software di local SEO
PiattaformaReact, Next.js, CMS headless
ServizioPower hour, agosto 2026
 Il cliente
Un nuovo sito che passava su desktop e falliva su mobilegmbapi sviluppa software per la local SEO, e lo fa bene. A luglio 2026 sono passati da WordPress a un nuovo sito in React e Next.js su un CMS headless. Su desktop rientrava nei Core Web Vitals. Su mobile, LCP, FCP e INP no.
Conosco Michel van Luijtelaar, che la guida, dal 2021. Mi ha chiesto di controllare il sito WordPress nel 2023 e di nuovo nel 2025, e a luglio 2026 è tornato con quello nuovo.
 Cosa abbiamo trovato, cosa abbiamo fatto
Morte per mille tagliNon c'era un unico grande problema, e non c'è quasi mai. Abbiamo registrato il caricamento di una pagina mobile in DevTools, analizzato la trace dal primo byte al LCP e sistemato le cose mentre parlavamo.
Cosa non andava
Cosa abbiamo fatto
TTFB
Il server impiegava 3 secondi prima del primo byte. Ogni pagina veniva renderizzata a ogni richiesta e recuperava i contenuti live dal CMS headless; gli header di cache avevano no-store, quindi la CDN non salvava mai l'HTML.
Le pagine sono passate al rendering statico con ISR, le fetch al CMS sono state messe in cache e gli header ora permettono alla CDN di salvare l'HTML. La risposta del server è scesa a 700 ms, tutti tolti da FCP e LCP prima ancora di toccare il resto.
LCPINP
Tag e analytics nell'head, widget di terze parti in cima alla pagina e componenti renderizzati nel browser che il server poteva renderizzare altrettanto bene. Tutto quel JavaScript serviva; veniva solo eseguito troppo presto.
Tag e widget ora aspettano che la pagina sia pronta, e quei componenti arrivano dal server
LCP
L'hero era in lazy loading. Passava da next/image senza priority, il blocco del CMS impostava loading="lazy" su ogni immagine e, dove l'hero era uno sfondo CSS, il browser lo trovava troppo tardi.
L'hero ha ricevuto priority e fetchpriority="high", il blocco del CMS un'eccezione per la prima immagine e lo sfondo CSS è diventato un vero tag img con preload. Insieme hanno tolto 120 ms al LCP.
LCP
Due fogli di stile, da 30 kB e 0,5 kB, che il primo schermo doveva attendere.
Riscritti entrambi a 15 kB complessivi, togliendo altri 100 ms.
LCP
Tante piccole cose, nessuna critica da sola.
Abbiamo continuato a scorrere la trace e le abbiamo sistemate una a una mentre parlavamo.
Su CrUX
È il grafico che speri di vedere. Il LCP per i visitatori da mobile è passato da 5,6 secondi nel momento peggiore a 2,0, e la risposta del server da 4,2 a 0,8 secondi. Entrambe le curve impiegano settimane a scendere, perché ogni punto include ancora i giorni lenti nella finestra di 28 giorni. Da agosto il LCP è rimasto stabile tra 1,9 e 2,2 secondi.
2,5 s4,0 sFebMarAprMagGiuLugAgoSetOtt3,8 s2,0 s5,6 sLCP su mobile, p75
0,8 s1,8 sFebMarAprMagGiuLugAgoSetOtt2,0 s0,76 s4,2 sTTFB su mobile, p75
gmbapi.com su CrUX, da gennaio a ottobre 2026. Ogni punto rappresenta i 28 giorni precedenti a quella data. Verde è buono, arancione da migliorare, rosso scarso.
Follow-up
Dopo la call ho dato loro accesso a CoreDash, così vedono i visitatori da mobile per pagina e per release, e ho controllato la loro task list. I numeri in alto arrivano da CrUX, i field data ufficiali di Google.
Un'ora basta quando gli sviluppatori sono in call e i fix sono piccoli. Le cose più grandi finiscono nelle note, in ordine di importanza.
 Cosa abbiamo imparato
La loro ipotesi era il JavaScript inutilizzatoUn'ipotesi ragionevole su un sito React nuovo. La trace ha messo in cima la risposta del server e un hero in lazy loading.
Un nuovo framework non ti rende veloceErano appena passati a Next.js, e con il framework sono arrivati anche i suoi default: next/image applica il lazy loading a ogni immagine a meno che non imposti priority, e l'hero era una di quelle.
 Un'ora con gli sviluppatori in call: 350 €Porta lo sviluppatore e la pagina più lenta. La guardiamo insieme e sistemiamo quello che possiamo mentre parliamo.
Prenota una power hourAltri risultati nella pagina clienti.
Core Web Vitals gmbapi: LCP da 5 a 1,9 secondi in una sola call