Prestanda vid inläsning av webbtypsnitt (fonter)

Snabba upp din webbplats genom att optimera inläsningen av webbtypsnitt. Förbättra fontprestanda med font-display, preload och subsetting för snabbare typsnitt.

De första sekunderna på en webbplats är det mest kritiska ögonblicket, då besökaren avgör om hen ska stanna kvar eller inte. Under denna korta stund avgör hur snabbt din sida öppnas, när texten blir läsbar och hur stabil den visuella layouten är direkt användarupplevelsen. Och det är precis här en detalj som de flesta förbiser kommer in i bilden: inläsningen av typsnitt. Trots att typsnitten är ett av de viktigaste elementen som bär en modern webbplats varumärkesidentitet, blir de en osynlig belastning som allvarligt drar ner prestandan när de konfigureras fel.

De flesta utvecklare och webbplatsägare fokuserar på att komprimera bilder, minifiera JavaScript-filer och förbättra serverns svarstid. Men hur typsnitten läses in är minst lika avgörande. Ett felaktigt inläst typsnitt kan fördröja att texten visas på skärmen, orsaka störande hopp genom att plötsligt flytta sidans layout, och påverka dina Core Web Vitals-mätvärden negativt. Dessutom kan de flesta av dessa problem lösas till stor del med bara några rader korrekt konfiguration.

I den här guiden går vi igenom webbfontprestanda från början till slut. Vi kommer steg för steg att granska alla praktiska ämnen: från hur webbläsare läser in typsnitt och vilka format som bör föredras, till korrekt användning av egenskapen font-display samt subsetting- och preload-tekniker. Vårt mål är att du både ska bygga upp en gedigen teknisk grund och få en konkret färdplan som du kan tillämpa direkt.

Varför påverkar webbfonter prestandan?

Typsnitt utgör ryggraden i en sidas synliga innehåll. När webbläsaren tolkar ett HTML-dokument får den reda på vilket typsnitt som ska användas via CSS. Om detta typsnitt inte är installerat i systemet måste webbläsaren ladda ner det från en fjärrserver. Trots att denna nedladdningsprocess kan verka liten är den en kritisk fördröjningskälla som kan försena att sidan blir läsbar.

Inläsningen av ett webbtypsnitt är inte en process i ett enda steg. Först laddas CSS-filen ner och tolkas, därefter utvärderas @font-face-reglerna, sedan begärs den aktuella typsnittsfilen och slutligen bearbetas det nedladdade typsnittet av webbläsaren och tillämpas på skärmen. En fördröjning i vilken länk som helst i denna kedja kan leda till att användaren möts av tomma eller felaktigt visade texter.

Vad är FOIT och FOUT?

I typsnittsvärlden finns det två grundläggande beteenden, och de står i centrum för prestandadiskussionerna:

FOIT (Flash of Invisible Text): Blixt av osynlig text. Webbläsaren visar ingen text alls förrän typsnittet har laddats ner. Användaren ser en tom yta och texten dyker upp plötsligt när typsnittet anländer. Detta kan leda till tomma skärmar som varar i flera sekunder vid långsamma anslutningar.
FOUT (Flash of Unstyled Text): Blixt av ostiliserad text. Webbläsaren visar först texten med ett reservtypsnitt som finns i systemet, och ritar sedan om texten med det anpassade typsnittet när det har laddats in. Användaren kan läsa innehållet omedelbart, men en synlig förändring i typsnittet sker.

Vilket som bör föredras beror på din webbplats prioriteringar. Som en allmän regel är innehållets tillgänglighet viktigare än varumärkets konsekvens. Därför är FOUT-metoden, där texten blir läsbar så snabbt som möjligt, i de flesta fall det sundare valet. Att användaren kan läsa innehållet, om än med ett reservtypsnitt, är nästan alltid en bättre upplevelse än att stirra på en tom skärm.

Sambandet med Core Web Vitals

