La checklist definitiva dei Core Web Vitals (2026)

Table of Contents!

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

Ottimizzare le immagini

Le immagini grandi nel viewport visibile diventeranno, nella maggior parte dei casi, l'elemento Largest Contentful Paint. Ottimizzare le immagini è una delle azioni con il maggiore impatto per LCP. Usa questi elementi della checklist 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 corrispondere alle dimensioni massime sullo schermo: Questo garantisce che nessun byte venga sprecato per scaricare immagini più grandi della loro dimensione massima sullo schermo. Combina questa pratica con le immagini responsive per schermi più piccoli. Servire immagini correttamente dimensionate può ridurre la dimensione dei file immagine del 50% o più senza alcuna perdita di qualità visibile.
• Usa il lazy loading per le immagini sotto la piega: Il lazy loading ritarda il caricamento delle immagini al di fuori del viewport fino a quando non vengono scrollate nella vista, migliorando First Contentful Paint (FCP) e la velocità complessiva di caricamento della pagina. Non applicare mai il lazy loading all'immagine LCP, poiché la ritarderebbe significativamente.
• Precarica le immagini visivamente importanti come l'elemento LCP: Il precaricamento istruisce il browser a scaricare le immagini critiche prima del resto del contenuto, dando priorità a LCP. Usa <link rel="preload" as="image"> combinato con fetchpriority="high" per i migliori risultati. Questo è particolarmente importante quando l'immagine LCP è referenziata dal CSS o caricata tramite JavaScript.
• Imposta larghezza e altezza: Definire le dimensioni delle immagini in anticipo previene gli spostamenti del layout causati dal browser in attesa che le immagini si carichino. Questo migliora CLS. I browser moderni usano gli attributi width e height per calcolare l'aspect ratio prima che l'immagine sia caricata, riservando la quantità corretta di spazio.
• Usa formati immagine moderni come WebP o AVIF: Questi formati offrono dimensioni di file più piccole rispetto a JPEG o PNG mantenendo una qualità simile, portando a tempi di caricamento più rapidi. WebP raggiunge tipicamente file del 25-34% più piccoli rispetto a JPEG, mentre AVIF può ridurre la dimensione del file fino al 50%. Usa l'elemento <picture> con fallback di formato per la massima compatibilità con i browser.
• Usa il lazy loading nativo e disabilita il lazy loading basato su JavaScript: Il lazy loading ritarda il caricamento delle immagini al di fuori del viewport fino a quando non vengono scrollate nella vista. Il lazy loading nativo offerto dai browser tramite l'attributo loading="lazy" è generalmente più efficiente che affidarsi a JavaScript per questo compito, poiché non richiede parsing o 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 download di grandi dimensioni 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 permette al motore di rendering di continuare a dipingere 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 non necessari. Rimuovere queste informazioni può ridurre 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 processo di build.
• Evita le immagini di sfondo CSS per gli elementi LCP: Le immagini di sfondo referenziate nel CSS vengono scoperte più tardi dal browser rispetto agli elementi <img> nell'HTML. Se devi usare un'immagine di sfondo come elemento LCP, precaricala con un tag <link rel="preload"> per garantire la scoperta anticipata. Scopri di più su LCP resource load delay.

Ottimizzare i web font

I web font possono ritardare il First Contentful Paint, causare spostamenti del layout e competere per le risorse a banda limitata iniziali. Usa questa checklist per garantire un'esperienza web font fluida. Per le migliori pratiche sull'hosting dei font, consulta la nostra guida sull'hosting locale di Google Fonts.

