's Picture

Webbfonter vs. UX

Postad av Jonas Waldén

DEL 4 – Så byggde vi nya Expressen.se snabbare än någonsin

När Expressen.se skulle byggas om var ett av huvudmålen att bygga en så snabb site som möjligt med fokus på upplevd prestanda. Prestanda är en viktig komponent inom god användarupplevelse. En annan viktig komponent är typografi. För att uppnå god typografi använder vi webbfonter, men de brukar medföra en drös prestandaproblem vilka snarare leder till dålig användarupplevelse. Behöver vi välja mellan prestanda eller typografi?

Innan en webbfont kan användas för rendering behöver dess fontfil laddas in. Under tiden måste webbläsaren använda en annan font i reserv, vanligtvis en som finns i operativsystemet - en systemfont.

I väntan på att filen laddas yttrar sig ett par problem - FOUT och FOIT. Flash of unstyled text, FOUT, innebär att texten visas sin reservfont innan resursen har laddats. Flash of invisible text, FOIT, innebär samma sak men texten också hålls osynlig under tiden.

Ett annat problem uppstår när laddningen av filen är klar och texten renderas om. Utbudet på systemfonter skiljer sig mellan Mac OS, Windows, Android, iOS etc. och det är svårt att hitta en där tecknens storlekar matchar webbfonten. Skillnaden kan göra att en text som först renderas på en rad spiller över på två vid omrendering, eller tvärtom.

I värsta fall drabbas användare av allt i följd. Med en blixtsnabb site vill vi att fonterna renderas direkt och inte först långt efter att användaren redan fått en skärm full av innehåll. Vilken väg tar oss dit?

Modernt och enkelt

Till viss del är lösningen trivial. Med lite javascript anropar vi fontfilen via FontFace API:et. Genom att placera skriptet inline i HTML-head minimerar vi ledtiden till att anropet går iväg. Hård cache på det så är fonten tillgänglig redan vid första rendering. FOIT / FOUT blir obefintlig och reservfont blir inte ett problem.

Även om stödet för FontFace är brett är det tyvärr inte komplett. Bland de moderna webbläsarna saknas det i nuvarande versionen av Edge. Internet Explorer varken har eller kommer få stöd. Av våra läsare använder ca. 9% Edge och IE - inte en försumbar andel.

Bakåtkompatibelt och komplext

Kan vi inte använda JS och FontFace måste vi på något sätt använda CSS och @font-face. Det har funnits ända sedan år 2001 och är förmodligen den vanligast förekommande metoden för att använda och ladda in webbfonter. I och med det är det förmodligen också den vanligast förekommande orsaken till FOIT / FOUT.

Problemet med CSS

Som CSS fungerar laddas bara länkade resurser om de faktiskt används. Det medför att anropet först kommer ske i stunden då resursen kommer till användning dvs. i renderingsfasen, efter HTML / CSS har laddats och lästs. I vårt fall, med webbfont, när renderingen har tagit sig igenom all HTML fram till en textnod vars stilregler använder fonten. Med ledtider minimeras chansen att vi får en komplett första rendering.

Minimera ledtider med JS och data-URL

Istället för att länka in en fontfil kan vi bädda in den direkt i referensen - en data-URL. Detta minskar dramatiskt tiden mellan att CSS läses in och att fonten finns tillgänglig. Då webbläsare har olika preferens gällande format, woff2 / woff / ttf, skapar vi ett CSS-dokument per fil. Vi förlorar webbläsarens automatiska val av filformat så vi får hantera det med javascript istället.

Nu kan vi skicka anropet till fontens CSS-dokument väldigt tidigt. CSS-koden vi får tillbaka stoppas in i ett tomt style-element och vips, vi har font.

Hittills låter nog det här onödigt och komplext men den stora vinsten kommer med sista pusselbiten localStorage - ett lagringsutrymme beständigt mellan sidvisningar och sessioner. I samma vända som vi fyller på vårt tomma style-element kan vi också spara CSS-koden i localStorage. Nästa sidvisning kan vi plocka vår CSS raka vägen därifrån.

Utan problemen som webbfonter medför behöver vi inte byta typografi mot prestanda - webbfonter vs. UX.

PS. Missa inte vår nästa bloggpost, följ oss på Twitter!

Till startsidan