Core Web Vitals: come migliorare LCP, INP e CLS

Il motore di ricerca non si limita più a leggere le parole chiave presenti in una pagina. Valuta la frustrazione di chi naviga. Quando un utente clicca su un risultato di ricerca, si aspetta un caricamento istantaneo, un’interfaccia reattiva e un layout che non salti all’improvviso. Google ha quantificato queste aspettative attraverso i Core Web Vitals, trasformando la qualità tecnica del frontend in un parametro di valutazione ufficiale all’interno del Page Experience Update.

Ottimizzare queste metriche significa intervenire direttamente sull’architettura della pagina. Richiede precisione chirurgica nella gestione delle risorse, dalla priorità di caricamento delle immagini all’esecuzione degli script. A marzo 2024, l’algoritmo ha subito una mutazione fondamentale: la metrica INP ha ufficialmente sostituito il FID, imponendo nuovi standard per misurare l’interattività. Questo cambiamento costringe sviluppatori e specialisti SEO a rivedere le proprie strategie di ottimizzazione, spostando l’attenzione dall’istante iniziale alla latenza complessiva dell’intera sessione di navigazione.

Cosa sono i Core Web Vitals e perché determinano il successo SEO

I Core Web Vitals sono un sottoinsieme specifico di metriche all’interno dei segnali della User Experience (UX) di Google. Non misurano la pertinenza del testo rispetto alla query dell’utente, ma quantificano l’usabilità tecnica della pagina web. Si concentrano su tre dimensioni fisiche dell’esperienza di navigazione: la velocità di rendering visibile, la reattività ai comandi dell’utente e la stabilità degli elementi a schermo durante il caricamento.

Dal punto di vista del posizionamento organico, il contenuto di altissima qualità rimane il fattore primario. Tuttavia, i Core Web Vitals agiscono come fattore di spareggio, o “tie-breaker”. Se due pagine offrono informazioni altrettanto valide e possiedono un profilo backlink simile, l’algoritmo preferirà e posizionerà più in alto la pagina che garantisce l’esperienza tecnica superiore. Ignorare questi parametri significa concedere un vantaggio competitivo gratuito ai concorrenti diretti nelle SERP. Se desideri un audit tecnico completo, il team di DB Agenzie Italia è a disposizione per una consulenza personalizzata sui Core Web Vitals.

L’impatto di queste metriche si estende ben oltre la semplice acquisizione di traffico organico, colpendo direttamente il tasso di conversione. Dati alla mano, colossi come Amazon e Google hanno dimostrato ripetutamente che frazioni di secondo di ritardo nel caricamento causano cali drastici nelle vendite e nell’engagement. Una pagina lenta o instabile genera rimbalzi immediati. Ottimizzare LCP, INP e CLS significa trattenere l’utente sul sito, abbassare il costo di acquisizione e massimizzare la probabilità che compia l’azione desiderata, che si tratti di un acquisto, della compilazione di un modulo o della lettura di un intero articolo.

Tabella riassuntiva: Soglie dei Core Web Vitals

Nota bene: Google valuta queste metriche basandosi sul 75° percentile dei dati field. Questo significa che affinché il tuo sito superi il test dei Core Web Vitals, almeno il 75% delle visite reali degli utenti deve registrare prestazioni rientranti nella fascia verde per ciascuna metrica analizzata.

Come misurare i Core Web Vitals: Dati Lab vs Dati Field

L’errore più comune nell’ottimizzazione delle performance è confondere gli strumenti di misurazione. Per diagnosticare e risolvere i colli di bottiglia, è imperativo comprendere la differenza strutturale tra i dati raccolti sul campo e le simulazioni di laboratorio. Affidarsi esclusivamente a un solo tipo di dato porta a diagnosi errate e a ore di lavoro sprecate su problemi inesistenti.

Dati Field (CrUX – Chrome User Experience Report)

I Dati Field rappresentano la verità assoluta per l’algoritmo di Google. Sono i dati reali di telemetria raccolti in forma anonima dagli utenti che navigano il sito utilizzando il browser Google Chrome. Queste misurazioni tengono conto delle reali condizioni di rete, della potenza dei dispositivi mobili utilizzati e del comportamento effettivo di chi interagisce con le pagine.

