Font display in Lighthouse: cosa segnala e come risolverlo

L'avviso su font-display danneggia il punteggio?

Lighthouse segnala ogni web font caricato con font-display: block, auto o fallback tramite l'insight Font display ("Consider setting font-display to swap or optional"), chiamato "Ensure text remains visible during webfont load" prima di Lighthouse 13. Non ha peso nel punteggio, ma se un titolo è l'elemento LCP, nasconderlo ritarda il LCP su mobile. Imposta swap sui font che i visitatori vedono per primi e adatta il fallback con i metric overrides.

Cosa controlla l'insight Font display?

In Lighthouse 13 e PageSpeed Insights l'insight dice: "Consider setting font-display to swap or optional to ensure text is consistently visible. swap can be further optimized to mitigate layout shifts with font metric overrides." Prima di Lighthouse 13 l'audit si chiamava "Ensure text remains visible during webfont load".

Lighthouse legge il trace del caricamento della pagina generato direttamente da Chrome. Per ogni web font che la pagina inizia a scaricare, il trace registra il valore di font-display usato da Chrome. L'insight segnala tre valori:

• block: il testo rimane invisibile fino a 3 secondi mentre il font si scarica.
• auto: nessun valore. Google Fonts lo invia in assenza di &display=; è presente anche nei temi più vecchi, in Font Awesome 4 e in Material Icons.
• fallback: il testo rimane invisibile solo per 100 ms. Lighthouse 13 lo segnala comunque.

Passano solo due valori: swap e optional. La novità è arrivata con Lighthouse 13. Il vecchio audit accettava block e fallback, quindi un sito che aveva "risolto" il problema anni fa con fallback riceve di nuovo l'avviso. I temi a blocchi di WordPress usano fallback per impostazione predefinita, mentre Font Awesome 5 e 6 usano block.

"Est savings" è il tempo impiegato dalla richiesta del font nel trace, con un limite massimo di 3.000 ms. PageSpeed Insights registra quel trace senza throttling, quindi lì vedi spesso un numero basso. Il report qui sotto proviene da una pagina di test (la scheda prodotto di un negozio outdoor con un font condensed per il titolo), su uno smartphone con throttling di DevTools (Slow 4G). Lì il font del corpo testo ha impiegato più di 3 secondi e la tabella mostra il limite massimo. In ogni caso quel tempo non si recupera: con fallback un font nasconde il testo al massimo per 100 ms, e con auto Chrome smette di attenderlo 2 secondi dopo l'inizio della navigazione.

Accanto alla descrizione Lighthouse mostra due etichette. FCP è la metrica su cui Lighthouse stima il risparmio. Unscored indica un peso pari a 0: l'insight in sé non modifica mai il punteggio. Un font con block si riflette sul punteggio attraverso Speed Index e LCP.

Una regola @font-face non utilizzata non attiva mai la segnalazione. E poiché Lighthouse legge il trace, ora elenca anche i font che non hai aggiunto direttamente, come un kit Typekit o il file di Google Fonts caricato da un plugin. Il vecchio audit mostrava "unable to check" per i font provenienti da altri domini.

Cosa succede nel browser mentre un web font si carica?

Il browser non può richiedere un font finché non sa che un elemento visibile ne ha bisogno. Deve prima ricevere l'HTML, poi il CSS, e infine eseguire un calcolo degli stili che stabilisce: "questo titolo usa Barlow Condensed". Solo a quel punto parte la richiesta del font. Su uno smartphone con throttling questo è avvenuto a 0,74 s, dopo l'arrivo dell'HTML e del CSS. Un font viene sempre scoperto tardi. Un preload anticipa solo la partenza della richiesta: i font ricevono già la priorità più alta.

Da quel momento, il valore di font-display decide cosa vede il visitatore. Queste sono le tempistiche definite nel codice sorgente del browser:

Anche Safari e Firefox nascondono il testo fino a 3 s con block e auto. Firefox attende 1,5 s in più se ha già scaricato il 75% del font. Entrambi nascondono il testo per 100 ms con fallback e optional, e Firefox fa lo stesso con swap.

