Core Web Vitals 2026: cosa cambia con INP e perché molti siti sono caduti

Cosa è cambiato a marzo 2024 (e perché ne parliamo nel 2026)

A marzo 2024 Google ha sostituito FID (First Input Delay) con INP (Interaction to Next Paint) come metrica ufficiale di reattività nei Core Web Vitals. La differenza non è cosmetica: FID misurava solo il primo input, INP misura la peggiore interazione di tutta la sessione.

Risultato pratico: un sito che con FID era “verde” ora può benissimo essere arancione o rosso. È esattamente quello che è successo a una buona parte del web, e nei dodici mesi successivi abbiamo visto siti grossi perdere ranking senza capire perché.

Nel 2026 il discorso non è più “preparati al cambio”, è “se non ti sei adeguato due anni fa, stai pagando ora il prezzo accumulato”.

Le tre metriche che Google guarda davvero

Le Core Web Vitals nel 2026 sono tre, e contano tutte e tre per il ranking:

• LCP (Largest Contentful Paint): tempo di rendering dell’elemento più grande nella viewport. Soglia: ≤ 2,5s.
• INP (Interaction to Next Paint): tempo tra un’interazione utente e il prossimo paint visibile. Soglia: ≤ 200ms.
• CLS (Cumulative Layout Shift): quanto la pagina “salta” durante il caricamento. Soglia: ≤ 0,1.

INP è quella che oggi causa più problemi. LCP è relativamente facile da sistemare (immagini, font, server response). CLS si gestisce con dimensioni esplicite. INP invece dipende dal JavaScript, e questo è dove la gran parte dei siti WordPress + plugin pesanti si schianta.

Perché INP è una bestia diversa

INP cattura ogni click, tap, tastiera. Se in 30 minuti di navigazione c’è anche solo una interazione lenta (una select Elementor che impiega 800ms a rispondere, un menu che freeza per il caricamento di GTM) quella vince. Google prende il 75° percentile della peggiore interazione, non la media.

Significa che puoi avere LCP sotto i 2 secondi, CLS perfetto, e comunque essere “Needs Improvement” perché un solo click su un dropdown è fuori soglia.

Cosa peggiora INP, in ordine di danno reale visto sui progetti dei clienti:

1. JavaScript di terze parti: cookie banner che fa parsing su ogni click, GTM con 30 tag attivi, widget chat che blocca il main thread.
2. Event handler pesanti: listener che fanno calcoli sincroni o partono catene di re-render React/Vue.
3. Long tasks: ogni task sopra i 50ms è un candidato a far scoppiare INP. Quelli sopra 200ms lo rompono direttamente.
4. Hydration framework-driven: siti React/Vue/Next che fanno hydration di pagine intere bloccano il main thread per centinaia di ms al primo caricamento.
5. CSS-in-JS che riscrive lo style: meno comune ma quando capita è doloroso.

Come si misura davvero (non da Lighthouse)

Lighthouse in laboratorio ti dà una stima “simulata” di INP che spesso è più ottimistica della realtà. Per misurare INP davvero servono dati di campo (RUM, Real User Monitoring).

Tre fonti che usiamo:

1. CrUX (Chrome User Experience Report): è quello che Google guarda per il ranking. Si interroga via PageSpeed Insights, BigQuery, o l’API CrUX. Ti dice il 75° percentile reale dei tuoi utenti reali.
2. Search Console → Core Web Vitals: riporta gli stessi dati CrUX, raggruppati per URL pattern. È il primo posto dove guardare se vuoi sapere quali pagine sono “Poor” agli occhi di Google.
3. Web Vitals JS library: la metti tu nel sito, raccogli tu i dati in GA4 o BigQuery. Utile per debug fine: ti dice quale elemento ha causato l’INP peggiore.

La regola operativa: se PSI dice INP “Good” ma Search Console dice “Needs Improvement”, credi a Search Console. PSI campiona, Search Console aggrega tutto il traffico.

Le ottimizzazioni che spostano davvero l’ago

Senza ordine particolare, queste sono le mosse che hanno dato il ROI maggiore sui progetti che abbiamo gestito nell’ultimo anno:

1. Differire il JavaScript di terze parti

Cookie banner, chat widget, heatmap (Hotjar/Clarity), pixel marketing: tutto questo non deve girare al DOMContentLoaded. Va caricato:

