Hoe je lettertypen lokaal host in plaats van Google Fonts te gebruiken

Waarom Google Fonts zelf hosten?

Google Fonts maakte goede typografie eenvoudig. Voeg een stylesheet toe, kies een paar gewichten en publiceer de pagina. Jarenlang was dat de logische standaard voor kleine teams.

De keerzijde is dat de browser van elke bezoeker contact maakt met een dienst van een derde partij om font-CSS en fontbestanden op te halen. Dat heeft twee gevolgen.

Ten eerste voegt het een externe afhankelijkheid toe aan de rendering. Als de font-CSS traag is, wordt geblokkeerd of niet beschikbaar is in de regio of het netwerk van een gebruiker, wacht je pagina of valt die terug op een alternatief.

Ten tweede roept het een privacyvraag op. Een fontverzoek kan het IP-adres van de gebruiker, de user agent, de context van het referrerbeleid en timinginformatie aan een derde partij onthullen. Google Fonts stelt dat het via de Fonts API geen cookies plaatst, maar “geen cookies” is niet hetzelfde als “geen persoonsgegevens.” Onder de AVG kan een IP-adres in context nog steeds een persoonsgegeven zijn.

Lettertypen zelf hosten is niet automatisch verplicht voor elke website, en dit is geen juridisch advies. Maar voor Europese sites, websites in de publieke sector, zorg, onderwijs, finance of elk team dat onnodige verzoeken aan derden wil verminderen, is lokaal hosten meestal de schonere keuze.

Het is ook vaak een prestatieverbetering, mits goed gedaan. De kanttekening is “goed gedaan.” Zes fontbestanden naar /assets/fonts/ kopiëren en ze op elke pagina allemaal laden kan slechter zijn dan de gehoste dienst gebruiken. Als je de bredere prestatiecontext wilt, behandelt ons eerdere stuk over waarom webfonts nog steeds de eenvoudigste prestatiewinst zijn op de meeste sites de veelvoorkomende verspilling.

Wat verandert er wanneer je zelf host

Wanneer je Google Fonts op de gebruikelijke manier gebruikt, doet je pagina dit:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&display=swap" rel="stylesheet">

De browser vraagt eerst CSS op bij fonts.googleapis.com en downloadt daarna fontbestanden van fonts.gstatic.com.

Wanneer je zelf host, moet je pagina zowel de CSS als de fontbestanden vanaf je eigen domein opvragen:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

Dat verwijdert het fontverzoek aan een derde partij. Het maakt jou ook verantwoordelijk voor het kiezen van bestandsformaten, cacheheaders, fallback-lettertypen en updates.

Die verantwoordelijkheid verdient serieuze aandacht. Lettertypen liggen op het kritieke renderingpad. Een slechte fontconfiguratie kan onzichtbare tekst, layout shifts en een trage eerste render veroorzaken.

Stap 1: Controleer wat je daadwerkelijk gebruikt

Maak, voordat je iets downloadt, een lijst van de fontfamilies, gewichten, stijlen en tekensets die je site echt nodig heeft.

Een typische marketingsite heeft misschien nodig:

• Regular 400 voor lopende tekst
• Semibold 600 of bold 700 voor koppen en knoppen
• Italic 400 alleen als het ontwerp daadwerkelijk cursief gebruikt
• Alleen de Latijnse tekenset, tenzij de site meer talen ondersteunt

Wees kritisch op oude standaardinstellingen uit designsystemen. Veel sites laden 300, 400, 500, 600, 700, cursieve varianten en meerdere scripts omdat iemand ze ooit in een fontkiezer heeft geselecteerd.

Open in browser DevTools het Network-paneel, filter op “font,” laad de pagina opnieuw en controleer welke bestanden worden opgevraagd. Inspecteer daarna je CSS op gebruik van font-weight. Als je CSS nooit 300 gebruikt, host dan geen 300.

Als je later de impact beoordeelt, kan Lighthouse helpen, maar behandel de score niet als het hele verhaal. Gebruik het als diagnosehulpmiddel, niet als rechter. We hebben een aparte gids over een Lighthouse-rapport lezen zonder in paniek te raken die nuttig is bij het prioriteren van fontverbeteringen.

Stap 2: Download de juiste fontbestanden

Google Fonts biedt open-source lettertypen. Je kunt ze downloaden vanaf de Google Fonts-website of vanuit de relevante repository van het fontproject. Controleer de licentie, maar de meeste Google Fonts worden verspreid onder open licenties zoals de SIL Open Font License of Apache License.

Geef voor het web de voorkeur aan WOFF2. Het wordt breed ondersteund door moderne browsers en is meestal veel kleiner dan TTF of OTF. In 2026 is het rechtstreeks aanbieden van TTF aan browsers zelden te rechtvaardigen voor publieke websites.

