Caricamento web font responsive: una strategia consapevole del dispositivo

Strategia di font display e preloading responsive

Come specialista di Core Web Vitals, vedo ogni giorno diverse soluzioni creative. La maggior parte non ha molto senso, ma ogni tanto mi imbatto in una strategia così semplice ed elegante che ha senso per certi siti.

Secondo il 2025 Web Almanac, l'88% dei siti web utilizza web fonts, caricando una media di 4 file font per pagina. Eppure solo il 12% dei siti effettua il preload dei font, e appena lo 0,5% utilizza font-display: optional. La maggior parte dei siti tratta il caricamento dei font como un problema universale. Questo articolo spiega un approccio più intelligente: caricare i font in modo diverso per desktop e mobile.

La strategia combina il preloading responsive con font-display: optional su desktop (eliminando il Flash Of Unstyled Text) e font-display: swap su mobile (prioritarizzando il rendering rapido del testo rispetto alla coerenza visiva).

Ultima revisione di Arjen Karel a marzo 2026

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

Il problema del caricamento anticipato dei font

Quando si ottimizzano i Core Web Vitals c'è una regola semplice 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 fonts. Dare priorità al caricamento dei web fonts durante il caricamento della pagina può migliorare la user experience, ma se il tuo sito fatica a raggiungere le soglie dei Core Web Vitals, specialmente per specifici tipi di dispositivi, potresti dover bilanciare la UX rispetto al miglioramento dell'LCP.

Il capitolo Performance del 2025 Web Almanac mostra che il testo è l'elemento LCP in quasi il 24% delle pagine mobili. 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 iniziale della rete e possono ritardare il caricamento dell'immagine.

Consideriamo l'esempio seguente di un sito di un quotidiano olandese. Su un dispositivo mobile, 3 font vengono messi in coda prima dell'elemento LCP. Ciò fa sì che i 3 font competano per le risorse di rete iniziali e ritardino il timing dell'immagine.

Capire font-display: optional vs swap

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

font-display: swap mostra immediatamente il font di fallback e inserisce il font personalizzato una volta caricato. Questo è ottimo per l'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 salto di layout 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 100ms per caricare il font. Se il font arriva in tempo (solitamente dalla cache o da un preload veloce), viene utilizzato. In caso contrario, il font di fallback viene utilizzato per l'intero caricamento della pagina e non avviene mai alcuno swap. Ciò significa zero salti di layout, 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.

Da Chrome 83, la combinazione di font-display: optional con <link rel="preload"> blocca il first paint fino a ~100ms (con un massimo assoluto di 1500ms), in attesa che arrivi il font. Se il font è precaricato, arriva quasi sempre entro quella finestra. Il risultato: testo formattato al first paint, zero FOUT, zero salti di layout. Ecco perché la parte desktop della strategia responsive funziona così bene.

Strategia responsive dei font in soccorso!

In casi come questo, dove c'è molta competizione iniziale sulla rete, ha senso distinguere tra i tipi di dispositivi. Tipicamente 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 e ha perfettamente senso fare il preload di alcuni file font critici.

I dispositivi mobili, d'altro canto, potrebbero essere utilizzati durante il tragitto casa-lavoro in condizioni de rete meno che ottimali. I dispositivi mobili hanno anche spesso CPU più lente e meno memoria disponibile rispetto ai desktop. Queste limitazioni significano 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 prestazioni di rendering sui dispositivi con migliore larghezza di banda e potenza di elaborazione. Usa font-display: optional per eliminare i problemi di swap dei font. Combinato con un preload, Chrome bloccherà brevemente il rendering (fino a ~100ms) per attendere il font, offrendoti testo formattato al first paint con zero CLS.
• Mobile: Non effettuare il preload del font a causa della competizione sulla rete. Usa font-display: swap per un rendering del testo più veloce. Questo approccio visualizza immediatamente i font di fallback mentre il font personalizzato continua a caricarsi in background, offrendo un'esperienza migliore sui dispositivi meno potenti.