In Chrome, block è più lento di auto: auto ha il limite di 2 secondi, block no. Inoltre optional in Chrome non offre alcun periodo di tolleranza di 100 ms. Senza un preload il font non fa quasi mai in tempo per il primo render, nemmeno da un server veloce. Con un preload può farcela, se arriva entro circa 100 ms dal momento in cui la pagina è pronta per il render. Dalla cache, nella pagina successiva, ci riesce sempre.

La pagina prodotto al primo paint, a 0,9 s su uno smartphone con throttling. Il riquadro scuro è la foto, ancora in caricamento in entrambi i casi. Pagina di test su corewebvitals.io, Chrome 155, smartphone largo 412 px, Slow 4G e rallentamento CPU 4x.

Con block, il primo paint mostra l'header, i breadcrumb e la valutazione a stelle, con uno spazio vuoto al posto del nome del prodotto. Il font del titolo è leggero (15 kB) e arriva a 1,7 s. Il font del corpo testo pesa 344 kB ed è ancora in download quando Chrome smette di attenderlo a 3,7 s; fino a quel momento non compare nulla sotto la foto. Con swap, il nome del prodotto e la descrizione sono leggibili già dal primo paint.

La stessa pagina a 3 s: il font del titolo e la foto sono arrivati, il font del corpo testo no.

font-display influisce su LCP, CLS e FCP?

LCP

Il testo invisibile non può essere l'elemento LCP. Con block o auto, un LCP di tipo testo viene registrato solo quando il testo diventa visibile: all'arrivo del font o al termine del periodo di blocco. Su una pagina in cui l'elemento LCP è un titolo o un paragrafo, block può aggiungere fino a 3 secondi al LCP. Chrome ne aggiunge meno con auto, e su connessione Slow 4G ha perfino mostrato quel testo in Arial fin da subito. Con swap, il LCP corrisponde al paint con il font di fallback, e il passaggio al web font non aggiunge una nuova voce di LCP, anche se il testo con il web font risulta più grande.

Nella pagina prodotto qui sopra la foto è l'elemento LCP in tutte le versioni, quindi lì font-display non ha spostato il LCP. Questa è la prima cosa da verificare sulle pagine: l'elemento LCP è testo o un'immagine? L'insight LCP breakdown nello stesso report di Lighthouse lo indica chiaramente.

CLS

Ogni swap che modifica lo spazio occupato dal testo sposta tutto ciò che segue. Succede anche con block e auto: il testo invisibile occupa lo spazio del font di fallback e il passaggio al web font provoca lo stesso salto. Le versioni con block, auto e swap hanno tutte registrato un CLS di 0,031, nel momento esatto in cui è arrivato il font del titolo.

Con il normale swap il titolo passa da tre righe a due quando Barlow Condensed arriva a 1,7 s. Tutto ciò che si trova sotto sale di 39 px: CLS 0,031. Il contorno tratteggiato indica la posizione iniziale della foto.

La stessa pagina con un font di fallback che scala Arial Bold alla larghezza di Barlow (size-adjust: 68,32%). Il titolo occupa due righe fin dal primo paint e nulla si sposta: CLS 0.

In questo modo swap supera l'insight Font display ma mantiene il layout shift. 0,031 è inferiore a 0,1, ma su una pagina prodotto reale un secondo font che arriva dopo, un prezzo con un altro font o una barra sticky possono sommarsi. I metric overrides sul fallback eliminano questo shift.

Lighthouse non ti indirizzerà verso il font. Nella versione con swap, Layout shift culprits incolpa la foto definendola "Unsized image element". Eppure l'immagine ha larghezza e altezza impostate. A spostarla è stato il font del titolo, arrivato esattamente in quel momento. Confronta il momento dello shift con le richieste dei font prima di cercare dimensioni che in realtà ci sono già.

FCP

Lighthouse calcola il risparmio come FCP. Nella maggior parte delle pagine è qualcos'altro a determinare il FCP: sulla pagina prodotto, l'header e la barra delle spedizioni usano un font di sistema e fanno il paint a 0,8 s sia con block sia con swap. In un mio test personale con solo testo in web font sulla pagina, Chrome 155 ha comunque registrato il FCP a 112 ms mentre il testo era invisibile. Chrome considera il testo disegnato, salta solo il rendering dei glifi. Di conseguenza, il tempo che Lighthouse mostra come risparmio di FCP non si rifletterà sul tuo FCP. Quello che perdi con block è il LCP di un elemento di testo, lo Speed Index e ciò che vede il visitatore.

