Caricamento responsive dei web font: una strategia basata sul dispositivo

Responsive font display & strategia di preload responsiva

Come specialista dei Core Web Vitals vedo ogni giorno diverse soluzioni creative. La maggior parte non ha molto senso. Ogni tanto però mi imbatto in una strategia così semplice ed elegante da avere senso per alcuni siti.

Secondo il Web Almanac 2025, l'88% dei siti web usa web font, caricando una mediana di 4 file di font per pagina. Eppure solo il 12% dei siti esegue il preload dei font e solo lo 0,5% usa font-display: optional. La maggior parte dei siti tratta il caricamento dei font come un problema con una soluzione unica per tutti. Questo articolo spiega un approccio più intelligente: caricare i font in modo diverso per desktop e mobile.

La strategia combina il preloading responsivo con font-display: optional su desktop (eliminando il Flash Of Unstyled Text) e font-display: swap su mobile (dando priorità al rendering veloce del testo rispetto alla coerenza visiva).

Ultima revisione di Arjen Karel a marzo 2026

tip: questa strategia funziona bene per i siti con un critical rendering path più ampio, ovvero i siti che caricano più font, fogli di stile e script prima dell'elemento LCP. Se il tuo sito carica un singolo font leggero, la complessità aggiuntiva non ne vale la pena.

Il problema con il caricamento anticipato dei font

Quando ottimizzi i Core Web Vitals c'è una semplice regola che si applica sempre:
"Tutto ciò che fai prima del Largest Contentful Paint rallenterà quel Largest Contentful Paint".

Questo principio si applica anche ai web font. Dare priorità al caricamento dei web font durante il caricamento della pagina può migliorare la UX. Ma se il tuo sito fa fatica a rispettare le soglie dei Core Web Vitals, specialmente per alcuni tipi di dispositivi, potresti dover bilanciare la UX con il miglioramento del LCP.

Il capitolo Performance del Web Almanac 2025 mostra che il testo è l'elemento LCP in quasi il 24% delle pagine mobile. Quando il testo è l'elemento LCP, la strategia di caricamento dei font influisce direttamente sul tuo punteggio LCP. Nel restante 76% delle pagine in cui un'immagine è l'elemento LCP, i font competono comunque per la larghezza di banda di rete iniziale e possono ritardare il caricamento dell'immagine.

Consideriamo l'esempio di seguito di un sito di notizie olandese. Su un dispositivo mobile 3 font vengono messi in coda prima dell'elemento LCP. Questo fa sì che i 3 font competano per le risorse di rete iniziali e ritardino il caricamento dell'immagine.

Capire font-display: optional vs swap

Prima di immergerti nella strategia responsiva, devi capire i due valori di font-display su cui si basa. Per una panoramica più ampia su font-display, vedi come assicurarti che il testo rimanga visibile durante il caricamento dei webfont.

font-display: swap mostra immediatamente il font di fallback e lo sostituisce con il font personalizzato una volta caricato. Questo è ottimo per il LCP perché il testo è visibile fin dall'inizio. Lo svantaggio: quando il font personalizzato arriva e sostituisce il fallback, le diverse metriche del font possono causare un layout shift visibile, danneggiando il tuo punteggio CLS. Circa il 50% dei siti usa swap, rendendolo di gran lunga il valore più popolare.

font-display: optional dà al browser circa 100 ms per caricare il font. Se il font arriva in tempo (tipicamente dalla cache o da un preload veloce), viene usato. Altrimenti, il font di fallback viene usato per l'intero caricamento della pagina e non avviene alcuno swap. Questo significa zero layout shift, ma il font personalizzato potrebbe non essere mostrato alla prima visita. Solo lo 0,5% dei siti usa optional, nonostante sia l'opzione più sicura per il CLS.

A partire da Chrome 83, combinare font-display: optional con <link rel="preload"> blocca il first paint fino a ~100 ms (con un massimo assoluto di 1500 ms), in attesa dell'arrivo del font. Se il font è precaricato, arriva quasi sempre all'interno di quella finestra. Il risultato: testo stilizzato al first paint, zero FOUT, zero layout shift. Questo è il motivo per cui il lato desktop della strategia responsiva funziona così bene.

