@font-face e Google Fonts: font custom senza rallentare il sito

Un font personalizzato è un file da scaricare, non un semplice stile. E fino a quando quel file non arriva, il browser deve decidere cosa fare: aspettare a schermo bianco, o mostrare subito qualcosa? Questa scelta ha un nome preciso, ed è tutta nella regola @font-face.

1. font-display: swap, il valore che quasi sempre vuoi

Il descrittore font-display definisce come si comporta il font mentre viene scaricato. MDN descrive due fasi: un blocco (il testo resta invisibile in attesa del font) e uno scambio (il testo appare subito con un font di riserva, sostituito appena il font vero è pronto).

@font-face { 
    font-family: "Inter"; src: url("/fonts/inter.woff2") format("woff2"); 
    font-display: swap; 
}

Con swap, il periodo di blocco è quasi nullo: il testo appare subito con il font di sistema, e passa al font personalizzato non appena disponibile. La guida MDN alle performance web lo raccomanda esplicitamente, proprio per non bloccare il rendering della pagina.

Fonte: MDN Web Docs: «font-display»: definisce blocco e scambio del caricamento font.

2. Subset: scaricare solo i caratteri che usi davvero

Un font completo contiene migliaia di glifi, alfabeti, simboli, lingue che probabilmente non userai nella pagina. Il subsetting è il processo di generare un file più piccolo con solo i caratteri necessari.

Attenzione a un equivoco comune: la proprietà unicode-range da sola non riduce il peso del file. Dice al browser «scarica questo file solo se ti serve questo intervallo di caratteri», ma se il file non è stato fisicamente ridotto, il browser scarica comunque tutto il file intero quando serve anche un solo carattere in quell'intervallo.

@font-face {
    font-family: "Inter";
    src: url("/fonts/inter-latin.woff2") format("woff2");
    unicode-range: U+0000-00FF, U+0131, U+0152-0153; /* solo latino base */
}

Il subsetting vero avviene prima, con uno strumento che genera il file ridotto; unicode-range serve poi solo a dire al browser quale dei file (già ridotti) scaricare.

Fonte: MDN Web Docs: «unicode-range» (CSS at-rule descriptor): specifica l'insieme di codepoint Unicode supportati, usato come indicazione per decidere se scaricare una risorsa font.

3. preload: dare priorità al font critico

Normalmente il browser scopre di aver bisogno di un font solo dopo aver letto e interpretato il CSS, un ritardo che si somma al tempo di download del font stesso. <link rel="preload"> dice al browser di iniziare il download subito, in parallelo, senza aspettare quella scoperta tardiva.

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

L'attributo crossorigin qui non è opzionale: MDN specifica che i font vengono sempre recuperati in modalità CORS anonima, e senza crossorigin il preload viene semplicemente ignorato e il font ri-scaricato da capo.

Usa preload solo per i font davvero critici (di solito uno, il testo principale): precaricare troppi font fa concorrenza di banda alle altre risorse e vanifica il vantaggio.

Fonte: MDN Web Docs: «rel=preload»: font e fetch richiedono l'attributo crossorigin per essere considerati validi dal browser.

4. Self-hosting vs CDN

Google Fonts via CDN è comodo: una riga di <link> e il font è pronto, con aggiornamenti gestiti automaticamente. Il costo tecnico verificabile: il browser deve aprire una connessione separata verso un dominio esterno (fonts.gstatic.com), con la sua risoluzione DNS e handshake, prima ancora di iniziare il download del font.

Il self-hosting: scaricare i file del font e servirli dal tuo stesso dominio con @font-face, elimina quella connessione esterna aggiuntiva, e ti dà controllo diretto su font-display, subsetting e preload. Il costo è occuparci degli aggiornamenti e conversione dei formati.

In sintesi

Nessuna di queste tecniche vale da sola: font-display: swap senza subsetting scarica comunque un file enorme, e il preload senza crossorigin non serve a niente. La velocità dei font nasce dalla somma di piccole scelte corrette, non da una sola.