Quanti siti ricevono la segnalazione e quando puoi ignorarla?

State of CWV analizza le regole @font-face nelle home page di 170.706 siti che dichiarano web font. La metà di queste regole attiverebbe l'insight al caricamento del font: il 39,7% non ha alcun valore (auto), il 9,6% usa block e lo 0,9% fallback. Solo 471 siti usano il valore optional.

Siti con un buon LCP su mobile, raggruppati per numero di file di font caricati dalla home page e per i valori di font-display nelle regole @font-face. State of CWV, ottobre 2026: 170.706 siti che dichiarano web font, CrUX p75 su mobile, buon LCP pari a 2,5 s o inferiore.

Con uno o due file di font non c'è quasi differenza: l'88% dei siti con solo swap o optional ha un buon LCP su mobile, contro l'87% dei siti con solo block, auto o fallback. Con un numero di file compreso tra sei e dieci il divario è di 6 punti, con undici o più è di 9. I siti che combinano entrambi i tipi hanno i risultati peggiori. Dichiarano molti più font (una mediana di 44 regole @font-face contro 18), il che lascia pensare al font del tema più il font di un plugin più un icon font. Il CLS non presenta quasi differenze tra i gruppi.

Questa è una correlazione. I siti che curano i propri font di solito curano anche tutto il resto. Aggiungi il comportamento del browser descritto sopra, e la mia regola è: prima riduci i file di font, poi imposta font-display.

Puoi ignorare la segnalazione quando:

• il font renderizza solo testo below the fold, come il footer o le recensioni;
• l'elemento LCP è un'immagine e il font non causa shift.

Come individuare i problemi dei font nei field data?

Lighthouse mostra un solo caricamento su un unico smartphone simulato. I visitatori usano ogni tipo di connessione, e un visitatore di ritorno ha già il font in cache. In CoreDash due analisi ti dicono se i font ti stanno penalizzando.

• LCP per elemento. Se su mobile l'elemento LCP è un titolo o un paragrafo, un font impostato su block o auto lo ritarda in ogni visita che deve attenderlo. Se è un'immagine, il font non influisce sul LCP.
• CLS per elemento. Lo swap del font sposta ciò che si trova sotto il testo: la foto, la sezione successiva, il pulsante di acquisto. CoreDash indica l'elemento che si è spostato. Non dirà che è colpa di un font: se l'elemento che si muove si trova subito sotto un titolo o un paragrafo e ha larghezza e altezza definite, lo swap del font è la causa probabile.

CrUX fornisce le stesse metriche al p75 per l'origine o per un URL, negli ultimi 28 giorni, senza l'attribuzione.

LCP per elemento

CLS per elemento

CoreDash su un negozio di esempio, acme-pagespeed.com, mobile, p75. Il titolo del prodotto è l'elemento LCP in più sessioni di qualsiasi altro elemento, con un LCP di 3,28 s. Quando l'elemento LCP è la foto del prodotto, il LCP scende a 2,21 s. Nella tabella del CLS quella foto, posizionata subito sotto il titolo, compare in prima riga: 0,07 su 1.214 sessioni. Valutazione ancora buona, ma nessun altro elemento si sposta su così tante sessioni.

Come trovare il font segnalato in DevTools?

Apri la pagina in Chrome, vai nel pannello Performance, imposta la rete su Slow 4G e la CPU su 4x slowdown, quindi registra un ricaricamento. La barra laterale Insights elenca Font display insieme a ogni font segnalato. Cliccaci sopra e DevTools evidenzierà le richieste dei font nella traccia Network.

Controlla quindi dove termina ogni richiesta di font, dove si trova il marker del LCP e se la traccia Layout shifts registra uno shift subito dopo il termine di un font.

Per trovare ogni regola @font-face che punta a un file segnalato, apri Sources, cerca il nome del file in tutti i file (Ctrl+Shift+F, Cmd+Option+F su Mac) e imposta il valore in ogni regola trovata.

Come risolvere l'insight Font display?