Een verstandige mappenstructuur ziet er zo uit:

/public
  /fonts
    inter-latin-400.woff2
    inter-latin-600.woff2
    inter-latin-700.woff2

Gebruik beschrijvende bestandsnamen. Zes maanden later is font.woff2 irritant. inter-latin-600.woff2 is saai en nuttig.

Als je site een buildsysteem gebruikt, bewaar de bronfonts dan op een duidelijke plek en laat de buildpipeline geoptimaliseerde bestanden naar de map met publieke assets kopiëren.

Stap 3: Pas subsetting toe waar dat zinvol is

Subsetting betekent dat je tekens verwijdert die je niet nodig hebt. Een volledig lettertype kan Latijn, Cyrillisch, Grieks, Vietnamees, symbolen en veel OpenType-functies bevatten. Als je Engelstalige landingspagina alleen Latijnse tekens nodig heeft, kan een subset dramatisch kleiner zijn.

Er zijn twee gangbare benaderingen:

1. Gebruik een vooraf gemaakte subset van de fontprovider of repository.
2. Genereer je eigen subset met een fonttool zoals pyftsubset uit fonttools.

Voor veel teams zijn vooraf gemaakte Latijnse subsets genoeg. Aangepaste subsetting is nuttig wanneer je zeer afgebakende pagina’s hebt, zoals één campagnepagina met beperkte tekst, of een productinterface met voorspelbare tekendekking.

Wees voorzichtig met meertalige sites. Ontbrekende glyphs veroorzaken een mix van fallback-lettertypen, wat er kapot uit kan zien en de leesbaarheid kan schaden. Als je meerdere talen ondersteunt, koppel fontsubsets dan aan taalroutes in plaats van overal één piepkleine subset af te dwingen.

Stap 4: Schrijf je @font-face-regels

Een minimale lokale setup ziet er zo uit:

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-400.woff2") format("woff2");
  font-weight: 400;
  font-style: normal;
  font-display: swap;
}

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter-latin-600.woff2") format("woff2");
  font-weight: 600;
  font-style: normal;
  font-display: swap;
}

body {
  font-family: "Inter", system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
}

Een paar details zijn hier belangrijk.

Gebruik font-display: swap voor de meeste contentsites. Daarmee vertel je de browser om fallback-tekst snel te tonen en daarna het webfont in te wisselen zodra het arriveert. Dat voorkomt de ergste vorm van FOIT: flash of invisible text.

Stel een expliciete fallback-stack in. Als het aangepaste font faalt, moeten gebruikers nog steeds leesbare tekst krijgen. Fallbacks zijn geen bijzaak; ze maken deel uit van het ontwerp. Als je opnieuw naar grootte, regellengte en keuzes voor lopende tekst moet kijken, begin dan met een praktische gids voor leesbare typografie op het moderne web.

Laat gewichten correct overeenkomen. Als je CSS om font-weight: 500 vraagt maar je alleen 400 en 700 definieert, kan de browser een tussenliggend gewicht synthetiseren. Dat is niet altijd rampzalig, maar het kan inconsistent ogen.

Stap 5: Verwijder de externe Google Fonts-aanroepen

Verwijder na het toevoegen van lokale font-CSS de oude externe aanroepen uit je templates.

Zoek naar:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?..." rel="stylesheet">

Controleer ook:

• Thema-instellingen in CMS-platformen
• Typografiepanelen in page builders
• Widgets van derden
• Tagmanagers
• Oude CSS-imports zoals @import url('https://fonts.googleapis.com/...')

Die laatste komt vaak voor. CSS @import voor fonts is meestal slechter voor de prestaties omdat ontdekking wordt vertraagd. Als je zelf host, definieer fonts dan direct in je hoofd-CSS of in een font-CSS-bestand dat vroeg wordt geladen.

Privacywerk mislukt vaak omdat teams de voor de hand liggende template oplossen, maar scripts, widgets en legacy embeds missen. Datzelfde patroon zie je bij consentwerk; onze gids over wat er in 2026 voor cookies veranderde is een nuttige aanvulling als je het oppervlak van derden breder wilt verkleinen.

Stap 6: Stel cacheheaders in

Fontbestanden zijn statische assets. Ze moeten agressief worden gecachet als hun bestandsnamen geversioneerd zijn of een contenthash bevatten.

Een goede productieheader is:

Cache-Control: public, max-age=31536000, immutable

Gebruik langlevende immutable caching alleen als de URL verandert wanneer het bestand verandert. Bijvoorbeeld:

inter-latin-400.a8f3c2.woff2

of een geversioneerd pad:

/fonts/v2/inter-latin-400.woff2