Questi sono gli unici numeri che influenzano il ranking. Per analizzarli, lo strumento principale è il rapporto “Segnali web essenziali” all’interno di Google Search Console, che raggruppa gli URL per tipologia di problema. Un’altra fonte immediata è la sezione superiore di PageSpeed Insights, specificatamente l’area denominata “Scopri cosa provano i tuoi utenti reali”. Se i dati field indicano un problema, significa che gli utenti stanno concretamente soffrendo durante la navigazione sul sito.

Dati Lab

I Dati Lab sono simulazioni eseguite in un ambiente strettamente controllato. Vengono generati caricando la pagina da un server specifico, con una connessione di rete e un dispositivo emulati artificialmente. Non tengono conto delle variabili imprevedibili del mondo reale, come un utente che scorre velocemente la pagina prima che sia completamente caricata.

Strumenti come Google Lighthouse (integrato nei Chrome DevTools) o l’estensione Web Vitals per Chrome forniscono esclusivamente dati di laboratorio. Il loro scopo non è dirti come Google valuta il tuo sito in ottica SEO, ma offrirti un ambiente di debugging riproducibile. Modifichi il codice, lanci Lighthouse e vedi immediatamente se la modifica ha ridotto il tempo di esecuzione di uno script. Sono lo strumento diagnostico per lo sviluppatore, non la pagella finale.

LCP (Largest Contentful Paint): Ottimizzare il tempo di caricamento

Il Largest Contentful Paint misura il tempo esatto necessario affinché il browser riesca a renderizzare l’elemento visibile più grande all’interno della viewport iniziale dell’utente (la porzione di schermo visibile senza scorrere, nota come above the fold). Questo elemento può essere un’immagine di copertina, un video, o un blocco di testo massiccio come il titolo principale.

Google impone soglie rigide per questa metrica. Per superare il test, l’LCP deve verificarsi entro 2,5 secondi dall’inizio del caricamento della pagina. Tempi compresi tra 2,5 e 4,0 secondi richiedono miglioramenti, mentre un LCP superiore ai 4,0 secondi viene classificato come scadente, penalizzando l’esperienza utente.

Come trovare l’elemento LCP della tua pagina

Prima di poter ottimizzare l’LCP, è fondamentale identificare con precisione quale elemento rappresenta il Largest Contentful Paint per quella specifica pagina. L’elemento LCP può variare significativamente tra la versione mobile e quella desktop del sito. Generalmente si tratta di tag <img>, video con attributo poster, elementi con background-image in CSS o blocchi di testo massicci come un H1.

Ecco tre metodi pratici per individuarlo:

• PageSpeed Insights: Esegui un test del tuo URL. Scorri fino alla sezione diagnostica e cerca la voce “Elemento Largest Contentful Paint”. Lo strumento mostrerà il nodo HTML esatto evidenziato in un riquadro.
• Chrome DevTools (Performance Panel): Apri gli strumenti per sviluppatori di Chrome (F12), vai sulla tab “Performance”, registra un caricamento della pagina e cerca l’indicatore “LCP” nella timeline. Cliccandoci, il browser evidenzierà l’elemento nel DOM.
• Estensione Web Vitals: Installando l’estensione ufficiale per Chrome, potrai visualizzare un overlay in tempo reale che evidenzia l’elemento LCP corrente mentre navighi sul tuo sito.

Differenza tra LCP e FCP

Spesso si tende a confondere l’LCP con il FCP (First Contentful Paint), ma misurano due momenti ben distinti dell’esperienza utente. Il FCP registra l’istante in cui il browser renderizza il primo elemento visivo in assoluto, che potrebbe essere anche solo un’icona di caricamento o il colore di sfondo. Non è necessariamente un’informazione utile per chi naviga.

L’LCP, al contrario, misura quando appare l’elemento più grande e significativo nella porzione di schermo visibile. È il momento esatto in cui l’utente percepisce che “la pagina si è caricata”. Ad esempio, in un articolo di blog, il FCP potrebbe essere il logo del sito (visibile dopo 0,8 secondi), mentre l’LCP è l’immagine di copertina dell’articolo (visibile dopo 2,3 secondi). Google utilizza l’LCP come Core Web Vital proprio perché riflette in modo molto più accurato la reale percezione dell’utente.

Cause comuni di un LCP lento

