Riduci il lavoro dei font che ogni percorso richiede al browser
Fai l’inventario delle richieste di font a cache fredda nella home page, nelle pagine di conversione, nelle viste con login e nei template con diversi sistemi di design. Registra la famiglia, il peso, lo stile, il file, l’origine, la dimensione trasferita e il selettore. Una regola dichiarata @font-face non provoca di per sé un download; un browser normalmente scarica una face quando il layout corrente la usa. Questo rende degni di rimozione i pesi e gli stili globali non usati.
Usa il tipo personalizzato dove porta reale valore di brand, spesso nei titoli display, e considera uno stack di system font per il body copy quando il design lo permette. Non dare per scontato che un font variabile sia sempre più piccolo: può sostituire più file statici ma essere più grande di un singolo face statico. Confronta gli asset compressi effettivamente richiesti dal percorso.
Rimuovi famiglie, pesi, italici e icon font che non hanno un uso testato a livello di percorso.
Verifica che la licenza permetta la delivery web, il subsetting e l’auto-hosting prima di cambiare la build.
Usa WOFF2 e sottoponilo a subsetting senza rimuovere caratteri necessari
Parti da WOFF2 come baseline per i browser moderni. La Recommendation del W3C descrive WOFF2 come un pacchetto di web-font progettato per una compressione migliorata e una decompressione rapida, ed è implementato nei principali browser. Mantieni un altro formato solo per un requisito documentato di browser legacy; altrimenti un fallback ben progettato è il percorso di compatibilità più sicuro.
Il subsetting crea un file più piccolo contenente glifi selezionati, o forme dei caratteri. unicode-range può associare i subset a intervalli di caratteri così che il browser scelga un file rilevante mentre effettua il matching del testo. Costruisci i subset dalle pagine reali e dalle lingue che supporti, includendo punteggiatura, valute, nomi, testi legali e script inseriti dagli utenti. I glifi mancanti sono un problema di correttezza, non un risparmio di byte accettabile.
Testa pagine localizzate rappresentative e input di form, non solo campioni di design in inglese.
Assicurati che unicode-range e gli intervalli di peso/stile di ogni subset corrispondano al file distribuito.
Progetta fallback e policy di font-display insieme
Un font di fallback è ciò che gli utenti vedono quando la face personalizzata non è pronta. Sceglilo per proporzioni simili, poi confronta titoli reali, pulsanti multilinea, navigazione, tabelle, form e stringhe localizzate lunghe. Larghezze diverse cambiano il wrapping; ascent, descent o line-gap diversi cambiano l’altezza dei blocchi. Entrambi possono spostare contenuto già visibile nella pagina.
font-display definisce il comportamento di rendering mentre una face è indisponibile. optional ha un periodo di blocco estremamente breve e nessun periodo di swap, perciò può andare bene per il testo di corpo quando un fallback stabile è preferibile alla prima visita. swap mostra il fallback prontamente e può applicare in seguito il web font, ma usalo solo dove una sostituzione tardiva non causerà un reflow dirompente. Block o fallback dovrebbero servire a una motivazione di design testata, non essere un default globale. CSS size-adjust può aiutare a sintonizzare le metriche di un fallback, ma verifica visivamente ogni script e viewport supportato.
Non fare dipendere il testo di pagamento, recupero, account, sicurezza o navigazione da un font personalizzato tardivo.
Una lettera di fallback può comunicare il significato sbagliato; le icone SVG sono generalmente più sicure per i simboli dell’interfaccia.
Migliora la scoperta, ma limita preload e valuta il flusso di dati
Una face dichiarata solo in un foglio di stile esterno può essere scoperta dopo che quel CSS è stato scaricato e parsato. Un critical CSS mantenibile può esporre una dichiarazione necessaria prima; non inlinesare il binario del font, che ingrandisce il documento. Per un’origine di terze parti, preconnect può stabilire la connessione prima. Le richieste di font sono risorse CORS, quindi la delivery cross-origin e i preload richiedono il corretto handling di crossorigin.
Preload è un override di priorità, non un interruttore universale di velocità. Può competere con altro lavoro critico e può scaricare una face che un percorso non usa mai; inoltre bypassa la selezione unicode-range. Risolvi prima la scoperta tardiva, poi effettua il preload di al massimo un file dimostrato come primo-view usando l’URL esatto, as=font e crossorigin. Google Fonts dichiara che le richieste API includono l’indirizzo IP del visitatore, l’URL richiesto, gli header HTTP e il referer; afferma inoltre che la sua API non imposta né registra cookie e non usa le informazioni raccolte per profili o advertising mirato. L’auto-hosting impedisce a Google di ricevere i dati per quei caricamenti. Valuta delivery, informativa sulla privacy, giurisdizione, contratti e consulenza qualificata quando necessario.
Confronta i tracce a cache fredda e conferma che il file preloaded viene consumato sul percorso.
Pesa setup della connessione, capacità di cache e CDN, manutenzione degli asset e flusso di dati dei visitatori.
Versiona gli asset dei font e conserva una configurazione CSS di fallback testata.
Testa il comportamento renderizzato e gestisci i font come una dipendenza di resilienza
Con cache fredda, usa gli strumenti di rete del browser per ispezionare la catena CSS→font, timing, origine, caching e fallimenti. Ripeti con una connessione limitata, poi limita o blocca il font. Il successo significa testo leggibile, controlli usabili, simboli corretti e layout coerente prima che la face personalizzata appaia. Testa layout realistici sia stretti che desktop, stringhe lunghe, errori, copy di consenso, prezzi e ogni script supportato.
In Chromium, registra un reload nel Performance panel e ispeziona la traccia Layout Shifts; DevTools può identificare gli elementi spostati e animare lo shift. Il caricamento dei font è un noto colpevole, ma un elemento spostato non è necessariamente la causa radice, quindi correlare la traccia con l’applicazione del font. La Layout Instability API è disponibile principalmente in Chromium, il che rende importanti i controlli visivi cross-browser. Includi asset di font, comportamento CORS, policy di cache, fallback e rollback nella review di release. La modalità degradata prevista è testo leggibile, non contenuto bianco o navigazione rotta.
Una cache calda può nascondere la richiesta iniziale e il problema di rendering.
Ripeti il controllo quando file, copy CMS, template, provider o regole CDN cambiano.