Miglioramento delle performance Web tramite ottimizzazione dei Font

Quando si parla di performance web, l’attenzione si concentra quasi sempre su immagini, cache, CDN, compressione HTML, CSS, JavaScript, ottimizzazione del database e tempi di risposta del server. Tutti aspetti fondamentali, ovviamente, soprattutto in contesti CMS come WordPress, WooCommerce, Joomla, Drupal, Magento o PrestaShop. Tuttavia, c’è un elemento che viene spesso ignorato o trattato superficialmente: i font web.

Un font apparentemente innocuo può pesare decine o centinaia di kilobyte. Se una pagina carica più varianti dello stesso carattere, ad esempio Regular, Bold, ExtraBold, Thin, Italic e relative combinazioni, il peso complessivo può diventare rilevante. Il problema diventa ancora più evidente su siti WordPress e WooCommerce costruiti con page builder, temi commerciali e plugin di personalizzazione tipografica, dove è molto facile caricare più font del necessario senza rendersene conto.

Ottimizzare i font non significa semplicemente “usare un carattere più leggero”. Significa scegliere il formato corretto, eliminare i formati obsoleti quando non servono, convertire i file nel formato più efficiente, ridurre l’insieme dei glifi caricati e configurare correttamente il CSS affinché il browser possa scaricare solo ciò che serve, quando serve.

Perché i font incidono sulle performance web

I font sono risorse bloccanti o semi-bloccanti per la resa visiva della pagina. Il browser deve scaricarli, interpretarli e applicarli agli elementi HTML. Se il font non è disponibile immediatamente, il browser può comportarsi in modi diversi: può mostrare temporaneamente un font di fallback, può nascondere il testo per un breve periodo, oppure può causare uno scambio visivo quando il font personalizzato viene finalmente caricato.

Questi comportamenti hanno un impatto diretto sull’esperienza utente e, indirettamente, anche sui segnali misurati da strumenti come PageSpeed Insights, Lighthouse, WebPageTest e sui Google Core Web Vitals. Un font troppo pesante può ritardare la visualizzazione del testo, aumentare il traffico di rete e peggiorare la percezione complessiva della velocità del sito.

Il problema è particolarmente frequente nei siti WordPress e WooCommerce, dove l’uso di temi grafici avanzati, page builder e plugin per la gestione dei font può portare a caricare file multipli senza una reale necessità. Ad esempio, un sito potrebbe usare visivamente solo un peso 400 e un peso 700, ma caricare anche 300, 500, 600, 800, italic e altre varianti non utilizzate. Ogni file aggiuntivo rappresenta una richiesta HTTP e un peso trasferito al client.

TTF, WOFF e WOFF2: differenze pratiche

Per comprendere come ottimizzare i font, bisogna prima distinguere i formati più comuni: TTF, WOFF e WOFF2.

Il formato TTF, acronimo di TrueType Font, è un formato storico, molto diffuso sui sistemi operativi e negli ambienti desktop. È adatto all’installazione locale su computer, software grafici e sistemi operativi, ma non è il formato ideale da servire direttamente sul web. Un file TTF contiene le informazioni del font in modo completo, ma non nasce specificamente per essere trasferito in modo efficiente via HTTP.

Il formato WOFF, Web Open Font Format, è stato introdotto proprio per l’uso web. È sostanzialmente un contenitore compresso per font TrueType o OpenType, pensato per ridurre il peso rispetto al file sorgente e per essere gestito meglio dai browser. Rispetto al TTF, un file WOFF è normalmente più piccolo e più adatto alla distribuzione online.

Il formato WOFF2 è l’evoluzione di WOFF. Utilizza una compressione più moderna ed efficiente basata su Brotli e rappresenta oggi il formato consigliato per i font web. In molti casi, passando da TTF o OTF a WOFF2 si può ottenere un risparmio compreso indicativamente tra il 30% e il 50%. Passando da WOFF a WOFF2, il risparmio è spesso più contenuto ma comunque significativo, in genere nell’ordine del 15-30%, prima ancora di applicare tecniche più spinte come il subsetting.

