Vai al contenuto 
Molti Font web per WordPress caricano in parallelo, bloccano il rendering e quindi prolungano LCP e FCP, soprattutto sui dispositivi mobili. In questo articolo vi mostrerò perché troppi font costano tempo, come si verifica il FOIT/FOUT e quali misure specifiche velocizzeranno sensibilmente il vostro sito.
Punti centrali
- Riduzione a pochi tagli riduce le richieste e il trasferimento dei dati
- Precarico e Preconnect per dare priorità ai file importanti
- visualizzazione dei caratteri Impedisce il testo invisibile (FOIT)
- Locale l'hosting risparmia le latenze esterne e CORS
- Sottosetting rimuove i glifi inutilizzati e rende i caratteri piccoli
Perché molti web font in WordPress costano tempo di caricamento
Ogni font aggiuntivo porta con sé ulteriori Richieste, più ricerche DNS e ulteriori kilobyte. Diverse famiglie con caratteri regolari, grassetto e corsivo aggiungono rapidamente 500-1000 KB prima che il testo venga visualizzato in modo pulito. Questo ha un effetto diretto sul Largest Contentful Paint (LCP) perché il browser può eseguire il rendering solo quando sono disponibili i font importanti. Solo tre font possono allungare il primo rendering del 20-50%, il che colpisce duramente gli utenti con connessioni lente. Pertanto, per evitare il blocco del rendering, mi concentro su pochi e ben definiti tagli e fallback sicuri.
Come vengono caricati i web font in WordPress - e dove si bloccano
I font web sono spesso forniti da fornitori esterni o dalle opzioni dei temi, il che significa che è necessario aggiungere ulteriori font. DNS-lookup e handshake TLS. Con FOIT (Flash of Invisible Text), il browser attende i font e mostra un testo invisibile fino a quel momento, rafforzando l'impressione che „non stia succedendo nulla“. FOUT (Flash of Unstyled Text) è migliore, ma produce brevi salti di layout quando si passa dal font di fallback a quello web. Senza priorità, preconnessione e cache sensata, il tempo di caricamento e la sensazione di TTFB aumentano. Pianifico l'integrazione in modo che il contenuto principale appaia sempre per primo e che i font scorrano in seguito, senza interruzioni.
Audit e monitoraggio: rendere visibili tutti i caratteri
Prima di ottimizzare, ottengo una panoramica completa. In DevTools, nella scheda Network filtro per „Carattere“, controllare i nomi dei file, le dimensioni del trasferimento e Iniziatore (tema, plugin, editor di blocchi). I tempi della cascata mi mostrano se i font bloccano il percorso critico. Nel pannello di copertura, posso vedere se i grandi blocchi CSS @font-face solo minimo può essere utilizzato. Una traccia delle prestazioni rivela se il rendering del testo è bloccato finché i file WOFF2 non sono pronti. A livello di WordPress, disattivo i plugin su base di prova per identificare le fonti di font nascoste (page builder, icon pack). Le mie metriche principali sono: numero di richieste di font, KB totali, tempo per la prima riga leggibile, durata di FOUT/FOIT e impatto su LCP/FCP nel filmstrip.
Confronto i dati di laboratorio e quelli sul campo: Un desktop veloce via LAN nasconde problemi che diventano visibili solo con la rete 4G. Per questo motivo eseguo i test con un basso livello di CPU e di larghezza di banda per simulare condizioni mobili realistiche. Solo quando le catene sono pulite e i fallback vengono resi in modo stabile, aggiungo un'ulteriore messa a punto dei refusi.
Effetti misurabili sui Core Web Vitals
LCP, FCP e CLS reagiscono in modo sensibile a carichi imprudenti Caratteri, perché i font in ritardo spostano i layout e oscurano i contenuti. Secondo HTTP Archive, le pagine con font web trasferiscono in media una quantità di dati significativamente maggiore, il che è più evidente sui dispositivi mobili. La documentazione di PageSpeed Insights spiega chiaramente che le risorse che bloccano il rendering allungano il percorso verso la prima visualizzazione. Le richieste prioritarie accorciano questa catena e riducono sensibilmente i tempi di attesa. Se volete approfondire il tema della prioritizzazione, potete trovare informazioni di base su Priorità delle richieste, che uso specificamente per i temi estesi.
Cause tecniche in dettaglio
Molti file singoli, stili non combinati e sottoinsiemi mancanti aumentano la Carico utile inutile. Senza HTTP/2 o HTTP/3, le richieste vengono spesso accodate e bloccano il percorso di rendering. Domini esterni come fonts.googleapis.com aggiungono ulteriori latenze, che si sommano per più famiglie. Le intestazioni CORS sono necessarie, altrimenti il browser annulla il precaricamento o non lo utilizza. Prevengo questi ostacoli attraverso la fornitura locale, l'impostazione pulita delle intestazioni e la limitazione mirata a due o tre tagli.
Evitare le insidie tipografiche: Metriche, qualità di ripiego e falsi stili
Oltre alle dimensioni del file, i dettagli dei refusi influenzano la stabilità della visualizzazione. Se le metriche del font di fallback e di quello web differiscono notevolmente, si verificano salti visibili durante lo scambio. Equalizzo l'altezza con Regolazione della taglia e gli stili sintetici di blocco per evitare „falsi“ grassetti e corsivi:
@font-face {
font-family: 'Inter';
src: url('/fonts/Inter-roman.var.woff2') format('woff2');
font-weight: 100 900;
font-style: normal;
font-display: swap;
/* Regolare le metriche per ridurre il CLS */
regolazione delle dimensioni: 100%;
ascendente-override: 90%;
sovrapposizione della discesa: 20%;
line-gap-override: 0%;
}
/* Armonizzare visivamente il font di fallback */
corpo {
font-family: system-ui, -apple-system, Segoe UI, Roboto, Inter, sans-serif;
font-size-adjust: 0,5; /* Migliore regolazione dell'altezza della x */
font-synthesis: none; /* Previene il falso grassetto/italico */
}Definisco un asse o un file statico separato per le varianti in corsivo ed evito i falsi corsivi. Organizzo anche peso del carattere con precisione (300/400/600/700) in modo che il browser non interpoli. Questo lavoro di precisione richiede poco tempo, ma impedisce cambiamenti evidenti nel layout quando si passa dal font di fallback a quello web.
Razionalizzazione: tre misure immediate
Riduco il numero di famiglie, sostituisco i tagli decorativi con i ripieghi e utilizzo in modo coerente visualizzazione dei caratteriswap. Gli stack di sistema (-apple-system, Segoe UI, Roboto, Noto Sans, Ubuntu, Cantarell) producono rapidamente il testo mentre il font web viene caricato in background. I titoli di solito richiedono solo un taglio in grassetto, il testo del corpo una variante regolare. Elimino anche le chiamate remote non necessarie per generare meno richieste. Se si vuole ottenere ancora di più, è possibile Ridurre le richieste HTTP e quindi alleviare l'intero percorso critico.
Sostituire i font delle icone: SVG salva le richieste
Molti temi sono dotati di font di icone (ad esempio per le icone dei social o dell'interfaccia utente). Un singolo font di icone può pesare tra i 30 e gli 80 KB e può essere @font-face influenzano il percorso di rendering. Se possibile, sostituisco tali font con SVG - in linea o come sprite. In questo modo si riducono le richieste, si evita il FOIT/FOUT per le icone e si garantisce una visualizzazione nitidissima su tutti i display. Se non è possibile effettuare subito un cambio completo, sotto-seleziono il font delle icone in base ai pittogrammi effettivamente utilizzati e imposto font-display: opzionale, in modo che la pagina non attenda mai il font dell'icona:
@font-face {
font-family: 'ThemeIcons';
src: url('/fonts/theme-icons-subset.woff2') format('woff2');
font-display: opzionale; /* L'interfaccia utente rimane operativa, le icone appaiono in seguito */
}Inline SVG mi permette anche di controllare i colori e gli stati tramite i CSS senza caricare nuovi file. Questo si sposa perfettamente con l'obiettivo di mantenere la catena di rendering critica il più breve possibile.
Usare correttamente il precarico, il precollegamento e il preriscaldamento
Uso Preconnect per i casi decisivi Dominio, per dare priorità a DNS, TCP e TLS. Uso il preload solo per i file WOFF2 veramente critici, altrimenti spreco la priorità sulle risorse secondarie. Il tag deve impostare as=“font“, type=“font/woff2″ e crossorigin, altrimenti il browser ignorerà parzialmente il suggerimento. Troppi preload si sabotano a vicenda e fanno passare in secondo piano i contenuti più importanti. Un insieme di suggerimenti snello e testato accorcia il tempo necessario per arrivare alla prima riga leggibile:
Ospitare localmente e rimanere conformi al GDPR
Scarico i font di cui ho bisogno, li sottointegro e li servo direttamente dal mio sito web Server. In questo modo si risparmiano le ricerche DNS esterne, si riducono i problemi CORS e si ha il controllo completo della cache. Un approccio locale facilita i tempi di esecuzione della cache e garantisce una disponibilità costante. Per chiarezza legale e implementazione pratica, la mia guida a Google Fonts locali. In questo modo mantengo la tecnologia e la protezione dei dati puliti senza sacrificare la tipografia.
Sottosetting e font variabili: massimo effetto con dimensioni ridotte
Invece di caricare pacchetti di lingue completi, mantengo solo i pacchetti di lingue necessari. Glifi e rimuovere gli insiemi esotici. Il latino senza estensioni spesso fa risparmiare il 40-70% delle dimensioni del file, cosa particolarmente evidente sui dispositivi mobili. I font variabili sostituiscono diversi file statici con un'unica risorsa con assi per il peso e il corsivo. In questo modo si riducono le richieste e si migliora la priorità se si precarica un solo file WOFF2. Allo stesso tempo, la diversità visiva viene mantenuta senza dover trasferire cinque sezioni singolarmente.
Caratteri variabili nella pratica: uso mirato degli assi
Nella realizzazione, evito aree d'asse inutilmente ampie. Limito wght ad esempio, a 400-700 se si utilizzano solo i caratteri regolari e grassetto. Questo riduce la complessità del rendering e mantiene la coerenza visiva. Per la tipografia responsive, uso sistematicamente pesi numerici, non parole chiave:
@font-face {
font-family: 'InterVar';
src: url('/fonts/Inter-roman.var.woff2') format('woff2');
font-weight: 400 700; /* Gamma ristretta invece di 100-900 */
font-style: normal;
font-display: swap;
}
h1, h2 { font-family: 'InterVar', system-ui, sans-serif; font-weight: 700; }
p { font-family: 'InterVar', system-ui, sans-serif; font-weight: 400; }
:root { font-optical-sizing: auto; }
/* Casi speciali per asse, ove opportuno:
.element { font-variation-settings: 'wght' 650; } */In questo modo si mantiene la flessibilità di un font variabile senza appesantire il sistema con inutili fasi intermedie.
Quale ottimizzazione porta quanto? (Panoramica)
La panoramica che segue mostra ciò che utilizzo nella pratica per ottenere il massimo Risparmio e a cosa presto attenzione. I valori sono intervalli empirici e dipendono dallo stato iniziale, dal tema e dal numero di modifiche. Verifico ogni modifica con PageSpeed Insights e un WebPageTest per riconoscere gli effetti collaterali. Quindi apporto modifiche mirate ai valori di soglia e alla cache. Questo aumenta la certezza che ogni misura guadagni in tempo reale.
| Approccio di ottimizzazione | Risparmio tipico | Nota importante |
|---|---|---|
| Riduzione a 2 tagli | 150-400 KB | Pulito Ricadute set |
| visualizzazione dei caratteri: swap | + testo di rapida lettura | Accettare FOUT invece di FOIT |
| Hosting locale + caching lungo | 2-3 richieste in meno | Controllo della cache/ETag corretto |
| Precollegamento + precarico mirato | 50-200 ms | Solo critico File |
| Sottoinsieme (base latina) | 40-70 % più piccolo | Espandibile in un secondo momento |
| Font variabile invece di 4 file | -3 Richieste | Utilizzare solo WOFF2 |
Usare i plugin in modo sensato, senza spese eccessive
OMGF carica i font di Google a livello locale, li suddivide automaticamente e accorcia quelli non necessari. Segno out. Asset CleanUp mi permette di disattivare i font pagina per pagina se un modello specifico non ne ha bisogno. Autoptimise combina i CSS, li minifica e può estrarre i font in modo che gli stili critici vengano prima. Collaudo attentamente le combinazioni perché un'eccessiva aggregazione in HTTP/2 può essere controproducente. L'obiettivo rimane una catena stabile e breve verso il primo contenuto visibile.
Implementazione pratica in WordPress: esempi di codice
Molti temi o page builder includono automaticamente i font. Rimuovo le fonti duplicate, passo ai file locali e imposto priorità chiare, preferibilmente nel tema figlio.
1) Rimuovere i font esterni dal tema e caricare i font locali
/* functions.php nel tema figlio */
add_action('wp_enqueue_scripts', function() {
/* Personalizzare/trovare maniglie di esempio del tema/costruttore */
wp_dequeue_style('google-fonts');
wp_deregister_style('google-fonts');
/* Includere i propri stili di carattere locali */
wp_enqueue_style('local-fonts', get_stylesheet_directory_uri() . '/assets/css/fonts.css', [], '1.0', 'all');
}, 20);2) Precarico mirato per il WOFF2 critico
/* functions.php */
add_action('wp_head', function() {
echo '';
}, 1);3) Impostare la cache e l'intestazione CORS per i font
# .htaccess (Apache)
AddType font/woff2 .woff2
.
Header set Cache-Control "public, max-age=31536000, immutable"
Impostazione dell'intestazione Access-Control-Allow-Origin "*".# Nginx (blocco server)
posizione ~* .(woff2|woff)$ {
add_header Cache-Control "public, max-age=31536000, immutable";
add_header Access-Control-Allow-Origin "*";
types { font/woff2 woff2; }
}4) Esempio di fonts.css con sottoinsiemi e swap
@font-face {
font-family: 'Inter';
src: url('/fonts/InterLatin-400.woff2') format('woff2');
peso del carattere: 400;
font-style: normal;
font-display: swap;
unicode-range: U+000-5FF; /* base latina */
}
@font-face {
font-family: 'Inter';
src: url('/fonts/InterLatin-700.woff2') format('woff2');
font-weight: 700;
font-style: normal;
font-display: swap;
unicode-range: U+000-5FF;
}Pagine multilingue: Caricare sottoinsiemi per locale
Per i progetti internazionali, carico solo i font necessari. In WordPress, posso caricare per Locale registrano stili diversi. Per esempio, il tedesco/inglese rimane con un sottile sottoinsieme latino, mentre una variante polacca o turca ottiene glifi estesi - ma solo dove è necessario.
/* functions.php */
add_action('wp_enqueue_scripts', function() {
$locale = get_locale();
if (in_array($locale, ['de_DE','en_US','en_GB'])) {
wp_enqueue_style('fonts-latin', get_stylesheet_directory_uri().'/assets/css/fonts-latin.css', [], '1.0');
} elseif (in_array($locale, ['pl_PL','tr_TR'])) {
wp_enqueue_style('fonts-latin-ext', get_stylesheet_directory_uri().'/assets/css/fonts-latin-ext.css', [], '1.0');
}
});Importante: mi assicuro che il testo del corpo abbia sempre una solida catena di fallback del sistema. Questo assicura che la pagina rimanga leggibile anche se un file di lingua fallisce o la cache è fredda.
Hosting, cache e CDN come moltiplicatori
SSD NVMe veloci, HTTP/3 e una CDN accorciano il TTFB e forniscono Caratteri più veloce a livello globale. Una cache lato server riduce le richieste di backend, mentre la cache del browser recupera i font dalla cache locale per mesi. Brotli per WOFF2 non porta quasi più, ma per i CSS con @font-face è ancora utile. Inoltre, do priorità alle parti critiche del CSS in linea, in modo che il testo appaia immediatamente. Questo crea una catena: backend fisso, distribuzione pulita, file di font più piccoli e, alla fine, un testo visibile più velocemente.
Piano di test e rollout: andare in onda in sicurezza
Introduco le ottimizzazioni dei font passo dopo passo per ridurre al minimo i rischi. Innanzitutto documento lo status quo (richieste, KB, LCP/FCP/CLS). Poi riduco le famiglie e i tagli, sostituisco le icone e passo a file WOFF2 locali con una lunga cache. Poi aggiungo Preconnect/Preload - deliberatamente con parsimonia. Dopo ogni passaggio, controllo il filmstrip per vedere se il FOIT è stato ridotto e se i salti di layout sono scomparsi. Solo quando non sono più visibili regressioni, applico le modifiche a tutti i modelli.
Le pagine con titoli insoliti (dimensioni dei caratteri molto grandi, tracciamento) o con un uso massiccio del corsivo sono particolarmente critiche. Qui verifico specificamente se Regolazione della taglia e le sovrascritture metriche catturano davvero i salti di ripiego. Il mio obiettivo rimane costante: la prima linea leggibile il più presto possibile, senza atti di dressage attraverso caratteri tardivi.
Breve riassunto: tempo di caricamento ridotto, leggibilità aumentata
Troppi font costano molto Secondi, perché allungano le richieste, bloccano il rendering e aumentano il volume dei dati. Mantengo i font snelli, do priorità specifiche e mi affido a swap, subsetting e hosting locale. Questo riduce in modo affidabile LCP e FCP e riduce i salti visivi. Con il monitoraggio tramite PageSpeed Insights e test ripetuti, garantisco l'effetto e raccolgo i valori storici. In questo modo la tipografia rimane forte senza che gli utenti debbano aspettare, il che è esattamente ciò che voglio ottenere.
