Ottimizzazione dei Font Web: font-display, preload, Variable Fonts e Subsetting nel 2026

Aggiornato: 7 giugno 2026

Ottimizzare i font web significa servire il formato giusto (WOFF2), preloadare solo il file critico, scegliere il font-display corretto (quasi sempre swap o optional) e usare size-adjust con ascent-override sui font di fallback per azzerare il Cumulative Layout Shift. Nel 2026, con i variable fonts ormai supportati ovunque e il subsetting via unicode-range, è normale passare da 400 KB di font a meno di 30 KB senza perdere stili. In questa guida vediamo ogni leva, con codice pronto da incollare e numeri reali misurati su progetti veri.

• WOFF2 è l'unico formato che serve nel 2026: supportato dal 98%+ dei browser e ~30% più piccolo di WOFF.
• font-display: swap protegge dal FOIT ma può causare un piccolo CLS; optional elimina il CLS rinunciando al font su prima visita lenta.
• Variable fonts sostituiscono 4-9 file statici con un unico file di 60-120 KB e riducono drasticamente le richieste.
• Subsetting con unicode-range spezza il font in blocchi linguistici, scaricando solo i glifi effettivamente usati.
• preload + crossorigin="anonymous" sul file del font critico anticipa il download di 200-500 ms rispetto al discovery via CSS.
• size-adjust, ascent-override e descent-override allineano il font di fallback al font finale, riducendo il CLS a praticamente zero.

Perché i font web rallentano il sito

I font web sono risorse particolari: il browser scopre l'URL del file solo dopo aver scaricato il CSS, parsato le regole @font-face e capito quali glifi servono effettivamente al testo presente nella pagina. Questa catena di scoperta tardiva è la ragione per cui un font può ritardare il Largest Contentful Paint del titolo principale di 400-800 ms su connessioni 4G, anche quando il file pesa appena 40 KB.

Il secondo problema è il layout shift: il fallback (Arial, Times New Roman) ha metriche diverse dal font finale, quindi quando il font web arriva il testo si riflowsa, spinge gli elementi sotto e degrada il CLS. In Chrome, anche con font-display: swap, ho misurato di persona shift di 0,08-0,15 su pagine editoriali quando il fallback non è allineato.

Infine c'è il peso. Un singolo font variabile italiano-latino-esteso può pesare 280 KB; quattro pesi statici (Regular, Italic, Bold, BoldItalic) facilmente sforano gli 800 KB. Su 75th percentile di smartphone in 4G italiana, 800 KB significano circa 1,2 s solo per scaricarli. Le leve che vediamo sotto comprimono questi numeri di 5-30 volte.

Perché nel 2026 serve solo WOFF2

WOFF2 usa la compressione Brotli sui dati del font e raggiunge il 98%+ di supporto globale secondo i dati pubblicati su caniuse.com. Tutti gli altri formati (TTF, OTF, EOT, WOFF, SVG fonts) sono ormai obsoleti per il web nel 2026. Servirli in fallback è solo overhead di byte e regole CSS.

Confronto reale su Inter Variable (latin + latin-ext):

Formato	Peso	Supporto	Consigliato 2026
TTF / OTF	~480 KB	100%	No (non compresso)
WOFF	~260 KB	99,9%	No (legacy)
WOFF2	~180 KB	98,4%	Sì, unico formato
WOFF2 + subset latin	~28 KB	98,4%	Sì, ideale

La regola @font-face minimale nel 2026 è quindi una sola sorgente:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-var-latin.woff2") format("woff2-variations");
  font-weight: 100 900;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

Come scegliere font-display: swap, optional, fallback

La proprietà font-display controlla cosa il browser mostra mentre il font web è in download. Documentata su MDN — font-display, ha cinque valori, ma in pratica solo tre sono utili.

swap (default consigliato per body text)

Mostra subito il fallback (block period circa 0 ms), poi cambia al font web non appena arriva (swap period infinito). Pro: il testo è sempre leggibile. Contro: causa FOUT (Flash of Unstyled Text) e potenziale CLS se il fallback non è allineato.

optional (consigliato per font decorativi)

Block period di circa 100 ms, poi se il font non è ancora arrivato il browser si tiene il fallback per l'intera sessione. Zero CLS su prima visita perché non c'è swap. Il font verrà comunque cachato per le visite successive. Ideale per font display, headline, o quando il rischio di shift è inaccettabile.

fallback (compromesso)

Block period brevissimo (circa 100 ms), swap period di 3 s. Se entro 3 s il font non è arrivato, si tiene il fallback. Buono per body text dove non vuoi un FOUT tardivo a pagina già letta.

Preload del font critico: come e quando

Senza preload, il browser scopre il font web solo dopo aver parsato il CSS. Con <link rel="preload"> nell'<head>, il download parte in parallelo al CSS, recuperando 200-500 ms sul percorso critico.