• Usa font-display: swap per un primo paint più veloce: Imposta la proprietà font-display su swap nelle tue dichiarazioni @font-face. Questo assicura che il browser mostri immediatamente un font fallback mentre carica il web font in background. Una volta che il font è pronto, lo sostituisce senza interruzioni. Leggi di più su come garantire che il testo rimanga visibile durante il caricamento del webfont.
• Usa font-display: optional combinato con il precaricamento per eliminare lo spostamento del layout causato dai font: Combinare font-display: optional con il precaricamento offre un equilibrio tra velocità e potenziali spostamenti del layout. Il valore optional nasconde il testo brevemente (circa 100ms) prima di usare un font fallback. Il precaricamento istruisce il browser a scaricare il web font in anticipo, minimizzando il tempo speso sui font fallback e riducendo gli spostamenti del layout.
• Usa i descrittori font-face per far corrispondere le dimensioni del font fallback a quelle del web font: Questo garantisce un CLS minimo quando il web font viene sostituito. Specificando metriche simili usando size-adjust, ascent-override, descent-override e line-gap-override per il font fallback, puoi impedire al contenuto di saltare mentre il font si carica.
• Esegui il subsetting dei font per includere solo i caratteri necessari: Riduci la dimensione del file font eseguendo il subsetting dei font per includere solo i caratteri necessari per il tuo contenuto. Strumenti come Font Squirrel, pyftsubset o glyphhanger possono aiutare a generare i subset. Un font con il set completo di caratteri latini può spesso essere ridotto da 100KB+ a meno di 20KB con un subsetting appropriato.
• Limita il numero di pesi e stili dei font: Evita di caricare variazioni di font eccessive. Limitati a un massimo di 2 font critici (di solito precaricati) e 2 font a caricamento tardivo (caricati dopo il rendering iniziale). Ogni peso di font aggiuntivo aggiunge da 15 a 50KB di dimensione del download.

Ottimizzare gli script

Gli script possono causare problemi di Interaction to Next Paint, innescare Cumulative Layout Shift o ritardare il Largest Contentful Paint. Anche script ottimizzati e relativamente innocui caricati presto possono competere per le risorse e ritardare le metriche di paint (LCP e FCP). Per una guida completa, consulta 14 metodi per differire JavaScript.

• Rimuovi il JavaScript non necessario: Identifica ed elimina il codice JavaScript inutilizzato per minimizzare la quantità di codice che deve essere scaricato ed eseguito. Usa la scheda Coverage di Chrome DevTools per trovare il codice inutilizzato. Rimuovere il codice morto riduce sia il tempo di download che l'elaborazione sul main thread.
• Prioritizza gli script in base alla loro funzione e importanza: Gli script che fanno grandi modifiche al viewport visibile dovrebbero bloccare il rendering. Gli script importanti dovrebbero essere differiti o caricati in modo asincrono. Gli script non essenziali dovrebbero caricarsi quando il browser è inattivo. Consulta la nostra guida alla prioritizzazione delle risorse per una strategia dettagliata.
• Code splitting e lazy loading: Suddividi i grandi bundle JavaScript 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 sugli import dinamici.
• 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 tipicamente la dimensione dei file JavaScript dal 30 al 50%.
• Limita gli script di terze parti: Gli script di terze parti possono introdurre un overhead significativo sulle prestazioni. Valuta la loro necessità ed esplora alternative se possibile. Ogni script di terze parti aggiunge lookup DNS, overhead di connessione e tempo di elaborazione sul main thread. Audita 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 il rendering venga bloccato da terze parti. Usa l'attributo async o defer su tutti i tag script di terze parti.
• Monitora le prestazioni degli script di terze parti: Usa la Long Animation Frames (LoAF) API o CoreDash per tracciare l'impatto nel mondo reale degli script di terze parti su INP e LCP. Imposta budget di prestazioni per il JavaScript di terze parti e rivedili regolarmente.

Ottimizzare gli stili

Gli stili bloccano il rendering di default. Ottimizzare gli stili si tradurrà in metriche di paint ottimizzate. Segui la checklist per migliorare le prestazioni degli stili della tua pagina web. Il CSS che blocca il rendering impatta direttamente sia First Contentful Paint che LCP element render delay. Per suggerimenti sulla pulizia degli stili inutilizzati, consulta come rimuovere il CSS inutilizzato.

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