Webbfontprestanda påverkar direkt de Core Web Vitals-mätvärden som sökmotorer använder som rankningsfaktor. Två mätvärden sticker särskilt ut. Det första är Largest Contentful Paint, som mäter när det största synliga innehållet på sidan ritas upp. Om detta innehåll är ett textblock och typsnittsinläsningen är långsam, försämras detta mätvärde. Det andra är Cumulative Layout Shift, som mäter hur stabil sidans layout är. Storleksskillnaderna mellan reservtypsnittet och det anpassade typsnittet leder till layoutförskjutningar när texten ritas om, och det förstör detta mätvärde.

Att förbättra typsnittens hastighet är därför inte bara ett estetiskt val, utan ett tekniskt krav som ger konkreta vinster både för användarupplevelsen och för SEO.

Hur läser webbläsaren in typsnitt?

Innan du bygger en strategi för fontoptimering behöver du förstå vad webbläsaren gör i bakgrunden. Webbläsaren laddar bara ner en typsnittsfil när den faktiskt behövs. Med andra ord laddas ett typsnitt som du definierar i en @font-face-regel inte ner förrän en text som använder det typsnittet faktiskt renderas på sidan. Detta beteende är utformat för att förhindra att oanvända typsnitt laddas ner i onödan och är vanligtvis till nytta.

Men denna mekanism skapar en bieffekt: typsnittsfilen upptäcks först efter att CSS:en har laddats ner och tolkats. Detta gör att typsnittet blir en resurs som upptäcks sent i inläsningskedjan. Eftersom webbläsaren inte i förväg vet att det är ett kritiskt typsnitt laddar den inte ner det med hög prioritet. Det är just för att eliminera denna fördröjning som tekniker som preload finns.

Vi kan grovt dela in inläsningsprocessen i följande steg:

HTML-dokumentet laddas ner och börjar tolkas.
CSS-resurser upptäcks, laddas ner och bearbetas.
@font-face-reglerna utvärderas och de typsnitt som ska användas fastställs.
De aktuella typsnittsfilerna begärs från servern.
Efter att typsnitten har laddats ner tolkas de och tillämpas på texten.

I denna kedja väntar varje steg på att det föregående ska slutföras. Den grundläggande logiken bakom prestandaförbättring är att förkorta denna kedja, parallellisera den eller prioritera kritiska resurser.

Att välja rätt fontformat

Typsnittsfilens format är den första hållplatsen för fontinläsningsprestanda, eftersom det direkt påverkar nedladdningsstorleken. Genom åren har många olika format använts, men idag har det till stor del klarnat vilket format som bör föredras för den moderna webben.

Format	Beskrivning	Webbläsarstöd	Filstorlek
WOFF2	Optimerat för den moderna webben, format som erbjuder bästa komprimeringen	Alla aktuella webbläsare	Minst
WOFF	Standard före WOFF2, fortfarande brett stöd	Inklusive äldre webbläsare	Medel
TTF/OTF	Skrivbordsbaserat, svag komprimering	Brett men ineffektivt	Stort
EOT	Historiskt format endast för mycket gamla versioner	Behövs nästan aldrig	Stort

Idag är WOFF2-formatet den de facto-standard för webben. Tack vare Brotli-baserad komprimering levererar det samma typsnitt i mycket mindre storlek jämfört med andra format. Eftersom alla aktuella webbläsare stöder WOFF2 räcker det att i de flesta moderna projekt enbart erbjuda detta format. Endast i särskilda fall där du måste stödja mycket gamla webbläsare kan du lägga till WOFF-formatet som reserv; formaten TTF, OTF och EOT rekommenderas däremot inte längre för webbleverans.

När du definierar formaten i din @font-face-regel är det viktigt att korrekt förmedla valprioriteten till webbläsaren. Webbläsaren väljer det första format den stöder, så du bör placera det mest effektiva formatet högst upp i listan.

Att styra inläsningsbeteendet med font-display

CSS-egenskapen font-display är ett av de kraftfullaste verktygen för att kontrollera FOIT- och FOUT-beteenden. Denna egenskap bestämmer hur webbläsaren ska hantera texten medan typsnittet laddas ner. Den läggs till inuti @font-face-regeln och kan anta flera olika värden.

font-display-värden