• Tempi di risposta del server lenti: Un TTFB (Time to First Byte) elevato significa che il server impiega troppo tempo per elaborare la richiesta e inviare il primo frammento di codice HTML al browser. Diventa quindi cruciale sapere come scegliere il provider hosting giusto fin dall’inizio del progetto. Se il server è lento, tutto il resto subirà un ritardo a catena.
• Risorse Render-blocking: File CSS e JavaScript caricati in modo sincrono nella sezione <head> del documento costringono il browser a fermare la costruzione della pagina per scaricarli ed eseguirli, ritardando la visualizzazione dell’elemento LCP.
• Tempi di caricamento delle risorse lenti: Immagini hero non compresse, caricate alle dimensioni originali o in formati obsoleti, saturano la larghezza di banda e richiedono secondi preziosi per essere scaricate.
• Rendering lato client non ottimizzato: Nei siti costruiti con framework JavaScript (Client-side rendering), l’elemento LCP potrebbe apparire solo dopo che enormi bundle di codice sono stati scaricati, parsati ed eseguiti.

Le 4 fasi dell’LCP e come ottimizzarle

Per diagnosticare correttamente un LCP lento, è necessario scomporre il tempo totale di caricamento nelle sue 4 fasi tecniche fondamentali. Ottimizzare l’LCP significa ridurre il tempo speso in ciascuna di queste sotto-categorie, non solo concentrarsi sulla velocità del server.

1. TTFB (Time to First Byte): È il tempo che intercorre dal click dell’utente alla ricezione del primo frammento di HTML dal server. Consuma tipicamente una fetta importante del budget LCP. Azione principale: Utilizza una CDN e un sistema di caching aggressivo lato server.
2. Resource Load Delay: Il ritardo tra la ricezione dell’HTML e l’inizio effettivo del download della risorsa LCP (es. l’immagine hero). Azione principale: Inserisci l’attributo fetchpriority="high" sull’immagine LCP per istruire il browser a scaricarla immediatamente.
3. Resource Load Time: Il tempo materiale necessario per scaricare la risorsa LCP attraverso la rete. Azione principale: Comprimi l’immagine usando formati Next-Gen come WebP o AVIF e servila nelle dimensioni corrette tramite attributi srcset.
4. Element Render Delay: Il tempo che passa tra il completamento del download della risorsa e la sua effettiva comparsa a schermo. Azione principale: Evita che file CSS o JavaScript blocchino il rendering (render-blocking resources) estraendo il Critical CSS.

Ricorda: ottimizzare l’LCP significa ridurre ognuna di queste 4 fasi in modo sinergico.

Soluzioni pratiche per migliorare l’LCP

• Assegnare la priorità all’elemento LCP: Il browser deve sapere immediatamente quale immagine è la più importante. Utilizza l’attributo fetchpriority="high" sul tag <img> dell’immagine hero. Al contrario, non applicare mai e poi mai il Lazy Loading alle immagini above the fold: ritardare il caricamento dell’elemento principale distrugge letteralmente il punteggio LCP.
• Ottimizzazione drastica delle immagini: Abbandona i formati tradizionali. Converti le immagini in formati Next-Gen come WebP o, ancora meglio, AVIF. Implementa attributi srcset per servire immagini ridimensionate in base alla larghezza dello schermo del dispositivo, evitando di inviare file da 2000 pixel a uno smartphone.
• Gestione avanzata di CSS e JS: Minifica tutti i file di stile e script. Utilizza gli attributi defer o async per i file JavaScript non critici. Estrai il Critical CSS (gli stili necessari per renderizzare la parte superiore della pagina) e inseriscilo inline direttamente nell’HTML, differendo il caricamento del foglio di stile principale.
• Potenziamento dell’infrastruttura server: Abbatti il TTFB implementando una CDN (Content Delivery Network) per distribuire i file statici da server fisicamente vicini all’utente. Attiva sistemi di caching aggressivi a livello di server (come Redis o Memcached) e di pagina intera (Full Page Cache). Assicurati che il CMS giri sull’ultima versione stabile di PHP o del linguaggio di backend utilizzato.

INP (Interaction to Next Paint): La nuova metrica di interattività

L’Interaction to Next Paint ha rivoluzionato il modo in cui misuriamo la reattività. Fino a marzo 2024, Google utilizzava il FID (First Input Delay), che presentava un difetto strutturale: misurava esclusivamente il ritardo della primissima interazione dell’utente e ignorava il tempo di elaborazione dell’evento stesso. L’INP, invece, campiona e valuta la latenza di tutte le interazioni (click del mouse, tap sullo schermo, pressione di tasti sulla tastiera) per l’intera durata della visita sulla pagina.

