Slik hoster du skrifter lokalt i stedet for å bruke Google Fonts

Hvorfor selvhoste Google Fonts?

Google Fonts gjorde god typografi enkelt. Legg til et stilark, velg noen vekter, publiser siden. I mange år var det det fornuftige standardvalget for små team.

Avveiningen er at hver besøkendes nettleser kontakter en tredjepartstjeneste for å hente font-CSS og fontfiler. Det har to konsekvenser.

For det første legger det til en ekstern avhengighet i rendringen. Hvis font-CSS-en er treg, blokkert eller utilgjengelig i brukerens region eller nettverk, må siden vente eller falle tilbake til reserveskrifter.

For det andre reiser det et personvernspørsmål. En fontforespørsel kan avsløre brukerens IP-adresse, user agent, kontekst for referrer policy og tidsinformasjon til en tredjepart. Google Fonts opplyser at de ikke setter informasjonskapsler gjennom Fonts API, men «ingen informasjonskapsler» er ikke det samme som «ingen personopplysninger». Under GDPR kan en IP-adresse fortsatt være en personopplysning i kontekst.

Selvhosting av skrifter er ikke automatisk påkrevd for alle nettsteder, og dette er ikke juridisk rådgivning. Men for europeiske nettsteder, offentlige nettsteder, helse, utdanning, finans eller team som prøver å redusere unødvendige tredjepartsforespørsler, er lokal hosting som regel det ryddigere valget.

Det er også ofte en ytelsesgevinst når det gjøres riktig. Haken er «gjøres riktig». Å kopiere seks fontfiler inn i /assets/fonts/ og laste dem alle på hver side kan være verre enn å bruke den hostede tjenesten. Hvis du vil ha den bredere ytelseskonteksten, dekker vår tidligere artikkel om hvorfor webskrifter fortsatt er den enkleste ytelsesgevinsten på de fleste nettsteder de vanlige mønstrene for sløsing.

Hva endrer seg når du selvhoster

Når du bruker Google Fonts på vanlig måte, gjør siden din dette:

<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">

Nettleseren ber først om CSS fra fonts.googleapis.com, og laster deretter ned fontfiler fra fonts.gstatic.com.

Når du selvhoster, bør siden be om både CSS-en og fontfilene fra ditt eget domene:

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

Det fjerner tredjepartsforespørselen for skrifter. Det gjør deg også ansvarlig for å velge filformater, cache-headere, reserveskrifter og oppdateringer.

Det ansvaret er verdt å ta på alvor. Skrifter ligger på den kritiske renderingsstien. Et dårlig fontoppsett kan føre til usynlig tekst, layoutforskyvninger og treg første rendering.

Steg 1: Kartlegg hva du faktisk bruker

Før du laster ned noe, bør du liste opp fontfamiliene, vektene, stilene og tegnsettene nettstedet ditt faktisk trenger.

Et typisk markedsføringsnettsted kan trenge:

• Regular 400 for brødtekst
• Semibold 600 eller bold 700 for overskrifter og knapper
• Italic 400 bare hvis designet faktisk bruker kursiv
• Kun latinsk tegnsett, med mindre nettstedet støtter flere språk

Vær skeptisk til gamle standardvalg fra designsystemer. Mange nettsteder laster 300, 400, 500, 600, 700, kursiver og flere skriftsystemer fordi noen valgte dem én gang i en fontvelger.

I nettleserens DevTools åpner du Network-panelet, filtrerer på «font», laster siden på nytt og sjekker hvilke filer som etterspørres. Deretter inspiserer du CSS-en for bruk av font-weight. Hvis CSS-en din aldri bruker 300, skal du ikke hoste 300.

Hvis du vurderer effekten senere, kan Lighthouse hjelpe, men ikke behandle poengsummen som hele sannheten. Bruk det som et diagnoseverktøy, ikke som en dommer. Vi har en egen veiledning om å lese en Lighthouse-rapport uten å få panikk som er nyttig når du prioriterer fontfikser.

Steg 2: Last ned de riktige fontfilene

Google Fonts tilbyr åpen kildekode-skrifter. Du kan laste dem ned fra Google Fonts-nettstedet eller fra det relevante fontprosjektets repository. Sjekk lisensen, men de fleste Google Fonts distribueres under åpne lisenser som SIL Open Font License eller Apache License.

