Come ospitare i font localmente invece di usare Google Fonts

Perché ospitare autonomamente Google Fonts?

Google Fonts ha reso semplice una buona tipografia. Aggiungi un foglio di stile, scegli qualche peso, pubblichi la pagina. Per anni è stata l’impostazione predefinita più sensata per i team piccoli.

Il compromesso è che il browser di ogni visitatore contatta un servizio di terze parti per recuperare il CSS dei font e i file dei font. Questo ha due conseguenze.

Primo, aggiunge una dipendenza esterna al rendering. Se il CSS dei font è lento, bloccato o non disponibile nella regione o nella rete dell’utente, la pagina resta in attesa o passa a un font di fallback.

Secondo, crea una questione di privacy. Una richiesta di font può rivelare a una terza parte l’indirizzo IP dell’utente, lo user agent, il contesto della referrer policy e informazioni temporali. Google Fonts dichiara di non impostare cookie tramite la Fonts API, ma “nessun cookie” non equivale a “nessun dato personale”. Ai sensi del GDPR, un indirizzo IP può comunque essere un dato personale nel contesto appropriato.

Ospitare autonomamente i font non è automaticamente obbligatorio per ogni sito web, e questo non è un parere legale. Ma per siti europei, siti del settore pubblico, sanità, istruzione, finanza o qualsiasi team che voglia ridurre richieste non necessarie a terze parti, l’hosting locale è di solito la scelta più pulita.

Spesso è anche un vantaggio prestazionale, se fatto bene. Il punto è “fatto bene”. Copiare sei file di font in /assets/fonts/ e caricarli tutti su ogni pagina può essere peggio che usare il servizio ospitato. Se vuoi il contesto prestazionale più ampio, il nostro articolo precedente sul perché i web font sono ancora il miglioramento prestazionale più semplice sulla maggior parte dei siti copre i modelli di spreco più comuni.

Cosa cambia quando ospiti i font autonomamente

Quando usi Google Fonts nel modo consueto, la tua pagina fa questo:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">

Il browser richiede prima il CSS da fonts.googleapis.com, poi scarica i file dei font da fonts.gstatic.com.

Quando ospiti i font autonomamente, la pagina dovrebbe richiedere sia il CSS sia i file dei font dal tuo dominio:

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

Questo elimina la richiesta di font a terze parti. Ti rende anche responsabile della scelta dei formati dei file, degli header di cache, dei font di fallback e degli aggiornamenti.

È una responsabilità da prendere sul serio. I font si trovano nel percorso critico di rendering. Una configurazione scadente dei font può causare testo invisibile, spostamenti di layout e un primo rendering lento.

Passaggio 1: verifica cosa usi davvero

Prima di scaricare qualsiasi cosa, elenca famiglie di font, pesi, stili e set di caratteri di cui il tuo sito ha davvero bisogno.

Un tipico sito marketing potrebbe aver bisogno di:

• Regular 400 per il testo del corpo
• Semibold 600 o bold 700 per titoli e pulsanti
• Italic 400 solo se il design usa davvero il corsivo
• Solo set di caratteri Latin, a meno che il sito supporti più lingue

Diffida delle vecchie impostazioni predefinite dei design system. Molti siti caricano 300, 400, 500, 600, 700, corsivi e più script perché qualcuno li ha selezionati una volta in un selettore di font.

Nei DevTools del browser, apri il pannello Network, filtra per “font”, ricarica la pagina e controlla quali file vengono richiesti. Poi ispeziona il CSS per l’uso di font-weight. Se il tuo CSS non usa mai 300, non ospitare 300.

Se in seguito devi valutarne l’impatto, Lighthouse può aiutare, ma non trattare il suo punteggio come l’intera storia. Usalo come strumento diagnostico, non come giudice. Abbiamo una guida separata su come leggere un report Lighthouse senza andare nel panico, utile quando devi assegnare priorità alle correzioni sui font.

Passaggio 2: scarica i file di font corretti

Google Fonts offre font open source. Puoi scaricarli dal sito di Google Fonts o dal repository del progetto del font pertinente. Controlla la licenza, ma la maggior parte dei Google Fonts è distribuita con licenze aperte come la SIL Open Font License o la Apache License.

