La Checklist Definitiva per i Core Web Vitals (2026)

Table of Contents!

• La checklist definitiva per i Core Web Vitals
• Checklist di ottimizzazione dei Core Web Vitals
  • Ottimizza le immagini
  • Ottimizza i web font
  • Ottimizza gli script
  • Ottimizza gli stili
  • Ottimizza i resource hint
  • Ottimizza le icone
  • Ottimizza i tempi di risposta del server
  • Ottimizza l'interattività
  • Monitoraggio dei Core Web Vitals
  • Ottimizza il percorso di rendering critico
  • Ottimizza il consenso ai cookie
  • Ottimizza le Single Page Application
  • Evita dimensioni eccessive del DOM
  • Ottimizza le richieste API
  • Ottimizza i widget di chat
  • Ottimizza le prestazioni del service worker
  • Ottimizza i contenuti video

Ottimizza le immagini

Nella maggior parte dei casi, le immagini grandi nel viewport visibile diventano l'elemento Largest Contentful Paint. Ottimizzare le immagini è una delle azioni con il maggiore impatto che puoi fare per il LCP. Usa questi elementi della checklist dei Core Web Vitals per migliorare la velocità delle immagini. Per la strategia completa, leggi la nostra guida su come ottimizzare l'immagine LCP.

• Ridimensiona le immagini per adattarle alle dimensioni massime sullo schermo: Questo assicura di non sprecare mai byte per scaricare immagini più grandi della loro dimensione massima sullo schermo. Combina questa pratica con le immagini responsive per gli schermi più piccoli. Servire immagini della dimensione corretta può ridurre il peso del file del 50% o più senza alcuna perdita di qualità visibile.
• Usa il lazy loading per le immagini sotto la piega: Il lazy loading posticipa il caricamento delle immagini fuori dal viewport finché non vengono visualizzate, migliorando il First Contentful Paint (FCP) e la velocità di caricamento complessiva della pagina. Non applicare mai il lazy loading all'immagine LCP, perché questo la ritarderebbe notevolmente.
• Precarica le immagini visivamente importanti come l'elemento LCP: Il precaricamento indica al browser di recuperare le immagini critiche prima del resto del contenuto, dando priorità al LCP. Usa <link rel="preload" as="image"> combinato con fetchpriority="high" per ottenere i migliori risultati. Questo è particolarmente importante quando l'immagine LCP è referenziata nel CSS o caricata tramite JavaScript.
• Imposta larghezza e altezza: Definire le dimensioni dell'immagine in anticipo evita gli spostamenti di layout causati dal browser che attende il caricamento delle immagini. Questo migliora il CLS. I browser moderni usano gli attributi width e height per calcolare il rapporto d'aspetto prima del caricamento dell'immagine, riservando lo spazio corretto.
• Usa formati di immagine moderni come WebP o AVIF: Questi formati offrono file di dimensioni ridotte rispetto a JPEG o PNG mantenendo una qualità simile, con conseguenti tempi di caricamento più veloci. WebP consente solitamente di ottenere file più piccoli del 25-34% rispetto a JPEG, mentre AVIF può ridurne le dimensioni fino al 50%. Usa l'elemento <picture> con fallback di formato per la massima compatibilità tra browser.
• Usa il lazy loading nativo e disattiva il lazy loading basato su JavaScript: Il lazy loading ritarda il caricamento delle immagini fuori dal viewport finché non vengono visualizzate. Il lazy loading nativo offerto dai browser tramite l'attributo loading="lazy" è generalmente più efficiente rispetto all'uso di JavaScript per questo scopo, poiché non richiede il parsing o l'esecuzione di script aggiuntivi.
• Usa immagini responsive con srcset: Questo attributo specifica diverse versioni dell'immagine per varie dimensioni di schermo, assicurando che il browser fornisca l'immagine ottimale per il dispositivo dell'utente, riducendo i download di file grandi non necessari. Combina srcset con l'attributo sizes per un controllo preciso.
• Aggiungi decoding="async": L'attributo decoding="async" impedisce al browser di bloccare altri contenuti durante la decodifica di un'immagine. Questo consente al motore di rendering di continuare a disegnare gli altri elementi mentre la decodifica dell'immagine avviene in parallelo.
• Rimuovi i metadati delle immagini: I metadati come i dati EXIF incorporati nelle immagini possono aggiungere byte superflui. Rimuovere queste informazioni riduce la dimensione del file senza influire sulla qualità dell'immagine. Strumenti come ImageOptim, Squoosh o Sharp possono automatizzare la rimozione dei metadati come parte del tuo processo di build.
• Evita le immagini di sfondo CSS per gli elementi LCP: Le immagini di sfondo referenziate nel CSS vengono individuate dal browser più tardi rispetto agli elementi <img> in HTML. Se devi utilizzare un'immagine di sfondo come elemento LCP, precaricala con un tag <link rel="preload"> per assicurarne una scoperta anticipata. Scopri di più sul ritardo nel caricamento delle risorse LCP.

