Un catalogo che apre in due secondi e un checkout che si pianta al pagamento è un negozio chiuso. Si misura dove si compra, non dove si guarda la vetrina.
Un ecommerce lento non si giudica dalla home. Si giudica dalla scheda prodotto, dal carrello, dal checkout: i tre URL su cui si decide l'acquisto. Una vetrina veloce e un pagamento che non risponde al tap è un negozio chiuso. Si misura lì, con le stesse soglie di sempre, non con un punteggio PageSpeed sulla homepage e un "poi vediamo il resto".
In breve: Per un'esperienza buona, web.dev chiede LCP entro 2,5 secondi, INP entro 200 millisecondi, CLS entro 0,1, al 75° percentile. Si applicano a PDP, carrello e checkout, non solo alla home. Script di pagamento, recensioni, tag manager pesano sull'INP. Non si citano qui percentuali di conversione "guadagnate": non sono in queste fonti, e non si inventano.
Cosa trovi in questo articolo
Le soglie, e dove applicarle
Google chiama LCP, INP e CLS Core Web Vitals. Entrano nella page experience di Search. Non sostituiscono catalogo, prezzo, logistica. Restano il modo ripetibile per dire se la pagina è usabile. Il dettaglio delle tre metriche sta nel pezzo sulla performance del sito: qui conta dove le misuri.
Search e gli utenti atterrano sulla scheda, su una categoria, su un link a un carrello abbandonato. I Vitals si valutano per URL, non per "il sito in media". Una home da laboratorio e una PDP da 4 MB di immagini sono due prodotti. Stesso discorso per il campo (CrUX, Search Console) contro Lighthouse in ufficio. Si crede al campo. Si usa il laboratorio per capire quale elemento è l'LCP e quale task blocca l'INP.
Google Search Central ha una sezione ecommerce: strutturazione, dati, visibilità. Non è un permesso a ottimizzare solo la vetrina. Se il checkout è un altro host, un altro template, un altro bundle JS, va misurato lì, con le sue terze parti, non ereditando il verde della home.
Scheda prodotto: LCP e peso della pagina
Sulla PDP l'LCP è quasi sempre l'immagine principale o il blocco titolo-prezzo. Se l'hero è una JPEG enorme, se il gallery attende un JS, se un banner cookie spinge giù il contenuto, i 2,5 secondi se ne vanno prima del testo. Si dichiara width e height, si dà priorità all'immagine LCP, si evita che un carosello nasconda la prima slide dietro tre librerie. Il CLS nasce dalle stesse immagini senza spazio, dalle recensioni che si iniettano dopo, dal font del prezzo che arriva tardi.
Dietro la scheda c'è spesso il database: prezzo, scorta, varianti. Una query lenta sulla PDP si vede come TTFB, poi come LCP. Prima di "aggiungere RAM", si guarda la query: è il mestiere del pezzo sul database lento. La cache HTTP aiuta se la scheda è pubblica e sai invalidare su cambio prezzo o stock. Non aiuta se ogni PDP è personalizzata da un layer di raccomandazioni che gira in JS al paint.
Varianti, zoom, video: ognuno aggiunge byte e lavoro sul thread principale. Si pesano. Si caricano dopo il primo contenuto utile. Un configuratore che ricalcola il DOM a ogni tap è un problema di INP, non di CDN.
Carrello: HTML che non si può cachare in pubblico
Il carrello è stato, non catalogo. Dipende dalla sessione. Non va in una cache CDN pubblica. La guida alla cache HTTP dice la stessa cosa per checkout e account: private, spesso no-store. Se "ottimizzi" il carrello cachandolo, servi quantità e prezzi di un altro momento, o di un altro utente. Velocità falsa, bug vero.
Quello che puoi fare: origine decente, query di riga carrello semplici, niente HTML da 800 KB per tre prodotti, niente widget di recensioni sulla pagina in cui si cambia quantità. L'INP qui è il tap su "aggiorna" e "procedi". Un listener pesante, un ricalcolo sconti in JS sincrono, un tag manager che spara quattro tag a ogni mutation: il bottone fa finta.
Mini-cart in header su tutte le pagine: comodo, e costoso se tira un round-trip o un bundle a ogni view. Si misura. Se la maggior parte delle visite non lo apre, non deve pagare il parse di quel JS sulla PDP.
Checkout: INP, iframe, third-party
Il checkout è il prodotto. LCP conta ancora (form visibile, riepilogo), ma l'INP è il metro onesto: campo, tap su paga, cambio metodo di spedizione. Soglia buona: 200 ms al 75° percentile. Sopra, l'utente doppio-clicca, invia due volte, abbandona. Il CLS su un form è un clic sul bottone sbagliato. width, height, slot per iframe di pagamento: si riservano prima, non dopo il load dello script della banca.
I hosted field e gli iframe del PSP sono terze parti necessarie. Non si "ottimizzano" comprimendoli. Si fa in modo che il resto della pagina non li aspetti per diventare interattiva, e che non si accumulino tre SDK di pagamento "perché un giorno attiveremo anche X". Un SDK in pagina è costo certo. Un metodo spento nel backend non giustifica il parse sul telefono.
Guest checkout contro account obbligatorio è una scelta di prodotto con effetto su round-trip e JS. Non si risolve con una CDN. Si risolve togliendo passi, validazioni sincrone ridondanti, script che non servono a chi sta pagando.
Pagamenti, recensioni, tag manager
Le terze parti più comuni su un negozio: gateway, recensioni, chat, A/B test, pixel, GTM con un contenitore cresciuto a strati. Ognuna può essere lecita. Ognuna occupa il thread principale. L'INP peggiora qui più che su un'immagine da 200 KB. Si elenca cosa c'è in pagina sul checkout, si toglie ciò che non serve a pagare, si rinvia ciò che può aspettare il primo ordine completato.
GTM non è "gratis". È un loader di altro JS. Un contenitore senza owner, senza scadenza dei tag, è debito. Le recensioni in above-the-fold sulla PDP possono essere LCP o CLS; in checkout non hanno mestiere. La chat che si apre da sola sul form di pagamento compete con il tap. Si misura INP prima e dopo, sul campo, su quegli URL. Non si discute in riunione sul "si è sempre fatto così".
Se lo stack è cresciuto a plugin e snippet, il problema è di prodotto, non di un optimizer. È il tipo di intervento che coprono i servizi di sviluppo web di Keidea, o una piattaforma KeideaCMS se il catalogo vive su un CMS tenuto insieme da estensioni. L'articolo resta vero senza quei nomi: meno JS sul path di acquisto, misure sulle URL giuste, terze parti con un owner.
Errori da evitare
Ottimizzare la home e dichiarare il negozio veloce. Si compra sulla scheda e si paga al checkout.
Cachare in pubblico HTML di carrello e checkout. Non è performance, è un bug in attesa.
Inseguire il punteggio Lighthouse e ignorare CrUX su PDP e checkout. Il campo vince.
Caricare tre SDK di pagamento "per completezza". Si paga in INP anche i metodi spenti.
Mettere recensioni, chat e pixel sopra il form di paga. Il tap deve arrivare al frame successivo, non alla coda dei tag.
Promettere un lift di conversione in percentuale. Le soglie di web.dev non lo fanno. Non lo fa nemmeno questo articolo.
In sintesi
Si misura dove si compra: scheda, carrello, checkout. LCP 2,5 s, INP 200 ms, CLS 0,1, al 75° percentile, sulle URL vere, sul campo. La PDP si tiene leggera e prevedibile. Il carrello non va in cache pubblica. Il checkout si difende dalle terze parti, non si "arricchisce". Pagamenti, recensioni, tag manager hanno un costo sul thread principale; si tiene solo ciò che ha un owner e uno scopo su quella pagina. Il resto, home verde e plugin optimizer, è rumore.
Gli altri pezzi del laboratorio stanno nel cluster Performance. Questo è il taglio ecommerce: se il checkout è lento, il negozio è lento. Punto.
Fonti
web.dev, Web Vitals (soglie LCP, INP, CLS, 75° percentile).
web.dev, Largest Contentful Paint (LCP).
web.dev, Interaction to Next Paint (INP).
Google Search Central, Understanding Core Web Vitals and Google search results.
Google Search Central, Ecommerce.
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