Per il web, preferisci WOFF2. È ampiamente supportato dai browser moderni e di solito è molto più piccolo di TTF o OTF. Nel 2026, servire TTF direttamente ai browser è raramente giustificato per siti web pubblici.

Una struttura di directory sensata è questa:

/public
  /fonts
    inter-latin-400.woff2
    inter-latin-600.woff2
    inter-latin-700.woff2

Usa nomi di file descrittivi. Tra sei mesi, font.woff2 sarà fastidioso. inter-latin-600.woff2 è noioso e utile.

Se il tuo sito usa un sistema di build, conserva i font sorgente in un punto chiaro e lascia che la pipeline di build copi i file ottimizzati nella directory degli asset pubblici.

Passaggio 3: crea subset dei font quando opportuno

Il subsetting significa rimuovere i caratteri che non ti servono. Un font completo può includere Latin, Cyrillic, Greek, Vietnamese, simboli e molte funzionalità OpenType. Se la tua landing page solo in inglese ha bisogno solo di caratteri Latin, un subset può essere drasticamente più piccolo.

Ci sono due approcci comuni:

1. Usare un subset precompilato dal provider del font o dal repository.
2. Generare un subset personalizzato con uno strumento per font come pyftsubset da fonttools.

Per molti team, i subset Latin precompilati sono sufficienti. Il subsetting personalizzato è utile quando hai pagine molto vincolate, come una singola pagina di campagna con testo limitato, o una UI di prodotto con copertura dei caratteri prevedibile.

Fai attenzione con i siti multilingue. I glifi mancanti causano una mescolanza di font di fallback, che può apparire rotta e danneggiare la leggibilità. Se supporti più lingue, associa i subset dei font alle route linguistiche invece di forzare un unico subset minuscolo ovunque.

Passaggio 4: scrivi le regole @font-face

Una configurazione locale minima è questa:

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

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