auto: Använder webbläsarens standardbeteende. Detta leder oftast till FOIT och rekommenderas inte.
block: Texten förblir osynlig under en kort blockeringsperiod, och om typsnittet inte anländer byts det till ett reservtypsnitt. Ett medvetet FOIT-val.
swap: Texten visas omedelbart med ett reservtypsnitt och byts direkt ut när det anpassade typsnittet anländer. FOUT-beteende. Det vanligaste valet för innehållsprioriterade webbplatser.
fallback: Byter till ett reservtypsnitt efter en mycket kort blockeringsperiod; om det anpassade typsnittet inte anländer inom en viss tid används det inte under den sessionen. En bra medelväg för dem som söker balans.
optional: Webbläsaren avgör utifrån nätverksförhållandena om det anpassade typsnittet ska användas eller inte. Vid långsamma anslutningar kanske typsnittet inte laddas ner alls. Idealiskt för situationer där prestanda är absolut högsta prioritet.

I praktiken är font-display: swap en rimlig utgångspunkt för de flesta webbplatser, eftersom användaren kan börja läsa innehållet omedelbart. Men när du använder swap måste du vara uppmärksam på layoutförskjutningar som beror på storleksskillnaden mellan reservtypsnittet och det anpassade typsnittet. För projekt som är ytterst känsliga för prestanda är värdet optional det mest aggressiva alternativet för att bevara typsnittens hastighet; det använder typsnittet endast om förhållandena är gynnsamma, utan att alls störa textflödet.

Att prioritera kritiska typsnitt med preload och preconnect

Som vi nämnt tidigare upptäcker webbläsaren typsnitten sent. För att eliminera denna fördröjning kan du använda ledtrådarna preload och preconnect. Dessa två tekniker är bland de mest effektiva och minst arbetskrävande sätten att förbättra webbfontprestandan.

Hur används preload?

preload talar om för webbläsaren att en viss resurs bör laddas ner tidigt och med hög prioritet. Du kan i förväg läsa in ett kritiskt typsnitt som används i sidans synliga område med hjälp av en länkledtråd som du lägger till i HTML:ens <head>-sektion. På så sätt börjar webbläsaren ladda ner typsnittet utan att vänta på att tolka CSS:en.

<link rel="preload" href="/fonts/brodtypsnitt.woff2" as="font" type="font/woff2" crossorigin>

Här är det av avgörande betydelse att lägga till attributet crossorigin. Eftersom typsnitt begärs i anonymt läge laddas den preloadade resursen ner igen utan detta attribut, vilket gör skada i stället för nytta. Dessutom bör du endast preloada de typsnitt som verkligen är kritiska, det vill säga de som används i sidans första vy. Att preloada varje typsnitt slösar bandbredd och försämrar prestandan genom att fördröja inläsningen av andra kritiska resurser.

Att snabba upp tredjepartsanslutningar med preconnect

Om du hämtar dina typsnitt från en annan domän, till exempel från en tjänst för fonthosting, tar det tid för webbläsaren att upprätta en anslutning till den servern. DNS-uppslag, TCP-handskakning och TLS-förhandling är steg som följer på varandra. preconnect ser till att denna anslutning upprättas i förväg och sparar därmed värdefulla millisekunder när typsnittet behöver laddas ner.

<link rel="preconnect" href="https://fonts.exempel-kalla.com" crossorigin>

Om möjligt bör du föredra att leverera typsnitten från din egen server (self-hosting). På så sätt slipper du helt kostnaden för att ansluta till ytterligare en domän och får hela inläsningsprocessen under din egen kontroll.

Subsetting: Läs bara in de tecken du behöver

En typsnittsfil innehåller ofta glyfer för tusentals tecken. När det latinska alfabetet, kyrilliska, grekiska, olika accenttecken och specialsymboler läggs samman växer filstorleken snabbt. Men de flesta webbplatser använder bara en liten del av dessa tecken. Det är här subsetting kommer in i bilden.

Subsetting är processen att skapa en mycket mindre fil genom att välja ut endast de tecken du behöver från typsnittsfilen och ta bort resten. För en svensk webbplats räcker det latinska alfabetet och de svenskspecifika tecknen (å, ä, ö och deras versaler). Det är meningslöst att läsa in en delmängd som innehåller kyrilliska eller kinesiska tecken.