Ottimizzare i resource hint

I resource hint aiutano a dare priorità ai download per le risorse critiche. Le risorse precaricate vengono di solito messe in coda per il download e sono disponibili per il browser molto prima di quanto lo sarebbero state senza precaricamento. L'uso efficace dei resource hint può ridurre significativamente LCP resource load delay. Per un'implementazione avanzata, leggi 103 Early Hints.

• Rimuovi i resource hint non critici: Rimuovi i suggerimenti di precaricamento per le risorse che non sono essenziali per il caricamento iniziale della pagina. Questo impedisce download o connessioni di rete non necessari che competono per quelle risorse iniziali a banda limitata. Ogni precaricamento non necessario consuma banda che potrebbe essere usata per le risorse critiche.
• Preconnettiti ai domini critici: Stabilisci connessioni con domini importanti (come reti di distribuzione dei contenuti o fornitori di font) in anticipo. Questo velocizza il download delle risorse critiche da quei 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.
• Considera il DNS prefetch come alternativa al preconnect: Simile al preconnect, il DNS prefetch suggerisce al browser potenziali connessioni. Tuttavia, il preconnect dà priorità allo stabilire la connessione completa, mentre il DNS prefetch dice solo al browser di risolvere il nome di dominio in anticipo. Usa <link rel="dns-prefetch"> quando l'overhead completo della connessione del preconnect non è giustificato.
• Precarica l'elemento LCP: LCP misura quanto tempo impiega il contenuto principale a caricarsi. Precaricare l'elemento LCP istruisce il browser a 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 referenziate nel CSS o caricate tramite JavaScript.
• Precarica i font critici: Precaricare i font critici assicura che il browser li scarichi presto, prevenendo ritardi nella visualizzazione del testo e migliorando gli spostamenti cumulativi del layout causati dalla sostituzione dei font. Usa <link rel="preload" as="font" type="font/woff2" crossorigin> per i tuoi caratteri tipografici più importanti.
• Preferisci 103 Early Hints per i resource hint: Il codice di stato HTTP 103 Early Hints permette al server di inviare resource hint prima che la risposta completa sia pronta. Se il tuo server non supporta 103, usa gli header di risposta Link in alternativa. Se gli header non sono disponibili, aggiungi elementi <link> al <head> della pagina come fallback. Una consegna più anticipata dei suggerimenti significa una scoperta più rapida delle risorse.
• Precarica i font prima che i file CSS li scoprano: I font referenziati nel CSS vengono scoperti solo dopo che il file CSS è stato scaricato e analizzato. Precaricando i font direttamente nel <head> dell'HTML, elimini la dipendenza dall'analisi del CSS e permetti ai font di caricarsi in parallelo, riducendo sia FCP che il rischio di spostamento del layout.

Ottimizzare le icone

Le icone possono aggiungere un peso significativo alla tua pagina se non ottimizzate. Grandi icone SVG inline appesantiscono il tuo HTML, mentre i font di icone spesso includono migliaia di glifi inutilizzati. Ottimizzare le icone impatta sia LCP (riduzione del peso HTML/CSS) che CLS (corretta riserva delle dimensioni).

• Evita le icone SVG inline nell'HTML: Integrare grandi icone SVG inline può aumentare la dimensione del codice HTML e rallentare il caricamento della pagina. Considera metodi alternativi come servirle come file separati o usare font di icone (con cautela) per minimizzare la dimensione dell'HTML e permettere il caching del browser delle icone. Un foglio sprite SVG esterno è spesso il miglior equilibrio tra prestazioni e flessibilità.
• Evita font di icone grandi: Non usare mai grandi set di icone come Font Awesome nella loro interezza. Usa il subsetting per creare font di icone ottimizzati o SVG individuali 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 sotto i 5KB.
• Riserva larghezza e altezza per le icone: Simile alle immagini, specificare larghezza e altezza per le icone aiuta il browser a riservare spazio e previene gli spostamenti del layout durante il caricamento. Usa gli attributi width e height sugli elementi SVG o imposta dimensioni esplicite nel CSS.
• De-prioritizza i set di icone non critici: Se le icone non sono critiche per il rendering iniziale della pagina, considera di caricarle con priorità inferiore. Questo assicura che il contenuto essenziale si carichi per primo e minimizza l'impatto sulle metriche Core Web Vitals. Usa il lazy loading o carica i fogli di stile delle icone in modo asincrono dopo il paint iniziale.