Ottimizza i web font

I web font possono ritardare il First Contentful Paint, causare spostamenti di layout e competere per le prime risorse di larghezza di banda. Usa questa checklist per garantire un'esperienza fluida con i web font. Per le migliori pratiche sull'hosting dei font, consulta la nostra guida sul self-hosting di Google Fonts.

• Usa font-display: swap per un first paint più veloce: Imposta la proprietà font-display su swap nelle tue dichiarazioni @font-face. Questo garantisce che il browser mostri un font di fallback immediatamente mentre carica il web font in background. Una volta che il font è pronto, lo sostituisce senza interruzioni. Leggi di più su come assicurare che il testo rimanga visibile durante il caricamento del web font.
• Usa font-display: optional combinato con il preloading per eliminare gli spostamenti di layout causati dai font: Combinare font-display: optional con il preloading offre un equilibrio tra velocità e potenziali spostamenti di layout. Il valore optional nasconde brevemente il testo (circa 100ms) prima di usare un font di fallback. Il preloading indica al browser di richiedere il web font in anticipo, riducendo al minimo il tempo di permanenza del font di fallback e diminuendo gli spostamenti di layout.
• Usa i descrittori font-face per fare in modo che le dimensioni del font di fallback corrispondano a quelle del web font: Questo garantisce un CLS minimo quando il web font lo sostituisce. Specificando metriche simili per il font di fallback tramite size-adjust, ascent-override, descent-override e line-gap-override, puoi evitare che il contenuto si sposti improvvisamente durante il caricamento del font.
• Crea subset dei font per includere solo i caratteri necessari: Riduci le dimensioni del file del font tramite subsetting, includendo solo i caratteri necessari per i tuoi contenuti. Strumenti come Font Squirrel, pyftsubset o glyphhanger possono aiutarti a generare i subset. Un font con un set di caratteri latini completo può spesso essere ridotto da oltre 100KB a meno di 20KB con un subsetting corretto.
• Limita il numero di pesi e stili dei font: Evita di caricare troppe varianti di font. Limitati a un massimo di 2 font critici (solitamente precaricati) e 2 font a caricamento tardivo (caricati dopo il rendering iniziale). Ogni peso aggiuntivo aggiunge da 15 a 50KB alle dimensioni del download.

Ottimizza gli script

