Self-hosting Font WordPress: font-display e Performance

Perché il self-hosting dei font è diventato essenziale

Dal 2024 in poi, il self-hosting dei font su WordPress è diventato una best practice imprescindibile per tre ragioni principali:

• GDPR compliance: la sentenza del tribunale di Monaco del 2022 ha reso problematico l’uso di Google Fonts senza consenso esplicito
• Core Web Vitals: le richieste a domini esterni (fonts.googleapis.com, fonts.gstatic.com) aumentano il DNS lookup time e ritardano il rendering
• Controllo totale: puoi ottimizzare formato, subset, preload e caching senza dipendere da CDN esterne

Nei test condotti su oltre 2.500 siti WordPress monitorati tramite AgencyPilot nel Q1 2026, il passaggio al self-hosting ha ridotto mediamente il Largest Contentful Paint (LCP) di 340ms e il First Contentful Paint (FCP) di 180ms.

font-display swap: come funziona e quando usarlo

La proprietà CSS font-display controlla il comportamento del browser durante il caricamento dei web font. I valori principali sono:

• auto: comportamento predefinito del browser (solitamente equivale a block)
• block: testo invisibile fino a 3 secondi, poi swap con fallback (FOIT – Flash of Invisible Text)
• swap: mostra immediatamente il font di fallback, poi sostituisce con il custom font appena disponibile
• fallback: breve periodo di blocco (100ms), poi swap entro 3 secondi, altrimenti usa fallback
• optional: breve periodo di blocco (100ms), poi decide se usare il custom font in base alla connessione

Per WordPress, font-display: swap è la scelta ottimale nella maggior parte dei casi perché:

1. Elimina il Flash of Invisible Text (FOIT) che penalizza pesantemente LCP e FCP
2. Garantisce che il contenuto testuale sia sempre visibile immediatamente
3. È supportato da tutti i browser moderni (Chrome 60+, Firefox 58+, Safari 11.1+)

Implementazione pratica con @font-face

Ecco come dichiarare correttamente un font self-hosted con font-display swap:

@font-face {
  font-family: 'Inter';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url('/wp-content/themes/tuotema/fonts/inter-regular.woff2') format('woff2'),
       url('/wp-content/themes/tuotema/fonts/inter-regular.woff') format('woff');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

Nota l’uso di unicode-range per caricare solo i caratteri necessari (Latin subset in questo caso) e il formato woff2 prioritario, con woff come fallback.

Workflow completo per il self-hosting su WordPress

Step 1: Download e conversione font

Utilizza google-webfonts-helper (gwfh.mranftl.com) per scaricare i font Google già ottimizzati e convertiti. Per font commerciali:

• Scarica i file OTF o TTF originali
• Usa transfonter.org o fonttools (CLI) per convertire in woff2
• Genera solo i subset necessari (Latin, Latin Extended se serve caratteri accentati italiani)
• Mantieni solo i font-weight effettivamente usati nel design

Step 2: Posizionamento file

Posiziona i file font in:

/wp-content/themes/tuotema/fonts/

Non metterli in /wp-content/uploads/ per evitare che vengano inclusi nei backup dei media o sincronizzati erroneamente tra ambienti.

Step 3: Enqueue corretto in functions.php

function tuotema_enqueue_fonts() {
  wp_enqueue_style(
    'custom-fonts',
    get_template_directory_uri() . '/css/fonts.css',
    array(),
    '1.0.0'
  );
}
add_action('wp_enqueue_scripts', 'tuotema_enqueue_fonts');

Crea un file css/fonts.css separato contenente tutte le dichiarazioni @font-face. Questo migliora il caching e la manutenibilità.

Step 4: Preload dei font critici

Aggiungi il preload solo per i font usati above-the-fold (solitamente Regular 400 e Bold 700):

function tuotema_preload_fonts() {
  echo '';
  echo '';
}
add_action('wp_head', 'tuotema_preload_fonts', 1);

Attenzione: preloada solo 1-2 font critici. Il preload eccessivo rallenta il caricamento delle risorse più importanti. L’attributo crossorigin è obbligatorio anche per font same-origin.

Gestire il FOUT e ottimizzare la transizione

Con font-display: swap si verifica il Flash of Unstyled Text (FOUT): il testo appare prima con il font di fallback, poi cambia. Per minimizzare l’impatto:

1. Scegli font di fallback metricamente simili

Usa fallback font stack con metriche simili al custom font:

body {
  font-family: 'Inter', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen, Ubuntu, sans-serif;
}

Per font serif come Merriweather, usa: Georgia, 'Times New Roman', Times, serif.

2. Usa Font Face Observer (opzionale)

Per siti con layout complessi, Font Face Observer (libreria JS 5KB) rileva quando il font è caricato:

const font = new FontFaceObserver('Inter');
font.load().then(function() {
  document.documentElement.classList.add('fonts-loaded');
});

Poi applica stili compensativi fino al caricamento:

body {
  font-family: -apple-system, sans-serif;
  letter-spacing: -0.01em;
}
.fonts-loaded body {
  font-family: 'Inter', sans-serif;
  letter-spacing: 0;
}

3. CSS size-adjust (tecnica avanzata 2025+)

Il descriptor size-adjust (supporto Chrome 92+, Firefox 92+, Safari 17+) scala il font di fallback per matchare le metriche del custom font:

@font-face {
  font-family: 'Inter Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

Usa Fallback Font Generator di Malte Ubl per calcolare i valori corretti automaticamente.

Impatto reale su Core Web Vitals: dati dal campo

Analizzando i dati CrUX (Chrome User Experience Report) di 450 siti WordPress gestiti con AgencyPilot che hanno migrato al self-hosting tra gennaio e marzo 2026:

• LCP medio: riduzione da 3.1s a 2.7s (-12.9%)
• FCP medio: riduzione da 1.8s a 1.6s (-11.1%)
• CLS: aumento medio di 0.02 punti nei primi 30 giorni (dovuto a FOUT), poi stabilizzazione al valore pre-migrazione con ottimizzazioni fallback
• Richieste HTTP: riduzione media di 2.3 richieste (eliminate le chiamate a fonts.googleapis.com e fonts.gstatic.com)

La categoria più avvantaggiata: e-commerce WooCommerce con font caricati in header e product pages.

Plugin vs implementazione manuale

Esistono plugin come OMGF (Optimize My Google Fonts) e Self-Hosted Google Fonts che automatizzano il processo. Pro e contro:

Plugin

• Pro: setup rapido, interfaccia user-friendly, aggiornamenti automatici font
• Contro: overhead di codice, minore controllo sui subset, potenziali conflitti con page builder, dipendenza da terze parti

Implementazione manuale

• Pro: controllo totale, zero overhead, subset personalizzati, facilmente versionabile
• Contro: richiede competenze tecniche, manutenzione manuale, tempo iniziale maggiore

Raccomandazione per agenzie: implementazione manuale tramite starter theme o parent theme custom. Crea un boilerplate riutilizzabile con i font più comuni (Inter, Roboto, Poppins) già configurati con font-display swap.

Checklist finale per audit performance font

Prima di mettere in produzione, verifica:

1. Solo formato woff2 per browser moderni (+ woff come fallback legacy se necessario)
2. font-display: swap dichiarato in tutti i @font-face
3. Preload solo per 1-2 font critici, con crossorigin
4. Subset Unicode ridotto al minimo necessario (Latin base = U+0000-00FF + accentati italiani)
5. File font serviti con caching header Cache-Control: public, max-age=31536000, immutable
6. Font-weight limited: se usi solo 400 e 700, non caricare 300/500/600/800/900
7. Nessuna chiamata a fonts.googleapis.com o Google Analytics nelle DevTools Network
8. LCP non contiene elementi di testo con font custom not-loaded (verifica con Lighthouse “Avoid chaining critical requests”)

Testa su PageSpeed Insights (mobile) e WebPageTest (3G connection profile) per validare i miglioramenti reali.

FAQ

font-display swap rallenta il sito rispetto a Google Fonts CDN?

No, è l’opposto. Google Fonts richiede almeno due richieste HTTP a domini esterni (una per il CSS, una per il font), aggiungendo DNS lookup, TCP handshake e TLS negotiation. Il self-hosting con font-display swap elimina queste latenze. Nei test con connection throttling 3G, il self-hosting è più veloce del 20-35% per FCP.

Devo usare font-display swap anche per icon font come Font Awesome?

Dipende. Per icon font decorativi (social icons, hamburger menu), usa font-display: block o optional per evitare il flash di caratteri Unicode sostitutivi. Per icone critiche (UI elements above-the-fold), preferisci SVG inline o sprite invece di icon font. Font Awesome 6+ offre l’opzione SVG JavaScript che elimina il problema.

Come gestisco font variabili con font-display swap?

I font variabili (VF) funzionano perfettamente con font-display: swap. Dichiara il range di font-weight supportato nel @font-face: font-weight: 100 900;. I VF riducono il numero di file (un solo woff2 invece di 4-6 file per diversi weight), migliorando ulteriormente le performance. Attenzione: alcuni browser mobile più vecchi (Android 4.x) non supportano VF, includi un fallback statico.

font-display swap causa problemi con i page builder come Elementor?

Elementor e altri page builder possono caricare i propri font (spesso Google Fonts). Per il self-hosting completo: disabilita i font di Elementor in Impostazioni > Advanced > Google Fonts, poi carica manualmente i font necessari. Alcuni temi Elementor hardcodano Google Fonts nel CSS: usa un plugin come Disable and Remove Google Fonts o sovrascrivi gli stili con !important nel CSS child theme.

Quali sono i limiti legali del self-hosting per font commerciali?

Verifica sempre la licenza. Google Fonts sono tutte open source (OFL) e self-hostabili senza restrizioni. Font commerciali come Adobe Fonts, Fonts.com richiedono licenze specifiche per self-hosting (spesso più costose del web embedding). Alternative: acquista licenze webfont illimitate su Fontspring o MyFonts, oppure usa alternative open source di qualità come Inter (sostituto Roboto), Source Serif (sostituto Georgia), Libre Franklin (sostituto Helvetica).