Privacy & Security

Så hostar du typsnitt lokalt i stället för att använda Google Fonts

En praktisk och integritetsmedveten guide till att ladda ned, skapa delmängder av, leverera och testa webbtypsnitt från din egen domän.

The Wux Webtools Team The Wux Webtools Team 10 min läsning AI-assisterad, mänskligt granskad
Illustration of locally hosted web font files being served from a website instead of a third-party service.
Innehållsförteckning
  1. Varför självhosta Google Fonts?
  2. Vad som förändras när du självhostar
  3. Steg 1: Inventera vad du faktiskt använder
  4. Steg 2: Ladda ned rätt typsnittsfiler
  5. Steg 3: Skapa delmängder av typsnitt där det passar
  6. Steg 4: Skriv dina `@font-face`-regler
  7. Steg 5: Ta bort de externa Google Fonts-anropen
  8. Steg 6: Ange cachehuvuden
  9. Steg 7: Överväg preload endast för det kritiska typsnittet
  10. Steg 8: Testa integritet och prestanda
  11. Vanliga misstag att undvika
  12. Att hosta för många vikter
  13. Att glömma kursiver
  14. Att behålla den gamla Google CSS-länken
  15. Att leverera typsnitt utan långsiktig caching
  16. Att ignorera juridiskt arbete och dokumentation
  17. En enkel checklista för migrering

Varför självhosta Google Fonts?

Google Fonts gjorde god typografi enkel. Lägg till en stylesheet, välj några vikter och publicera sidan. I många år var det standardvalet för små team.

Avvägningen är att varje besökares webbläsare kontaktar en tredjepartstjänst för att hämta typsnitts-CSS och typsnittsfiler. Det får två konsekvenser.

För det första lägger det till ett externt beroende i renderingen. Om typsnitts-CSS:en är långsam, blockerad eller otillgänglig i användarens region eller nätverk får sidan vänta eller falla tillbaka på reservtypsnitt.

För det andra skapar det en integritetsfråga. En typsnittsförfrågan kan avslöja användarens IP-adress, user agent, kontext för referrer-policy och tidsinformation för en tredje part. Google Fonts anger att det inte sätter cookies via Fonts API, men ”inga cookies” är inte samma sak som ”inga personuppgifter”. Enligt GDPR kan en IP-adress fortfarande vara en personuppgift i sitt sammanhang.

Att självhosta typsnitt är inte automatiskt ett krav för alla webbplatser, och detta är inte juridisk rådgivning. Men för europeiska webbplatser, offentliga verksamheter, vård, utbildning, finans eller team som försöker minska onödiga tredjepartsförfrågningar är lokal hosting oftast det renare valet.

Det är också ofta en prestandavinst när det görs väl. Haken är just ”när det görs väl”. Att kopiera sex typsnittsfiler till /assets/fonts/ och läsa in dem alla på varje sida kan vara sämre än att använda den hostade tjänsten. Om du vill ha den bredare prestandakontexten tar vår tidigare artikel om varför webbtypsnitt fortfarande är den enklaste prestandavinsten på de flesta webbplatser upp vanliga slöserimönster.

Vad som förändras när du självhostar

När du använder Google Fonts på det vanliga sättet gör sidan detta:

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

Webbläsaren hämtar först CSS från fonts.googleapis.com och laddar sedan ned typsnittsfiler från fonts.gstatic.com.

När du självhostar bör sidan hämta både CSS:en och typsnittsfilerna från din egen domän:

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

Det tar bort tredjepartsförfrågan för typsnittet. Det gör dig också ansvarig för att välja filformat, cachehuvuden, reservtypsnitt och uppdateringar.

Det ansvaret är värt att ta på allvar. Typsnitt ligger på den kritiska renderingsvägen. En svag typsnittsuppsättning kan orsaka osynlig text, layoutskiften och långsam första rendering.

Steg 1: Inventera vad du faktiskt använder