Ottimizzare i tempi di risposta del server

I tempi di risposta del server, misurati dal 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, esplora le nostre guide sulla diagnosi dei problemi TTFB e sulla configurazione di 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. Confronta i provider di hosting usando misurazioni TTFB del mondo reale, non affermazioni di marketing sintetiche.
• Ottimizza il codice lato server e le query del database: Registra frequentemente i tempi di esecuzione del codice e delle query del database per trovare colli di bottiglia e migliorare la velocità complessiva. Usa strumenti di profilazione delle query e di monitoraggio delle prestazioni delle applicazioni (APM) per identificare gli endpoint lenti.
• Implementa strategie di caching: Utilizza il caching del browser e il caching lato server per memorizzare i dati frequentemente acceduti, riducendo la necessità di recuperi ripetuti di dati e migliorando i tempi di caricamento. Il caching dell'intera pagina può ridurre il TTFB da secondi a meno di 100ms. Scopri di più sull'ottimizzazione della durata della cache.
• Rendering lato client o edge per la personalizzazione: Considera il rendering lato client o edge di piccole personalizzazioni come il conteggio del carrello, lo stato di login o piccole modifiche al menu per mantenere la funzionalità di cache dell'intera pagina. Questo evita di invalidare la cache dell'intera pagina per elementi dinamici minori.
• Ottimizza le configurazioni del server: Rivedi e ottimizza le impostazioni del tuo web server per le prestazioni. Questo include le impostazioni di keep-alive della connessione, il conteggio dei processi worker, l'allocazione della memoria e i valori di timeout. Server mal configurati possono sprecare risorse e aumentare i tempi di risposta.
• Usa un Content Delivery Network (CDN): Un CDN distribuisce il contenuto statico del tuo sito web su più nodi edge (server). Questo riduce la distanza fisica che gli utenti devono percorrere per accedere al tuo contenuto, portando a tempi di caricamento più rapidi per il pubblico globale. Inoltre, i CDN sono di solito meglio configurati del tuo server. Consulta la nostra guida sulla configurazione di Cloudflare per una guida pratica alla configurazione.
• Riduci l'elaborazione lato server: Minimizza la quantità di lavoro che il tuo server fa per ogni richiesta. Pre-calcola le operazioni costose, usa algoritmi efficienti e sposta l'elaborazione non essenziale su job in background. Analizza il ciclo di vita delle richieste della tua applicazione per trovare ed eliminare passaggi di elaborazione non necessari.
• Usa HTTP/3: HTTP/3 è l'ultima versione dell'Hypertext Transfer Protocol. HTTP/3 è più veloce e più efficiente di HTTP/2 e significativamente più veloce di HTTP/1.1. L'aggiornamento a HTTP/3 può migliorare i tempi di caricamento complessivi 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 su quanto tempo impiegano le diverse parti della tua pagina ad essere elaborate sul server. Con questi dati, puoi individuare colli di bottiglia e aree di miglioramento, concentrandoti specificamente 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 logging delle query lente nel tuo database (MySQL, PostgreSQL, MongoDB) e rivedi i log settimanalmente. L'ottimizzazione degli indici, la ristrutturazione delle query e l'aggiunta di livelli di caching 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, risultando in file circa il 70% più piccoli. Brotli raggiunge tipicamente una compressione dal 15 al 20% migliore rispetto a GZIP. File più piccoli si traducono in tempi di caricamento più rapidi.

