La Checklist Definitiva sui Core Web Vitals (2026)
Ogni ottimizzazione che dovresti verificare quando migliori le prestazioni di LCP, INP e CLS

La Checklist Definitiva sui Core Web Vitals
Questa checklist sui Core Web Vitals copre ogni ottimizzazione che dovresti verificare prima di pubblicare un nuovo sito, quando migliori il Largest Contentful Paint (LCP), l'Interaction to Next Paint (INP) o il Cumulative Layout Shift (CLS), o quando apporti modifiche significative al tuo sito. Usala come riferimento pratico per assicurarti che il tuo sito web offra un'esperienza veloce e fluida che superi la valutazione Core Web Vitals di Google.
Questa checklist è costantemente aggiornata in base alle scoperte più recenti. Se desideri contribuire sentiti libero di contattarmi.

Checklist di Ottimizzazione dei Core Web Vitals
In questo articolo, ti forniamo una checklist completa sui Core Web Vitals per aiutarti a identificare le aree di miglioramento e assicurarti che il tuo sito web offra un'esperienza fluida e veloce ai tuoi visitatori. Ogni sezione della checklist rimanda ai relativi articoli di approfondimento in modo da poter apprendere il "perché" dietro ogni raccomandazione.
Table of Contents!
- La Checklist Definitiva sui 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 Critical Rendering Path
- Ottimizzare il Consenso ai Cookie
- Ottimizzare le Single Page Application
- Evitare Dimensioni Eccessive del DOM
- 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, la maggior parte delle volte, l'elemento Largest Contentful Paint. Ottimizzare le immagini è una delle azioni a maggiore impatto che puoi intraprendere per l'LCP. Usa questi punti della checklist dei Core Web Vitals per migliorare la velocità delle immagini. Per un approfondimento, leggi la nostra guida su come ottimizzare l'immagine LCP.
- Ridimensiona le immagini per adattarle alle dimensioni massime sullo schermo: Questo garantisce che non vengano mai sprecati byte per il download di immagini più grandi della loro dimensione massima sullo schermo. Combina questa pratica con le immagini responsive per schermi di dimensioni inferiori. Servire immagini correttamente dimensionate può ridurre le dimensioni del file immagine del 50% o più senza alcuna perdita di qualità visibile.
- Usa il lazy loading per le immagini below-the-fold: Il lazy loading ritarda il caricamento delle immagini al di fuori del viewport finché non scorrono in vista, migliorando il First Contentful Paint (FCP) e la velocità di caricamento complessiva della pagina. Non usare mai il lazy loading per l'immagine LCP, poiché questo la ritarderà in modo significativo.
- 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à all'LCP. Usa
<link rel="preload" as="image">combinato confetchpriority="high"per i migliori risultati. Questo è particolarmente importante quando l'immagine LCP è richiamata dai CSS o caricata tramite JavaScript. - Imposta larghezza e altezza: Definire in anticipo le dimensioni dell'immagine previene i layout shift causati dall'attesa del caricamento delle immagini da parte del browser. Questo migliora il CLS. I browser moderni usano gli attributi width e height per calcolare l'aspect ratio prima che l'immagine sia caricata, riservando la corretta quantità di spazio.
- Usa formati immagine moderni come WebP o AVIF: Questi formati offrono file di dimensioni inferiori rispetto a JPEG o PNG pur mantenendo una qualità simile, portando a tempi di caricamento più rapidi. WebP raggiunge in genere file dal 25 al 34% più piccoli rispetto a JPEG, mentre AVIF può ridurre la dimensione del file fino al 50%. Usa l'elemento
<picture>con formati di fallback per la massima compatibilità dei browser. - Usa il lazy loading nativo e disabilita il lazy loading basato su JavaScript: Il lazy loading ritarda il caricamento delle immagini fuori dal viewport finché non vengono fatte scorrere in vista. Il lazy loading nativo offerto dai browser tramite l'attributo
loading="lazy"è generalmente più efficiente rispetto all'affidarsi a JavaScript per questo compito, poiché non richiede parsing o esecuzioni di script aggiuntive. - Usa immagini responsive con srcset: Questo attributo specifica diverse versioni dell'immagine per varie dimensioni dello schermo, garantendo che il browser fornisca l'immagine ottimale per il dispositivo dell'utente, riducendo download inutili e pesanti. Combina
srcsetcon l'attributosizesper un controllo preciso. - Aggiungi decoding="async": L'attributo
decoding="async"impedisce al browser di bloccare altri contenuti durante la decodifica di un'immagine. Ciò consente al motore di rendering di continuare a disegnare 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 le dimensioni 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 richiamate nei CSS vengono scoperte più tardi dal browser rispetto agli elementi
<img>in HTML. Se devi usare un'immagine di sfondo come elemento LCP, precaricala con un tag<link rel="preload">per garantirne una scoperta tempestiva. Scopri di più sul ritardo di caricamento delle risorse LCP.
Ottimizzare i Web Font
I web font possono ritardare il First Contentful Paint, causare layout shift 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 di hosting dei font, consulta la nostra guida su come ospitare i Google Fonts sul proprio server.
- Usa font-display: swap per un first paint più veloce: Imposta la proprietà
font-displaysuswapnelle tue dichiarazioni@font-face. Questo assicura che il browser mostri immediatamente un font di fallback mentre carica il web font in background. Una volta che il font è pronto, lo scambia senza interruzioni. Leggi di più su come garantire che il testo rimanga visibile durante il caricamento dei web font. - Usa font-display: optional combinato con il precaricamento per eliminare i layout shift causati dai font: Combinare
font-display: optionalcon il precaricamento offre un equilibrio tra velocità e potenziali layout shift. Il valoreoptionalnasconde brevemente il testo (circa 100ms) prima di utilizzare un font di fallback. Il precaricamento indica al browser di recuperare in anticipo il web font, riducendo al minimo il tempo trascorso sui font di fallback e riducendo i layout shift. - Usa i descrittori font-face per far corrispondere il font di fallback alle dimensioni del web font: Questo assicura un CLS minimo quando il web font viene scambiato.
Specificando metriche simili utilizzando
size-adjust,ascent-override,descent-overrideeline-gap-overrideper il font di fallback, puoi evitare che i contenuti saltino durante il caricamento del font. - Suddividi i font (subsetting) per includere solo i caratteri necessari: Riduci le dimensioni del file dei font creandone dei sottoinsiemi che includano solo i caratteri necessari per il tuo contenuto. Strumenti come Font Squirrel,
pyftsubsetoglyphhangerpossono aiutarti a generare sottoinsiemi. Un font con un set completo di caratteri latini può spesso essere ridotto da oltre 100KB a meno di 20KB con un subsetting adeguato. - Limita il numero di pesi e stili dei font: Evita di caricare eccessive variazioni di font. Attieniti a un massimo di 2 font critici (solitamente precaricati) e 2 font a caricamento ritardato (caricati dopo il rendering iniziale). Ogni peso del font aggiuntivo aggiunge da 15 a 50KB alla 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 gli script iniziali ottimizzati e relativamente innocui possono competere per le risorse e ritardare le metriche di paint (LCP e FCP). Per una guida completa, consulta i 14 metodi per differire JavaScript.
- Rimuovi JavaScript non necessario: Identifica ed elimina il codice JavaScript inutilizzato per ridurre al minimo la quantità di codice che deve essere scaricato ed eseguito. Usa la scheda Coverage dei Chrome DevTools per trovare il codice inutilizzato. La rimozione del codice morto riduce sia i tempi di download che l'elaborazione del thread principale.
- Dai priorità agli script in base alla loro funzione e importanza: Gli script che apportano grandi cambiamenti al viewport visibile dovrebbero bloccare il rendering. Gli script importanti dovrebbero essere differiti o caricati in modo asincrono. Gli script opzionali dovrebbero caricarsi durante l'inattività (idle) del browser. Consulta la nostra guida alla priorità delle risorse per una strategia dettagliata.
- Code splitting e lazy loading: Suddividi i grandi bundle JavaScript in blocchi 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 sulle importazioni dinamiche.
- Minimizza e ricompila i file JavaScript: Minimizza e ricompila sempre i tuoi file JavaScript con uno strumento di minimizzazione come SWC, Terser o esbuild. La minimizzazione riduce tipicamente le dimensioni dei file JavaScript del 30-50%.
- Limita gli script di terze parti: Gli script di terze parti possono introdurre un notevole sovraccarico prestazionale. Valuta la loro necessità ed esplora alternative se possibile. Ogni script di terze parti aggiunge lookup DNS, overhead di connessione e tempo di elaborazione del thread principale. Controlla regolarmente gli script di terze parti utilizzando il pannello Network dei 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 una terza parte. Usa l'attributo
asyncodefersu tutti i tag degli 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 performance per JavaScript di terze parti e rivedili regolarmente.
Ottimizzare gli Stili
Gli stili bloccano il rendering per impostazione predefinita. Ottimizzare gli stili si tradurrà in metriche di paint ottimizzate. Segui la checklist per migliorare le prestazioni degli stili della tua pagina web. I CSS che bloccano il rendering influiscono direttamente sia sul First Contentful Paint che sul ritardo di rendering dell'elemento LCP. Per suggerimenti su come ripulire gli stili inutilizzati, scopri come rimuovere i CSS inutilizzati.
- Minimizza i file CSS: Rimuovi i caratteri non necessari come spazi vuoti, commenti e formattazione dai file CSS. I file minimizzati hanno dimensioni inferiori, portando a tempi di caricamento più rapidi. Strumenti come cssnano, PostCSS o la compressione integrata del tuo preprocessore CSS possono automatizzare questo processo.
- Rimuovi i CSS inutilizzati: Identifica ed elimina il codice CSS che non è utilizzato sulle tue pagine web. Questo riduce la quantità di dati che il browser deve scaricare e parsare, migliorando le prestazioni. Strumenti come PurgeCSS o la scheda Coverage dei Chrome DevTools aiutano a identificare i CSS inutilizzati.
- Includi in linea i CSS critici (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 i CSS critici solo ai nuovi visitatori e di usare fogli di stile esterni memorizzati nella cache per i visitatori ricorrenti. Questa tecnica può ridurre l'FCP eliminando il round trip necessario per recuperare un foglio di stile esterno.
- Distribuisci equamente le dimensioni dei file CSS: Sebbene possa sembrare efficiente combinare tutti i CSS in un solo file, file eccessivamente grandi possono rallentare i tempi di download. Considera di suddividere i CSS in file più piccoli con una distribuzione delle dimensioni più uniforme (da 10 a 15KB ciascuno) per ottimizzare il caricamento e consentire 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 di utilizzare il caricamento asincrono tramite il pattern
media="print" onload="this.media='all'". Questo consente al browser di recuperare questi stili in parallelo ad altre risorse senza bloccare il rendering iniziale della pagina.
Ottimizzare 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 rese disponibili al browser molto prima di quanto lo sarebbero state senza il precaricamento. Un uso efficace dei resource hint può ridurre significativamente il ritardo di caricamento delle risorse LCP. Per implementazioni avanzate, leggi a proposito di 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 previene download non necessari o connessioni di rete che competono per le prime risorse, la cui larghezza di banda è limitata. Ogni precaricamento non necessario consuma larghezza di banda che potrebbe essere utilizzata per risorse realmente critiche.
- Pre-connetti ai domini critici: Stabilisci in anticipo le connessioni con domini importanti (come le Content Delivery Network o i fornitori di font). Questo accelera 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 origini di terze parti critiche. - Considera il DNS prefetch come alternativa al preconnect: Similmente al preconnect, il DNS prefetch suggerisce al browser potenziali connessioni. Tuttavia, il preconnect dà la priorità a stabilire l'intera connessione, mentre il DNS prefetch dice semplicemente al browser di risolvere il nome di dominio in anticipo. Usa
<link rel="dns-prefetch">quando l'overhead della connessione completa del preconnect non è giustificato. - Precarica l'elemento LCP: LCP misura quanto tempo impiega il contenuto principale a caricarsi. Precaricare l'elemento LCP indica al browser di dare la priorità al download di questa risorsa critica, accelerando il tempo necessario affinché gli utenti vedano il contenuto principale. Questo è particolarmente importante per le immagini richiamate dai CSS o caricate tramite JavaScript.
- Precarica i font critici: Precaricare i font critici garantisce che il browser li recuperi presto, prevenendo ritardi nella visualizzazione del testo e migliorando i layout shift cumulativi causati dallo scambio di 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: Il codice di stato HTTP 103 Early Hints consente al server di inviare suggerimenti sulle risorse prima che l'intera risposta sia pronta. Se il tuo server non supporta 103, usa in alternativa le intestazioni di risposta
Link. Se le intestazioni non sono disponibili, aggiungi gli elementi<link>nella sezione<head>della pagina come fallback. Una consegna anticipata dei suggerimenti significa una scoperta più rapida delle risorse. - Precarica i font prima che i file CSS li scoprano: I font richiamati nei CSS vengono scoperti solo dopo che il file CSS è stato scaricato e parsato. Precaricando i font direttamente nel tag
<head>dell'HTML, elimini la dipendenza dal parsing dei CSS e permetti ai font di caricarsi in parallelo, riducendo sia l'FCP che il rischio di layout shift.
Ottimizzare le Icone
Le icone possono aggiungere un peso significativo alla tua pagina se non ottimizzate. Le grandi icone SVG in linea appesantiscono il tuo HTML, mentre gli icon font spesso includono migliaia di glifi inutilizzati. L'ottimizzazione delle icone influisce sia sull'LCP (ridotto peso HTML/CSS) sia sul CLS (corretta prenotazione delle dimensioni).
- Evita icone SVG in linea nell'HTML: Inserire grandi icone SVG direttamente nell'HTML può aumentare le dimensioni del tuo codice HTML e rallentare il caricamento della pagina. Considera metodi alternativi come servirle come file separati o usare icon font (con cautela) per ridurre al minimo le dimensioni dell'HTML e consentire la memorizzazione nella cache del browser delle icone. Uno sprite sheet SVG esterno è spesso il miglior equilibrio tra prestazioni e flessibilità.
- Evita grandi icon font: Non usare mai set di icone di grandi dimensioni come Font Awesome nella loro interezza. Usa il subsetting per creare icon font ottimizzati o SVG individuali per ridurre la dimensione complessiva della pagina web e migliorare la velocità di caricamento. Un set completo Font Awesome può superare i 100KB, mentre un subset con 20 icone può essere inferiore a 5KB.
- Riserva larghezza e altezza per le icone: Similmente alle immagini, specificare larghezza e altezza per le icone
aiuta il browser a riservare lo spazio ed evita i layout shift mentre si caricano. Usa gli attributi
widtheheightsugli elementi SVG o imposta dimensioni esplicite nel CSS. - Riduci la priorità dei set di icone non critici: Se le icone non sono critiche per il rendering iniziale della tua pagina, considera di caricarle con una priorità inferiore. Questo assicura che il contenuto essenziale si carichi per primo e minimizza 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 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 su come diagnosticare i problemi di TTFB e su come configurare Cloudflare per le prestazioni.
- Usa un provider di hosting veloce e affidabile: Un provider di hosting veloce con una solida infrastruttura può migliorare significativamente i tempi di risposta del server e le prestazioni complessive del sito web. Valuta i provider di hosting utilizzando misurazioni reali del TTFB, 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 i colli di bottiglia e migliorare la velocità complessiva. Usa la profilazione delle query e strumenti di Application Performance Monitoring (APM) per identificare gli endpoint lenti.
- Implementa strategie di cache: Utilizza la cache del browser e la cache lato server per memorizzare i dati a cui si accede di frequente, riducendo la necessità di recuperare i dati ripetutamente e migliorando i tempi di caricamento. La cache 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 su edge per la personalizzazione: Considera il rendering lato client o sull'edge server di piccole personalizzazioni come il conteggio del carrello, lo stato di accesso o piccole modifiche al menu per mantenere la funzionalità di cache completa della pagina. Questo evita l'annullamento della cache dell'intera pagina per piccoli elementi dinamici.
- Ottimizza le configurazioni del server: Rivedi e metti a punto le impostazioni del tuo server web per le prestazioni. Ciò include le impostazioni di connessione keep-alive, il numero di processi worker, l'allocazione della memoria e i valori di timeout. Server configurati male 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 riduce la distanza fisica che gli utenti devono percorrere per accedere ai tuoi contenuti, portando a tempi di caricamento più rapidi per il pubblico globale. Inoltre, le CDN sono solitamente configurate meglio del tuo stesso server. Consulta la nostra guida su come configurare Cloudflare per una spiegazione pratica dell'installazione.
- Riduci l'elaborazione lato server: Riduci al minimo la quantità di lavoro che il tuo server svolge per ogni richiesta. Pre-calcola operazioni costose, usa algoritmi efficienti e sposta l'elaborazione non essenziale su job in background. Analizza il ciclo di vita della richiesta della tua applicazione per trovare ed eliminare i passaggi di elaborazione non necessari.
- Usa HTTP/3: L'HTTP/3 è l'ultima versione dell'Hypertext Transfer Protocol. L'HTTP/3 è più veloce e più efficiente dell'HTTP/2 e significativamente più veloce dell'HTTP/1.1. L'aggiornamento a HTTP/3 può migliorare i tempi di caricamento complessivi della pagina e potenzialmente tutte e tre le metriche dei Core Web Vitals (LCP, INP, CLS). Scopri di più sull'ottimizzazione della durata della connessione.
- Imposta le intestazioni Server-Timing: Queste intestazioni forniscono informazioni dettagliate su quanto tempo impiegano le diverse parti della tua pagina per essere elaborate sul server. Con questi dati, puoi individuare i colli di bottiglia e le aree di miglioramento, concentrandoti specificamente sul miglioramento del Largest Contentful Paint (LCP). Le intestazioni Server-Timing sono visibili nel pannello Network dei Chrome DevTools e possono essere catturate dagli strumenti RUM come CoreDash.
- Registra le query lente del database e ottimizzale regolarmente: Abilita la registrazione 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 cache per 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 di dimensioni inferiori di circa il 70%. Brotli in genere raggiunge una compressione migliore del 15-20% rispetto a GZIP. Dimensioni dei file più piccole si traducono in tempi di caricamento più rapidi.
Ottimizzare l'Interattività
L'Interaction to Next Paint (INP) misura quanto velocemente il tuo sito risponde alle interazioni degli utenti. Una scarsa interattività è spesso causata da attività JavaScript di lunga durata che bloccano il thread principale. Per un'analisi completa delle tre fasi dell'INP, consulta le nostre guide su input delay, processing time, e presentation delay.
- Implementa un pattern idle-until-urgent per gli script onerosi: Questo approccio prevede
di dare la priorità alle attività critiche e differire l'esecuzione del JavaScript non essenziale finché
il thread principale del browser non è inattivo. Questo assicura che attività critiche come il rendering e le interazioni dell'utente non
vengano bloccate da script di lunga esecuzione. Usa
requestIdleCallbackper programmare lavori non urgenti. Scopri di più su come ottimizzare il processing time. - Suddividi le attività lunghe cedendo il controllo al thread principale: Attività JavaScript complesse possono
bloccare il thread principale, ritardando la reattività. Suddividere queste attività in porzioni più piccole
e restituire il controllo al thread principale tra una porzione e l'altra consente al browser di gestire
le interazioni dell'utente e mantenere un'esperienza fluida. Usa
scheduler.yield()(dove supportato) osetTimeout(0)per spezzare compiti lunghi. Consulta la nostra guida su come migliorare l'INP abbandonando lo scrolling tramite JavaScript. - Fornisci feedback immediato dopo l'input: Gli utenti
si aspettano una reattività immediata dopo aver interagito con il tuo sito web. Fornisci segnali visivi
o conferma l'input dell'utente in modo rapido, anche mentre le attività più lunghe vengono elaborate in
background. Usa transizioni CSS e la pseudo-classe
:activeper un feedback visivo istantaneo. Questo aiuta a mantenere un senso di interattività e impedisce agli utenti di avere la sensazione che il sito web sia bloccato. - Usa listener di eventi passivi per lo scroll e il tocco: Aggiungi
{ passive: true }ai listener degli eventi di scorrimento e tocco. I listener passivi dicono al browser che il gestore non chiamerà maipreventDefault(), permettendogli di iniziare lo scorrimento immediatamente senza aspettare JavaScript. Questo ha un impatto notevole sui dispositivi mobili e migliora direttamente l'INP per le interazioni adiacenti allo scorrimento.
Monitoraggio dei Core Web Vitals
Monitorare continuamente i tuoi Core Web Vitals è essenziale per individuare tempestivamente le regressioni e confermare che le ottimizzazioni abbiano l'impatto atteso. Usa una combinazione di strumenti di laboratorio, dati sul campo e monitoraggio degli utenti reali per un quadro completo.
- Controlla regolarmente Lighthouse: Lighthouse è uno strumento di controllo 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 nel contesto di un utente reale, è un ottimo strumento per testare e confrontare periodicamente il tuo sito web in condizioni regolate e standardizzate. Esegui Lighthouse nelle pipeline CI/CD per catturare le regressioni prima del deployment.
- Controlla regolarmente i dati storici CrUX: Il CrUX (Chrome User Experience Report) è un set di dati pubblico di Google che fornisce dati sulle prestazioni del mondo reale. CrUX è la fonte di dati utilizzata 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, la Dashboard CrUX o l'API CrUX.
- Imposta il tracciamento RUM: Il RUM (Real User Monitoring) prevede 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 preziose informazioni sulle prestazioni nel mondo reale, integrando i dati simulati da Lighthouse e CrUX. Raccomandiamo CoreDash come tuo strumento di tracciamento RUM per dati dettagliati di attribuzione dei Core Web Vitals.
- Imposta budget di performance: I budget di performance fissano obiettivi di prestazione specifici (ad esempio, LCP sotto i 2,5 secondi, INP sotto i 200ms, CLS sotto 0,1) per diverse metriche. Questi agiscono come parametri di riferimento per guidare i tuoi sforzi di ottimizzazione. Verificare 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 tuoi tipi di visitatori più preziosi e i diversi tipi di pagina. Grandi quantità di traffico potrebbero altrimenti mascherare problemi di prestazione che colpiscono specificamente questi gruppi vitali. Segmenta per tipo di dispositivo, velocità di connessione, area geografica e modello di pagina per scoprire problemi nascosti.
Ottimizzare il Critical Rendering Path
Il Critical Rendering Path è la sequenza di passaggi che il browser esegue per convertire HTML, CSS e JavaScript in pixel visibili. L'ottimizzazione di 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 che blocca il rendering (CSS e JavaScript sincrono) deve essere scaricata ed elaborata prima che il browser possa iniziare a disegnare. Riduci il numero di risorse critiche differendo script non essenziali e caricando in modo asincrono fogli di stile non critici.
- Ottimizza l'ordine di caricamento delle risorse: Assicurati che i CSS e i font critici si carichino per primi, seguiti dalle immagini above-the-fold, e poi dagli script differiti. Usa l'attributo
fetchprioritye i suggerimenti per la priorità delle risorse per comunicare la loro importanza al browser. - Riduci la profondità dell'albero del DOM: Alberi del DOM profondamente annidati aumentano i tempi di calcolo degli stili e il lavoro di layout. Punta a una profondità massima di 32 livelli e meno di 1.500 elementi DOM in totale, ove possibile. Una struttura DOM più piatta migliora sia le prestazioni di paint che il ritardo di presentazione dell'INP.
- Privilegia classi e ID rispetto ai tag elemento e agli attributi:
Invece di
p.important, usa.important. Questo riduce la necessità da parte del browser di cercare tra tutti gli elementi di quel tipo per far corrispondere lo stile, risultando in ricalcoli di stile più rapidi. - Evita di annidare i selettori profondamente: Più a fondo annidi i selettori CSS, più calcoli dovrà eseguire il browser. Prova a ristrutturare il tuo HTML per ridurre l'annidamento o usa classi più specifiche più vicine all'elemento. Limita la profondità del selettore a un massimo di 3 livelli.
- Riduci al minimo i selettori discendenti: Selettori come
.container > .contentobbligano il browser a controllare ogni elemento all'interno del contenitore. Se possibile, usa una classe più diretta sull'elemento contenuto per un accoppiamento del selettore più rapido. - Consolida 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 normative simili, ma possono avere un impatto significativo sui Core Web Vitals se non implementati con attenzione. Un banner di consenso caricato male può ritardare l'LCP, causare CLS, e aumentare l'INP. Per maggiori dettagli, leggi di più sull'ottimizzazione dei 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 renderizzi il banner di consenso nella risposta HTML iniziale è spesso più veloce del caricare una soluzione separata basata su JavaScript. 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 cacheate: Per le pagine memorizzate nella cache, carica in modo asincrono lo script di consenso ai cookie e considera di aggiungere
fetchpriority="high"allo script per assicurarti che si carichi abbastanza presto da essere visualizzato prima dell'interazione dell'utente. - Mantieni breve il testo del consenso per evitare interferenze con LCP: Testi lunghi per l'informativa sui cookie possono assumere il ruolo di elemento LCP, poiché il browser considera il blocco di testo visibile più grande come potenziale candidato LCP. Valuta di scrivere testi più brevi o di suddividere i testi in più paragrafi con un'area visibile più piccola.
- Self-hosta gli script di notifica dei cookie: Memorizza nella cache e self-hosta gli script e i fogli di stile delle notifiche sui cookie quando possibile. Questo elimina le ricerche DNS e l'overhead di connessione verso piattaforme di gestione del consenso di terze parti e ti dà il pieno controllo 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 l'FCP che l'LCP, mentre l'idratazione (hydration) può bloccare l'INP.
- Usa sempre il rendering lato server (SSR) o il prerendering: Le SPA che si basano esclusivamente sul 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 l'HTML iniziale che il browser può disegnare immediatamente.
- Preferisci i prerender statici alla generazione dinamica: I prerender statici (generati a build-time) 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 ad ogni singola richiesta.
- Carica gli script di terze parti dopo l'idratazione: Durante l'idratazione, il framework sta già consumando tempo significativo del thread principale per rendere la pagina interattiva. Caricare simultaneamente script di terze parti aggrava il problema e peggiora l'input delay. Differisci tutti gli script non essenziali a dopo il completamento del processo di idratazione.
Evitare Dimensioni Eccessive del DOM
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 ricalcoli del layout (reflow). Questo influisce direttamente sia sul ritardo di presentazione dell'INP che sulle metriche di paint. Scopri come risolvere l'eccessiva grandezza del DOM.
- Riduci gli elementi DOM non necessari: Controlla il tuo HTML per elementi wrapper che non hanno scopo stilistico o strutturale. Sostituisci strutture
<div>profondamente annidate con elementi HTML semantici. Considera di virtualizzare lunghe liste con librerie come react-window o virtual-scroller per mantenere ridotto il DOM attivo. - Usa selettori JavaScript e CSS efficienti: Selettori CSS e query del DOM JavaScript complessi (come
querySelectorAllcon pattern ampi) diventano esponenzialmente più lenti al crescere delle dimensioni del DOM. Usa selettori di classe specifici e limita l'ambito delle interrogazioni DOM ai sotto-alberi ogni volta che è possibile. - Usa content-visibility: auto per i contenuti fuori schermo: La proprietà CSS
content-visibility: autosuggerisce al browser di ignorare il rendering di elementi fuori dallo schermo finché non vengono scrollati in vista. Questo può ridurre drasticamente il lavoro di rendering iniziale per pagine con lunghe sezioni di contenuto.
Ottimizzare le Richieste API
Le richieste API che bloccano il rendering o ritardano il contenuto possono avere un impatto negativo su LCP e TTFB. Il recupero di dati lato client è una fonte comune di un LCP lento nelle single page application.
- Minimizza il numero di richieste API: Ogni richiesta API si aggiunge al tempo di caricamento complessivo della pagina. Valuta le funzionalità del tuo sito web e identifica le opportunità per ridurre il numero di richieste API necessarie per il rendering del contenuto iniziale. Tecniche come il data batching (la combinazione di più richieste in una sola) e GraphQL possono ridurre i viaggi di andata e ritorno (round trip).
- Usa API efficienti e ottimizzate: Il design e l'implementazione delle API stesse possono influire sulle prestazioni. Assicurati di utilizzare API ben progettate e ottimizzate per velocità ed efficienza. Implementa meccanismi di cache lato API per ridurre i tempi di risposta per dati richiesti frequentemente.
- Precarica le richieste API critiche: Analogamente 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 indicare al browser di recuperare le API critiche in anticipo, minimizzando i ritardi quando sono necessarie per il rendering del contenuto iniziale. Consulta la nostra guida alla priorità delle risorse per ulteriori tecniche.
Ottimizzare i Widget di Chat
I widget di chat sono una causa comune di layout shift e potrebbero persino causare problemi con l'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 il caricamento del contenuto principale: Nessuno nella storia di internet ha mai avuto bisogno di chattare prima che il contenuto principale della pagina fosse caricato. Ritarda l'inizializzazione del widget di chat fino a quando la pagina non ha terminato il suo rendering iniziale, usando
requestIdleCallbacko un trigger basato sullo scorrimento. - Previeni i layout shift causati dal widget di chat: Se i widget di chat causano un layout shift, di solito è una buona idea nasconderli con
opacity: 0finché non sono stati completamente renderizzati sulla pagina. Questo consente al widget di eseguire il layout in background senza far "saltare" i contenuti visibili. Usa una transizione CSS per far apparire il widget in modo fluido. - Scegli fornitori di widget di chat leggeri: Guardati attorno. Alcuni widget di chat sono molto più leggeri e causano meno problemi ai Core Web Vitals rispetto ad altri. Confronta le dimensioni del bundle JavaScript, il numero di richieste di rete e l'impatto sull'INP dei diversi provider prima di decidere.
Ottimizzare le Prestazioni dei Service Worker
I service worker possono migliorare significativamente le prestazioni per le visite di ritorno memorizzando in cache asset e persino intere risposte della pagina, riducendo il TTFB per i visitatori di ritorno. Tuttavia, un service worker mal implementato può in realtà rallentare la navigazione. Scopri di più sull'ottimizzazione della durata della cache.
- Metti in cache gli asset critici nel service worker: Usa una strategia cache-first per gli asset statici come CSS, JavaScript, font e immagini. Questo consente ai visitatori di ritorno di caricare il tuo sito quasi all'istante dalla cache locale. Precarica 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 manifesti di precache di grandi dimensioni che rallentano l'installazione. Usa il pattern stale-while-revalidate per le risorse che cambiano di frequente ma che non richiedono aggiornamento immediato.
Ottimizzare i Contenuti Video
Gli elementi video possono diventare l'elemento LCP se sono il contenuto visibile più grande nel viewport. Inoltre, i video di grandi dimensioni 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à appropriate. Riduci la risoluzione del video per adattarla 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 tra qualità e dimensione del file.
- Usa il lazy loading per i video: Per i video below-the-fold, usa l'attributo
loading="lazy"sugli elementi<iframe>o ritarda il caricamento del video con l'API Intersection Observer. Sostituisci i video di sfondo in riproduzione automatica con immagini poster e carica il video solo quando l'utente vi scorre vicino. - Ospita i video su una CDN veloce: I file video sono grandi e beneficiano immensamente della distribuzione via CDN. Usa una CDN o un servizio di hosting dedicato per i video (come Cloudflare Stream, Mux o Bunny.net) che offra adaptive bitrate streaming, distribuzione geografica e consegna ottimizzata.
- Usa immagini poster per gli elementi video: Imposta sempre un attributo
postersugli elementi<video>. L'immagine poster fornisce al browser qualcosa da disegnare immediatamente mentre il video si carica, che può servire come elemento LCP. Ottimizza l'immagine poster esattamente come qualsiasi altra immagine LCP.
17 years of fixing PageSpeed.
I have optimized platforms for some of the largest publishers and e-commerce sites in Europe. I provide the strategy, the code, and the RUM verification. Usually in 1 to 2 sprints.
View Services