Il problema dei plugin font nei CMS

Nei CMS moderni è molto comune caricare font personalizzati attraverso plugin. In WordPress, ad esempio, plugin come “Custom Fonts” permettono di caricare file WOFF, WOFF2, TTF o OTF e di registrarli all’interno del tema o del builder. Questa comodità, però, può nascondere alcuni problemi.

Il primo problema è che il nome visibile nel CSS non sempre coincide con il nome del file fisico. Se nel browser vediamo una regola come questa:

element.style {
    font-family: "Managed Server Extra Bold";
    font-size: 1.3rem;
    font-style: normal;
    font-weight: 400;
}

il valore font-family: "Managed Server Extra Bold" rappresenta il nome della famiglia tipografica registrata nel CSS, non necessariamente il nome del file caricato sul server. Il file reale potrebbe chiamarsi in modo completamente diverso, ad esempio Gordita-Black.woff, managed-server-extra-bold.woff2 o essere stato rinominato automaticamente dal plugin.

Per individuare il file effettivamente servito al browser è consigliabile usare gli strumenti di sviluppo del browser, aprendo il pannello Network e filtrando le richieste di tipo font. In alternativa, lato server, è possibile cercare i file caricati nella directory del sito.

find . -path "*/wp-content/*" -type f ( -iname "*.woff" -o -iname "*.woff2" -o -iname "*.ttf" -o -iname "*.otf" )

Un’altra possibilità è cercare nel codice o nel database il nome della famiglia font visualizzata nel CSS:

grep -Rni "Managed Server Extra Bold" wp-content/

Oppure, se si dispone di WP-CLI:

wp db search "Managed Server Extra Bold"

Questo approccio è utile perché molti plugin generano dinamicamente le regole @font-face o le salvano come opzioni nel database.

Conversione dei font in WOFF2

Una prima ottimizzazione consiste nel convertire i font disponibili in formato WOFF, TTF o OTF verso WOFF2. Su Linux si possono utilizzare strumenti come FontTools, Brotli e, in alcuni casi, i tool della suite WOFF2.

È importante chiarire un aspetto pratico: il comando woff2_compress non è sempre adatto a convertire direttamente un file WOFF in WOFF2. In molti scenari funziona correttamente partendo da file TTF o OTF, ma può fallire con un WOFF già compresso, restituendo errori di parsing. Per questo motivo, una soluzione più affidabile è usare direttamente FontTools, che consente di leggere un WOFF e salvarlo come WOFF2.

Installazione su Debian, Ubuntu o ambienti WSL:

apt update
apt install python3-fonttools python3-brotli

In alternativa, tramite pip:

pip3 install fonttools brotli

Conversione diretta di un singolo file WOFF in WOFF2 con Python e FontTools:

from fontTools.ttLib import TTFont

src = "Gordita-Black.woff"
dst = "Gordita-Black.woff2"

font = TTFont(src)
font.flavor = "woff2"
font.save(dst)

print(f"{src} -> {dst}")

Per convertire tutti i file .woff presenti nella directory corrente:

from fontTools.ttLib import TTFont
from pathlib import Path

for src in Path(".").glob("*.woff"):
    dst = src.with_suffix(".woff2")
    try:
        font = TTFont(str(src))
        font.flavor = "woff2"
        font.save(str(dst))
        print(f"OK: {src} -> {dst}")
    except Exception as e:
        print(f"ERRORE: {src}: {e}")

Dopo la conversione è sempre buona norma verificare dimensioni e formato dei file:

ls -lh *.woff *.woff2
file *.woff2

Il vero salto di qualità: il subsetting

La conversione in WOFF2 è utile in quanto ci consente un’ottimizzazione accademica tra il 25 ed il 30% del peso, ma spesso non è l’ottimizzazione più potente. Il vero salto di qualità si ottiene con il subsetting, cioè la creazione di un file font contenente solo i glifi realmente necessari.