Innan du laddar ned något, lista vilka typsnittsfamiljer, vikter, stilar och teckenuppsättningar din webbplats faktiskt behöver.

En typisk marknadsföringssajt kan behöva:

  • Regular 400 för brödtext
  • Semibold 600 eller bold 700 för rubriker och knappar
  • Italic 400 endast om designen faktiskt använder kursiv stil
  • Endast latinsk teckenuppsättning, om inte webbplatsen stöder fler språk

Var skeptisk till gamla standardinställningar i designsystem. Många webbplatser läser in 300, 400, 500, 600, 700, kursiver och flera skript eftersom någon valde dem en gång i en typsnittsväljare.

Öppna Network-panelen i webbläsarens DevTools, filtrera på ”font”, ladda om sidan och kontrollera vilka filer som begärs. Granska sedan din CSS för användning av font-weight. Om din CSS aldrig använder 300 ska du inte hosta 300.

Om du senare granskar effekten kan Lighthouse hjälpa, men behandla inte poängen som hela sanningen. Använd det som ett diagnostiskt verktyg, inte som en domare. Vi har en separat guide om att läsa en Lighthouse-rapport utan panik som är användbar när du prioriterar typsnittsfixar.

Steg 2: Ladda ned rätt typsnittsfiler

Google Fonts erbjuder typsnitt med öppen källkod. Du kan ladda ned dem från Google Fonts-webbplatsen eller från det relevanta typsnittsprojektets repository. Kontrollera licensen, men de flesta Google Fonts distribueras under öppna licenser som SIL Open Font License eller Apache License.

För webben bör du föredra WOFF2. Det stöds brett av moderna webbläsare och är vanligtvis mycket mindre än TTF eller OTF. År 2026 är det sällan motiverat att leverera TTF direkt till webbläsare på publika webbplatser.

En rimlig katalogstruktur ser ut så här:

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

Använd beskrivande filnamn. Sex månader senare kommer font.woff2 att vara irriterande. inter-latin-600.woff2 är tråkigt och användbart.

Om webbplatsen använder ett byggsystem, placera källtypsnitten på en tydlig plats och låt byggpipelinen kopiera optimerade filer till katalogen för publika assets.

Steg 3: Skapa delmängder av typsnitt där det passar

Subsetting innebär att ta bort tecken du inte behöver. Ett komplett typsnitt kan innehålla latin, kyrilliska, grekiska, vietnamesiska, symboler och många OpenType-funktioner. Om din engelskspråkiga landningssida bara behöver latinska tecken kan en delmängd bli dramatiskt mindre.

Det finns två vanliga metoder:

  1. Använd en förbyggd delmängd från typsnittsleverantören eller repositoryt.
  2. Skapa din egen delmängd med ett typsnittsverktyg som pyftsubset från fonttools.

För många team räcker förbyggda latinska delmängder. Anpassad subsetting är användbar när du har mycket begränsade sidor, till exempel en enskild kampanjsida med begränsad text eller ett produktgränssnitt med förutsägbar teckentäckning.

Var försiktig med flerspråkiga webbplatser. Saknade glyfer leder till blandning av reservtypsnitt, vilket kan se trasigt ut och försämra läsbarheten. Om du stöder flera språk bör du mappa typsnittsdelmängder till språkvägar i stället för att tvinga fram en enda liten delmängd överallt.

Steg 4: Skriv dina @font-face-regler

En minimal lokal uppsättning ser ut så här:

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

Några detaljer spelar roll här.

Använd font-display: swap för de flesta innehållssajter. Det säger åt webbläsaren att visa reservtext snabbt och sedan byta in webbtypsnittet när det har kommit fram. Det undviker den värsta versionen av FOIT: flash of invisible text.

Ange en tydlig fallback-stack. Om det anpassade typsnittet misslyckas ska användarna ändå få läsbar text. Reservtypsnitt är inte en eftertanke; de är en del av designen. Om du behöver se över storlek, radlängd och val av brödtext, börja med en praktisk guide till läsbar typografi på den moderna webben.