L’INP registra il tempo che intercorre tra l’azione dell’utente e il momento in cui il browser è effettivamente in grado di mostrare il fotogramma successivo (Next Paint) con l’aggiornamento visivo richiesto. Un INP eccellente deve essere inferiore a 200 millisecondi. Tra 200 e 500 millisecondi la pagina necessita di ottimizzazioni, mentre oltre i 500 millisecondi l’esperienza risulta palesemente laggosa e frustrante per l’utente.

Perché l’INP ha sostituito il FID: differenze chiave

A marzo 2024, Google ha ufficialmente mandato in pensione il FID (First Input Delay) in favore dell’INP. Il motivo risiede in un difetto strutturale del FID: misurava esclusivamente il ritardo della prima interazione (Input Delay), ignorando del tutto il tempo necessario al browser per elaborare l’evento e aggiornare lo schermo.

Una pagina poteva vantare un FID eccellente di 50ms, ma risultare poi terribilmente lenta e bloccata durante l’uso di un menu a tendina o di un carosello. L’INP risolve questo problema misurando la latenza end-to-end (dall’input al rendering visivo) di tutte le interazioni che avvengono durante l’intera sessione di navigazione, riportando il valore peggiore al 75° percentile. È una metrica molto più severa, ma infinitamente più rappresentativa della reale frustrazione dell’utente.

Cause comuni di un INP scarso

• Thread Principale (Main Thread) bloccato: Il browser esegue il JavaScript, calcola gli stili e disegna la pagina su un singolo thread. Se uno script JavaScript impiega troppo tempo per essere eseguito (i cosiddetti Long Tasks), il thread si blocca. Durante questo blocco, il browser non può rispondere ai tap o ai click dell’utente.
• Esecuzione eccessiva di codice di terze parti: Pixel di tracciamento multipli, widget per le chat di supporto, script pubblicitari o tool di analisi del comportamento (come Hotjar) iniettano enormi quantità di codice JavaScript che monopolizzano le risorse della CPU del dispositivo.
• DOM eccessivamente grande e complesso: Il Document Object Model è la struttura ad albero della pagina. Un DOM con migliaia di nodi obbliga il browser a impiegare moltissimo tempo per ricalcolare gli stili e il layout ogni volta che un’interazione modifica un singolo elemento.

Le 3 fasi dell’INP: Input Delay, Processing Time e Presentation Delay

Esattamente come per l’LCP, anche l’Interaction to Next Paint si compone di tre fasi distinte. Comprendere dove si accumula il ritardo è il primo passo per risolverlo. Poiché l’INP sceglie l’interazione peggiore della sessione, è vitale ottimizzare tutte le interazioni, non solo la prima.

1. Input Delay (Ritardo di Input): È il tempo che intercorre tra l’azione fisica dell’utente (click, tap) e il momento in cui il browser è libero di iniziare a eseguire il codice JavaScript associato. Causa principale: Il Main Thread è occupato da altri processi pesanti (Long Tasks superiori a 50ms). Azione pratica: Fraziona i task JavaScript lunghi per liberare il thread principale.
2. Processing Time (Tempo di Elaborazione): Il tempo effettivo impiegato dal browser per eseguire i callback JavaScript legati a quell’evento. Causa principale: Funzioni JS troppo complesse o manipolazioni massive del DOM. Azione pratica: Ottimizza la logica del codice e rimuovi script di terze parti non strettamente necessari.
3. Presentation Delay (Ritardo di Presentazione): Il tempo tra la fine dell’elaborazione JS e il momento in cui il browser riesce a ricalcolare il layout e dipingere i nuovi pixel a schermo. Causa principale: Un DOM eccessivamente grande e ricalcoli di stile complessi. Azione pratica: Riduci la profondità dell’albero DOM ed evita animazioni che innescano continui ricalcoli di layout.

Soluzioni pratiche per migliorare l’INP