Un font commerciale o professionale può contenere centinaia o migliaia di glifi: lettere latine, accenti, simboli matematici, caratteri greci, cirillici, legature, frecce, icone, valute, segni tipografici avanzati e molto altro. Se il sito è in italiano e utilizza il font solo per titoli, pulsanti e testi latini, non ha senso trasferire al browser l’intero set di caratteri.

Per un sito italiano o europeo, un subset ragionevole può includere il blocco ASCII di base e il supplemento latino necessario per le lettere accentate. Un intervallo molto usato è:

• U+0020-007E: caratteri ASCII stampabili, quindi lettere base, numeri e punteggiatura;
• U+00A0-00FF: Latin-1 Supplement, che include molte lettere accentate usate nelle lingue europee.

Con FontTools è possibile generare un WOFF2 subsettato usando pyftsubset:

pyftsubset Gordita-Black.woff 
  --output-file=Gordita-Black-subset.woff2 
  --flavor=woff2 
  --layout-features='*' 
  --unicodes="U+0020-007E,U+00A0-00FF" 
  --with-zopfli

Lo stesso approccio può essere applicato a tutte le varianti del font effettivamente utilizzate:

pyftsubset Gordita-Bold.woff 
  --output-file=Gordita-Bold-subset.woff2 
  --flavor=woff2 
  --layout-features='*' 
  --unicodes="U+0020-007E,U+00A0-00FF" 
  --with-zopfli

pyftsubset Gordita-Thin-1.woff 
  --output-file=Gordita-Thin-1-subset.woff2 
  --flavor=woff2 
  --layout-features='*' 
  --unicodes="U+0020-007E,U+00A0-00FF" 
  --with-zopfli

L’opzione --with-zopfli può essere utile quando si genera WOFF, mentre nel caso di WOFF2 il vantaggio reale può essere limitato o dipendere dalla pipeline di FontTools e dalle librerie installate. In ogni caso, il punto centrale non è “comprimere di più” un WOFF2 già compresso con Brotli, ma ridurre il numero di glifi e tabelle incluse nel file finale.

Esempio reale: ottimizzazione del font Gordita

Prendiamo un caso reale di ottimizzazione su tre varianti del font Gordita: Black, Bold e Thin. I file iniziali erano in formato WOFF. Sono stati prima convertiti in WOFF2 e poi sottoposti a subsetting mantenendo i caratteri ASCII e Latin-1 Supplement, sufficienti per un uso tipico in lingua italiana ed europea.

La directory di lavoro mostrava questa situazione dopo la conversione e il subsetting:

Gordita-Black.woff              86K
Gordita-Black.woff2             66K
Gordita-Black-subset.woff2      24K

Gordita-Bold.woff               84K
Gordita-Bold.woff2              64K
Gordita-Bold-subset.woff2       23K

Gordita-Thin-1.woff             81K
Gordita-Thin-1.woff2            62K
Gordita-Thin-1-subset.woff2     22K

Rappresentiamo questi dati in forma tabellare:

Il risultato è estremamente interessante. La semplice conversione da WOFF a WOFF2 produce già un risparmio di circa il 23-24%. È un miglioramento importante, ottenuto senza alterare il set di caratteri disponibile. Tuttavia, il subsetting porta il risparmio complessivo a oltre il 72% rispetto ai file WOFF originali.

Considerando le tre varianti insieme, il peso complessivo passa da:

• 251 KB in formato WOFF originale;
• 192 KB in formato WOFF2 convertito;
• 69 KB in formato WOFF2 subsettato.

In pratica, rispetto ai WOFF originali, si risparmiano circa 182 KB. Rispetto ai WOFF2 non subsettati, si risparmiano comunque circa 123 KB. Su una singola visita può sembrare una cifra non enorme, ma su traffico mobile, connessioni lente, pagine con molte risorse e migliaia di visite giornaliere, l’impatto diventa concreto.

Perché il subsetting è più efficace della semplice compressione

Quando un file è già in WOFF2, cercare una “compressione ancora più forte” ha margini limitati. WOFF2 utilizza già Brotli, una compressione molto efficiente. Il modo più efficace per ridurre ulteriormente il peso non è comprimere meglio gli stessi dati, ma rimuovere i dati non necessari.