Matcha vikter korrekt. Om din CSS begär font-weight: 500 men du bara definierar 400 och 700 kan webbläsaren syntetisera en mellanvikt. Det är inte alltid katastrofalt, men det kan se inkonsekvent ut.

Steg 5: Ta bort de externa Google Fonts-anropen

När du har lagt till lokal typsnitts-CSS tar du bort de gamla fjärranropen från dina mallar.

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

Kontrollera också:

  • Temainställningar i CMS-plattformar
  • Typografipaneler i page builders
  • Tredjepartswidgets
  • Tag managers
  • Gamla CSS-importer som @import url('https://fonts.googleapis.com/...')

Det sista är vanligt. CSS @import för typsnitt är oftast sämre för prestandan eftersom det fördröjer upptäckten. Om du självhostar bör du definiera typsnitt direkt i din huvudsakliga CSS eller i en typsnitts-CSS-fil som laddas tidigt.

Integritetsarbete misslyckas ofta för att team fixar den uppenbara mallen men missar skript, widgets och äldre inbäddningar. Samma mönster syns i samtyckesarbete; vår guide till vad som förändrades för cookies 2026 är ett användbart komplement om du minskar tredjepartsytan mer generellt.

Steg 6: Ange cachehuvuden

Typsnittsfiler är statiska assets. De bör cachas aggressivt om filnamnen är versionerade eller innehållshashade.

Ett bra produktionshuvud är:

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

Använd långlivad immutable-cache endast om URL:en ändras när filen ändras. Till exempel:

inter-latin-400.a8f3c2.woff2

eller en versionerad sökväg:

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

Om du skriver över /fonts/inter-latin-400.woff2 utan att ändra URL:en kan vissa användare behålla den gamla filen länge. Det är okej tills det inte är det. Versionering undviker problemet.

Leverera också typsnitt med rätt MIME-typ:

Content-Type: font/woff2

De flesta moderna hostingplattformar hanterar detta automatiskt, men det är värt att verifiera.

Steg 7: Överväg preload endast för det kritiska typsnittet

Preloading kan hjälpa webbläsaren att upptäcka ett viktigt typsnitt tidigare:

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

Använd detta sparsamt. Preloada typsnittet för den primära texten ovanför vikningen, inte varje typsnittsvikt. För mycket preloading konkurrerar med CSS, bilder och JavaScript.

Även för typsnitt från samma ursprung bör du inkludera crossorigin på font preloads. Typsnittshämtning använder CORS-läge, och om det utelämnas kan det orsaka dubbla nedladdningar i vissa uppsättningar.

Om du är osäker, testa. Cargo-culta inte preloads bara för att en checklista säger det.

Steg 8: Testa integritet och prestanda

Testningen är enkel.

Öppna DevTools, ladda om sidan med cache inaktiverad och filtrera Network-panelen efter:

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

Du bör se typsnittsfiler som levereras från din egen domän och inga Google Fonts-förfrågningar.

Testa sedan med kall cache och varm cache. Vid första besöket bör typsnitt laddas ned en gång. Vid senare besök bör de komma från minnes- eller diskcache beroende på webbläsare.

Kontrollera layoutskiften när typsnittet byts in. Om rubriker hoppar skiljer sig mätvärdena för reservtypsnittet för mycket från webbtypsnittet. Du kan minska det synliga skiftet genom att välja ett närmare reservtypsnitt eller använda nyare CSS-åsidosättningar för typsnittsmått, som size-adjust, ascent-override, descent-override och line-gap-override. Dessa är mer avancerade, men användbara för polerade gränssnitt.

Testa slutligen sidor i privat surfning eller med innehållsblockerare aktiverade. En fördel med självhosting är att integritetsverktyg mer sällan blockerar din typografi av misstag.

Vanliga misstag att undvika

Att hosta för många vikter

Det här är det vanligaste misslyckandet. Två vikter räcker ofta. Tre är vanligtvis gott om. Fem är en designsystemvarning om du inte har ett starkt skäl.