Du kan tillämpa subsetting på följande sätt:

Statisk subsetting: Att med särskilda verktyg i förväg reducera typsnittsfilen till en bestämd teckenuppsättning. Det är den metod som ger mest kontroll.
Dynamisk subsetting med unicode-range: Att använda egenskapen unicode-range i @font-face-regeln för att definiera separata typsnittsfiler för olika teckenintervall. Webbläsaren laddar endast ner den fil som hör till det teckenintervall som faktiskt används på sidan.

@font-face {
  font-family: "Brodtypsnitt";
  src: url("/fonts/brod-latin.woff2") format("woff2");
  unicode-range: U+0000-00FF, U+0131, U+0150-0151, U+015E-015F;
  font-display: swap;
}

Subsetting reducerar ofta typsnittsfilens storlek till hälften, eller till och med mer. Detta innebär direkt snabbare nedladdning och bättre typsnittshastighet. Var bara uppmärksam på en sak: säkerställ att alla tecken som användaren kan tänkas se finns med i delmängden. Ett saknat tecken visas som en tom ruta på skärmen och ger ett dåligt intryck.

Systemtypsnitt och variabla typsnitt (Variable Fonts)

Ibland är det bästa typsnittet det du aldrig laddar ner. Systemtypsnittsstacken (system font stack) använder de typsnitt som redan är installerade på användarens enhet. Med detta tillvägagångssätt laddas inget typsnitt ner, vilket innebär att kostnaden för fontinläsning är noll och att texten renderas omedelbart. I projekt där varumärkesidentiteten inte är beroende av typsnittet och där prestanda är prioriterad är detta ett ytterst effektivt val.

body {
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif;
}

Fördelen med variabla typsnitt

Om du behöver använda ett typsnitt som är specifikt för ditt varumärke och behöver flera olika vikter och stilar av samma familj, är variabla typsnitt (variable fonts) en kraftfull lösning. I det traditionella tillvägagångssättet måste du ladda ner en separat fil för varje vikt (tunn, normal, fet) och varje stil (kursiv, normal). En webbplats som använder fem olika vikter laddar in fem separata typsnittsfiler.

Ett variabelt typsnitt rymmer däremot alla dessa variationer i en enda fil. Du kan från en enda fil producera alla vikter från tunn till fet, och till och med mellanliggande värden. Om du använder flera stilar är en enda variabel typsnittsfil oftast mindre än summan av de separata filerna och laddas in med färre HTTP-förfrågningar. Detta är en viktig vinst både för fontoptimering och för flexibilitet.

Men variabla typsnitt är inte alltid rätt val. Om du bara använder en enda vikt på din webbplats kan den subsettade statiska filen för just den vikten vara mindre än ett variabelt typsnitt som bär alla variationer. Bedöm ärligt hur många olika stilar och vikter du faktiskt använder när du fattar beslutet.

Att förhindra layoutförskjutningar (CLS)

En av de mest irriterande bieffekterna av typsnittsbyte är att sidans layout plötsligt förskjuts. När reservtypsnittet och det anpassade typsnittet har olika storlekar ritas texten om i samma ögonblick som det anpassade typsnittet laddas in, vilket gör att omgivande innehåll flyttar sig. Detta kan leda till att raden användaren håller på att läsa förskjuts nedåt, eller att hen av misstag klickar på en annan länk.

Modern CSS erbjuder egenskaper som låter dig justera reservtypsnitten så att de närmar sig det anpassade typsnittet, för att lösa detta problem. Med egenskaper som size-adjust, ascent-override, descent-override och line-gap-override kan du definiera ett reservtypsnitt och föra dess metriska värden närmare ditt anpassade typsnitt. På så sätt ändras den yta som texten upptar nästan inte alls vid typsnittsbytet, och layoutförskjutningen minimeras.

@font-face {
  font-family: "Brodtypsnitt Reserv";
  src: local("Arial");
  size-adjust: 105%;
  ascent-override: 90%;
  descent-override: 22%;
}

Denna teknik kräver lite finjustering, men när den används tillsammans med font-display: swap får du både en snabb första rendering och en stabil layout. Att kombinera dessa två fördelar är den gyllene balansen för webbfontprestanda.