Un font completo può contenere caratteri che il sito non userà mai. Se un sito è in italiano, potrebbe non avere bisogno di glifi cirillici, greci, simboli fonetici, operatori matematici avanzati o alfabeti estesi. Se il font viene usato solo nei titoli, potrebbe non essere necessario includere ogni simbolo tipografico disponibile. Se viene usato solo per un logo testuale o per poche call to action, si può addirittura generare un subset basato sui caratteri effettivamente presenti in quelle frasi.

FontTools permette anche di creare subset partendo da un file di testo contenente i caratteri realmente usati:

pyftsubset Gordita-Black.woff 
  --output-file=Gordita-Black-used.woff2 
  --flavor=woff2 
  --layout-features='*' 
  --text-file=caratteri-usati.txt

Questa tecnica è molto aggressiva e va usata con cautela. È perfetta per elementi molto controllati, come loghi testuali, hero title statici, bottoni o headline specifiche. È invece rischiosa per testi dinamici, contenuti generati dagli utenti, cataloghi WooCommerce, blog multilingua o aree dove il contenuto cambia frequentemente.

Come integrare i font ottimizzati nel CSS

Dopo aver generato i file WOFF2 ottimizzati, bisogna integrarli correttamente nel sito. L’uso di @font-face permette di dichiarare il font e indicare al browser il file da scaricare.

@font-face {
  font-family: 'Gordita';
  src: url('/wp-content/uploads/fonts/Gordita-Black-subset.woff2') format('woff2');
  font-weight: 900;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'Gordita';
  src: url('/wp-content/uploads/fonts/Gordita-Bold-subset.woff2') format('woff2');
  font-weight: 700;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: 'Gordita';
  src: url('/wp-content/uploads/fonts/Gordita-Thin-1-subset.woff2') format('woff2');
  font-weight: 100;
  font-style: normal;
  font-display: swap;
}

La proprietà font-display: swap è particolarmente importante. Indica al browser di mostrare subito un font di fallback e sostituirlo con il font personalizzato appena disponibile. In questo modo si riduce il rischio che il testo rimanga invisibile durante il caricamento del font.

È altrettanto importante associare correttamente il peso del font. Se un file si chiama “Black” o “ExtraBold”, è probabile che debba essere dichiarato con un peso 800 o 900, non con 400. Un’incongruenza tra file reale e font-weight può causare comportamenti indesiderati, rendering non coerente e caricamento di varianti sbagliate.

Ottimizzazione in WordPress e WooCommerce

In WordPress l’ottimizzazione dei font può essere gestita in diversi modi. Alcuni temi permettono di caricare font personalizzati dal pannello di configurazione. Alcuni page builder hanno una sezione dedicata ai custom font. Plugin come “Custom Fonts” consentono di caricare famiglie tipografiche personalizzate e associarle ai vari pesi.

La raccomandazione è semplice: caricare solo i formati e i pesi realmente necessari. Se il sito usa solo WOFF2, non ha senso caricare anche TTF, OTF e WOFF, salvo necessità specifiche di compatibilità con browser molto vecchi. Se il design usa solo Regular e Bold, non ha senso registrare sei o sette varianti.

In WooCommerce il discorso è ancora più importante, perché le pagine prodotto, categoria, carrello e checkout devono essere il più possibile rapide e stabili. Un font pesante può sembrare un dettaglio estetico, ma su mobile può contribuire a rallentare la visualizzazione del contenuto, soprattutto quando viene caricato insieme a immagini prodotto, script di tracciamento, CSS del tema, plugin di pagamento, widget marketing e componenti dinamici.

Il principio, comunque, è valido a prescindere dal CMS. Che si tratti di WordPress, WooCommerce, Magento, PrestaShop, Drupal, Joomla o di un’applicazione custom sviluppata in Laravel, Symfony, Next.js o altro stack, il browser dovrà comunque scaricare i font. Meno byte inutili vengono trasferiti, migliore sarà il comportamento della pagina.

Preload dei font critici