• Spezzare i task lunghi (Yielding to the Main Thread): Qualsiasi operazione JavaScript che superi i 50 millisecondi è un Long Task. Devi frammentare queste operazioni. Utilizza tecniche come setTimeout per cedere temporaneamente il controllo al thread principale, permettendogli di processare le interazioni dell’utente in sospeso prima di riprendere l’esecuzione dello script. Le API più recenti, come scheduler.yield(), offrono un controllo ancora più granulare su questo processo.
• Ridurre drasticamente le dimensioni del DOM: Google consiglia esplicitamente di mantenere il numero totale di nodi DOM al di sotto di 1.500, con una profondità massima di 32 livelli. Evita di annidare div dentro altri div senza una reale necessità semantica o strutturale. Semplifica il layout e usa CSS Grid o Flexbox per posizionare gli elementi invece di moltiplicare i contenitori HTML.
• Gestione chirurgica degli script Third-Party: Non caricare script non essenziali al caricamento della pagina. Ritarda (delay) l’esecuzione dei widget di chat, dei pixel secondari o dei pulsanti di condivisione social fino a quando l’utente non esegue uno scroll o muove il mouse.
• Evitare il Layout Thrashing: Quando crei animazioni o modifichi l’interfaccia, evita di animare proprietà che forzano il browser a ricalcolare le geometrie della pagina (come width, height, top o left). Utilizza esclusivamente proprietà CSS accelerate via hardware, come transform e opacity.

CLS (Cumulative Layout Shift): Garantire la stabilità visiva

Il Cumulative Layout Shift valuta un aspetto profondamente irritante della navigazione: l’instabilità visiva. Misura la somma totale di tutti i cambiamenti di layout imprevisti che si verificano durante l’intera vita della pagina. Accade quando un elemento visibile cambia improvvisamente posizione, spingendo il contenuto verso il basso o di lato senza preavviso.

Il classico esempio è l’utente che sta per toccare un pulsante o un link testuale, ma un’immagine o un banner pubblicitario si carica improvvisamente sopra di esso, spostando il pulsante e causando un click accidentale su un’inserzione. Google richiede un punteggio CLS inferiore a 0.1 per considerare la pagina stabile. Fino a 0.25 la situazione è migliorabile, oltre è classificata come scadente.

Cause comuni di un CLS elevato

• Elementi multimediali senza dimensioni dichiarate: Immagini, video e iframe inseriti nell’HTML senza gli attributi fisici di larghezza e altezza. Il browser non sa quanto spazio occuperanno finché non li ha scaricati completamente, causando un collasso del layout al loro apparire.
• Annunci pubblicitari e widget iniettati dinamicamente: I network pubblicitari spesso caricano banner di dimensioni variabili in modo asincrono. Se il contenitore dell’annuncio non ha uno spazio pre-riservato, l’inserimento del banner spingerà giù tutto il contenuto sottostante.
• Web Fonts non ottimizzati: Il caricamento di font personalizzati causa due fenomeni: il FOIT (Flash of Invisible Text), dove il testo rimane invisibile finché il font non è pronto, o il FOUT (Flash of Unstyled Text), dove il testo viene mostrato con un font di sistema per poi cambiare bruscamente stile e dimensioni quando il web font viene applicato.
• Contenuto iniettato dinamicamente: Banner di iscrizione alla newsletter, avvisi sui cookie o prodotti correlati caricati via JavaScript sopra i contenuti già renderizzati.

Soluzioni pratiche per migliorare il CLS

• Dichiarare sempre gli attributi dimensionali: Inserisci sistematicamente gli attributi width e height in ogni tag <img>, <video> e <iframe>. I browser moderni utilizzano questi valori per calcolare automaticamente l’aspect ratio (le proporzioni) dell’elemento e riservare l’esatto spazio vuoto necessario sullo schermo prima ancora che il file venga scaricato.
• Riservare spazio rigido per gli elementi dinamici: Crea contenitori statici per gli annunci pubblicitari o i widget esterni. Utilizza la proprietà CSS min-height o la più moderna aspect-ratio per definire le dimensioni della scatola che conterrà l’annuncio. Se l’annuncio non viene caricato, mostrerai uno spazio vuoto, ma eviterai disastrosi salti di layout.
• Ottimizzazione drastica della tipografia: Utilizza la direttiva CSS font-display: swap (o optional) all’interno delle dichiarazioni @font-face. Per eliminare totalmente il salto causato dal FOUT, sfrutta le nuove API CSS come size-adjust, ascent-override e descent-override per manipolare le dimensioni del font di fallback (quello di sistema) affinché occupi esattamente lo stesso spazio fisico del tuo font personalizzato.

Ottimizzare i Core Web Vitals sui CMS (Focus WordPress)

La teoria dell’ottimizzazione si scontra spesso con la realtà di piattaforme prestrutturate come WordPress. Chi amministra un CMS raramente scrive codice da zero, ma assembla temi, plugin e costruttori visivi. In questo ecosistema, le performance degradano rapidamente a causa della stratificazione di codice ridondante generato da strumenti di terze parti.