Ottimizzare l'interattività

Interaction to Next Paint (INP) misura quanto velocemente il tuo sito risponde alle interazioni degli utenti. Una scarsa interattività è spesso causata da task JavaScript di lunga durata che bloccano il main thread. Per un'analisi completa delle tre fasi INP, consulta le nostre guide su input delay, processing time e presentation delay.

• Implementa un pattern idle-until-urgent per gli script costosi: Questo approccio comporta dare priorità ai task critici e differire l'esecuzione del JavaScript non essenziale fino a quando il main thread del browser è inattivo. Questo assicura che i task critici come il rendering e le interazioni degli utenti non vengano bloccati da script di lunga durata. Usa requestIdleCallback per pianificare il lavoro non urgente. Scopri di più sull'ottimizzazione del processing time.
• Suddividi i task lunghi cedendo il controllo al main thread: I task JavaScript complessi possono bloccare il main thread, ritardando la reattività. Suddividere questi task in chunk più piccoli e cedere il controllo al main thread tra i chunk permette al browser di gestire le interazioni degli utenti e mantenere una user experience fluida. Usa scheduler.yield() (dove supportato) o setTimeout(0) per suddividere i task lunghi. Consulta la nostra guida su migliorare INP eliminando lo scrolling JavaScript.
• Fornisci feedback immediato dopo l'input: Gli utenti si aspettano reattività immediata dopo aver interagito con il tuo sito web. Fornisci indicazioni visive o riconosci l'input dell'utente prontamente, anche mentre i task di lunga durata vengono elaborati in background. Usa transizioni CSS e la pseudo-classe :active per un feedback visivo istantaneo. Questo aiuta a mantenere un senso di interattività e impedisce agli utenti di sentire che il sito web sia bloccato.
• Usa event listener passivi per scroll e touch: Aggiungi { passive: true } agli event listener di scroll e touch. I listener passivi dicono al browser che il gestore non chiamerà mai preventDefault(), permettendogli di iniziare lo scrolling immediatamente senza aspettare JavaScript. Questo è particolarmente impattante sui dispositivi mobili e migliora direttamente INP per le interazioni adiacenti allo scroll.

Monitoraggio dei Core Web Vitals

Monitorare i tuoi Core Web Vitals continuamente è essenziale per individuare le regressioni presto e verificare che le ottimizzazioni abbiano l'impatto previsto. Usa una combinazione di strumenti di laboratorio, dati di campo e monitoraggio degli utenti reali per un quadro completo.

• Controlla Lighthouse regolarmente: Lighthouse è uno strumento di auditing gratuito e open-source di Google che ti aiuta a identificare problemi di prestazioni sulle tue pagine web. Sebbene Lighthouse non misuri i Core Web Vitals direttamente in un contesto di utenti reali, è un ottimo strumento per testare e confrontare periodicamente il tuo sito web in condizioni regolate e standardizzate. Esegui Lighthouse nelle pipeline CI/CD per individuare le regressioni prima del deployment.
• Controlla i dati storici di CrUX regolarmente: CrUX (Chrome User Experience Report) è un dataset pubblico di Google che fornisce dati sulle prestazioni del mondo reale. CrUX è la fonte dati usata da Google per determinare se superi o meno i Core Web Vitals. Usa i dati storici per individuare rapidamente le regressioni. Puoi accedere ai dati CrUX tramite PageSpeed Insights, il CrUX Dashboard o la CrUX API.
• Configura il tracciamento RUM: RUM (Real User Monitoring) comporta il tracciamento delle esperienze degli utenti reali sul tuo sito web. Gli strumenti RUM raccolgono dati su quanto tempo impiegano effettivamente le pagine a caricarsi per i tuoi visitatori in diverse località e su vari dispositivi. Questo fornisce informazioni preziose sulle prestazioni del mondo reale, complementando i dati simulati di Lighthouse e CrUX. Raccomandiamo CoreDash come strumento di tracciamento RUM per dati dettagliati di attribuzione dei Core Web Vitals.
• Imposta budget di prestazioni: I budget di prestazioni stabiliscono obiettivi specifici (ad esempio, LCP sotto i 2,5 secondi, INP sotto i 200ms, CLS sotto 0,1) per diverse metriche. Questi fungono da benchmark per guidare i tuoi sforzi di ottimizzazione. Controllare regolarmente le tue prestazioni rispetto a questi budget ti aiuta a identificare le aree che necessitano di attenzione immediata e a dare priorità alle ottimizzazioni.
• Usa la segmentazione: Usa la segmentazione per tracciare i tipi di visitatori più preziosi e diversi tipi di pagina. Quantità maggiori di traffico potrebbero altrimenti mascherare problemi di prestazioni che impattano specificamente questi gruppi vitali. Segmenta per tipo di dispositivo, velocità di connessione, area geografica e template di pagina per scoprire problemi nascosti.