Implementazione tramite <link rel="preload"> e media queries

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 di font in base ai tipi di dispositivo.

Implementazione completa

<head>
  <!-- il meta viewport DEVE venire prima dei preload condizionali ai media -->
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <!-- Preload 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 assicura un rendering rapido del testo *\/
    @font-face {
        font-family: 'CustomFont';
        src: url('/fonts/custom-font.woff2') format('woff2');
        font-display: swap;
    }

    \/* Desktop: optional + preload = testo formattato 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. Ordinamento 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 altri meta tag. Se il viewport non è impostato, la media query verrà valutata rispetto alle dimensioni errate sui dispositivi mobili.
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 sono a cascata (cascade). 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 dello stesso dominio (same-origin).
4. Corrispondenza dei breakpoint: L'attributo media sul preload (768px) deve corrispondere alla media query CSS (768px). Se non corrispondono, effettuerai il preload su un breakpoint e applicherai il font-display errato su un altro.

Ridurre i salti di layout su mobile con il matching del font di fallback

La strategia mobile utilizza font-display: swap, il che significa che ci sarà un breve Flash Of Unstyled Text quando il font personalizzato sostituisce il fallback. Puoi minimizzare questo salto visivo usando le sovrascritture delle metriche dei font CSS:

@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 a quelle del 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 sovrascrittura per i tuoi font specifici.

Vantaggi di questo approccio

• UX Desktop: Il desktop esegue il rendering con il web font al first paint, prevenendo sia FOUT che FOIT. Zero salti di layout dal caricamento dei font.
• Prestazioni 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. Niente JavaScript, niente librerie di caricamento font, niente dipendenze da framework. Ciò significa anche che funziona con qualsiasi strategia di priorità delle risorse già in atto.

Impatto nel mondo reale

Questa strategia si basa su un esempio del mondo reale che ho riscontrato controllando un sito di e-commerce. Il sito caricava 3 font personalizzati: un font per i titoli, uno per il corpo del testo e uno per le icone. Su desktop, tutto si caricava abbastanza velocemente da non causare quasi mai problemi. Ma su mobile via 4G, i tre preload dei font competevano con l'immagine hero e spingevano l'LCP ben oltre la soglia di 2,5 secondi.

Dopo aver implementato la strategia responsive (preloading solo su desktop, rimozione dei preload dei font su mobile):

• Desktop: Migliorato CLS e UX con font formattati che appaiono al first paint. La combinazione preload + font-display: optional ha eliminato tutti i salti di layout relativi ai font.
• Mobile: Più veloci First Contentful Paint e Largest Contentful Paint perché i font non competevano più per la larghezza di banda iniziale. L'immagine hero si caricava senza conflitti.

Ricerche di DebugBear confermano l'impatto: il preloading dei font può migliorare l'LCP di circa il 30% (da 1,82s a 1,24s) se applicato correttamente. Ma se abusato (un sito aveva 38 font precaricati), il preloading peggiora le cose. L'approccio responsive 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 pagine mobili supera l'LCP quando i font sono precaricati strategicamente, rispetto al 70% per le pagine che caricano tutti i font nello 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 font personalizzati
• Mobile e desktop hanno diversi profili di prestazioni Core Web Vitals (comune nei siti in cui il mobile fatica con l'LCP mentre il desktop lo supera)
• I font competono con altre risorse critiche (immagini hero, CSS critico) su mobile
• Stai effettuando il self-hosting dei tuoi font (questa strategia funziona con qualsiasi hosting di font, ma il self-hosting ti dà il pieno controllo sul percorso di preload)

Salta questa strategia quando:

• Carichi solo un font WOFF2 leggero (sotto i 20 KB). L'overhead del caricamento responsive 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 dati sul campo. I test di laboratorio possono trascurare la variabilità delle condizioni di rete reali che rende questa strategia preziosa in primo luogo.