<link rel="preload"
      href="/fonts/inter-var-latin.woff2"
      as="font"
      type="font/woff2"
      crossorigin="anonymous">

Tre dettagli che onestamente vengono sbagliati nove volte su dieci:

• crossorigin="anonymous" è obbligatorio anche se il font è sullo stesso dominio. Senza, il browser scarica il font due volte (una per il preload, una per la CSS). Ci sono caduto pure io, la prima volta che ho integrato un design system custom.
• Preloada UN solo file, quello del peso/stile usato sopra la piega. Preloadare 4 font equivale a non preloadare niente: la banda iniziale è satura.
• Non preloadare font non self-hosted da CDN cross-origin: il crossorigin sui font Google fonts ad esempio richiede attenzione al CORS e spesso la risorsa non viene effettivamente riutilizzata.

Se non sai quale font sta sopra la piega, ispeziona il pannello Coverage di DevTools dopo aver caricato la pagina con la cache vuota: il primo file .woff2 richiesto è quello da preloadare.

Variable fonts: un solo file per tutti gli stili

Un variable font codifica più assi (peso, larghezza, inclinazione, ottico) in un singolo file. Invece di 8 file (Regular, Italic, Medium, MediumItalic, Bold, BoldItalic, Black, BlackItalic) servi un solo file di 80-180 KB che copre l'intera gamma. La specifica completa è nelle CSS Fonts Module Level 4 (W3C).

/* Un solo @font-face, tutti i pesi disponibili */
@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-var.woff2") format("woff2-variations");
  font-weight: 100 900;        /* range, non valore singolo */
  font-style: normal;
  font-display: swap;
}

body  { font-family: "Inter", sans-serif; font-weight: 400; }
h1    { font-weight: 750; }    /* qualsiasi valore intermedio */
strong{ font-weight: 620; }    /* "semibold" personalizzato */

Numeri tipici che ho visto sui progetti più recenti:

• 4 file statici (Regular, Italic, Bold, BoldItalic), latin subset: ~120 KB totali.
• 1 variable font (peso 100-900), latin subset: ~52 KB totali.
• Richieste HTTP risparmiate: 3 (da 4 a 1), a beneficio del TTFB percepito.

Subsetting e unicode-range: tagliare il peso del 70-90%

Un font completo include centinaia di glifi che probabilmente non userai mai: cirillico, greco, vietnamita, simboli matematici. Il subsetting taglia il file lasciando solo i glifi che servono. Combinato con unicode-range, il browser scarica solo i blocchi davvero presenti nella pagina.

Generare i subset con fonttools

# Installa fonttools (Python)
pip install fonttools brotli

# Subset latin base (basta per italiano + inglese)
pyftsubset Inter-Variable.ttf \
  --output-file=inter-var-latin.woff2 \
  --flavor=woff2 \
  --unicodes="U+0000-00FF,U+0131,U+0152-0153,U+02BB-02BC,U+02C6,U+02DA,U+02DC,U+2000-206F,U+2074,U+20AC,U+2122,U+2191,U+2193,U+2212,U+2215,U+FEFF,U+FFFD" \
  --layout-features="kern,liga,calt" \
  --no-hinting

# Subset latin-ext (caratteri accentati estesi: č, ř, ş, ț…)
pyftsubset Inter-Variable.ttf \
  --output-file=inter-var-latin-ext.woff2 \
  --flavor=woff2 \
  --unicodes="U+0100-024F,U+0259,U+1E00-1EFF,U+2020,U+20A0-20AB,U+20AD-20CF,U+2113,U+2C60-2C7F,U+A720-A7FF"

Dichiarare i subset in CSS

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-var-latin.woff2") format("woff2-variations");
  font-weight: 100 900;
  font-display: swap;
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC,
                 U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074,
                 U+20AC, U+2122, U+2212, U+2215;
}
@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-var-latin-ext.woff2") format("woff2-variations");
  font-weight: 100 900;
  font-display: swap;
  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020,
                 U+20A0-20AB, U+2113, U+2C60-2C7F, U+A720-A7FF;
}

Il browser scaricherà latin-ext solo se la pagina contiene davvero un carattere in quei range (es. una citazione in polacco). Per il 95% delle pagine italiane si scarica solo il subset latin: ~28 KB invece di 180 KB.

Eliminare il CLS con size-adjust e ascent-override

Le metriche di un font (altezza maiuscole, discendenti, x-height) raramente coincidono col fallback di sistema. Quando il font web sostituisce Arial al volo, il testo si ridimensiona e tutto sotto si sposta. La soluzione moderna è creare un font di fallback "regolato" che combaci col font finale.

/* Fallback regolato sulle metriche di Inter */
@font-face {
  font-family: "Inter Fallback";
  src: local("Arial");
  size-adjust: 107.4%;          /* scala l'em-box per allineare la x-height */
  ascent-override: 90%;          /* allinea la linea di base superiore */
  descent-override: 22.43%;
  line-gap-override: 0%;
}

