Webfonts zijn nog altijd de makkelijkste prestatiewinst op de meeste sites

Het patroon dat blijft terugkomen

Als je vandaag tien willekeurige productiewebsites auditt, zie je op de meeste ervan ongeveer dezelfde fontsituatie:

• Zes tot tien fontbestanden geladen op de homepage
• Allemaal in WOFF2 (goed), maar zonder font-display-strategie (slecht)
• Meerdere gewichten en stijlen die nergens op de pagina worden gebruikt
• De hele stack wordt geleverd vanaf een domein van een derde partij (meestal Google Fonts), met alle DNS-, TLS- en privacykosten die daarbij horen
• Geen subsetting met unicode-range, waardoor elke bezoeker de Cyrillische en Griekse glyphs downloadt, zelfs als de pagina in het Engels is

Dit is geen probleem dat alleen bij kleine sites voorkomt. Veel goed gefinancierde marketingpagina’s laden nog steeds 600 KB aan fonts voordat de eerste alinea zichtbaar kan worden gerenderd. Als je het patroon eenmaal ziet, kun je het niet meer niet zien.

De oplossing is niet exotisch. Het is een handvol goed begrepen technieken die al jaren in browsers zitten.

Gebruik één variabel font in plaats van zes statische

Als je Inter Regular, Inter Medium, Inter SemiBold, Inter Bold en hun cursieven laadt, download je grofweg zes keer meer bytes dan nodig. Eén enkel variabel Inter-font dekt de volledige gewichtas (en in sommige builds ook slant) in één bestand dat nauwelijks groter is dan twee statische gewichten.

De browserondersteuning is al jaren geen discussie meer — variabele fonts werken overal waar het ertoe doet. De resterende aarzeling is vooral aangeleerd spiergeheugen uit het tijdperk van statische fonts.

Een praktische vuistregel: één variabel fontbestand per schrift, per familie. Latijn in één bestand, Cyrillisch in een ander, Grieks in een derde, voorwaardelijk geladen met unicode-range. Dat is alles.

Stel een verstandige font-display in

Het standaardgedrag wanneer een custom font nog laadt, is om niets te tonen — onzichtbare tekst — tot maximaal drie seconden. Dit is de slechtst mogelijke standaard. Gebruikers zien een lege pagina en nemen aan dat er iets stuk is.

Voeg dit toe aan elke @font-face-regel:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2-variations');
  font-weight: 100 900;
  font-display: swap;
}

swap toont het fallback-font onmiddellijk en wisselt naar het custom font zodra dat is geladen. De gebruiker kan de pagina lezen vanaf milliseconde nul. De afweging is een korte layoutverschuiving wanneer de swap gebeurt; die beperk je met de volgende techniek.

Stem je fallback-metrics af

Een flits van ongestileerde tekst voelt alleen storend wanneer het fallback-font en het custom font heel verschillende metrics hebben. Moderne CSS lost dit op met size-adjust, ascent-override en verwante eigenschappen:

@font-face {
  font-family: 'Inter Fallback';
  src: local('Arial');
  size-adjust: 107%;
  ascent-override: 90%;
  descent-override: 22%;
  line-gap-override: 0%;
}

Met goed afgestemde fallback-metrics is de swap nauwelijks waarneembaar — woorden nemen vóór en na het laden van het custom font dezelfde horizontale ruimte in.

Het werk van Google rond --allow-fallback-font-metrics valt nu onder basisondersteuning in browsers, en er is een toolingpipeline (de fontaine-library en vergelijkbare tools) die de juiste waarden binnen enkele seconden voor je berekent.

Host zelf

Google Fonts is handig en gratis, maar brengt twee echte kosten met zich mee:

1. Een tweede TLS-handshake. Zelfs met HTTP/3 en connection coalescing is een extra origin zelden gratis.
2. Een privacy- en compliancevraag. Meerdere Europese rechtbanken hebben geoordeeld dat het laden van Google Fonts vanaf fonts.gstatic.com neerkomt op het doorgeven van persoonsgegevens (het IP-adres) aan een derde partij. Zelf hosten haalt die vraag volledig weg.

De download-en-host-pipeline is:

1. Haal het WOFF2-bestand op (de variabele build als die bestaat)
2. Subset het naar de schriften die je publiek daadwerkelijk gebruikt
3. Serveer het vanaf dezelfde origin als de rest van je site, met een lange Cache-Control: max-age=31536000, immutable
4. Preload het meest kritieke gewicht: <link rel="preload" as="font" type="font/woff2" href="/fonts/inter-var.woff2" crossorigin>

Dat is de hele pipeline. Voor een bestaande site kost het een middag, en je gaat bijna nooit terug.

Wanneer je custom fonts helemaal kunt overslaan

Het is de moeite waard om hardop te zeggen: niet elke site heeft een custom font nodig. De systeemfontstack is inmiddels op elk besturingssysteem echt fraai:

font-family: system-ui, -apple-system, 'Segoe UI', Roboto, Inter, sans-serif;

Het gewicht klopt, de metrics kloppen, de rendering is afgestemd op het apparaat, en de kosten in bytes over de lijn zijn precies nul. Voor een toolsite, een interne app, een portfolio dat content voorrang geeft, of alles wat bedoeld is voor gebruikers op trage netwerken, is de systeemstack het juiste antwoord.

<!-- tool-cta:start -->

💡 Probeer dit: Converteer je TTF- of OTF-bestanden naar moderne WOFF2 met gebruiksklare CSS met behulp van Webfont Generator, wat de formaatwissel is die het bericht aanbeveelt.

<!-- tool-cta:end -->

De eerlijke samenvatting

Voor een typische kleine site dekken vier stappen het hele webfont-prestatieverhaal:

1. Eén variabel font per familie per schrift
2. font-display: swap met afgestemde fallback-metrics
3. Zelf gehost met lange cacheheaders en een preload voor het kritieke gewicht
4. Of sla fonts helemaal over en gebruik de systeemstack

Doe dit één keer en je wint enkele honderden kilobytes terug op de homepage, pakt een paar honderd milliseconden aan ervaren prestaties, en verwijdert onderweg een afhankelijkheid van een derde partij. Weinig wijzigingen hebben een betere verhouding tussen inspanning en opbrengst.