Un nuovo modo per ridurre l'impatto del caricamento dei caratteri: i descrittori dei caratteri CSS

Il caricamento dei caratteri è stato a lungo un bugbear delle prestazioni web e non ci sono davvero buone scelte qui. Se vuoi usare i font web, le tue scelte sono fondamentalmente Flash of Invisible Text (aka FOIT) dove il testo è nascosto fino al download del font o Flash of Unstyled Text (FOUT) dove usi inizialmente il font di sistema di fallback e poi lo aggiorni al font web quando viene scaricato. Nessuna delle due opzioni ha davvero "vinto" perché nessuna delle due è davvero soddisfacente, ad essere onesti.

font-display non doveva risolvere questo problema?

La proprietà font-display per @font-face ha dato quella scelta allo sviluppatore web mentre in precedenza il browser lo aveva deciso (IE ed Edge preferivano FOUT in passato, mentre gli altri browser preferivano FOIT). Tuttavia, oltre a ciò non ha davvero risolto il problema.

Un certo numero di siti è passato alla font-display: swap quando è uscito per la prima volta e Google Fonts lo ha persino reso predefinito nel 2019. L'idea qui era che fosse meglio per le prestazioni visualizzare il testo il più rapidamente possibile , anche se è nel carattere di fallback e quindi per scambiare il carattere quando viene finalmente scaricato.

Anche allora ero favorevole a questo, ma mi trovo sempre più frustrato dall '"effetto di idratazione" quando i download dei caratteri Web e i caratteri si espandono (o si contraggono) a causa delle differenze tra i caratteri. Smashing Magazine, come la maggior parte degli editori, fa uso di font web e lo screenshot qui sotto mostra la differenza tra il rendering iniziale (con i font di fallback) e il rendering finale (con i font web):

Ora, se messi fianco a fianco, i caratteri web sono notevolmente più belli e si adattano al marchio Smashing Magazine. Ma vediamo anche che c'è una certa differenza nel layout del testo con i due caratteri. I caratteri sono di dimensioni molto diverse e, per questo motivo, il contenuto dello schermo cambia. In quest'epoca in cui i Core Web Vitals e i Cumulative Layout Shifts sono (giustamente!) riconosciuti come dannosi per gli utenti, font-display: swap è una scelta sbagliata per questo motivo.

Sono tornato alla font-display: block sui siti di cui mi occupo perché trovo davvero che lo spostamento del testo sia piuttosto stridente e fastidioso. Sebbene sia vero che il block non fermerà i turni (il carattere è ancora visualizzato in testo invisibile), almeno li rende meno evidenti per l'utente. Ho anche ottimizzato il caricamento dei caratteri precaricando i caratteri che ho ridotto il più possibile ospitando automaticamente i caratteri sottoimpostati , quindi i visitatori spesso hanno visto i caratteri di riserva solo per un piccolo periodo di tempo. Per me, il "periodo di blocco" dello swap è stato troppo breve e onestamente preferirei aspettare un po' più a lungo per ottenere il rendering iniziale corretto.

Usando font-display: optional può risolvere FOIT e FOUT — a un costo

L'altra opzione è usare font-display: optional . Questa opzione fondamentalmente rende i caratteri Web opzionali o, in altre parole, se il carattere non è presente quando la pagina ne ha bisogno, spetta al browser non scambiarlo mai. Con questa opzione evitiamo sia FOIT che FOUT utilizzando fondamentalmente solo i caratteri che sono già stati scaricati.

Se il carattere Web non è disponibile, torniamo al carattere di riserva, ma la navigazione della pagina successiva (o un ricaricamento di questa pagina) utilizzerà il carattere, poiché a quel punto dovrebbe aver terminato il download. Tuttavia, se il carattere web non è così importante per il sito, allora potrebbe essere una buona idea rimuoverlo completamente, il che è ancora meglio per le prestazioni web!

Le prime impressioni contano e avere quel carico iniziale senza caratteri web sembra un po' troppo. Penso anche - senza assolutamente alcuna prova a sostegno di questo, tra l'altro! — che darà alle persone l'impressione, forse inconsciamente, che qualcosa è "non funzionante" nel sito Web e potrebbe influire sul modo in cui le persone utilizzano il sito Web.