body {
  font-family: "Inter", "Inter Fallback", sans-serif;
}

I valori non vanno indovinati. Strumenti come fontaine (npm) o il calcolatore npx capsize li derivano dai metadati del font in pochi secondi. Risultato: durante il FOUT il fallback occupa esattamente lo stesso spazio del font finale, il CLS scende a 0,00 e la transizione diventa invisibile a occhio. Sul mio ultimo progetto editoriale è bastato questo per portare la pagina dal CLS 0,12 a 0,00 senza toccare altro.

Self-hosting vs Google Fonts nel 2026

Fino al 2019 Google Fonts aveva il vantaggio della cache condivisa cross-site. Dal 2020 i browser hanno introdotto la cache partizionata: ogni dominio cache separatamente, anche se l'URL è identico. Il vantaggio è sparito.

Nel 2026 il self-hosting batte la CDN esterna su quasi ogni metrica:

• Niente DNS lookup / handshake TLS aggiuntivo verso fonts.googleapis.com e fonts.gstatic.com (risparmio 150-300 ms in 4G).
• Niente blocco render per il fetch CSS di Google Fonts.
• Conformità GDPR: una sentenza tedesca del 2022 ha già dichiarato illegittimo Google Fonts in hotlinking senza consenso; servirli dal proprio dominio elimina il problema alla radice.
• Controllo del subsetting: con Google ti tocca il subset che decide loro; self-hostato definisci tu i blocchi unicode.

Per generare i file pronti si possono usare strumenti come Google Webfonts Helper, che produce WOFF2 con i CSS già impostati, oppure scaricare direttamente da Google Fonts i TTF e fare il subsetting manuale con pyftsubset.

Errori comuni da evitare

Una sintesi dei pattern sbagliati che vedo ricorrere nei progetti italiani:

1. Servire TTF e WOFF in fallback: nel 2026 è solo CSS più pesante, nessun utente trae beneficio.
2. Preloadare 3-4 file di font: satura la banda iniziale e ritarda LCP/CSS critico.
3. Dimenticare crossorigin="anonymous" sul preload: download duplicato silenzioso.
4. Usare font-display: block "per evitare il FOUT": penalizza LCP di centinaia di ms e fallisce l'audit Lighthouse.
5. Importare Google Fonts via @import in CSS: catena di dipendenze (HTML → CSS → CSS Google → font), il peggio possibile.
6. Caricare l'intero font Cyrillic+Greek+Vietnamese per un sito italiano: 200 KB sprecati per glifi mai renderizzati.
7. Non usare size-adjust: il CLS rimane positivo e la metrica fallisce nei test Core Web Vitals reali sul campo.

Domande frequenti

Qual è il miglior valore di font-display nel 2026?

Per il body text usa swap combinato con size-adjust sul fallback per evitare il CLS. Per font decorativi o display dove un FOUT tardivo è inaccettabile, usa optional: zero shift, e dalla seconda visita il font è in cache e viene applicato istantaneamente.

Devo ancora servire file WOFF oltre al WOFF2?

No. WOFF2 ha il 98%+ di supporto nel 2026 secondo caniuse, e i browser che non lo supportano sono versioni mobili obsolete con una quota di traffico trascurabile per la stragrande maggioranza dei siti italiani. Servire WOFF in fallback aggiunge solo regole CSS e bytes scaricati a vuoto.

I variable fonts sono davvero più veloci dei font statici?

Sì, quando usi 3 o più pesi. Un variable font copre l'intero range con un singolo file che pesa di solito 50-80 KB in più di un singolo peso statico, ma sostituisce 3-8 file. Se ti serve solo Regular + Bold puoi anche restare sugli statici, sotto i 60 KB totali.

Perché i font web causano layout shift anche con font-display swap?

Perché il font di fallback (Arial, Times) ha metriche diverse (x-height, altezza riga, larghezza media glifo) dal font web finale. Quando avviene lo swap, il testo si ridimensiona e gli elementi sotto si spostano. La soluzione è dichiarare un fallback regolato con size-adjust, ascent-override e descent-override calibrati sulle metriche del font web.

È meglio self-hostare i font o usare Google Fonts via CDN?

Self-hostare. Dal 2020 i browser usano la cache partizionata, quindi il riuso cross-site non esiste più. Self-hostando elimini DNS lookup verso fonts.googleapis.com, riduci la catena di richieste, mantieni il controllo sul subsetting e ti metti al riparo dai problemi GDPR di trasmissione IP a Google.

Come si fa il subsetting di un font?

Usa pyftsubset dal pacchetto Python fonttools: passi il TTF di origine, gli unicode-range che vuoi mantenere e produci un WOFF2 più piccolo. Per i siti italiani il subset "latin" copre tutto il fabbisogno standard; aggiungi "latin-ext" come secondo @font-face con unicode-range per parole straniere occasionali.