Self-Hosting dei Web Font: Ottimizza Core Web Vitals e GDPR su WordPress

L’impiego di Content Delivery Network esterne per la distribuzione dei web font, come Google Fonts o Adobe Fonts, è stato a lungo considerato uno standard de facto. Oggi rappresenta una scelta architetturale obsoleta che degrada le prestazioni misurate dai Core Web Vitals ed espone l’infrastruttura a sanzioni per violazione della privacy.

In un’architettura enterprise orientata alle massime prestazioni, il self-hosting dei file tipografici in formato compresso non è più un’opzione facoltativa, ma un requisito strutturale indispensabile.

1. L’impatto architetturale sui Core Web Vitals

Il recupero di file CSS e binari da host remoti come fonts.googleapis.com e fonts.gstatic.com inserisce colli di bottiglia critici nella catena di rendering del browser:

• Latenza di rete supplementare: Ogni dominio terzo impone una nuova risoluzione DNS, l’avvio della connessione TCP e l’handshake TLS. Nei contesti di connessione mobile o con latenza elevata, questi passaggi aggiungono centinaia di millisecondi di attesa prima che il browser possa anche solo avviare il download del file .woff2.
• Degrado del Largest Contentful Paint (LCP): Se il testo Above The Fold dipende da un file tipografico remoto, il browser ne sospende o ne ritarda la resa finale. Questo posticipa il momento in cui l’elemento tipografico primario viene dipinto sullo schermo, peggiorando direttamente il punteggio LCP.
• Layout Shifts (CLS) e artefatti visivi: L’attesa del font remoto produce il fenomeno del FOIT (Flash of Invisible Text, con testo invisibile durante il caricamento) o del FOUT (Flash of Unstyled Text, con il font di fallback di sistema sostituito bruscamente all’arrivo del file esterno). La differenza metrica tra i glifi di sistema e il web font remoto provoca slittamenti improvvisi degli elementi di pagina, distruggendo la stabilità visiva (CLS).

Ospitare i file sullo stesso server web azzera le negoziazioni TLS multiple, sfrutta i socket HTTP/2 o HTTP/3 già aperti per il documento principale e garantisce la massima priorità di trasferimento.

2. Il profilo legale: Indirizzi IP e conformità GDPR

Oltre agli aspetti sistemistici, la risoluzione remota dei font presenta una criticità legale insanabile.

L’architettura client-server impone che, per servire il file CSS e i glifi, il provider cloud riceva l’indirizzo IP del visitatore. La Corte di Giustizia dell’Unione Europea e la giurisprudenza consolidata (tra cui la nota sentenza della Corte di Monaco di Baviera) qualificano l’indirizzo IP come dato personale.

Inviare questo dato verso server situati al di fuori dello Spazio Economico Europeo (tipicamente negli Stati Uniti) senza il consenso preventivo dell’interessato o senza adeguate basi giuridiche costituisce una violazione diretta degli articoli 6 e 44 del GDPR. Il self-hosting azzera completamente qualsiasi trasferimento transfrontaliero: il dato rimane confinato all’interno dell’infrastruttura proprietaria, eliminando la necessità di inserire blocchi nel banner cookie per i font di pagina.

3. Configurazione in Full Site Editing tramite theme.json

A partire dall’introduzione della Font Face API in WordPress, la gestione dei caratteri locali non richiede plugin ingombranti o fogli di stile sparsi. Si gestisce in modo dichiarativo e nativo nel file theme.json del tema a blocchi.

Fase 1: Predisposizione degli asset WOFF2

Elimina qualsiasi formato legacy (.eot, .ttf, .svg). Lo standard moderno per il web è esclusivamente WOFF2 (Web Open Font Format 2.0), che garantisce una compressione Brotli superiore di oltre il 30% rispetto a WOFF.

Posiziona i file convertiti nella directory del tema child o del tema FSE:

wp-content/themes/tuo-tema/assets/fonts/inter-v13-latin-regular.woff2
wp-content/themes/tuo-tema/assets/fonts/inter-v13-latin-700.woff2

Fase 2: Dichiarazione in theme.json

All’interno della sezione settings.typography.fontFamilies definisci la famiglia e i relativi percorsi:

{
  "version": 3,
  "settings": {
    "typography": {
      "fontFamilies": [
        {
          "fontFamily": "\"Inter\", sans-serif",
          "name": "Inter",
          "slug": "inter",
          "fontFace": [
            {
              "fontFamily": "Inter",
              "fontWeight": "400",
              "fontStyle": "normal",
              "fontDisplay": "swap",
              "src": [
                "file:./assets/fonts/inter-v13-latin-regular.woff2"
              ]
            },
            {
              "fontFamily": "Inter",
              "fontWeight": "700",
              "fontStyle": "normal",
              "fontDisplay": "swap",
              "src": [
                "file:./assets/fonts/inter-v13-latin-700.woff2"
              ]
            }
          ]
        }
      ]
    }
  }
}

La proprietà "fontDisplay": "swap" assicura che il testo rimanga visibile immediatamente tramite il font di sistema durante il download, eliminando il blocco del rendering.

4. Ottimizzazione Above The Fold: Preload dei font critici

Dichiarare il font nel tema non basta a garantire il massimo punteggio nei benchmark sintetici. Per impostazione predefinita, il motore di rendering del browser inizia a scaricare un font solo dopo aver scaricato e analizzato il DOM e il CSS di pagina, verificando che un nodo HTML visibile utilizzi effettivamente quella specifica regola @font-face.

Per eliminare questo ritardo sull’area Above The Fold, è fondamentale istruire lo scanner pre-parsing del browser tramite la direttiva rel="preload".

Inserisci nel file functions.php del tema (o in un modulo dedicato) l’iniezione nell’header:

/**
 * Precaricamento Above The Fold del font primario locale.
 */
function sys_preload_local_fonts() {
    $font_uri = get_theme_file_uri( 'assets/fonts/inter-v13-latin-regular.woff2' );
    echo '<link rel="preload" href="' . esc_url( $font_uri ) . '" as="font" type="font/woff2" crossorigin>' . "\n";
}
add_action( 'wp_head', 'sys_preload_local_fonts', 1 );

Attenzione sistemistica sull’attributo crossorigin: La specifica W3C impone che i web font vengano richiesti anonimamente tramite modalità CORS, anche quando risiedono sullo stesso dominio. Omettere l’attributo crossorigin genererebbe un doppio download dello stesso file da parte del browser.

5. Caching e configurazione del Web Server

Per massimizzare la resa del self-hosting, i file WOFF2 devono essere serviti con intestazioni di cache immutabili, poiché si tratta di asset statici che non subiscono variazioni nel tempo.

Su NGINX: Inserisci la direttiva nel blocco server:

location ~* \.woff2$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
    access_log off;
    log_not_found off;
}

Su Apache (.htaccess): Inserisci le regole nei moduli headers ed expires:

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>
<IfModule mod_headers.c>
    <FilesMatch "\.woff2$">
        Header set Cache-Control "public, max-age=31536000, immutable"
    </FilesMatch>
</IfModule>

Questa configurazione permette al browser dei visitatori di memorizzare il file tipografico locale per dodici mesi, riducendo le richieste successive a zero byte di trasferimento di rete e rendendo istantaneo il caricamento di qualsiasi pagina del sito.