Quindi, tutte le opzioni dei caratteri hanno i loro svantaggi, inclusa la possibilità di non utilizzare affatto i caratteri Web o l'utilizzo di caratteri di sistema (che è limitante, ma forse non così limitante come molti pensano!).

Rendi il tuo carattere di riserva più vicino al tuo carattere

Il Santo Graal del caricamento dei caratteri Web è stato quello di rendere il carattere di fallback più vicino al carattere Web effettivo per ridurre il più possibile lo spostamento evidente, in modo che l'uso dello swap abbia meno impatto. Anche se non saremo mai in grado di evitare del tutto i cambiamenti, possiamo fare di meglio rispetto allo screenshot qui sopra. L'app Font Style Matcher di Monica Dinculescu è spesso citata negli articoli sul caricamento dei caratteri e offre un fantastico assaggio di ciò che dovrebbe essere possibile qui. Ti consente di sovrapporre lo stesso testo in due caratteri diversi per vedere quanto sono diversi e di regolare le impostazioni dei caratteri per allinearli più da vicino:

Sfortunatamente, il problema con la corrispondenza dello stile del carattere è che non possiamo fare in modo che questi stili CSS si applichino solo ai caratteri di fallback, quindi dobbiamo usare JavaScript e l'API FontFace.load per applicare (o ripristinare) queste differenze di stile quando il web caricamenti dei caratteri .

La quantità di codice non è enorme, ma sembra comunque un po' più impegnativo di quanto dovrebbe essere. Sebbene ci siano altri vantaggi e possibilità nell'utilizzo dell'API JavaScript per questo, come spiegato da Zach Leatherman in questo fantastico discorso del lontano 2019, puoi ridurre i reflow e gestire la modalità data-server e prefers-reduced-motion (nota tuttavia che da allora entrambi sono stati esposti ai CSS da quel discorso).

È anche più complicato gestire i caratteri memorizzati nella cache che abbiamo già, per non parlare delle differenze nei vari stili di fallback. Qui su Smashing Magazine, proviamo una serie di fallback per utilizzare al meglio i caratteri di sistema che diversi utenti e sistemi operativi hanno installato:

 font-family: Mija,-apple-system,Arial,BlinkMacSystemFont,roboto slab,droid serif,segoe ui,Ubuntu,Cantarell,Georgia,serif;

Sapere quale font viene utilizzato o avere regolazioni separate per ciascuno e assicurarsi che siano applicati correttamente può diventare rapidamente piuttosto complesso.

Una soluzione migliore sta arrivando

Quindi, questo è un breve aggiornamento su dove stanno le cose fino ad oggi. Tuttavia, c'è del fumo che inizia ad apparire all'orizzonte.

Eccitato per il descrittore CSS "regolazione della dimensione" per i caratteri: riduci i cambiamenti di layout abbinando un carattere di riserva e un carattere Web primario attraverso un fattore di scala per i glifi (percentuale).

Vedi https://t.co/mdRW2BMg6A di @cramforce per una demo (Chrome Canary/FF Nightly con bandiere) pic.twitter.com/hEg1HfUJlT

— Addy Osmani (@addyosmani) 22 maggio 2021

Come accennato in precedenza, il problema principale con l'applicazione delle differenze di stile di fallback consisteva nell'aggiungerle e quindi rimuoverle. E se potessimo dire al browser che queste differenze riguardano solo i caratteri di fallback?

Questo è esattamente ciò che fa un nuovo set di descrittori di caratteri che viene proposto come parte del CSS Fonts Module Level 5. Questi vengono applicati alle dichiarazioni @font-face in cui è definito il singolo carattere.

Simon Hearne ha scritto di questo aggiornamento proposto per la specifica dei descrittori del carattere che include quattro nuovi descrittori: ascent-override , descent-override , line-gap-override e advance-override (poiché eliminati). Puoi giocare con il playground F-mods che Simon ha creato per caricare i tuoi font personalizzati e di riserva, quindi giocare con le sostituzioni per ottenere una corrispondenza perfetta.