body {
  font-family: "Inter", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

Qui contano alcuni dettagli.

Usa font-display: swap per la maggior parte dei siti di contenuto. Dice al browser di mostrare rapidamente il testo di fallback, poi sostituirlo con il web font quando arriva. Questo evita la versione peggiore del FOIT: flash of invisible text.

Imposta uno stack di fallback esplicito. Se il font personalizzato non si carica, gli utenti dovrebbero comunque ottenere testo leggibile. I fallback non sono un ripensamento; fanno parte del design. Se devi rivedere dimensioni, lunghezza delle righe e scelte per il testo del corpo, inizia con una guida pratica alla tipografia leggibile sul web moderno.

Abbina correttamente i pesi. Se il tuo CSS richiede font-weight: 500 ma definisci solo 400 e 700, il browser può sintetizzare un peso intermedio. Non è sempre terribile, ma può apparire incoerente.

Passaggio 5: rimuovi le chiamate esterne a Google Fonts

Dopo aver aggiunto il CSS locale dei font, rimuovi le vecchie chiamate remote dai template.

Cerca:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?..." rel="stylesheet">

Controlla anche:

• Impostazioni del tema nelle piattaforme CMS
• Pannelli tipografici dei page builder
• Widget di terze parti
• Tag manager
• Vecchi import CSS come @import url('https://fonts.googleapis.com/...')

Quest’ultimo è comune. @import CSS per i font di solito è peggiore per le prestazioni perché ne ritarda la scoperta. Se ospiti i font autonomamente, definiscili direttamente nel CSS principale o in un file CSS dei font caricato in anticipo.

Il lavoro sulla privacy spesso fallisce perché i team correggono il template più evidente ma trascurano script, widget ed embed legacy. Lo stesso schema compare nel lavoro sul consenso; la nostra guida a cosa è cambiato per i cookie nel 2026 è un complemento utile se stai riducendo più in generale la superficie esposta a terze parti.

Passaggio 6: imposta gli header di cache

I file dei font sono asset statici. Dovrebbero essere memorizzati in cache in modo aggressivo se i nomi dei file sono versionati o includono un hash del contenuto.

Un buon header di produzione è:

Cache-Control: public, max-age=31536000, immutable

Usa il caching immutabile a lunga durata solo se l’URL cambia quando cambia il file. Per esempio:

inter-latin-400.a8f3c2.woff2

o un percorso versionato:

/fonts/v2/inter-latin-400.woff2

Se sovrascrivi /fonts/inter-latin-400.woff2 senza cambiare l’URL, alcuni utenti potrebbero conservare il vecchio file per molto tempo. Va bene finché non lo è più. Il versioning evita il problema.

Servi inoltre i font con il MIME type corretto:

Content-Type: font/woff2

La maggior parte delle piattaforme di hosting moderne lo gestisce automaticamente, ma vale la pena verificarlo.

Passaggio 7: valuta il preload solo del font critico

Il preload può aiutare il browser a scoprire prima un font importante:

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

Usalo con parsimonia. Precarica il font principale del testo above-the-fold, non ogni peso del font. Un preload eccessivo compete con CSS, immagini e JavaScript.

Anche per i font same-origin, includi crossorigin nei preload dei font. Il fetching dei font usa la modalità CORS, e ometterlo può causare download duplicati in alcune configurazioni.

Se non sei sicuro, testa. Non copiare i preload per abitudine solo perché lo dice una checklist.

Passaggio 8: testa privacy e prestazioni

Il test è semplice.

Apri DevTools, ricarica la pagina con la cache disabilitata e filtra il pannello Network per:

• fonts.googleapis.com
• fonts.gstatic.com
• .woff2
• font

Dovresti vedere file di font serviti dal tuo dominio e nessuna richiesta a Google Fonts.

Poi testa con cache fredda e cache calda. Alla prima visita, i font dovrebbero essere scaricati una sola volta. Nelle visite successive, dovrebbero provenire dalla cache in memoria o su disco, a seconda del browser.

Controlla gli spostamenti di layout quando il font viene sostituito. Se i titoli saltano, le metriche del font di fallback differiscono troppo da quelle del web font. Puoi ridurre lo spostamento visibile scegliendo un fallback più vicino o usando override CSS più recenti delle metriche dei font, come size-adjust, ascent-override, descent-override e line-gap-override. Sono tecniche più avanzate, ma utili per interfacce curate.

Infine, testa le pagine in navigazione privata o con content blocker abilitati. Un vantaggio dell’hosting autonomo è che gli strumenti per la privacy hanno meno probabilità di bloccare accidentalmente la tua tipografia.

Errori comuni da evitare

Ospitare troppi pesi

Questo è l’errore più comune. Due pesi spesso bastano. Tre di solito sono più che sufficienti. Cinque sono un cattivo segnale nel design system, a meno che tu non abbia una ragione forte.

Dimenticare il corsivo

Se i tuoi contenuti usano enfasi reale, carica un vero file italic. Il corsivo sintetico può apparire scadente, soprattutto nei contenuti editoriali lunghi.

Mantenere il vecchio link CSS di Google

Questo vanifica lo scopo. Dopo la migrazione, nessuna richiesta di font dovrebbe andare a Google, a meno che un altro componente non la stia iniettando.

Servire font senza caching a lungo termine

L’hosting autonomo ti dà controllo. Usalo. I font sono candidati ideali per durate di cache lunghe.

Ignorare lavoro legale e documentazione

Se la tua informativa privacy in precedenza menzionava Google Fonts o il caricamento di font da terze parti, aggiornala dopo la migrazione. Se mantieni un inventario dei trattamenti di dati, aggiorna anche quello. La modifica tecnica e il registro di compliance dovrebbero essere allineati.

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

💡 Prova questo: Converti i file TTF che hai scaricato da Google Fonts in WOFF2 self-hostable più CSS con Webfont Generator.

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

Una semplice checklist di migrazione

1. Elenca famiglie di font, pesi, stili e script che usi davvero.
2. Scarica i file WOFF2 e conferma la licenza.
3. Crea subset dei font se il sito ha esigenze linguistiche limitate.
4. Aggiungi regole locali @font-face con font-display: swap.
5. Rimuovi tutti i riferimenti Google Fonts link, preconnect e @import.
6. Servi i font dal tuo dominio con header di cache a lunga durata.
7. Precarica solo il font above-the-fold più importante, se i test lo supportano.
8. Verifica in DevTools che non restino richieste a Google Fonts.
9. Aggiorna la documentazione privacy se necessario.

Ospitare autonomamente i font non è un lavoro affascinante. È quel tipo di piccola pulizia infrastrutturale che riduce il rischio di dipendenze, migliora la postura privacy e ti dà un rendering più prevedibile. Di solito vale l’ora o le due che richiede.