Ottimizzare il percorso di rendering critico

Il percorso di rendering critico è la sequenza di passaggi che il browser compie per convertire HTML, CSS e JavaScript in pixel visibili. Ottimizzare questo percorso migliora direttamente First Contentful Paint e LCP element render delay. Consulta anche come evitare dimensioni DOM eccessive.

• Minimizza il numero di risorse critiche: Ogni risorsa che blocca il rendering (CSS e JavaScript sincrono) deve essere scaricata ed elaborata prima che il browser possa dipingere. 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 si carichino per primi, seguiti dalle immagini above-the-fold, poi dagli script differiti. Usa l'attributo fetchpriority e i suggerimenti di prioritizzazione delle risorse per comunicare l'importanza al browser.
• Riduci la profondità dell'albero DOM: Alberi DOM profondamente nidificati aumentano il tempo di calcolo degli stili e il lavoro di layout. Punta a una profondità massima di 32 livelli e meno di 1.500 elementi DOM totali dove possibile. Una struttura DOM più piatta migliora sia le prestazioni di paint che il INP presentation delay.
• Preferisci classi e ID rispetto ai tag e attributi degli elementi: Invece di p.important, usa .important. Questo riduce la necessità del browser di cercare attraverso tutti gli elementi di quel tipo per la corrispondenza degli stili, risultando in un ricalcolo degli stili più veloce.
• Evita di nidificare i selettori in profondità: Più annidi in profondità i selettori CSS, più calcoli il browser deve eseguire. Prova a ristrutturare il tuo HTML per ridurre la nidificazione o usa classi più specifiche più vicine all'elemento. Limita la profondità dei selettori a un massimo di 3 livelli.
• Minimizza i selettori discendenti: Selettori come .container > .content costringono il browser a controllare ogni elemento all'interno del container. Se possibile, usa una classe più diretta sull'elemento del contenuto per una corrispondenza dei selettori più rapida.
• Consolida i selettori con gli stessi stili: Se più elementi condividono gli stessi stili, raggruppali in una singola classe o usa una convenzione di denominazione BEM (Block Element Modifier) per una migliore manutenibilità e un output CSS più piccolo.

Ottimizzare il consenso ai cookie