Gli script possono causare problemi di Interaction to Next Paint, attivare Cumulative Layout Shifts o ritardare il Largest Contentful Paint. Anche gli script iniziali ottimizzati e relativamente innocui possono competere per le risorse e ritardare le metriche di paint (il LCP e l'FCP). Per una guida completa, vedi 14 metodi per rinviare JavaScript.

• Rimuovi il JavaScript non necessario: Individua ed elimina il codice JavaScript inutilizzato per ridurre al minimo la quantità di codice da scaricare ed eseguire. Usa la scheda Coverage di Chrome DevTools per trovare il codice inutilizzato. La rimozione del codice morto riduce sia il tempo di download sia l'elaborazione del main thread.
• Prioritizza gli script in base a funzione e importanza: Gli script che apportano grandi modifiche al viewport visibile devono essere render blocking. Gli script importanti devono essere differiti o caricati in modo asincrono. Gli script non essenziali devono caricarsi quando il browser è inattivo. Vedi la nostra guida alla prioritizzazione delle risorse per una strategia dettagliata.
• Code splitting e lazy loading: Dividi i bundle JavaScript di grandi dimensioni in chunk più piccoli e caricali solo quando necessario. Questo riduce il tempo di caricamento iniziale. I bundler moderni come webpack, Rollup ed esbuild supportano il code splitting automatico basato su importazioni dinamiche.
• Minifica e ricompila i file JavaScript: Minifica e ricompila sempre i tuoi file JavaScript con uno strumento di minificazione come SWC, Terser o esbuild. La minificazione riduce in genere le dimensioni dei file JavaScript del 30-50%.
• Limita gli script di terze parti: Gli script di terze parti possono introdurre un sovraccarico significativo delle prestazioni. Valuta la loro necessità ed esplora alternative, se possibile. Ogni script di terze parti aggiunge risoluzioni DNS, overhead di connessione e tempo di elaborazione del main thread. Analizza regolarmente gli script di terze parti usando il pannello Network di Chrome DevTools.
• Carica gli script di terze parti in modo asincrono: A causa della natura imprevedibile degli script di terze parti, non permettere mai che una terza parte blocchi il rendering. Usa l'attributo async o defer su tutti i tag script di terze parti.
• Monitora le prestazioni degli script di terze parti: Usa l'API Long Animation Frames (LoAF) o CoreDash per misurare l'impatto reale degli script di terze parti sull'INP e sul LCP. Imposta performance budget per il JavaScript di terze parti e verificali regolarmente.

Ottimizza gli stili

Gli stili sono render blocking di default. Ottimizzare gli stili garantisce metriche di paint ottimizzate. Segui la checklist per migliorare le prestazioni degli stili della tua pagina. Il CSS render blocking influisce direttamente sia sul First Contentful Paint sia sul ritardo di rendering dell'elemento LCP. Per consigli su come ripulire gli stili inutilizzati, vedi come rimuovere il CSS inutilizzato.

• Minifica i file CSS: Rimuovi i caratteri non necessari come spazi bianchi, commenti e formattazione dai file CSS. I file minificati sono più piccoli, riducendo i tempi di caricamento. Strumenti come cssnano, PostCSS o la compressione integrata del tuo preprocessore CSS possono automatizzare questo processo.
• Rimuovi il CSS inutilizzato: Individua ed elimina il codice CSS non utilizzato nelle tue pagine web. Questo riduce la quantità di dati che il browser deve scaricare ed analizzare, migliorando le prestazioni. Strumenti come PurgeCSS o la scheda Coverage di Chrome DevTools aiutano a individuare il CSS inutilizzato.
• Inserisci inline il CSS critico: Fornisci gli stili essenziali per il rendering del contenuto iniziale della pagina direttamente nell'HTML per migliorare le metriche di paint. Valuta di fornire il CSS critico solo ai nuovi visitatori e di usare fogli di stile esterni in cache per i visitatori di ritorno. Questa tecnica può ridurre il FCP eliminando il round trip necessario per recuperare un foglio di stile esterno.
• Distribuisci equamente le dimensioni dei file CSS: Anche se può sembrare efficiente unire tutto il CSS in un unico file, i file eccessivamente grandi possono rallentare i tempi di download. Valuta di dividere il CSS in file più piccoli con una distribuzione delle dimensioni più uniforme (da 10 a 15 KB ciascuno) per ottimizzare il caricamento e consentire al browser di elaborare gli stili in modo incrementale.
• Carica in modo asincrono gli stili offscreen: Per gli stili che si applicano a elementi esterni al viewport iniziale, valuta l'uso del caricamento asincrono tramite il pattern media="print" onload="this.media='all'". Questo consente al browser di recuperare questi stili in parallelo con altre risorse, senza bloccare il rendering iniziale della pagina.

Ottimizza i resource hint

I resource hint aiutano a dare priorità ai download delle risorse critiche. Le risorse precaricate vengono solitamente accodate per il download e risultano disponibili per il browser molto prima rispetto a quanto accadrebbe senza il precaricamento. L'uso efficace dei resource hint può ridurre notevolmente il ritardo nel caricamento della risorsa LCP. Per un'implementazione avanzata, leggi l'articolo su 103 Early Hints.

• Rimuovi i resource hint non critici: Rimuovi i suggerimenti di preload per le risorse non essenziali per il caricamento iniziale della pagina. In questo modo eviti download o connessioni di rete non necessari che competono per quelle risorse iniziali a larghezza di banda limitata. Ogni preload non necessario consuma banda che potrebbe essere usata per le risorse critiche.
• Preconnetti ai domini critici: Stabilisci in anticipo le connessioni con i domini importanti (come content delivery network o provider di font). Questo velocizza il download delle risorse critiche da questi domini completando in anticipo gli handshake DNS, TCP e TLS. Usa <link rel="preconnect" href="https://example.com"> per le origini di terze parti critiche.
• Valuta il DNS prefetch come alternativa al preconnect: Analogamente al preconnect, il DNS prefetch suggerisce al browser le potenziali connessioni. Tuttavia, il preconnect dà la priorità alla creazione della connessione completa, mentre il DNS prefetch indica semplicemente al browser di risolvere il nome di dominio in anticipo. Usa <link rel="dns-prefetch"> quando il sovraccarico di una connessione completa tramite preconnect non è giustificato.
• Precarica l'elemento LCP: Il LCP misura il tempo necessario per caricare il contenuto principale. Il precaricamento dell'elemento LCP indica al browser di dare priorità al download di questa risorsa critica, velocizzando il tempo necessario agli utenti per vedere il contenuto principale. Questo è particolarmente importante per le immagini a cui si fa riferimento nel CSS o caricate tramite JavaScript.
• Precarica i font critici: Il precaricamento dei font critici assicura che il browser li scarichi in anticipo, evitando ritardi nella visualizzazione del testo e migliorando i Cumulative Layout Shift causati dallo swapping dei font. Usa <link rel="preload" as="font" type="font/woff2" crossorigin> per i tuoi font più importanti.
• Preferisci 103 Early Hints per i resource hint: Lo status code HTTP 103 Early Hints consente al server di inviare i resource hint prima che la risposta completa sia pronta. Se il tuo server non supporta lo stato 103, usa invece gli header di risposta Link. Se gli header non sono disponibili, aggiungi gli elementi <link> nel <head> della pagina come fallback. L'invio anticipato dei suggerimenti accelera la scoperta delle risorse.
• Precarica i font prima che i file CSS li individuino: I font a cui si fa riferimento nel CSS vengono individuati solo dopo che il file CSS è stato scaricato e analizzato. Precaricando i font direttamente nel <head> HTML, elimini la dipendenza dal parsing del CSS e consenti ai font di caricarsi in parallelo, riducendo sia il FCP sia il rischio di layout shift.

Ottimizza le icone

Se non ottimizzate, le icone possono appesantire notevolmente la tua pagina. Le grandi icone SVG inline gonfiano il tuo HTML, mentre i font di icone spesso includono migliaia di glifi inutilizzati. L'ottimizzazione delle icone influisce sia sul LCP (peso ridotto di HTML/CSS) sia sul CLS (corretta riserva delle dimensioni).

• Evita le icone SVG inline nell'HTML: inserire grandi icone SVG inline può aumentare la dimensione del codice HTML e rallentare il caricamento della pagina. Valuta metodi alternativi, come servirle in file separati o usare font di icone (con cautela) per ridurre al minimo la dimensione dell'HTML e consentire il caching delle icone da parte del browser. Uno sprite sheet SVG esterno è spesso il miglior equilibrio tra prestazioni e flessibilità.
• Evita grandi font di icone: non usare mai grandi set di icone come Font Awesome nella loro interezza. Usa il subsetting per creare font di icone ottimizzati o singoli SVG per ridurre la dimensione complessiva della pagina web e migliorare la velocità di caricamento. Un set completo di Font Awesome può superare i 100KB, mentre un subset con 20 icone può essere inferiore a 5KB.
• Riserva larghezza e altezza per le icone: come per le immagini, specificare larghezza e altezza per le icone aiuta il browser a riservare lo spazio e previene i layout shift durante il caricamento. Usa gli attributi width e height sugli elementi SVG o imposta dimensioni esplicite nel CSS.
• Deprioritizza i set di icone non critici: se le icone non sono critiche per il rendering iniziale della tua pagina, valuta di caricarle con una priorità inferiore. Questo assicura che il contenuto essenziale si carichi prima e riduce al minimo l'impatto sulle metriche dei Core Web Vitals. Usa il lazy loading o carica i fogli di stile delle icone in modo asincrono dopo il rendering iniziale.

Ottimizza i tempi di risposta del server

I tempi di risposta del server, misurati tramite Time to First Byte (TTFB), hanno una relazione diretta con tutte le metriche di paint. Una risposta lenta del server ritarda tutto ciò che segue. Per strategie di ottimizzazione dettagliate, consulta le nostre guide su come diagnosticare i problemi di TTFB e configurare Cloudflare per le prestazioni.

• Usa un provider di hosting veloce e affidabile: Un provider di hosting veloce con un'infrastruttura solida può migliorare significativamente i tempi di risposta del server e le prestazioni complessive del sito web. Fai un benchmark dei provider di hosting usando misurazioni reali del TTFB, non le promesse di marketing sintetiche.
• Ottimizza il codice lato server e le query del database: Registra regolarmente i tempi di esecuzione del codice e delle query del database per trovare i colli di bottiglia e migliorare la velocità complessiva. Usa strumenti di query profiling e APM per identificare gli endpoint lenti.
• Implementa strategie di caching: Utilizza la cache del browser e la cache lato server per memorizzare i dati ad accesso frequente, riducendo la necessità di recuperare ripetutamente i dati e migliorando i tempi di caricamento. La cache a pagina intera può ridurre il TTFB da diversi secondi a meno di 100 ms. Scopri di più sull'ottimizzazione della durata della cache.
• Rendering client-side o edge per la personalizzazione: Considera il rendering client-side o edge per piccole personalizzazioni come il conteggio del carrello, lo stato di login o modifiche minori al menu per mantenere attiva la cache a pagina intera. In questo modo eviti di invalidare la cache dell'intera pagina per elementi dinamici minori.
• Ottimizza le configurazioni del server: Esamina e ottimizza le impostazioni del tuo web server per le prestazioni. Questo include le impostazioni di keep-alive delle connessioni, il numero di processi worker, l'allocazione di memoria e i valori di timeout. I server configurati in modo errato possono sprecare risorse e aumentare i tempi di risposta.
• Usa una Content Delivery Network (CDN): Una CDN distribuisce i contenuti statici del tuo sito web su più nodi edge (server). Questo reduce la distanza fisica per accedere ai tuoi contenuti, velocizzando i tempi di caricamento per gli utenti di tutto il mondo. Inoltre, le CDN sono solitamente configurate meglio del tuo server. Consulta la nostra guida su come configurare Cloudflare per una guida pratica passo-passo.
• Riduci l'elaborazione lato server: Ruidici al minimo il lavoro del server per ogni richiesta. Pre-calcola le operazioni onerose, usa algoritmi efficienti e sposta le elaborazioni non essenziali in job in background. Analizza il ciclo di vita delle richieste della tua applicazione per individuare ed eliminare i passaggi superflui.
• Usa HTTP/3: HTTP/3 è l'ultima versione dell'Hypertext Transfer Protocol. HTTP/3 è più veloce ed efficiente di HTTP/2 e nettamente più rapido di HTTP/1.1. Il passaggio a HTTP/3 può migliorare i tempi di caricamento generali della pagina e, potenzialmente, tutte e tre le metriche Core Web Vitals (LCP, INP, CLS). Scopri di più sull'ottimizzazione della durata della connessione.
• Configura gli header Server-Timing: Questi header forniscono informazioni dettagliate sul tempo impiegato dal server per elaborare le diverse parti della pagina. Con questi dati puoi individuare i colli di bottiglia e le aree da ottimizzare, concentrandoti nello specifico sul miglioramento del Largest Contentful Paint (LCP). Gli header Server-Timing sono visibili nel pannello Network di Chrome DevTools e possono essere catturati da strumenti RUM come CoreDash.
• Registra le query lente del database e ottimizzale regolarmente: Abilita il log delle query lente nel tuo database (MySQL, PostgreSQL, MongoDB) e analizza i log settimanalmente. L'ottimizzazione degli indici, la ristrutturazione delle query e l'aggiunta di livelli di cache per le query frequenti possono ridurre drasticamente il TTFB.
• Usa la compressione GZIP o Brotli: GZIP, o il più recente Brotli, offre la compressione al volo delle risorse basate su testo (HTML, CSS, JavaScript) prima della trasmissione, riducendo le dimensioni dei file di circa il 70%. Brotli ottiene in genere una compressione migliore del 15-20% rispetto a GZIP. Dimensioni inferiori dei file si traducono in tempi di caricamento più rapidi.

Ottimizza l'interattività

L'Interaction to Next Paint (INP) misura la rapidità con cui il tuo sito risponde alle interazioni degli utenti. La scarsa interattività è spesso causata da task JavaScript lunghi che bloccano il main thread. Per un'analisi completa delle tre fasi dell'INP, consulta le nostre guide su ritardo di input, tempo di elaborazione e ritardo di presentazione.

• Implementa un pattern idle-until-urgent per gli script pesanti: Questo approccio dà la priorità ai task critici e posticipa l'esecuzione di JavaScript non essenziale finché il main thread del browser non è inattivo. Questo garantisce che i task critici, come il rendering e le interazioni dell'utente, non vengano bloccati da script lunghi. Usa requestIdleCallback per pianificare il lavoro non urgente. Scopri di più su come ottimizzare il tempo di elaborazione.
• Suddividi i long task con lo yielding al main thread: I task JavaScript complessi possono bloccare il main thread, rallentando la reattività. Dividere questi task in chunk più piccoli ed effettuare lo yielding al main thread tra un chunk e l'altro consente al browser di gestire le interazioni dell'utente e mantenere un'esperienza utente fluida. Usa scheduler.yield() (se supportato) o setTimeout(0) per suddividere i long task. Consulta la nostra guida su come migliorare l'INP eliminando lo scrolling JavaScript.
• Fornisci un feedback immediato dopo l'input: Gli utenti si aspettano una reattività immediata dopo aver interagito con il tuo sito. Fornisci segnali visivi o conferma l'input dell'utente tempestivamente, anche mentre i long task sono in esecuzione in background. Usa le transizioni CSS e la pseudoclasse :active per un feedback visivo istantaneo. Questo aiuta a mantenere la sensazione di interattività ed evita che gli utenti abbiano l'impressione che il sito sia bloccato.
• Usa event listener passivi per lo scroll e il touch: Aggiungi { passive: true } agli event listener di scroll e touch. I listener passivi comunicano al browser che l'handler non chiamerà mai preventDefault(), consentendogli di avviare lo scrolling immediatamente senza attendere JavaScript. Questo ha un forte impatto soprattutto sui dispositivi mobili e migliora direttamente l'INP per le interazioni adiacenti allo scroll.

Monitoraggio dei Core Web Vitals

Monitorare costantemente i tuoi Core Web Vitals è essenziale per individuare presto le regressioni e verificare che le ottimizzazioni abbiano l'impatto previsto. Per un quadro completo, usa una combinazione di strumenti lab, field data e monitoraggio degli utenti reali.

• Controlla regolarmente Lighthouse: Lighthouse è uno strumento di auditing gratuito e open source di Google che ti aiuta a individuare i problemi di prestazioni sulle tue pagine web. Anche se Lighthouse non misura direttamente i Core Web Vitals in un contesto di utenti reali, è un ottimo strumento per testare e confrontare periodicamente il tuo sito web in condizioni controllate e standardizzate. Esegui Lighthouse nelle pipeline di CI/CD per individuare le regressioni prima del deploy.
• Controlla regolarmente i dati storici di CrUX: CrUX (Chrome User Experience Report) è un dataset pubblico di Google che fornisce dati sulle prestazioni reali. CrUX è la fonte di dati utilizzata da Google per stabilire se superi o meno i Core Web Vitals. Usa i dati storici per individuare rapidamente le regressioni. Puoi accedere ai dati di CrUX tramite PageSpeed Insights, la CrUX Dashboard o le API di CrUX.
• Configura il tracciamento RUM: il RUM (Real User Monitoring) consiste nel tracciare l'esperienza degli utenti reali sul tuo sito web. Gli strumenti RUM raccolgono dati sul tempo che le pagine impiegano effettivamente a caricarsi per i tuoi visitatori in diverse aree geografiche e su vari dispositivi. Questo fornisce indicazioni preziose sulle prestazioni reali, integrando i dati simulati di Lighthouse e CrUX. Consigliamo CoreDash come strumento di tracciamento RUM per ottenere dati dettagliati sull'attribuzione dei Core Web Vitals.
• Definisci i performance budget: i performance budget stabiliscono obiettivi di prestazione specifici (ad esempio, LCP inferiore a 2,5 secondi, INP inferiore a 200ms, CLS inferiore a 0,1) per le diverse metriche. Questi fungono da benchmark per guidare le tue attività di ottimizzazione. Verificare regolarmente le prestazioni rispetto a questi budget ti aiuta a individuare le aree che richiedono attenzione immediata e a dare priorità alle ottimizzazioni.
• Usa la segmentazione: usa la segmentazione per tracciare le tipologie di visitatori più importanti e i diversi tipi di pagina. Altrimenti, grossi volumi di traffico potrebbero mascherare problemi di prestazioni che colpiscono specificamente questi gruppi chiave. Segmenta per tipo di dispositivo, velocità di connessione, area geografica e template di pagina per scoprire i problemi nascosti.

Ottimizza il percorso di rendering critico

Il percorso di rendering critico è la sequenza di passaggi che il browser esegue per convertire HTML, CSS e JavaScript in pixel visibili. Ottimizzare questo percorso migliora direttamente il First Contentful Paint e il ritardo di rendering dell'elemento LCP. Vedi anche come evitare dimensioni eccessive del DOM.

• Minimizza il numero di risorse critiche: Ogni risorsa render blocking (CSS e JavaScript sincrono) deve essere scaricata ed elaborata prima che il browser possa eseguire il paint. Riduci il numero di risorse critiche differendo gli script non essenziali e caricando in modo asincrono i fogli di stile non critici.
• Ottimizza l'ordine di caricamento delle risorse: Assicurati che il CSS critico e i font vengano caricati per primi, seguiti dalle immagini above-the-fold e poi dagli script differiti. Usa l'attributo fetchpriority e i suggerimenti per la prioritizzazione delle risorse per comunicare l'importanza al browser.
• Riduci la profondità dell'albero DOM: Alberi DOM molto nidificati aumentano il tempo di calcolo degli stili e il lavoro di layout. Punta a una profondità massima di 32 livelli e a meno di 1.500 elementi DOM totali, dove possibile. Una struttura DOM più piatta migliora sia le prestazioni di paint sia il ritardo di presentazione dell'INP.
• Favorisci classi e ID rispetto a tag e attributi degli elementi: Invece di p.important, usa .important. Questo riduce la necessità per il browser di cercare tra tutti gli elementi di quel tipo per la corrispondenza degli stili, velocizzando il ricalcolo dello stile.
• Evita di nidificare i selettori in modo profondo: Più nidifichi i selettori CSS, più calcoli deve eseguire il browser. Prova a ristrutturare l'HTML per ridurre la nidificazione o usa classi più specifiche e più vicine all'elemento. Limita la profondità dei selettori a un massimo di 3 livelli.
• Minimizza i selettori discendenti: I selettori come .container > .content costringono il browser a controllare ogni elemento all'interno del contenitore. Se possibile, usa una classe più diretta sull'elemento di contenuto per una corrispondenza del selettore più rapida.
• Consolida i selettori con gli stessi stili: Se più elementi condividono gli stessi stili, raggruppali in una singola classe o usa la convenzione di denominazione BEM (Block Element Modifier) per una migliore manutenibilità e un output CSS ridotto.

Ottimizza il consenso ai cookie

I banner per il consenso ai cookie sono richiesti dal GDPR e da normative simili, ma possono avere un impatto significativo sui Core Web Vitals se non li implementi con cura. Un banner di consenso caricato male può ritardare il LCP, causare il CLS e aumentare l'INP. Per maggiori dettagli, leggi come ottimizzare i widget di terze parti per i Core Web Vitals.

• Considera il consenso ai cookie lato server per le pagine dinamiche: Per le pagine renderizzate dinamicamente lato server, implementare una soluzione lato server che inserisca il banner di consenso nella risposta HTML iniziale è spesso più veloce del caricamento di una soluzione JavaScript separata. Questo elimina la richiesta di rete aggiuntiva e l'overhead di valutazione dello script.
• Carica in modo asincrono gli script di consenso ai cookie sulle pagine in cache: Per le pagine in cache, carica in modo asincrono il tuo script di consenso ai cookie e valuta di aggiungere fetchpriority="high" allo script per assicurarti che si carichi abbastanza presto da essere mostrato prima dell'interazione dell'utente.
• Mantieni breve il testo del consenso per evitare interferenze con il LCP: Testi lunghi per l'informativa sui cookie possono diventare l'elemento LCP, perché il browser considera il blocco di testo visibile più grande come un potenziale candidato LCP. Valuta di scrivere testi più brevi o di suddividerli in più paragrafi con un'area visibile minore.
• Esegui il self-hosting degli script di notifica dei cookie: Memorizza in cache ed esegui il self-hosting di script e fogli di stile per la notifica dei cookie quando possibile. Questo elimina le risoluzioni DNS e l'overhead di connessione verso le piattaforme di gestione del consenso di terze parti, dandoti il controllo completo sul comportamento di caricamento.

Ottimizza le Single Page Application

Le Single Page Application (SPA) create con React, Vue, Angular o framework simili affrontano sfide uniche legate ai Core Web Vitals. Il client-side rendering può ritardare sia l'FCP sia l'LCP, mentre l'idratazione può bloccare l'INP.

• Usa sempre il server-side rendering o il prerendering: le SPA che si affidano esclusivamente al client-side rendering costringono il browser a scaricare, analizzare ed eseguire il JavaScript prima che qualsiasi contenuto sia visibile. Usa l'SSR (Next.js, Nuxt, SvelteKit) o il prerendering statico per servire l'HTML iniziale che il browser può mostrare immediatamente.
• Preferisci i prerender statici alla generazione dinamica: i prerender statici (generati in fase di build) sono molto più veloci dei prerender generati dinamicamente perché possono essere serviti direttamente da una CDN senza alcuna elaborazione lato server. Usa la generazione statica per le pagine che non richiedono dati a ogni richiesta.
• Carica gli script di terze parti dopo l'idratazione: durante l'idratazione, il framework consuma già molto tempo sul main thread per rendere la pagina interattiva. Caricare script di terze parti contemporaneamente aggrava il problema e peggiora l'input delay. Posticipa tutti gli script non essenziali a dopo il completamento dell'idratazione.

Evita dimensioni eccessive del DOM

Un DOM di grandi dimensioni (più di 1.500 elementi o una profondità superiore a 32 livelli) aumenta l'uso della memoria, rallenta i calcoli di stile e causa costosi reflow del layout. Questo influisce direttamente sia sul ritardo di presentazione dell'INP sia sulle metriche di paint. Vedi come risolvere le dimensioni eccessive del DOM.

• Riduci gli elementi DOM non necessari: Analizza il tuo HTML alla ricerca di elementi wrapper senza scopi strutturali o di stile. Sostituisci le strutture <div> profondamente annidate con elementi HTML semantici. Valuta la virtualizzazione delle liste lunghe con librerie come react-window o virtual-scroller per mantenere piccolo il DOM attivo.
• Usa selettori JavaScript e CSS efficienti: I selettori CSS complessi e le query DOM JavaScript (come querySelectorAll con pattern generici) diventano esponenzialmente più lenti all'aumentare delle dimensioni del DOM. Usa selettori di classe specifici e limita l'ambito delle query DOM ai sottoalberi ogni volta che è possibile.
• Usa content-visibility: auto per i contenuti fuori schermo: La proprietà CSS content-visibility: auto indica al browser di saltare il rendering degli elementi fuori schermo finché non entrano nella viewport. Questo può ridurre drasticamente il lavoro di rendering iniziale per le pagine con sezioni di contenuto lunghe.

Ottimizza le richieste API

Le richieste API che bloccano il rendering o ritardano i contenuti possono influire negativamente su LCP e TTFB. Il recupero dei dati lato client è una causa comune di LCP lento nelle single page application.

• Riduci al minimo il numero di richieste API: Ogni richiesta API aumenta il tempo di caricamento complessivo della pagina. Valuta le funzionalità del tuo sito e individua le opportunità per ridurre il numero di richieste API necessarie per renderizzare il contenuto iniziale. Tecniche come il batching dei dati (l'unione di più richieste in una sola) e GraphQL possono ridurre i round trip.
• Usa API efficienti e ottimizzate: La progettazione e l'implementazione delle API stesse possono influire sulle prestazioni. Assicurati di usare API ben progettate e ottimizzate per velocità ed efficienza. Implementa meccanismi di caching lato API per ridurre i tempi di risposta per i dati richiesti di frequente.
• Precarica le richieste API critiche: Come per il precaricamento di risorse critiche come le immagini, il precaricamento delle richieste API essenziali può migliorare significativamente le prestazioni percepite. Usa <link rel="preload" as="fetch"> per indicare al browser di recuperare le API critiche in anticipo, riducendo al minimo i ritardi quando sono necessarie per renderizzare il contenuto iniziale. Consulta la nostra guida alla prioritizzazione delle risorse per altre tecniche.

Ottimizza i widget di chat

I widget di chat sono una causa comune di spostamenti del layout e possono persino causare problemi con il LCP se caricati in anticipo. Per una procedura passo-passo, leggi come implementare un widget di chat con Core Web Vitals perfetti.

• Carica i widget di chat dopo il caricamento del contenuto principale: Nessuno nella storia di internet ha mai avuto bisogno di chattare prima del caricamento del contenuto principale della pagina. Posticipa l'inizializzazione del widget di chat fino al termine del rendering iniziale della pagina, usando requestIdleCallback o un trigger basato sullo scroll.
• Previeni gli spostamenti del layout dei widget di chat: Se i widget di chat causano uno spostamento del layout, di solito conviene nasconderli con opacity: 0 finché non sono completamente renderizzati sulla pagina. Questo permette al widget di eseguire il layout in background senza causare salti del contenuto visibile. Usa una transizione CSS per far apparire il widget in modo fluido.
• Scegli provider di widget di chat leggeri: Confronta le opzioni. Alcuni widget di chat sono molto più leggeri e causano meno problemi con i Core Web Vitals rispetto ad altri. Confronta le dimensioni del bundle JavaScript, il numero di richieste di rete e l'impatto sull'INP dei vari provider prima di decidere.

Ottimizza le prestazioni del service worker

I service worker possono migliorare significativamente le prestazioni delle visite successive. Salvando in cache le risorse e persino intere risposte di pagina, riducono il TTFB per i visitatori di ritorno. Tuttavia, un service worker implementato male può rallentare la navigazione. Scopri di più sull'ottimizzazione della durata della cache.

• Memorizza in cache le risorse critiche nel service worker: Usa una strategia cache-first per le risorse statiche come CSS, JavaScript, font e immagini. Questo consente ai visitatori di ritorno di caricare il tuo sito quasi all'istante dalla cache locale. Esegui il precache delle risorse più importanti durante l'evento install del service worker.
• Ottimizza il codice del service worker: Mantieni il tuo service worker snello ed efficiente. Evita logiche di routing complesse, l'uso eccessivo di event.waitUntil() e manifest di precache di grandi dimensioni che rallentano l'installazione. Usa il pattern stale-while-revalidate per le risorse che cambiano spesso ma non richiedono un aggiornamento immediato.

Ottimizza i contenuti video

Gli elementi video possono diventare l'elemento LCP se sono il contenuto visibile più grande nel viewport. I video grandi e non ottimizzati competono per la larghezza di banda con altre risorse critiche.

• Comprimi e ottimizza i video: usa codec moderni come H.264, VP9 o AV1 con impostazioni di qualità adeguate. Riduci la risoluzione del video per adattarla alla dimensione massima di visualizzazione. Un video mostrato a 400px di larghezza non deve essere codificato a 1920px. Usa la codifica a due passaggi per ottenere il miglior rapporto tra qualità e dimensione del file.
• Usa il lazy loading per i video: per i video sotto la piega, usa l'attributo loading="lazy" sugli elementi <iframe> o ritarda il caricamento del video con la Intersection Observer API. Sostituisci i video di sfondo in riproduzione automatica con immagini poster e carica il video solo quando l'utente vi si avvicina scorrendo.
• Ospita i video su una CDN veloce: i file video sono grandi e traggono grande vantaggio dalla distribuzione tramite CDN. Usa una CDN video dedicata o un servizio di hosting (come Cloudflare Stream, Mux o Bunny.net) che offra streaming a bitrate adattivo, distribuzione geografica e consegna ottimizzata.
• Usa immagini poster per gli elementi video: imposta sempre l'attributo poster sugli elementi <video>. L'immagine poster fornisce al browser qualcosa da renderizzare immediatamente mentre il video si carica, il che può fungere da elemento LCP. Ottimizza l'immagine poster proprio come qualsiasi altra immagine LCP.