En praktisk checklista för fontoptimering

Låt oss omvandla alla tekniker vi har beskrivit hittills till en tillämpbar checklista. Du kan följa dessa steg när du startar ett projekt eller granskar en befintlig webbplats:

Format: Använd endast WOFF2; lägg inte till äldre format om det inte verkligen behövs.
Subsetting: Reducera typsnittet till teckenuppsättningen för det språk du använder.
font-display: Använd swap för innehållsprioriterade webbplatser och optional eller fallback för prestandaprioriterade projekt.
preload: Preloada endast de kritiska typsnitt som används i den första vyn, tillsammans med crossorigin.
preconnect: Upprätta en tidig anslutning om du använder en tredjepartskälla för typsnitt; föredra self-hosting om möjligt.
Minska antalet: Begränsa antalet vikter och stilar du verkligen behöver på webbplatsen.
Överväg variabelt typsnitt: Byt till ett variabelt typsnitt om du använder ett stort antal vikter.
CLS: Förhindra layoutförskjutningar genom att föra reservtypsnittets metrik närmare det anpassade typsnittet.
Cachning: Definiera långa cachehuvuden för typsnittsfilerna i webbläsaren.
Mät: Verifiera effekten av dina ändringar med verkliga prestandaverktyg.

Varje punkt på denna lista kan på egen hand verka som en liten vinst, men när de alla läggs samman ger de en slående förbättring av typsnittshastigheten och den allmänna sidprestandan.

Att mäta och övervaka prestandan

Du bör inte gå vidare utan att mäta om varje optimering du gör verkligen fungerar. Att förlita sig på data i stället för gissningar är en oskiljaktig del av fontoptimeringsprocessen. Nätverksfliken i webbläsarnas utvecklarverktyg låter dig se vilka typsnittsfiler som laddas ner när och i vilken storlek. Här kan du enkelt upptäcka oanvända typsnitt, onödigt stora filer och sent upptäckta resurser.

Vid sidan av detta ger automatiska verktyg som erbjuder prestandagranskning specifika varningar relaterade till fontinläsning. De pekar exempelvis på problem som renderingsblockerande resurser, onödiga preload-länkar eller avsaknad av font-display. Via prestandapanelen kan du också sekund för sekund granska när texten visas medan sidan laddas och i vilket ögonblick layoutförskjutningarna inträffar.

Vid sidan av tester i laboratoriemiljö är det viktigt att även övervaka verkliga användardata. Det beror på att den upplevelse en användare har med en snabb anslutning kan vara helt annorlunda än den upplevelse hen har med en långsam mobilanslutning. Genom att testa webbfontprestandan under olika nätverksförhållanden kan du säkerställa att användaren även i värsta fall når innehållet inom rimlig tid.

Vanliga frågor

Bör jag hosta mina webbtypsnitt på min egen server eller använda en tredjepartstjänst?

I de flesta fall ger det bättre prestanda att hosta typsnitten på din egen server (self-hosting). När du använder en tredjepartstjänst måste webbläsaren ansluta till ytterligare en domän, vilket för med sig kostnaden för DNS-uppslag och anslutningsupprättande. Med self-hosting eliminerar du denna kostnad och levererar typsnitten under full kontroll med din egen cachnings- och subsettingstrategi. Det ger också fördelar när det gäller integritet och oberoende. Om du ändå behöver använda en tredjepartskälla bör du absolut upprätta anslutningen i förväg med preconnect.

Bör jag använda font-display: swap eller optional?

Detta beslut beror på din webbplats prioriteringar. Om det är viktigt att det anpassade typsnittet absolut visas för varumärkesidentitetens skull och du vill att innehållet ska vara läsbart omedelbart, är swap rätt val; användaren läser innehållet direkt med ett reservtypsnitt och ett byte sker när det anpassade typsnittet anländer. Om absolut prestanda och noll layoutförskjutning däremot är din prioritet är optional mer lämpligt. Med detta värde kan webbläsaren välja att inte använda typsnittet alls under sessionen om det anländer långsamt, och därmed eliminera layoutförskjutningen helt. För många projekt är swap en balanserad utgångspunkt.