I banner di consenso ai cookie sono richiesti dal GDPR e da regolamenti simili, ma possono avere un impatto significativo sui Core Web Vitals se non implementati con cura. Un banner di consenso caricato male può ritardare LCP, causare CLS e aumentare 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 renderizza il banner di consenso nella risposta HTML iniziale è spesso più veloce che caricare una soluzione separata basata su JavaScript. Questo elimina la richiesta di rete extra e l'overhead di valutazione dello script.
• Carica gli script di consenso ai cookie in modo asincrono sulle pagine memorizzate nella cache: Per le pagine memorizzate nella cache, carica in modo asincrono il tuo script di consenso ai cookie e considera l'aggiunta di fetchpriority="high" allo script per assicurarti che si carichi abbastanza presto da essere visualizzato prima dell'interazione dell'utente.
• Mantieni il testo del consenso breve per evitare interferenze con LCP: Testi lunghi di avviso sui cookie possono prendere il posto dell'elemento LCP perché il browser considera il blocco di testo visibile più grande come potenziale candidato LCP. Considera di scrivere testi più brevi o suddividere i testi in più paragrafi con area visibile più piccola.
• Ospita localmente gli script di notifica dei cookie: Memorizza nella cache e ospita localmente gli script e i fogli di stile di notifica dei cookie quando possibile. Questo elimina i lookup DNS e l'overhead di connessione verso piattaforme di gestione del consenso di terze parti e ti dà il controllo completo sul comportamento di caricamento.

Ottimizzare le Single Page Application

Le Single Page Application (SPA) costruite con React, Vue, Angular o framework simili affrontano sfide uniche per i Core Web Vitals. Il rendering lato client può ritardare sia FCP che LCP, mentre l'hydration può bloccare INP.

• Usa sempre il server-side rendering o il prerendering: Le SPA che si affidano esclusivamente al rendering lato client costringono il browser a scaricare, analizzare ed eseguire JavaScript prima che qualsiasi contenuto sia visibile. Usa SSR (Next.js, Nuxt, SvelteKit) o il prerendering statico per servire HTML iniziale che il browser può dipingere immediatamente.
• Preferisci i prerender statici rispetto 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 un CDN senza alcuna elaborazione lato server. Usa la generazione statica per le pagine che non richiedono dati per ogni richiesta.
• Carica gli script di terze parti dopo l'hydration: Durante l'hydration, il framework sta già consumando un tempo significativo del main thread per rendere la pagina interattiva. Caricare script di terze parti contemporaneamente aggrava il problema e peggiora l'input delay. Differisci tutti gli script non essenziali fino al completamento del processo di hydration.

Evitare dimensioni DOM eccessive

Un DOM grande (più di 1.500 elementi o una profondità superiore a 32 livelli) aumenta l'uso della memoria, rallenta i calcoli degli stili e causa costosi reflow del layout. Questo impatta direttamente sia l'INP presentation delay che le metriche di paint. Consulta come correggere le dimensioni DOM eccessive.

• Riduci gli elementi DOM non necessari: Audita il tuo HTML per trovare elementi wrapper che non servono a scopi di stile o struttura. Sostituisci le strutture <div> profondamente nidificate con elementi HTML semantici. Considera la virtualizzazione delle liste lunghe con librerie come react-window o virtual-scroller per mantenere il DOM attivo piccolo.
• Usa selettori JavaScript e CSS efficienti: Selettori CSS complessi e query DOM JavaScript (come querySelectorAll con pattern ampi) diventano esponenzialmente più lenti con l'aumento delle dimensioni del DOM. Usa selettori di classe specifici e limita la portata delle query DOM ai sotto-alberi quando possibile.
• Usa content-visibility: auto per il contenuto fuori schermo: La proprietà CSS content-visibility: auto dice al browser di saltare il rendering degli elementi fuori schermo fino a quando non vengono scrollati nella vista. Questo può ridurre drasticamente il lavoro di rendering iniziale per le pagine con sezioni di contenuto lunghe.

Ottimizzare le richieste API

Le richieste API che bloccano il rendering o ritardano il contenuto possono impattare negativamente LCP e TTFB. Il recupero dati lato client è una fonte comune di LCP lento nelle single page application.