Strategia responsiva dei font in soccorso!

In casi come questo, dove c'è molta competizione di rete iniziale, ha senso distinguere tra i tipi di dispositivi. Solitamente i dispositivi desktop più veloci su connessioni cablate (e connessioni di rete più veloci) possono gestire più risorse di rete iniziali tutte in una volta. Ha perfettamente senso fare il preload di alcuni file di font critici.

I dispositivi mobile, d'altra parte, potrebbero essere usati nel tragitto casa-lavoro in condizioni di rete tutt'altro che ottimali. I dispositivi mobile hanno anche spesso CPU più lente e meno memoria disponibile rispetto ai desktop. Queste limitazioni implicano che trattare il caricamento dei font in modo diverso in base al tipo di dispositivo può avere senso.

• Desktop: Il preloading dei font migliora le performance di rendering su dispositivi con maggiore larghezza di banda e potenza di calcolo. Usa font-display: optional per eliminare i problemi di swapping dei font. Combinato con un preload, Chrome bloccherà brevemente il rendering (fino a ~100 ms) in attesa del font, dandoti testo stilizzato al first paint con zero CLS.
• Mobile: Non fare il preload del font a causa della competizione di rete. Usa font-display: swap per un rendering del testo più veloce. Questo approccio mostra immediatamente i font di fallback mentre il font personalizzato continua a caricarsi in background, offrendo un'esperienza migliore sui dispositivi meno potenti.

Implementazione usando <link rel="preload"> e media query

Invece di caricare il font in modo universale, puoi usare l'attributo media nel tag <link> dell'HTML insieme al CSS per applicare diverse strategie per i font in base ai tipi di dispositivo.

Implementazione completa

<head>
  <!-- il meta tag viewport DEVE precedere i preload condizionati dai media -->
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <!-- Preload del font solo per desktop -->
  <link rel="preload" href="/fonts/custom-font.woff2"
        as="font" type="font/woff2" crossorigin
        media="(min-width: 768px)">

  <style>
    /* Mobile: swap garantisce un rendering veloce del testo */
    @font-face {
        font-family: 'CustomFont';
        src: url('/fonts/custom-font.woff2') format('woff2');
        font-display: swap;
    }

    /* Desktop: optional + preload = testo stilizzato al first paint */
    @media (min-width: 768px) {
        @font-face {
            font-family: 'CustomFont';
            src: url('/fonts/custom-font.woff2') format('woff2');
            font-display: optional;
        }
    }

    body {
        font-family: 'CustomFont', sans-serif;
    }
  </style>
</head>

Alcuni dettagli importanti su questa implementazione:

1. Ordine del meta tag viewport: Il tag <meta name="viewport"> deve apparire prima del link di preload. Il preload scanner del browser valuta l'attributo media prima di analizzare gli altri meta tag. Se la viewport non è impostata, la media query verrà valutata in base alle dimensioni sbagliate sui dispositivi mobile.
2. Dichiarazioni @font-face complete: Ogni blocco @font-face deve includere sia font-family che src. A differenza delle normali proprietà CSS, i descrittori @font-face non vanno a cascata. Non puoi sovrascrivere solo font-display in un secondo blocco senza dichiarare nuovamente l'intero font face. Il browser scarterà una regola @font-face incompleta.
3. L'attributo crossorigin: I font precaricati senza crossorigin verranno scaricati due volte. Includilo sempre nei preload dei font, anche per i font della stessa origine.
4. Breakpoint corrispondenti: L'attributo media sul preload (768px) deve corrispondere alla media query CSS (768px). Se non corrispondono, farai il preload su un breakpoint e applicherai il font-display sbagliato su un altro.

Ridurre i layout shift su mobile abbinando i font di fallback

La strategia mobile usa font-display: swap, il che significa che ci sarà un breve Flash Of Unstyled Text quando il font personalizzato sostituisce il fallback. Puoi ridurre al minimo questo salto visivo usando i CSS font metric override:

@font-face {
    font-family: 'CustomFont Fallback';
    src: local('Arial');
    ascent-override: 105%;
    descent-override: 25%;
    size-adjust: 97%;
}