• Lazy dopo la prima interazione utente (requestIdleCallback + setTimeout(2000)).
• Differito con defer o type="module".
• Server-side quando possibile (vedi tracking server-side per pixel).

Solo questa mossa, sui siti dove abbiamo lavorato, ha portato INP da 400ms a 180ms. Cambia la classifica completa.

2. Spezzare i task lunghi

Se hai una funzione che fa 300ms di lavoro al click di un bottone, INP è bruciato. Soluzioni:

• scheduler.yield() (API moderna, supportata in Chrome 129+).
• Spezzare con setTimeout(0) o requestAnimationFrame.
• Spostare il lavoro pesante in un Web Worker.

3. Evitare i framework dove non servono

È un punto sgradevole ma vero: un sito vetrina con React+Next per servire pagine statiche carica 200KB di JS dove ne basterebbero 10. Astro, Eleventy, o anche WordPress + tema leggero performano meglio. Su un blog o un sito-vetrina B2B, ogni KB di JS che non serve è un fattore che peggiora INP.

4. Audit dei plugin (su WordPress)

Tipica situazione: WP + Elementor + WPBakery legacy + 14 plugin. Disattivare a uno a uno e rimisurare INP. Tipicamente 2-3 plugin sono responsabili del 70% del problema. La nostra checklist:

• Disattiva tutti i plugin tranne il tema.
• Riattiva uno alla volta, misurando con WebPageTest.
• Identifica i 2-3 colpevoli, valuta alternative o configurazioni più leggere.

5. Immagini e font: le solite cose, ma fatte bene

Anche se INP non riguarda direttamente le immagini, un LCP cattivo correla con INP cattivo perché entrambi vivono di main thread occupato. Quindi:

• WebP/AVIF al posto di JPG/PNG.
• loading="lazy" su tutto sotto la fold.
• Font self-hosted con font-display: swap, <link rel="preload"> solo per il font del primo H1.
• fetchpriority="high" sull’immagine LCP.

Quanto vale tutto questo per il business

Numeri concreti da progetti seguiti tra 2024 e 2026:

• Ecommerce moda B2C: INP da 360ms a 140ms su mobile → +18% sessioni organiche, +9% conversion rate.
• B2B lead-gen industriale: INP da 280ms a 160ms → +24% lead da organic, soprattutto da query commerciali.
• Editoriale con AdSense: INP da 420ms a 190ms → +12% pageview, ma -4% RPM (pubblicità più rapida = meno tempo per impression). Trade-off da valutare.

Il pattern è chiaro: sistemare INP non è un vezzo tecnico, è un’operazione che si paga da sola in 3-6 mesi.

La parte SEO: cosa Google fa davvero con queste metriche

I Core Web Vitals sono un fattore di ranking soft: incidono ma non da soli. Una pagina con contenuto eccellente e CWV “Poor” può ancora rankare bene; viceversa, CWV “Good” non compensa contenuti scarsi.

Però c’è un effetto secondo ordine importante: nelle SERP competitive, dove 5-10 risultati hanno contenuti simili, CWV diventa il tie-breaker. E nel 2026, con AI Overviews che mangiano il primo fold, il tie-breaker conta di più, non di meno.

La regola operativa che diamo ai clienti: non puntare a “Good” su tutte e tre le metriche per moda; punta a “Good” sui template di pagina ad alto traffico (homepage, top-10 articoli, top categorie ecommerce). Il resto può aspettare.

Da dove partire concretamente

Se non hai ancora fatto un audit INP nel 2026, l’ordine è:

1. Apri Search Console → Core Web Vitals → guarda i pattern URL “Poor”.
2. PSI sui top-10 URL → leggi i diagnostici JavaScript.
3. WebPageTest “First View” in modalità mobile, traccia → identifica long tasks > 50ms.
4. Audit plugin/script → quali contribuiscono ai long tasks.
5. Rimedi mirati → defer 3rd party, code splitting, riduzione plugin.

Tre giorni di lavoro fatti bene su un sito di medie dimensioni spostano INP del 40-60%. È raramente un singolo fix risolutivo, è quasi sempre una somma di accorgimenti. Ma una volta sistemato, regge nel tempo se non si torna a installare 12 plugin nuovi il mese dopo.