L'URL del font nella tabella di Lighthouse ne indica la provenienza, e questo determina dove impostare font-display, o se è possibile farlo.

Le tue regole @font-face

Un font ospitato sul tuo dominio senza /wp-content/, /cdn/fonts/ o /_next/ nell'URL proviene dal tuo CSS. Aggiungi font-display: swap a ogni regola @font-face per quel font, comprese le copie in un secondo foglio di stile. L'eccezione riguarda gli icon font, come spiegato più sotto.

@font-face {
  font-family: "Barlow Condensed";
  src: url(/fonts/barlow-condensed-700.woff2) format("woff2");
  font-weight: 700;
  font-display: swap;
}

Google Fonts

La tabella mostra fonts.gstatic.com, ma l'impostazione va inserita nel link fonts.googleapis.com/css2 che carica il font. Aggiungi &display=swap all'URL:

<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Barlow+Condensed:wght@700&display=swap">

Ancora più veloce è ospitare il font da te: nessuna connessione aggiuntiva e pieno controllo sul preload.

Adobe Fonts

I font su use.typekit.net ereditano font-display dal progetto web su fonts.adobe.com: seleziona Edit Project e configuralo nella barra laterale. L'impostazione predefinita di Adobe è auto, e l'aggiunta di un parametro nell'URL non ha alcun effetto.

WordPress

I font del tema hanno /wp-content/themes/ nell'URL. In un tema a blocchi, imposta fontDisplay per ciascun font face in theme.json:

"fontFace": [{
  "fontFamily": "Barlow Condensed",
  "fontWeight": "700",
  "fontStyle": "normal",
  "fontDisplay": "swap",
  "src": ["file:./assets/fonts/barlow-condensed-700.woff2"]
}]

In un tema classico, aggiungi &display=swap all'URL di Google Fonts in wp_enqueue_style, oppure inserisci font-display nelle regole @font-face del tema. I font sotto /wp-content/plugins/ appartengono a un plugin o a un page builder: cerca prima un'impostazione dedicata lì. Per i Google Fonts caricati da un page builder, l'opzione in Elementor si trova sotto Elementor, Editor, Settings, nella scheda Advanced: Google Fonts Load. OMGF ospita Google Fonts in locale e può forzare swap su di essi. La guida a WordPress descrive il resto del lavoro su font e CSS.

Shopify

I font del tema Shopify presentano /cdn/fonts/ nell'URL, sul dominio del negozio. Vengono inseriti tramite il filtro font_face in theme.liquid e, senza font_display, non generano alcuna proprietà font-display:

{{ settings.type_header_font | font_face: font_display: 'swap' }}

Dawn lo imposta già.

Next.js

next/font usa display: 'swap' per impostazione predefinita, precarica il font e crea un fallback con metric overrides (adjustFontFallback). I suoi font contengono /_next/static/media/ nell'URL. Un font segnalato con questo percorso ha ricevuto un valore diverso nella chiamata a next/font (display: 'block'): modificalo lì. Se un font segnalato non contiene quel percorso, è stato caricato in un altro modo: con un tag <link> verso Google Fonts nel layout, oppure tramite un file CSS di una libreria di componenti.

Font che non puoi o non devi modificare

• Un icon font (fa-solid-900.woff2, bootstrap-icons.woff2, eicons.woff2): con swap mostra lettere o riquadri vuoti al posto delle icone. Sostituisci gli icon font con SVG quando possibile; in alternativa, lasciali su block.
• Un plugin o un'app senza opzioni per i font (un plugin WordPress, un font aggiunto da un'app Shopify): chiedi allo sviluppatore di impostare swap.
• Uno script di terze parti che aggiunge un font alla pagina (sul dominio del fornitore): non dipende da te. Carica lo script dopo che la pagina ha completato il render, oppure non toccare quella riga.

Carica meno file di font

Elimina i pesi e gli stili inutilizzati e usa un solo variable font invece di sei file statici. Ogni file rimosso è una richiesta in meno, uno swap in meno e una riga in meno in questo insight.

swap o optional: quale scegliere?