La scelta del tema e del Page Builder determina l’80% del successo o del fallimento sui Core Web Vitals. Page builder obsoleti o configurati male (come le vecchie versioni di Elementor o WPBakery) generano una quantità spaventosa di nodi DOM (Divception), distruggendo l’INP e appesantendo l’LCP. La soluzione radicale è migrare verso temi nativamente leggeri e modulari come GeneratePress o Astra, abbinati all’editor a blocchi nativo (Gutenberg), che produce un markup HTML infinitamente più pulito e scarno.

L’implementazione di plugin di Caching e Performance di livello enterprise è obbligatoria. Soluzioni come WP Rocket, Perfmatters o LiteSpeed Cache (se il server usa LiteSpeed) non si limitano a creare file HTML statici. Per dominare l’INP e l’LCP, devi attivare funzioni avanzate specifiche: la “Rimozione del CSS inutilizzato” (che genera un file CSS critico per ogni singola pagina) e la funzione per “Ritardare l’esecuzione di JavaScript” (Delay JS), che blocca l’esecuzione di script pesanti finché l’utente non muove il mouse o tocca lo schermo.

Per la gestione visiva e la stabilità del CLS, l’ottimizzazione delle immagini deve essere automatizzata. Plugin come ShortPixel o Imagify intervengono direttamente in fase di caricamento nella libreria media. Non solo comprimono il file originale, ma generano automaticamente le versioni WebP o AVIF, servendole al browser corretto tramite regole di riscrittura sul server, eliminando il peso in eccesso senza richiedere alcun intervento manuale dell’amministratore.

Plugin consigliati per i Core Web Vitals su WordPress

WordPress offre un ecosistema vastissimo, ma per dominare i Core Web Vitals servono strumenti mirati. Per la gestione della cache e l’ottimizzazione del codice, plugin premium come WP Rocket o soluzioni server-side come LiteSpeed Cache sono imprescindibili. Per le immagini, affidati a ShortPixel o Imagify per la conversione automatica in WebP o AVIF. Infine, per pulire il codice inutile caricato dai temi, Perfmatters o Asset CleanUp ti permettono di disabilitare CSS e JS superflui pagina per pagina.

L’importanza dell’hosting per i Core Web Vitals

Nessun plugin potrà mai compensare un server strutturalmente lento. Un hosting di bassa qualità con un TTFB superiore a 600ms rende matematicamente impossibile ottenere un LCP in fascia verde (sotto i 2,5s). Scegli un provider cloud o un hosting gestito ottimizzato per WordPress, preferibilmente con dischi NVMe e integrazione nativa con CDN di livello enterprise come Cloudflare.

Inoltre, fai una spietata pulizia dei plugin: ogni estensione attiva aggiunge potenziale JavaScript al Main Thread. Un numero eccessivo di plugin degrada inesorabilmente il tuo punteggio INP, bloccando la reattività del sito durante le interazioni degli utenti.

L’ottimizzazione continua delle performance

Raggiungere la zona verde sui Core Web Vitals non è un traguardo definitivo, ma una linea di partenza. La manutenzione delle performance tecniche richiede un monitoraggio costante. L’installazione di un nuovo plugin per il marketing, l’aggiunta di un banner promozionale in homepage o l’aggiornamento del tema possono reintrodurre colli di bottiglia, alterando i punteggi dall’oggi al domani.

L’approccio corretto prevede audit periodici. Il punto di partenza ideale è sempre l’LCP, poiché dipende in gran parte dall’infrastruttura server e dal peso degli asset, rendendolo il parametro più meccanico e diretto da risolvere. Successivamente, si stabilizza l’interfaccia bloccando le dimensioni degli elementi per azzerare il CLS. L’INP, essendo profondamente legato all’esecuzione del codice JavaScript e alla complessità del DOM, richiede interventi architetturali più raffinati e rappresenta l’ultimo, decisivo passo verso l’eccellenza tecnica.

Apri immediatamente Google Search Console, estrai il rapporto sui Segnali web essenziali e identifica gli URL critici. Inserisci quelle pagine in PageSpeed Insights per isolare gli script bloccanti o le immagini non ottimizzate. Ogni millisecondo recuperato sul thread principale e ogni kilobyte rimosso dal caricamento iniziale si trasformerà in un segnale di qualità inequivocabile per l’algoritmo di ricerca e in un’esperienza senza attriti per i tuoi utenti.

FAQ sui Core Web Vitals