For web bør du foretrekke WOFF2. Det støttes bredt av moderne nettlesere og er vanligvis mye mindre enn TTF eller OTF. I 2026 er det sjelden berettiget å levere TTF direkte til nettlesere på offentlige nettsteder.

En fornuftig mappestruktur ser slik ut:

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

Bruk beskrivende filnavn. Seks måneder senere vil font.woff2 være irriterende. inter-latin-600.woff2 er kjedelig og nyttig.

Hvis nettstedet ditt bruker et byggsystem, hold kildefontene et tydelig sted og la byggeprosessen kopiere optimaliserte filer inn i mappen for offentlige ressurser.

Steg 3: Lag delmengder av skrifter der det passer

Delmengder betyr å fjerne tegn du ikke trenger. En full font kan inneholde latin, kyrillisk, gresk, vietnamesisk, symboler og mange OpenType-funksjoner. Hvis den engelskspråklige landingssiden din bare trenger latinske tegn, kan en delmengde bli dramatisk mindre.

Det finnes to vanlige tilnærminger:

1. Bruk en ferdiglaget delmengde fra fontleverandøren eller repository-et.
2. Generer din egen delmengde med et fontverktøy som pyftsubset fra fonttools.

For mange team er ferdiglagde latinske delmengder nok. Egendefinerte delmengder er nyttige når du har svært avgrensede sider, for eksempel en enkelt kampanjeside med begrenset tekst, eller et produktgrensesnitt med forutsigbar tegndekning.

Vær forsiktig med flerspråklige nettsteder. Manglende tegn gir blanding av reserveskrifter, noe som kan se ødelagt ut og svekke lesbarheten. Hvis du støtter flere språk, bør du mappe fontdelmengder til språkruter i stedet for å tvinge én liten delmengde overalt.

Steg 4: Skriv @font-face-reglene dine

Et minimalt lokalt oppsett ser slik ut:

@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;
}

Noen detaljer er viktige her.

Bruk font-display: swap for de fleste innholdsnettsteder. Det forteller nettleseren at den skal vise reservetekst raskt, og deretter bytte inn webskriften når den kommer. Det unngår den verste varianten av FOIT: flash of invisible text.

Sett en eksplisitt fallback stack. Hvis den egendefinerte skriften feiler, bør brukerne fortsatt få lesbar tekst. Reserveskrifter er ikke en ettertanke; de er en del av designet. Hvis du må vurdere størrelser, linjelengde og valg for brødtekst på nytt, start med en praktisk veiledning til lesbar typografi på det moderne nettet.

Match vekter riktig. Hvis CSS-en din ber om font-weight: 500, men du bare definerer 400 og 700, kan nettleseren syntetisere en mellomliggende vekt. Det er ikke alltid forferdelig, men det kan se inkonsekvent ut.

Steg 5: Fjern de eksterne Google Fonts-kallene

Etter at du har lagt til lokal font-CSS, fjerner du de gamle eksterne kallene fra malene dine.

Se etter:

<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">

Sjekk også:

• Temainnstillinger i CMS-plattformer
• Typografipaneler i sidebyggere
• Tredjeparts-widgets
• Tag managers
• Gamle CSS-importer som @import url('https://fonts.googleapis.com/...')

Den siste er vanlig. CSS @import for skrifter er vanligvis dårligere for ytelsen fordi det forsinker oppdagelsen. Hvis du selvhoster, definer skrifter direkte i hoved-CSS-en eller i en font-CSS-fil som lastes tidlig.

Personvernarbeid feiler ofte fordi team fikser den åpenbare malen, men overser skript, widgets og gamle embeds. Det samme mønsteret dukker opp i samtykkearbeid; veiledningen vår til hva som endret seg for informasjonskapsler i 2026 er en nyttig følgesvenn hvis du reduserer tredjepartsflaten mer generelt.

Steg 6: Sett cache-headere

Fontfiler er statiske ressurser. De bør caches aggressivt hvis filnavnene er versjonerte eller innholdshashede.

En god produksjonsheader er:

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

Bruk bare langvarig immutable-caching hvis URL-en endres når filen endres. For eksempel:

inter-latin-400.a8f3c2.woff2

eller en versjonert sti:

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

