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.
Innehållsförteckning
- Varför självhosta Google Fonts?
- Vad som förändras när du självhostar
- Steg 1: Inventera vad du faktiskt använder
- Steg 2: Ladda ned rätt typsnittsfiler
- Steg 3: Skapa delmängder av typsnitt där det passar
- Steg 4: Skriv dina `@font-face`-regler
- Steg 5: Ta bort de externa Google Fonts-anropen
- Steg 6: Ange cachehuvuden
- Steg 7: Överväg preload endast för det kritiska typsnittet
- Steg 8: Testa integritet och prestanda
- Vanliga misstag att undvika
- Att hosta för många vikter
- Att glömma kursiver
- Att behålla den gamla Google CSS-länken
- Att leverera typsnitt utan långsiktig caching
- Att ignorera juridiskt arbete och dokumentation
- 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:
- Använd en förbyggd delmängd från typsnittsleverantören eller repositoryt.
- Skapa din egen delmängd med ett typsnittsverktyg som
pyftsubsetfrå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.comfonts.gstatic.com.woff2font
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
- Lista de typsnittsfamiljer, vikter, stilar och skript du faktiskt använder.
- Ladda ned WOFF2-filer och bekräfta licensen.
- Skapa delmängder av typsnitt om webbplatsen har begränsade språkbehov.
- Lägg till lokala
@font-face-regler medfont-display: swap. - Ta bort alla Google Fonts-referenser för
link,preconnectoch@import. - Leverera typsnitt från din egen domän med långlivade cachehuvuden.
- Preloada endast det viktigaste typsnittet ovanför vikningen, om tester stöder det.
- Verifiera i DevTools att inga Google Fonts-förfrågningar finns kvar.
- 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.