I web font sono ancora il miglior intervento facile per le prestazioni della maggior parte dei siti

Il pattern che continua a ripresentarsi

Se oggi fai l’audit di dieci siti di produzione scelti a caso, troverai più o meno la stessa situazione dei font nella maggior parte di essi:

• Da sei a dieci file di font caricati nella home page
• Tutti in WOFF2 (bene), ma senza una strategia font-display (male)
• Diversi pesi e stili che non vengono usati da nessuna parte nella pagina
• L’intero stack servito da un dominio di terze parti (di solito Google Fonts), con tutti i costi DNS, TLS e di privacy che ne derivano
• Nessun sottoinsieme tramite unicode-range, quindi ogni visitatore scarica i glifi cirillici e greci anche se la pagina è in inglese

Questo non è un problema esclusivo dei siti piccoli. Molte pagine marketing ben finanziate caricano ancora 600 KB di font prima che il primo paragrafo sia renderizzabile. Una volta che inizi a notare il pattern, non puoi più non vederlo.

La correzione non è esotica. È un piccolo insieme di tecniche ben comprese che sono nei browser da anni.

Usa un solo variable font invece di sei statici

Se stai caricando Inter Regular, Inter Medium, Inter SemiBold, Inter Bold e i rispettivi corsivi, stai scaricando circa sei volte più byte del necessario. Un singolo variable font Inter copre l’intero asse del peso (e l’inclinazione, in alcune build) in un unico file appena più grande di due pesi statici.

La storia del supporto nei browser è chiusa da anni: i variable font funzionano ovunque conti. L’esitazione residua è soprattutto memoria muscolare ereditata dall’era dei font statici.

Una regola pratica: un file di variable font per script, per famiglia. Latino in un file, cirillico in un altro, greco in un terzo, caricati condizionalmente con unicode-range. Tutto qui.

Imposta un font-display sensato

Il comportamento predefinito quando un font personalizzato si sta ancora caricando è non mostrare nulla: testo invisibile, fino a tre secondi. È il peggior default possibile. Gli utenti vedono una pagina vuota e pensano che qualcosa sia rotto.

Aggiungi questo a ogni regola @font-face:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-display: swap;
}

swap mostra subito il font di fallback e sostituisce il font personalizzato quando viene caricato. L’utente può leggere la pagina dal millisecondo zero. Il compromesso è un breve spostamento del layout quando avviene lo swap, che puoi mitigare con la tecnica successiva.

Allinea le metriche del fallback

Un flash di testo non stilizzato risulta fastidioso solo quando il fallback e il font personalizzato hanno metriche molto diverse. Il CSS moderno risolve il problema con size-adjust, ascent-override e proprietà simili:

@font-face {
  font-family: 'Inter Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

Con le metriche del fallback regolate, lo swap è appena percepibile: le parole occupano lo stesso spazio orizzontale prima e dopo l’arrivo del font personalizzato.

Il lavoro di Google su --allow-fallback-font-metrics è ormai supportato di base nei browser, ed esiste una pipeline di strumenti (la libreria fontaine e simili) che calcola i numeri corretti per te in pochi secondi.

Self-host

Google Fonts è comodo, gratuito, e comporta due costi reali:

1. Un secondo handshake TLS. Anche con HTTP/3 e il connection coalescing, un’origine aggiuntiva raramente è gratis.
2. Una questione di privacy e conformità. Diversi tribunali europei hanno stabilito che caricare Google Fonts da fonts.gstatic.com costituisce trasmissione di dati personali (l’indirizzo IP) a una terza parte. Il self-hosting elimina del tutto la questione.

La pipeline di download e hosting è:

1. Ottieni il file WOFF2 (la build variabile, se esiste)
2. Riducilo agli script che il tuo pubblico usa davvero
3. Servilo dalla stessa origine del resto del sito, con un Cache-Control: max-age=31536000, immutable lungo
4. Precarica il peso più critico: <link rel="preload" as="font" type="font/woff2" href="/fonts/inter-var.woff2" crossorigin>

Questa è tutta la pipeline. Per un sito esistente richiede un pomeriggio, e quasi mai si torna indietro.

Quando evitare del tutto i font personalizzati

Vale la pena dirlo chiaramente: non ogni sito ha bisogno di un font personalizzato. Lo stack dei font di sistema è ormai davvero bello su ogni sistema operativo:

font-family: system-ui, -apple-system, 'Segoe UI', Roboto, Inter, sans-serif;

Il peso è corretto, le metriche sono corrette, il rendering è ottimizzato per il dispositivo, e il costo in byte trasmessi è esattamente zero. Per un sito di strumenti, un’app interna, un portfolio che dà priorità ai contenuti, o qualsiasi cosa rivolta a utenti su reti lente, lo stack di sistema è la risposta giusta.

<!-- tool-cta:start -->

💡 Prova questo: Converti i tuoi file TTF o OTF in WOFF2 moderno con CSS pronto all’uso usando Webfont Generator, che è il cambio di formato consigliato dal post.

<!-- tool-cta:end -->

Il riassunto onesto

Per un tipico sito piccolo, quattro passaggi coprono l’intera storia delle prestazioni dei web font:

1. Un variable font per famiglia e per script
2. font-display: swap con metriche di fallback allineate
3. Self-hosted con header di cache lunghi e un preload per il peso critico
4. Oppure evita del tutto i font e usa lo stack di sistema

Fallo una volta e recuperi diverse centinaia di kilobyte dalla home page, guadagni qualche centinaio di millisecondi di prestazioni percepite e rimuovi nel frattempo una dipendenza di terze parti. Poche modifiche hanno un rapporto migliore tra sforzo e risultato.