Hvis du overskriver /fonts/inter-latin-400.woff2 uten å endre URL-en, kan noen brukere beholde den gamle filen lenge. Det er greit helt til det ikke er det. Versjonering unngår problemet.

Lever også skrifter med riktig MIME-type:

Content-Type: font/woff2

De fleste moderne hostingplattformer håndterer dette automatisk, men det er verdt å verifisere.

Steg 7: Vurder å preloade bare den kritiske skriften

Preloading kan hjelpe nettleseren å oppdage en viktig font tidligere:

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

Bruk dette med måte. Preload den primære tekstfonten over folden, ikke hver fontvekt. For mye preloading konkurrerer med CSS, bilder og JavaScript.

Selv for same-origin-skrifter bør du inkludere crossorigin på font-preloads. Fontinnhenting bruker CORS-modus, og hvis du utelater det, kan det føre til doble nedlastinger i noen oppsett.

Hvis du er usikker, test. Ikke cargo-cult preloads fordi en sjekkliste sa det.

Steg 8: Test personvern og ytelse

Testing er rett frem.

Åpne DevTools, last siden på nytt med cache deaktivert, og filtrer Network-panelet etter:

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

Du bør se fontfiler levert fra ditt eget domene og ingen Google Fonts-forespørsler.

Test deretter med kald cache og varm cache. Ved første besøk bør skrifter lastes ned én gang. Ved senere besøk bør de komme fra minne- eller diskcache, avhengig av nettleseren.

Se etter layoutforskyvning når skriften byttes inn. Hvis overskrifter hopper, er metrikkene til reserveskriften for ulike fra webskriften. Du kan redusere den synlige forskyvningen ved å velge en nærmere reserve eller bruke nyere CSS-overstyringer for fontmetrikker, som size-adjust, ascent-override, descent-override og line-gap-override. Dette er mer avansert, men nyttig for polerte grensesnitt.

Til slutt bør du teste sider i privat nettlesing eller med innholdsblokkere aktivert. En fordel med selvhosting er at personvernverktøy er mindre tilbøyelige til å blokkere typografien din ved et uhell.

Vanlige feil å unngå

Å hoste for mange vekter

Dette er den vanligste feilen. To vekter er ofte nok. Tre er vanligvis rikelig. Fem lukter designsystem, med mindre du har en sterk grunn.

Å glemme kursiv

Hvis innholdet ditt bruker ekte utheving, last en ekte kursivfil. Syntetisk kursiv kan se dårlig ut, særlig i redaksjonelt langt innhold.

Å beholde den gamle Google CSS-lenken

Det undergraver hele poenget. Etter migreringen skal ingen fontforespørsel gå til Google med mindre en annen komponent injiserer den.

Å levere skrifter uten langtids-caching

Selvhosting gir deg kontroll. Bruk den. Skrifter er ideelle kandidater for lange cache-levetider.

Å ignorere juridisk arbeid og dokumentasjon

Hvis personvernerklæringen din tidligere nevnte Google Fonts eller tredjeparts fontlasting, oppdater den etter migreringen. Hvis du vedlikeholder en oversikt over databehandling, oppdater den også. Den tekniske endringen og etterlevelsesdokumentasjonen bør stemme overens.

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

💡 Prøv dette: Konverter TTF-filene du lastet ned fra Google Fonts, til WOFF2 som kan hostes selv, pluss CSS med Webfont Generator.

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

En enkel migreringssjekkliste

1. List opp fontfamiliene, vektene, stilene og skriftsystemene du faktisk bruker.
2. Last ned WOFF2-filer og bekreft lisensen.
3. Lag delmengder av skrifter hvis nettstedet har begrensede språkbehov.
4. Legg til lokale @font-face-regler med font-display: swap.
5. Fjern alle Google Fonts-referanser til link, preconnect og @import.
6. Lever skrifter fra ditt eget domene med langlivede cache-headere.
7. Preload bare den viktigste skriften over folden, hvis testing støtter det.
8. Verifiser i DevTools at ingen Google Fonts-forespørsler gjenstår.
9. Oppdater personverndokumentasjonen ved behov.

Selvhosting av skrifter er ikke glamorøst arbeid. Det er den typen liten infrastrukturrydding som reduserer avhengighetsrisiko, styrker personvernet og gir deg mer forutsigbar rendering. Det er som regel verdt timen eller to det tar.