Usa swap per i font legati al brand, come il titolo e il logo, abbinando un fallback allineato. Usa optional per il corpo del testo se il font di sistema va bene lo stesso, e fai il preload di quel font per dargli una possibilità già nella prima pagina:

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>
<style>
@font-face {
  font-family: "Inter";
  src: url(/fonts/inter-var.woff2) format("woff2");
  font-weight: 100 900;
  font-display: optional;
}
</style>

L'attributo crossorigin è obbligatorio, anche per un font ospitato sul tuo dominio: senza di esso il browser scarica il font due volte. Il preload di un font in Chrome può ritardare il primo render fino a 100 ms: fai quindi il preload di uno o due font al massimo, mai di tutti. Su rete Slow 4G i font con preload sono comunque arrivati dopo il primo paint e la pagina ha mantenuto il fallback.

Elimina il layout shift con i metric overrides

Assegna al font di fallback le dimensioni del web font. Lo fai con una seconda regola @font-face che punta a un font locale e lo ridimensiona:

@font-face {
  font-family: "Barlow Fallback Arial";
  src: local("Arial Bold"), local("Arial-BoldMT");
  font-weight: 700;
  size-adjust: 68.32%;
  ascent-override: 146.37%;
  descent-override: 29.27%;
  line-gap-override: 0%;
}
h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", Arial, sans-serif;
}

size-adjust è la larghezza del testo con il web font divisa per la sua larghezza con il font di fallback. ascent-override e descent-override corrispondono all'ascent e al descent del web font divisi per quello stesso size-adjust. Strumenti come Fontaine e Capsize li calcolano a partire dai file dei font.

Lo stesso vale per il font del corpo del testo: in questo caso misura sul tuo testo reale, alla larghezza di uno smartphone e alle dimensioni che utilizzi. Inter varia la propria larghezza in base alla dimensione del font: da circa il 98% di Arial alle dimensioni dei titoli fino a circa il 105% a 18 px. Un valore di size-adjust del 97,6% mandava a capo la descrizione del prodotto su cinque righe nel fallback contro le sei di Inter, e il pulsante di acquisto si spostava comunque. Al 101% il testo va a capo allo stesso modo. Per fare una verifica, blocca il file del font in DevTools (Network, clic destro, Block request URL), ricarica con la larghezza mobile e confronta le interruzioni di riga con un caricamento normale. Modifica size-adjust finché non coincidono.

local() trova solo i font installati sul dispositivo: Arial è presente su Windows, macOS e iPhone; gli smartphone Android hanno Roboto. Per gli utenti Android, aggiungi una seconda variante di fallback per Roboto con i propri valori:

h1 {
  font-family: "Barlow Condensed", "Barlow Fallback Arial", "Barlow Fallback Roboto", sans-serif;
}

local() ignora le varianti il cui font non è installato, quindi ogni dispositivo usa la prima disponibile. Safari supporta size-adjust ma non ancora gli override di ascent e descent: la larghezza corrisponde, ma con line-height: normal l'altezza di riga può differire leggermente. Né WordPress né Shopify offrono impostazioni per gestire tutto questo. Serve uno sviluppatore.

Come verificare che il fix abbia funzionato?

Esegui di nuovo Lighthouse su mobile: Font display passerà tra gli insight superati. Sulla pagina prodotto il punteggio è salito da 97 a 98, interamente grazie alle metriche ponderate: lo Speed Index è passato da 1,9 s a 1,3 s perché il testo compare prima, e il CLS è sceso da 0,031 a 0 grazie agli override. Controlla poi il CLS nel tuo report: se la pagina si sposta ancora all'arrivo del font, il fallback necessita dei metric overrides.

Lighthouse 13.5.0, mobile, throttling di DevTools.

Se hai scelto optional, lo screenshot di Lighthouse mostra in genere il font di fallback. Lighthouse carica la pagina a freddo, ed è semplicemente optional che fa il suo dovere.

CoreDash mostra l'impatto per dispositivo a partire dalla visita successiva. CrUX e Search Console mostrano gli ultimi 28 giorni: due settimane dopo il fix, metà dei dati riflette ancora il vecchio sito.

Vuoi sapere se è un font a tenere in rosso il tuo LCP o CLS su mobile? In una Core Web Vitals power hour analizziamo insieme i tuoi field data e un trace della pagina: saprai esattamente quale regola dei font modificare nel tuo tema.