Sådan hoster du skrifttyper lokalt i stedet for at bruge Google Fonts

Hvorfor self-hoste Google Fonts?

Google Fonts gjorde god typografi nemt. Tilføj et stylesheet, vælg nogle få vægte, udgiv siden. I årevis var det det fornuftige standardvalg for små teams.

Afvejningen er, at hver besøgendes browser kontakter en tredjepartstjeneste for at hente font-CSS og fontfiler. Det har to konsekvenser.

For det første tilføjer det en ekstern afhængighed til rendering. Hvis font-CSS er langsom, blokeret eller utilgængelig i en brugers region eller netværk, venter din side eller falder tilbage til en fallback.

For det andet rejser det et privatlivsspørgsmål. En fontforespørgsel kan afsløre brugerens IP-adresse, user agent, kontekst for referrer-politik og timingoplysninger til en tredjepart. Google Fonts angiver, at det ikke sætter cookies via Fonts API, men “ingen cookies” er ikke det samme som “ingen personoplysninger.” Under GDPR kan en IP-adresse stadig være en personoplysning i den rette kontekst.

Self-hosting af skrifttyper er ikke automatisk påkrævet for alle websites, og dette er ikke juridisk rådgivning. Men for europæiske sites, sites i den offentlige sektor, sundhed, uddannelse, finans eller ethvert team, der forsøger at reducere unødvendige tredjepartsforespørgsler, er lokal hosting som regel det renere valg.

Det er også ofte en performancegevinst, når det gøres ordentligt. Fangsten ligger i “ordentligt.” At kopiere seks fontfiler ind i /assets/fonts/ og indlæse dem alle på hver side kan være værre end at bruge den hostede tjeneste. Hvis du vil have den bredere performancekontekst, gennemgår vores tidligere artikel om hvorfor web fonts are still the easiest performance win on most sites de almindelige spildmønstre.

Hvad ændrer sig, når du self-hoster

Når du bruger Google Fonts på den sædvanlige måde, gør din side 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">

Browseren anmoder først om CSS fra fonts.googleapis.com og downloader derefter fontfiler fra fonts.gstatic.com.

Når du self-hoster, bør din side anmode om både CSS og fontfiler fra dit eget domæne:

@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ørgslen efter skrifttyper. Det gør dig også ansvarlig for at vælge filformater, cache-headere, fallback-skrifttyper og opdateringer.

Det ansvar er værd at tage alvorligt. Skrifttyper ligger på den kritiske renderingssti. En dårlig fontopsætning kan give usynlig tekst, layout shifts og langsom første rendering.

Trin 1: Auditér, hvad du faktisk bruger

Før du downloader noget, så lav en liste over de fontfamilier, vægte, stilarter og tegnsæt, dit site reelt har brug for.

Et typisk marketingsite kan have brug for:

• Regular 400 til brødtekst
• Semibold 600 eller bold 700 til overskrifter og knapper
• Italic 400 kun hvis designet faktisk bruger kursiv
• Kun latinsk tegnsæt, medmindre sitet understøtter flere sprog

Vær skeptisk over for gamle standarder i designsystemet. Mange sites indlæser 300, 400, 500, 600, 700, kursiv og flere scripts, fordi nogen engang valgte dem i en fontvælger.

Åbn Network-panelet i browserens DevTools, filtrér efter “font,” genindlæs siden, og tjek hvilke filer der anmodes om. Gennemgå derefter din CSS for brug af font-weight. Hvis din CSS aldrig bruger 300, skal du ikke hoste 300.

Hvis du senere gennemgår effekten, kan Lighthouse hjælpe, men behandl ikke scoren som hele historien. Brug det som et diagnostisk værktøj, ikke som en dommer. Vi har en separat guide til at læse en Lighthouse-rapport uden panik, som er nyttig, når du prioriterer fontrettelser.

Trin 2: Download de rigtige fontfiler

Google Fonts tilbyder open source-skrifttyper. Du kan downloade dem fra Google Fonts-websitet eller fra det relevante fontprojekts repository. Tjek licensen, men de fleste Google Fonts distribueres under åbne licenser som SIL Open Font License eller Apache License.