In alcuni casi può essere utile usare il preload per i font realmente critici, cioè quelli necessari alla porzione above the fold della pagina. Il preload deve essere usato con attenzione: precaricare troppi font può peggiorare le performance invece di migliorarle, perché sottrae priorità ad altre risorse importanti.

Esempio di preload per un font WOFF2:

<link rel="preload"
      href="/wp-content/uploads/fonts/Gordita-Bold-subset.woff2"
      as="font"
      type="font/woff2"
      crossorigin>

Il preload ha senso per uno o due font davvero essenziali, ad esempio il font usato nel titolo principale della home page o nella hero section. Non va usato indiscriminatamente per tutte le varianti della famiglia tipografica.

Attenzione a cache, CDN e MIME type

Una volta ottimizzati i file, bisogna assicurarsi che vengano serviti correttamente dal server. I font dovrebbero avere header di cache lunghi, soprattutto se il nome del file contiene una versione o se viene modificato solo in fase di deploy. Un file WOFF2 può essere tranquillamente cacheato dal browser e da una CDN per periodi lunghi.

È utile verificare anche il MIME type. Per WOFF2, il tipo corretto è:

font/woff2

Per WOFF:

font/woff

Configurazioni errate possono generare warning nel browser o comportamenti non ottimali. Su Nginx, ad esempio, è possibile assicurarsi che i MIME type siano presenti nella configurazione globale o nel file mime.types.

Checklist pratica per ottimizzare i font

Una buona procedura operativa per ottimizzare i font web può essere la seguente:

• individuare tutti i file font caricati dal sito tramite DevTools o ricerca lato server;
• verificare quali varianti sono realmente usate nel CSS;
• eliminare pesi, stili e formati non necessari;
• convertire i file in WOFF2 quando possibile;
• applicare subsetting per includere solo i caratteri necessari;
• configurare correttamente @font-face con font-display: swap;
• usare il preload solo per i font critici above the fold;
• impostare cache HTTP adeguata;
• testare il risultato con PageSpeed Insights, Lighthouse e waterfall di rete.

Per cercare tutti i font in una directory WordPress si può usare:

find . -type f ( -iname "*.woff" -o -iname "*.woff2" -o -iname "*.ttf" -o -iname "*.otf" )

Per generare subset WOFF2 in blocco da tutti i file WOFF della directory corrente:

for f in *.woff; do
  base="${f%.woff}"
  pyftsubset "$f" 
    --output-file="${base}-subset.woff2" 
    --flavor=woff2 
    --layout-features='*' 
    --unicodes="U+0020-007E,U+00A0-00FF"
done

Conclusione

L’ottimizzazione dei font è uno degli interventi più sottovalutati nelle performance web. A differenza di altre attività più complesse, come tuning del database, ottimizzazione del backend o interventi architetturali, la riduzione del peso dei font è spesso relativamente semplice, misurabile e immediata.

L’esempio reale visto con i file Gordita dimostra chiaramente il potenziale dell’intervento. La sola conversione da WOFF a WOFF2 ha ridotto il peso complessivo da 251 KB a 192 KB. Il subsetting ha portato il totale a soli 69 KB, con un risparmio complessivo superiore al 70% rispetto ai file originali.

Questo tipo di ottimizzazione è particolarmente utile su siti WordPress e WooCommerce, dove temi, builder e plugin possono introdurre molte risorse tipografiche non sempre necessarie. Tuttavia, il principio è universale: ogni CMS, framework o applicazione web trae beneficio dal servire meno byte, meno varianti e formati più efficienti.

In un web sempre più orientato alla velocità percepita, alla qualità dell’esperienza utente e ai Core Web Vitals, i font non possono più essere considerati un dettaglio estetico secondario. Devono essere trattati come vere e proprie risorse critiche, da analizzare, comprimere, subsettare, cacheare e servire nel modo più efficiente possibile.

Ottimizzare i font significa migliorare il caricamento, ridurre il traffico, rendere più stabile il rendering e offrire un’esperienza migliore agli utenti. E, come dimostrano i numeri, spesso bastano pochi comandi Linux e una corretta configurazione CSS per ottenere risultati molto concreti.