body {
    font-family: 'CustomFont', 'CustomFont Fallback', sans-serif;
}

I descrittori ascent-override, descent-override e size-adjust ti permettono di far corrispondere le dimensioni del font di fallback al font personalizzato. Quando avviene lo swap, il testo si muove a malapena. Questi descrittori sono supportati in tutti i browser moderni. Librerie come Capsize possono calcolare automaticamente i giusti valori di override per i tuoi font specifici.

I vantaggi di questo approccio

• UX su desktop: Il desktop esegue il rendering con il web font al first paint, prevenendo sia il FOUT che il FOIT. Zero layout shift derivanti dal caricamento dei font.
• Performance su mobile: font-display: swap assicura che gli utenti vedano immediatamente il testo, anche se il font personalizzato non è ancora caricato. Nessun preload significa che i font non competono con l'immagine LCP per la larghezza di banda.
• Semplicità dichiarativa: Puro HTML e CSS. Nessun JavaScript, nessuna libreria di caricamento dei font, nessuna dipendenza da framework. Questo significa anche che funziona con qualsiasi strategia di prioritizzazione delle risorse che hai già in atto.

Impatto nel mondo reale

Questa strategia si basa su un esempio del mondo reale che ho incontrato facendo l'audit di un sito e-commerce. Il sito caricava 3 font personalizzati: un font per le intestazioni, un font per il corpo e un icon font. Su desktop, tutto si caricava così velocemente che i font raramente causavano problemi. Ma su mobile sotto rete 4G, i tre preload dei font competevano con l'immagine hero e spingevano il LCP ben oltre la soglia dei 2,5 secondi.

Dopo aver implementato la strategia responsiva (preloading solo su desktop, rimuovendo i preload dei font su mobile):

• Desktop: CLS e UX migliorati con font stilizzati che appaiono al first paint. La combinazione preload + font-display: optional ha eliminato tutti i layout shift legati ai font.
• Mobile: First Contentful Paint e Largest Contentful Paint più veloci perché i font non competevano più per la larghezza di banda iniziale. L'immagine hero si è caricata senza contese.

Una ricerca di DebugBear conferma l'impatto: il preloading dei font può migliorare il LCP di circa il 30% (da 1,82s a 1,24s) se applicato correttamente. Ma quando se ne abusa (un sito aveva 38 font in preload), il preloading peggiora le cose. L'approccio responsivo ti dà il vantaggio del preloading su desktop senza il costo su mobile.

Tra i siti monitorati da CoreDash, circa l'82% dei caricamenti di pagina su mobile supera il LCP quando i font sono precaricati strategicamente, rispetto al 70% per le pagine che caricano tutti i font allo stesso modo indipendentemente dal tipo di dispositivo. Su desktop, dove la combinazione preload + optional funziona meglio, il divario è ancora più ampio.

Quando usare questa strategia (e quando no)

Usa questa strategia quando:

• Il tuo sito carica 2 o più file di font personalizzati
• Mobile e desktop hanno profili di performance dei Core Web Vitals diversi (comune nei siti in cui il mobile fa fatica con il LCP mentre il desktop lo supera)
• I font competono con altre risorse critiche (immagini hero, CSS critici) su mobile
• Stai facendo il self-hosting dei tuoi font (questa strategia funziona con qualsiasi hosting di font, ma il self-hosting ti dà pieno controllo sul percorso di preload)

Salta questa strategia quando:

• Carichi solo un font WOFF2 leggero (sotto i 20 KB). L'overhead del caricamento responsivo non ne vale la pena.
• Il tuo sito supera già tutti i Core Web Vitals sia su mobile che su desktop. Non aggiungere complessità a un problema che non hai.
• Ti affidi ai font di sistema. Se stai già usando font-family: system-ui, sans-serif, non c'è nulla da ottimizzare.

Dopo aver implementato questa o qualsiasi strategia di caricamento dei font, monitora l'impatto con il Real User Monitoring per confermare che la modifica abbia effettivamente migliorato i tuoi field data. I test di laboratorio possono non cogliere la variabilità delle condizioni di rete reali che rende questa strategia preziosa in primo luogo.