Til web bør du foretrække WOFF2. Det understøttes bredt af moderne browsere og er som regel meget mindre end TTF eller OTF. I 2026 er det sjældent berettiget at servere TTF direkte til browsere på offentlige websites.

En fornuftig mappestruktur ser sådan ud:

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

Brug beskrivende filnavne. Seks måneder senere vil font.woff2 være irriterende. inter-latin-600.woff2 er kedeligt og nyttigt.

Hvis dit site bruger et buildsystem, så opbevar kildefilerne et tydeligt sted, og lad build-pipelinen kopiere optimerede filer til mappen med offentlige assets.

Trin 3: Subset skrifttyper, hvor det giver mening

Subsetting betyder at fjerne tegn, du ikke har brug for. En fuld skrifttype kan indeholde latin, kyrillisk, græsk, vietnamesisk, symboler og mange OpenType-funktioner. Hvis din engelsksprogede landing page kun har brug for latinske tegn, kan et subset være dramatisk mindre.

Der er to almindelige tilgange:

1. Brug et forudbygget subset fra fontudbyderen eller repositoryet.
2. Generér dit eget subset med et fontværktøj som pyftsubset fra fonttools.

For mange teams er forudbyggede latinske subsets nok. Custom subsetting er nyttigt, når du har meget afgrænsede sider, såsom en enkelt kampagneside med begrænset tekst eller et produkt-UI med forudsigelig tegndækning.

Vær forsigtig med flersprogede sites. Manglende glyffer giver blanding af fallback-skrifttyper, hvilket kan se ødelagt ud og skade læsbarheden. Hvis du understøtter flere sprog, så map fontsubsets til sprogruter i stedet for at tvinge ét lille subset igennem overalt.

Trin 4: Skriv dine @font-face-regler

En minimal lokal opsætning ser sådan ud:

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

Nogle få detaljer betyder noget her.

Brug font-display: swap til de fleste indholdssites. Det fortæller browseren, at den hurtigt skal vise fallback-tekst og derefter skifte til webfonten, når den ankommer. Det undgår den værste version af FOIT: flash of invisible text.

Angiv en eksplicit fallback-stack. Hvis den tilpassede skrifttype fejler, skal brugerne stadig få læsbar tekst. Fallbacks er ikke en eftertanke; de er en del af designet. Hvis du har brug for at genoverveje størrelser, linjelængde og valg af brødtekst, så start med en praktisk guide til læsbar typografi på det moderne web.

Match vægte korrekt. Hvis din CSS beder om font-weight: 500, men du kun definerer 400 og 700, kan browseren syntetisere en mellemliggende vægt. Det er ikke altid katastrofalt, men det kan se inkonsistent ud.

Trin 5: Fjern de eksterne Google Fonts-kald

Når du har tilføjet lokal font-CSS, skal du fjerne de gamle fjernkald fra dine templates.

Se efter:

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

Tjek også:

• Temaindstillinger i CMS-platforme
• Typografipaneler i page-builders
• Tredjepartswidgets
• Tag managers
• Gamle CSS-imports som @import url('https://fonts.googleapis.com/...')

Den sidste er almindelig. CSS @import til skrifttyper er som regel værre for performance, fordi det forsinker opdagelsen. Hvis du self-hoster, så definér skrifttyper direkte i din primære CSS eller i en font-CSS-fil, der indlæses tidligt.

Privatlivsarbejde fejler ofte, fordi teams retter den åbenlyse template, men overser scripts, widgets og ældre embeds. Det samme mønster ses i samtykkearbejde; vores guide til hvad der ændrede sig for cookies i 2026 er en nyttig ledsager, hvis du mere bredt reducerer tredjepartsfladen.

Trin 6: Sæt cache-headere

Fontfiler er statiske assets. De bør caches aggressivt, hvis deres filnavne er versionerede eller content-hashede.

En god produktionsheader er:

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

Brug kun langlivet immutable caching, hvis URL’en ændrer sig, når filen ændrer sig. For eksempel:

inter-latin-400.a8f3c2.woff2

eller en versioneret sti:

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

Hvis du overskriver /fonts/inter-latin-400.woff2 uden at ændre URL’en, kan nogle brugere beholde den gamle fil i lang tid. Det er fint, indtil det ikke er. Versionering undgår problemet.

Servér også skrifttyper med den korrekte MIME-type:

Content-Type: font/woff2

De fleste moderne hostingplatforme håndterer dette automatisk, men det er værd at verificere.

Trin 7: Overvej kun at preloade den kritiske skrifttype

Preloading kan hjælpe browseren med at opdage en vigtig skrifttype tidligere:

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

Brug dette sparsomt. Preload den primære skrifttype til tekst over folden, ikke alle fontvægte. For meget preloading konkurrerer med CSS, billeder og JavaScript.

Selv for same-origin-skrifttyper bør du inkludere crossorigin på fontpreloads. Fontindlæsning bruger CORS-tilstand, og hvis du udelader det, kan det i nogle opsætninger medføre dobbelte downloads.

Hvis du er i tvivl, så test. Lad være med at cargo-cult’e preloads, bare fordi en tjekliste siger det.

Trin 8: Test privatliv og performance

Test er ligetil.

Åbn DevTools, genindlæs siden med cache deaktiveret, og filtrér Network-panelet efter:

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

Du bør se fontfiler serveret fra dit eget domæne og ingen Google Fonts-forespørgsler.

Test derefter med kold cache og varm cache. Ved første besøg bør skrifttyper downloades én gang. Ved senere besøg bør de komme fra memory cache eller disk cache afhængigt af browseren.

Tjek for layout shift, når skrifttypen skiftes ind. Hvis overskrifter hopper, adskiller metrikkerne i din fallback-skrifttype sig for meget fra webfonten. Du kan reducere det synlige skift ved at vælge en tættere fallback eller bruge nyere CSS-overrides til fontmetrikker som size-adjust, ascent-override, descent-override og line-gap-override. De er mere avancerede, men nyttige til polerede interfaces.

Test til sidst sider i privat browsing eller med content blockers aktiveret. En fordel ved self-hosting er, at privatlivsværktøjer er mindre tilbøjelige til ved et uheld at blokere din typografi.

Almindelige fejl, du bør undgå

At hoste for mange vægte

Dette er den mest almindelige fejl. To vægte er ofte nok. Tre er som regel rigeligt. Fem er et designsystem-lugtesignal, medmindre du har en stærk grund.

At glemme kursiv

Hvis dit indhold bruger reel fremhævelse, så indlæs en rigtig kursivfil. Syntetisk kursiv kan se dårlig ud, især i langt redaktionelt indhold.

At beholde det gamle Google CSS-link

Det modarbejder hele pointen. Efter migreringen bør ingen fontforespørgsel gå til Google, medmindre en anden komponent injicerer den.

At servere skrifttyper uden langsigtet caching

Self-hosting giver dig kontrol. Brug den. Skrifttyper er ideelle kandidater til lange cachelevetider.

At ignorere juridisk arbejde og dokumentation

Hvis din privatlivspolitik tidligere nævnte Google Fonts eller tredjepartsindlæsning af skrifttyper, skal du opdatere den efter migreringen. Hvis du vedligeholder en fortegnelse over databehandling, skal du også opdatere den. Den tekniske ændring og compliance-dokumentationen bør stemme overens.

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

💡 Prøv dette: Konvertér de TTF-filer, du downloadede fra Google Fonts, til WOFF2, der kan hostes selv, plus CSS med Webfont Generator.

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

En enkel migreringstjekliste

1. Lav en liste over de fontfamilier, vægte, stilarter og scripts, du faktisk bruger.
2. Download WOFF2-filer, og bekræft licensen.
3. Subset skrifttyper, hvis sitet har begrænsede sprogbehov.
4. Tilføj lokale @font-face-regler med font-display: swap.
5. Fjern alle Google Fonts-link, preconnect og @import-referencer.
6. Servér skrifttyper fra dit eget domæne med langlivede cache-headere.
7. Preload kun den vigtigste skrifttype over folden, hvis test understøtter det.
8. Verificér i DevTools, at der ikke er Google Fonts-forespørgsler tilbage.
9. Opdater privatlivsdokumentation, hvis det er nødvendigt.

Self-hosting af skrifttyper er ikke glamourøst arbejde. Det er den slags lille oprydning i infrastrukturen, der reducerer afhængighedsrisiko, forbedrer privatlivspositionen og giver mere forudsigelig rendering. Det er som regel den time eller to værd, det tager.