Påverkar det prestandan mycket att använda flera typsnittsfamiljer?

Ja, varje ytterligare typsnittsfamilj och varje viktvariation du använder innebär att en separat fil laddas ner, vilket ökar tiden för fontinläsning och den totala sidstorleken. Det ideala är att hålla sig till en eller två typsnittsfamiljer och endast läsa in de vikter du verkligen använder. Om du behöver många vikter av samma familj kan det vara effektivare att samla dem alla i ett enda variabelt typsnitt i stället för separata filer. Bedöm varje typsnittsbeslut med frågan "behöver den här texten verkligen detta typsnitt?".

Vilka tecken bör jag inkludera när jag gör subsetting?

Det beror på din webbplats språk och innehåll. För en svensk webbplats bör du, utöver de grundläggande latinska tecknen, absolut inkludera de svenskspecifika bokstäverna å, ä, ö och deras versaler. Glöm inte heller de skiljetecken, valutasymboler och specialtecken du använder på webbplatsen. I fall där användarinnehållet (till exempel kommentarer) kan innehålla olika språk kan du överväga en bredare teckenuppsättning eller dynamisk subsetting med unicode-range. Eftersom ett saknat tecken visas som en tom ruta på skärmen måste delmängden fastställas noggrant.

Förbättrar preload alltid prestandan?

Nej, preload kan försämra prestandan om den används felaktigt. Du bör endast preloada de kritiska typsnitt som verkligen används i sidans första synliga område. Att preloada varje typsnitt får webbläsaren att slösa bandbredd på oviktiga resurser och leder till att mer kritiskt innehåll fördröjs. Glöm inte heller att lägga till attributet crossorigin när du preloadar typsnitt; annars laddas typsnittet ner två gånger och gör skada i stället för nytta. Använd preload som ett kirurgiskt verktyg, endast för det eller de mest kritiska typsnitten.

Är det en bra idé att använda systemtypsnitt?

Om prestanda är prioriterad och din varumärkesidentitet inte är hårt knuten till ett visst typsnitt är systemtypsnittsstacken ett utmärkt val. Eftersom systemtypsnitten redan är installerade på användarens enhet laddas ingen fil ner, texten renderas omedelbart och risken för layoutförskjutning försvinner. Detta är det snabbaste tillvägagångssättet, som reducerar kostnaden för fontinläsning helt till noll. Nackdelen är att din webbplats kan se något olika ut på olika operativsystem. Om varumärkets konsekvens inte är kritisk är denna lilla visuella skillnad oftast en acceptabel avvägning.

Slutsats

Hur webbtypsnitt läses in är ett prestandaområde som direkt avgör en webbplats upplevda hastighet och användarupplevelse, men som ändå ofta förbises. Den goda nyheten är att du inte behöver komplicerade infrastrukturändringar för att förbättra fontinläsningsprestandan. Några riktade steg, som att välja rätt format (WOFF2), ta bort onödiga tecken med subsetting, styra inläsningsbeteendet med egenskapen font-display och prioritera kritiska typsnitt med preload, ger slående vinster på de flesta webbplatser.

Kom ihåg att den bästa optimeringen är den som sätter användarens behov i centrum. Ibland är det rätta beslutet att inte läsa in något anpassat typsnitt alls och få omedelbar rendering med systemtypsnitt; ibland är det att samla hela varumärkets flexibilitet i en enda effektiv fil med ett variabelt typsnitt. Oavsett vilket tillvägagångssätt du väljer bör du grunda dina beslut på verkliga prestandamätningar, inte på gissningar.

Genom att ta webbfontprestandan på allvar förbättrar du både dina Core Web Vitals-mätvärden och erbjuder dina besökare en flytande, stabil och läsbar upplevelse vid alla anslutningshastigheter. När du väl har ställt in typsnittshastigheten rätt en gång fortsätter denna vinst att i tysthet bidra till varje besökares upplevelse så länge din webbplats finns. Börja idag med en liten granskning, se över de typsnitt du använder och tillämpa checklistan i den här guiden steg för steg; du kommer att se resultaten både i dina mätvärden och i dina användares nöjdhet.