• Minimizza il numero di richieste API: Ogni richiesta API aggiunge al tempo di caricamento complessivo della pagina. Valuta la funzionalità del tuo sito web e identifica opportunità per ridurre il numero di richieste API necessarie per renderizzare il contenuto iniziale. Tecniche come il batching dei dati (combinare più richieste in una) e GraphQL possono ridurre i round trip.
• Usa API efficienti e ottimizzate: Il design e l'implementazione delle API stesse possono impattare le prestazioni. Assicurati di usare API ben progettate che sono ottimizzate per velocità ed efficienza. Implementa meccanismi di caching lato API per ridurre i tempi di risposta per i dati richiesti frequentemente.
• Precarica le richieste API critiche: Simile al precaricamento di risorse critiche come le immagini, precaricare le richieste API essenziali può migliorare significativamente le prestazioni percepite. Usa <link rel="preload" as="fetch"> per istruire il browser a scaricare le API critiche in anticipo, minimizzando i ritardi quando sono necessarie per renderizzare il contenuto iniziale. Consulta la nostra guida alla prioritizzazione delle risorse per più tecniche.

Ottimizzare i widget di chat

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

• Carica i widget di chat dopo che il contenuto principale è stato caricato: Nessuno nella storia di internet ha mai avuto bisogno di chattare prima che il contenuto principale della pagina fosse caricato. Differisci l'inizializzazione del widget di chat fino a quando la pagina ha completato il rendering iniziale, 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 è una buona idea nasconderli con opacity: 0 fino a quando non sono completamente renderizzati sulla pagina. Questo permette al widget di posizionarsi in background senza causare salti visibili del contenuto. Usa una transizione CSS per far apparire il widget in modo fluido.
• Scegli provider di widget di chat leggeri: Fai confronti. Alcuni widget di chat sono molto più leggeri e causano meno problemi di Core Web Vitals rispetto ad altri. Confronta la dimensione del bundle JavaScript, il numero di richieste di rete e l'impatto su INP di diversi provider prima di impegnarti.

Ottimizzare le prestazioni dei Service Worker

I service worker possono migliorare significativamente le prestazioni delle visite successive memorizzando nella cache gli asset e persino le risposte complete delle pagine, riducendo il TTFB per i visitatori di ritorno. Tuttavia, un service worker implementato male può effettivamente rallentare la navigazione. Scopri di più sull'ottimizzazione della durata della cache.

• Memorizza nella cache gli asset critici nel service worker: Usa una strategia cache-first per gli asset statici come CSS, JavaScript, font e immagini. Questo permette ai visitatori di ritorno di caricare il tuo sito quasi istantaneamente dalla cache locale. Pre-memorizza le risorse più importanti durante l'evento di installazione del service worker.
• Ottimizza il codice del service worker: Mantieni il tuo service worker snello ed efficiente. Evita logiche di routing complesse, un uso eccessivo di event.waitUntil() e grandi manifesti di precache che rallentano l'installazione. Usa il pattern stale-while-revalidate per le risorse che cambiano frequentemente ma non richiedono freschezza immediata.

Ottimizzare i contenuti video

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

• Comprimi e ottimizza i video: Usa codec moderni come H.264, VP9 o AV1 con impostazioni di qualità appropriate. Riduci la risoluzione video per corrispondere alla dimensione massima di visualizzazione. Un video che appare a 400px di larghezza non ha bisogno di essere codificato a 1920px. Usa la codifica a due passaggi per il miglior rapporto qualità/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 l'Intersection Observer API. Sostituisci i video di sfondo in autoplay con immagini poster e carica il video solo quando l'utente scorre vicino ad esso.
• Ospita i video su un CDN veloce: I file video sono grandi e beneficiano enormemente dalla distribuzione CDN. Usa un CDN dedicato ai video o un servizio di hosting (come Cloudflare Stream, Mux o Bunny.net) che fornisca streaming a bitrate adattivo, distribuzione geografica e consegna ottimizzata.
• Usa immagini poster per gli elementi video: Imposta sempre un attributo poster sugli elementi <video>. L'immagine poster dà al browser qualcosa da dipingere immediatamente mentre il video si carica, che può servire come elemento LCP. Ottimizza l'immagine poster come qualsiasi altra immagine LCP.