Att glömma kursiver

Om ditt innehåll använder verklig betoning, ladda en riktig kursiv fil. Syntetisk kursiv kan se dålig ut, särskilt i längre redaktionellt innehåll.

Att behålla den gamla Google CSS-länken

Det motverkar syftet. Efter migreringen ska ingen typsnittsförfrågan gå till Google om inte en annan komponent injicerar den.

Att leverera typsnitt utan långsiktig caching

Självhosting ger dig kontroll. Använd den. Typsnitt är idealiska kandidater för långa cachelivstider.

Att ignorera juridiskt arbete och dokumentation

Om din integritetspolicy tidigare nämnde Google Fonts eller typsnittsladdning via tredje part bör du uppdatera den efter migreringen. Om du underhåller en förteckning över databehandling bör du uppdatera den också. Den tekniska förändringen och efterlevnadsdokumentationen bör stämma överens.

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

💡 Prova detta: Konvertera TTF-filerna som du laddade ner från Google Fonts till WOFF2 för egen hosting plus CSS med Webfont Generator.

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

En enkel checklista för migrering

  1. Lista de typsnittsfamiljer, vikter, stilar och skript du faktiskt använder.
  2. Ladda ned WOFF2-filer och bekräfta licensen.
  3. Skapa delmängder av typsnitt om webbplatsen har begränsade språkbehov.
  4. Lägg till lokala @font-face-regler med font-display: swap.
  5. Ta bort alla Google Fonts-referenser för link, preconnect och @import.
  6. Leverera typsnitt från din egen domän med långlivade cachehuvuden.
  7. Preloada endast det viktigaste typsnittet ovanför vikningen, om tester stöder det.
  8. Verifiera i DevTools att inga Google Fonts-förfrågningar finns kvar.
  9. Uppdatera integritetsdokumentation vid behov.

Att självhosta typsnitt är inte glamoröst arbete. Det är den typ av liten infrastrukturrensning som minskar beroenderisk, förbättrar integritetsskyddet och ger mer förutsägbar rendering. Det är vanligtvis värt den timme eller två det tar.

Vanliga frågor

Är det lagligt att självhosta Google Fonts?
Vanligtvis ja. De flesta typsnitt som finns via Google Fonts är open source och kan självhostas enligt sina respektive licenser. Kontrollera alltid den specifika typsnittslicensen innan du publicerar det.
Gör självhosting av typsnitt automatiskt min webbplats GDPR-kompatibel?
Nej. Det tar bara bort en vanlig tredjepartsöverföring av data. GDPR-efterlevnad beror på din bredare datainsamling, samtycke, dokumentation och leverantörsuppsättning. Men att självhosta typsnitt är en praktisk integritetsförbättring.
Bör jag bara använda WOFF2?
För de flesta moderna webbplatser, ja. WOFF2 har brett webbläsarstöd och stark komprimering. Äldre format som TTF, OTF, EOT och SVG-typsnitt behövs sällan numera.
Är lokala typsnitt alltid snabbare än Google Fonts?
Inte alltid. Dåligt hostade lokala typsnitt kan vara långsammare. Lokal hosting fungerar bäst när du använder små WOFF2-filer, undviker onödiga vikter, anger korrekta cachehuvuden och levererar typsnitt från snabb infrastruktur.
Hur vet jag om Google Fonts fortfarande laddas?
Öppna webbläsarens DevTools, ladda om sidan och kontrollera Network-panelen efter förfrågningar till `fonts.googleapis.com` eller `fonts.gstatic.com`. Sök också i dina mallar och din CSS efter gamla Google Fonts-länkar eller `@import`-regler.

Källor och vidare läsning

  1. MDN Web Docs: @font-face
  2. web.dev: Optimize webfont loading and rendering
  3. Google Fonts FAQ
  4. Regulation (EU) 2016/679: General Data Protection Regulation
Om författaren
The Wux Webtools Team

Senast uppdaterad:

Fortsätt läsa