Als je /fonts/inter-latin-400.woff2 overschrijft zonder de URL te wijzigen, kunnen sommige gebruikers het oude bestand lang behouden. Dat is prima totdat het dat niet meer is. Versionering voorkomt het probleem.

Bied fonts ook aan met het juiste MIME-type:

Content-Type: font/woff2

De meeste moderne hostingplatformen handelen dit automatisch af, maar het is de moeite waard om te verifiëren.

Stap 7: Overweeg alleen het kritieke font te preloaden

Preloading kan de browser helpen een belangrijk font eerder te ontdekken:

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin>

Gebruik dit spaarzaam. Preload het primaire tekstfont boven de vouw, niet elk fontgewicht. Te veel preloaden concurreert met CSS, afbeeldingen en JavaScript.

Neem ook voor same-origin fonts crossorigin op bij fontpreloads. Fonts ophalen gebruikt CORS-modus, en het weglaten ervan kan in sommige setups dubbele downloads veroorzaken.

Als je twijfelt, test. Neem preloads niet klakkeloos over omdat een checklist dat zegt.

Stap 8: Test privacy en prestaties

Testen is eenvoudig.

Open DevTools, laad de pagina opnieuw met de cache uitgeschakeld en filter het Network-paneel op:

• fonts.googleapis.com
• fonts.gstatic.com
• .woff2
• font

Je zou fontbestanden moeten zien die vanaf je eigen domein worden aangeboden, en geen Google Fonts-verzoeken.

Test daarna met een koude cache en een warme cache. Bij het eerste bezoek moeten fonts één keer downloaden. Bij latere bezoeken moeten ze uit de geheugen- of schijfcache komen, afhankelijk van de browser.

Controleer op layout shift wanneer het font wordt ingewisseld. Als koppen verspringen, wijken de metrics van je fallback-font te veel af van die van het webfont. Je kunt de zichtbare verschuiving verminderen door een dichterbij liggend fallback-font te kiezen of nieuwere CSS-overrides voor fontmetrics te gebruiken, zoals size-adjust, ascent-override, descent-override en line-gap-override. Die zijn geavanceerder, maar nuttig voor verzorgde interfaces.

Test pagina’s tot slot in privévensters of met content blockers ingeschakeld. Een voordeel van zelf hosten is dat privacytools minder snel per ongeluk je typografie blokkeren.

Veelgemaakte fouten om te vermijden

Te veel gewichten hosten

Dit is de meest voorkomende fout. Twee gewichten zijn vaak genoeg. Drie is meestal ruim voldoende. Vijf is een designsystem-geurtje, tenzij je een sterke reden hebt.

Cursief vergeten

Als je content echte nadruk gebruikt, laad dan een echt cursief bestand. Synthetisch cursief kan er slecht uitzien, vooral in lange redactionele content.

De oude Google CSS-link behouden

Dat ondermijnt het doel. Na de migratie mag geen enkel fontverzoek naar Google gaan, tenzij een ander component het injecteert.

Fonts aanbieden zonder langetermijncaching

Zelf hosten geeft je controle. Gebruik die. Fonts zijn ideale kandidaten voor lange cachelevensduren.

Juridisch en documentatiewerk negeren

Als je privacybeleid eerder Google Fonts of het laden van fonts van derden noemde, werk het dan bij na de migratie. Als je een register van gegevensverwerkingen bijhoudt, werk dat ook bij. De technische wijziging en de compliance-administratie moeten overeenkomen.

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

💡 Probeer dit: Zet de TTF-bestanden die je van Google Fonts hebt gedownload om naar zelf te hosten WOFF2 plus CSS met Webfont Generator.

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

Een eenvoudige migratiechecklist

1. Maak een lijst van de fontfamilies, gewichten, stijlen en scripts die je daadwerkelijk gebruikt.
2. Download WOFF2-bestanden en bevestig de licentie.
3. Pas subsetting toe als de site beperkte taalbehoeften heeft.
4. Voeg lokale @font-face-regels toe met font-display: swap.
5. Verwijder alle Google Fonts-verwijzingen via link, preconnect en @import.
6. Bied fonts vanaf je eigen domein aan met langlevende cacheheaders.
7. Preload alleen het belangrijkste font boven de vouw, als tests dat ondersteunen.
8. Verifieer in DevTools dat er geen Google Fonts-verzoeken overblijven.
9. Werk privacydocumentatie bij indien nodig.

Lettertypen zelf hosten is geen glamoureus werk. Het is het soort kleine infrastructuuropschoning dat afhankelijkheidsrisico vermindert, je privacypositie verbetert en je meer voorspelbare rendering geeft. Dat is meestal het uur of de twee die het kost waard.