Come scrive Simon, la combinazione di questi quattro descrittori ci ha permesso di sovrascrivere il layout del font di fallback in modo che corrisponda al font web, ma in realtà modificano solo la spaziatura verticale e il posizionamento. Quindi, per la spaziatura dei caratteri e delle lettere, dovremo fornire CSS aggiuntivi.

Ma le cose sembrano cambiare ancora una volta. Più di recente, advance-override è stato eliminato a favore del prossimo descrittore size-adjust che ci consente di ridurre i cambiamenti di layout facendo corrispondere un font di fallback e un font Web primario attraverso un fattore di scala per i glifi (percentuale).

Come funziona? Supponiamo che tu abbia il seguente CSS:

 @font-face { font-family: 'Lato'; src: url('/static/fonts/Lato.woff2') format('woff2'); font-weight: 400; } h1 { font-family: Lato, Arial, sans-serif; }

Quindi quello che dovresti fare è creare un @font-face per il carattere di fallback di Arial e applicarvi i descrittori di regolazione. Quindi otterrai il seguente snippet CSS:

 @font-face { font-family: 'Lato'; src: url('/static/fonts/Lato.woff2') format('woff2'); font-weight: 400; } @font-face { font-family: "Lato-fallback"; size-adjust: 97.38%; ascent-override: 99%; src: local("Arial"); } h1 { font-family: Lato, Lato-fallback, sans-serif; }

Ciò significa che quando viene utilizzato inizialmente il Lato-fallback (poiché Arial è un font local e può essere utilizzato immediatamente senza alcun download aggiuntivo), le impostazioni size-adjust e ascent-override ti consentono di avvicinarlo al font Lato. È una dichiarazione @font-face in più da scrivere, ma sicuramente molto più semplice dei cerchi che dovevamo saltare prima!

Complessivamente, ci sono quattro descrittori @font-face principali inclusi in questa specifica: size-adjust , ascent-override , descent-override e line-gap-override con pochi altri ancora presi in considerazione per pedice, apice e altri casi d'uso .

Malte Ubl ha creato uno strumento molto utile per calcolare automaticamente queste impostazioni dati due font e un browser che supporta queste nuove impostazioni (ne parleremo più in un attimo!). Come sottolinea Malte, i computer sono bravi in ​​questo genere di cose! Idealmente, potremmo anche esporre queste impostazioni per i caratteri comuni agli sviluppatori web, ad esempio fornire questi suggerimenti in raccolte di caratteri come Google Fonts? Ciò aiuterebbe sicuramente ad aumentare l'adozione.

Ora diversi sistemi operativi possono avere impostazioni dei caratteri leggermente diverse e ottenerle esattamente nel modo giusto è fondamentalmente un compito impossibile, ma non è questo l'obiettivo. L'obiettivo è colmare il divario utilizzando quindi il font-display: swap non è più un'esperienza così stridente, ma non abbiamo bisogno di andare agli estremi di font web optional o assenti.

Quando possiamo iniziare a usarlo?

Tre di queste impostazioni sono già state fornite in Chrome dalla versione 87 , sebbene il descrittore size-adjust della chiave non sia ancora disponibile in nessun browser stabile. Tuttavia, Chrome Canary ce l'ha, così come Firefox dietro una bandiera, quindi questo non è un concetto astratto e lontano, ma qualcosa che potrebbe atterrare molto presto.

Al momento, le specifiche hanno tutti i tipi di disclaimer e avvertenze che non sono ancora pronte per il tempo reale, ma sembra sicuramente che ci stia arrivando. Come sempre, c'è un equilibrio tra noi, designer e sviluppatori, testandolo e fornendo feedback e scoraggiandone l'uso, quindi l'implementazione non si blocca perché troppe persone finiscono per utilizzare una bozza precedente.

Chrome ha dichiarato la propria intenzione di rendere disponibile size-adjust in Chrome 92 il cui rilascio è previsto per il 20 luglio, presumibilmente indicando che è quasi arrivato.

Quindi, non è ancora pronto, ma sembra che arriverà in un futuro molto prossimo. Nel frattempo, gioca con la demo in Chrome Canary e vedi se può andare un po' più vicino ad affrontare i problemi di caricamento dei caratteri e l'impatto CLS che causano.