Paano mag-host ng mga font nang lokal sa halip na gumamit ng Google Fonts

Bakit i-self-host ang Google Fonts?

Pinadali ng Google Fonts ang magandang typography. Magdagdag ng stylesheet, pumili ng ilang weight, ilabas ang page. Sa loob ng maraming taon, iyon ang makatwirang default para sa maliliit na team.

Ang kapalit nito ay ang browser ng bawat bisita ay kumokontak sa isang third-party service upang kunin ang font CSS at mga font file. May dalawang bunga iyon.

Una, nagdaragdag ito ng external dependency sa rendering. Kung mabagal, naka-block, o hindi available ang font CSS sa rehiyon o network ng user, maghihintay ang page mo o gagamit ng fallback.

Ikalawa, lumilikha ito ng usapin sa privacy. Maaaring maipakita ng isang font request ang IP address ng user, user agent, referrer policy context, at timing information sa isang third party. Sinasabi ng Google Fonts na hindi ito nagse-set ng cookies sa pamamagitan ng Fonts API, ngunit ang “walang cookies” ay hindi katumbas ng “walang personal data.” Sa ilalim ng GDPR, ang IP address ay maaari pa ring maging personal data depende sa konteksto.

Hindi awtomatikong kailangan ang self-hosting ng fonts para sa bawat website, at hindi ito legal advice. Ngunit para sa mga European site, public-sector site, healthcare, education, finance, o anumang team na gustong bawasan ang hindi kailangang third-party requests, karaniwang mas malinis na pagpipilian ang local hosting.

Madalas din itong performance win kapag maayos ang pagkakagawa. Ang hamon ay ang “maayos ang pagkakagawa.” Ang pagkopya ng anim na font file sa /assets/fonts/ at pag-load ng lahat ng iyon sa bawat page ay maaaring mas masama kaysa paggamit ng hosted service. Kung gusto mo ng mas malawak na konteksto sa performance, tinatalakay ng nauna naming artikulo kung bakit ang web fonts pa rin ang pinakamadaling performance win sa karamihan ng sites ang karaniwang mga pattern ng pag-aaksaya.

Ano ang nagbabago kapag nag-self-host ka

Kapag ginagamit mo ang Google Fonts sa karaniwang paraan, ginagawa ito ng page mo:

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

Una munang humihiling ang browser ng CSS mula sa fonts.googleapis.com, pagkatapos ay dina-download ang mga font file mula sa fonts.gstatic.com.

Kapag nag-self-host ka, dapat humiling ang page mo ng parehong CSS at mga font file mula sa sarili mong domain:

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

Inaalis nito ang third-party font request. Ginagawa ka rin nitong responsable sa pagpili ng file formats, cache headers, fallback fonts, at updates.

Dapat seryosohin ang responsibilidad na iyon. Nasa critical rendering path ang fonts. Ang hindi maayos na font setup ay maaaring magdulot ng invisible text, layout shifts, at mabagal na first render.

Hakbang 1: I-audit kung ano talaga ang ginagamit mo

Bago mag-download ng kahit ano, ilista ang font families, weights, styles, at character sets na tunay na kailangan ng site mo.

Maaaring kailanganin ng isang karaniwang marketing site ang:

• Regular 400 para sa body text
• Semibold 600 o bold 700 para sa headings at buttons
• Italic 400 lamang kung talagang gumagamit ng italics ang design
• Latin character set lamang, maliban kung sumusuporta ang site sa mas maraming wika

Magduda sa lumang design-system defaults. Maraming site ang naglo-load ng 300, 400, 500, 600, 700, italics, at maraming scripts dahil may pumili ng mga iyon minsan sa isang font picker.

Sa browser DevTools, buksan ang Network panel, i-filter ayon sa “font,” i-reload ang page, at tingnan kung aling files ang hinihiling. Pagkatapos, suriin ang CSS mo para sa paggamit ng font-weight. Kung hindi kailanman gumagamit ng 300 ang CSS mo, huwag mag-host ng 300.

Kung rerepasuhin mo ang impact mamaya, makakatulong ang Lighthouse, ngunit huwag ituring ang score nito bilang buong kuwento. Gamitin ito bilang diagnostic tool, hindi bilang hukom. May hiwalay kaming gabay sa pagbasa ng Lighthouse report nang hindi nagpapanic na kapaki-pakinabang kapag inuuna ang font fixes.

Hakbang 2: I-download ang tamang font files

Nag-aalok ang Google Fonts ng open-source fonts. Maaari mong i-download ang mga ito mula sa Google Fonts website o mula sa kaugnay na font project repository. Suriin ang license, ngunit karamihan sa Google Fonts ay ipinamamahagi sa ilalim ng open licenses tulad ng SIL Open Font License o Apache License.

Para sa web, mas piliin ang WOFF2. Malawak itong suportado ng modern browsers at karaniwang mas maliit kaysa TTF o OTF. Sa 2026, bihira nang may sapat na dahilan para direktang mag-serve ng TTF sa browsers para sa public websites.

Ganito ang isang makatwirang directory structure:

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

Gumamit ng malinaw na filenames. Pagkalipas ng anim na buwan, nakakainis ang font.woff2. Ang inter-latin-600.woff2 ay boring ngunit kapaki-pakinabang.

Kung gumagamit ang site mo ng build system, ilagay ang source fonts sa malinaw na lokasyon at hayaang kopyahin ng build pipeline ang optimized files papunta sa public assets directory.

Hakbang 3: Mag-subset ng fonts kung naaangkop

Ang subsetting ay nangangahulugang pag-aalis ng mga character na hindi mo kailangan. Maaaring kabilang sa full font ang Latin, Cyrillic, Greek, Vietnamese, symbols, at maraming OpenType features. Kung Latin characters lang ang kailangan ng English-only landing page mo, maaaring maging lubhang mas maliit ang subset.

May dalawang karaniwang paraan:

1. Gumamit ng prebuilt subset mula sa font provider o repository.
2. Gumawa ng sarili mong subset gamit ang font tool tulad ng pyftsubset mula sa fonttools.

Para sa maraming team, sapat na ang prebuilt Latin subsets. Kapaki-pakinabang ang custom subsetting kapag mayroon kang napakahigpit na pages, tulad ng isang single campaign page na may limitadong text, o product UI na may predictable character coverage.

Mag-ingat sa multilingual sites. Ang nawawalang glyphs ay nagdudulot ng paghahalo ng fallback font, na maaaring magmukhang sira at makasama sa readability. Kung sumusuporta ka sa maraming wika, i-map ang font subsets sa language routes sa halip na piliting gamitin ang isang napakaliit na subset sa lahat ng lugar.

Hakbang 4: Isulat ang iyong @font-face rules

Ganito ang isang minimal na local setup:

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

May ilang detalyeng mahalaga rito.

Gamitin ang font-display: swap para sa karamihan ng content sites. Sinasabi nito sa browser na mabilis na ipakita ang fallback text, pagkatapos ay ipalit ang web font kapag dumating ito. Iniiwasan nito ang pinakamasamang bersyon ng FOIT: flash of invisible text.

Magtakda ng explicit fallback stack. Kung mabigo ang custom font, dapat makakuha pa rin ang users ng nababasang text. Hindi panghuling-isip ang fallbacks; bahagi sila ng design. Kung kailangan mong balikan ang sizing, line length, at body text choices, magsimula sa isang praktikal na gabay sa nababasang type sa modern web.

Itugma nang tama ang weights. Kung humihiling ang CSS mo ng font-weight: 500 ngunit 400 at 700 lang ang dine-define mo, maaaring mag-synthesize ang browser ng intermediate weight. Hindi ito palaging masama, ngunit maaari itong magmukhang hindi consistent.

Hakbang 5: Alisin ang external Google Fonts calls

Pagkatapos idagdag ang local font CSS, alisin ang lumang remote calls mula sa templates mo.

Hanapin ang:

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

Suriin din ang:

• Theme settings sa CMS platforms
• Page-builder typography panels
• Third-party widgets
• Tag managers
• Lumang CSS imports tulad ng @import url('https://fonts.googleapis.com/...')

Karaniwan ang huling iyon. Ang CSS @import para sa fonts ay kadalasang mas masama para sa performance dahil inaantala nito ang discovery. Kung nag-self-host ka, i-define ang fonts nang direkta sa main CSS mo o sa isang font CSS file na maagang nilo-load.

Madalas nabibigo ang privacy work dahil inaayos ng teams ang halatang template ngunit nakakaligtaan ang scripts, widgets, at legacy embeds. Lumilitaw din ang parehong pattern sa consent work; ang aming gabay sa kung ano ang nagbago para sa cookies noong 2026 ay kapaki-pakinabang na kasama kung mas malawak mong binabawasan ang third-party surface area.

Hakbang 6: Magtakda ng cache headers

Static assets ang font files. Dapat silang i-cache nang agresibo kung versioned o content-hashed ang filenames nila.

Isang magandang production header ay:

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

Gumamit lamang ng long-lived immutable caching kung nagbabago ang URL kapag nagbago ang file. Halimbawa:

inter-latin-400.a8f3c2.woff2

o isang versioned path:

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

Kung io-overwrite mo ang /fonts/inter-latin-400.woff2 nang hindi binabago ang URL, maaaring panatilihin ng ilang users ang lumang file nang matagal. Ayos lang iyon hanggang sa hindi na. Iniiwasan ng versioning ang problema.

I-serve din ang fonts gamit ang tamang MIME type:

Content-Type: font/woff2

Awtomatikong inaasikaso ito ng karamihan sa modern hosting platforms, ngunit sulit itong i-verify.

Hakbang 7: Isaalang-alang ang preloading lamang ng critical font

Makakatulong ang preloading na mas maagang madiskubre ng browser ang mahalagang font:

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

Gamitin ito nang matipid. I-preload ang primary above-the-fold text font, hindi bawat font weight. Ang sobrang preloading ay nakikipag-agawan sa CSS, images, at JavaScript.

Kahit para sa same-origin fonts, isama ang crossorigin sa font preloads. Gumagamit ng CORS mode ang font fetching, at ang pag-alis nito ay maaaring magdulot ng duplicate downloads sa ilang setup.

Kung hindi ka sigurado, mag-test. Huwag basta gumaya ng preloads dahil sinabi ito ng isang checklist.

Hakbang 8: I-test ang privacy at performance

Direkta ang testing.

Buksan ang DevTools, i-reload ang page nang naka-disable ang cache, at i-filter ang Network panel para sa:

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

Dapat mong makita ang font files na sine-serve mula sa sarili mong domain at walang Google Fonts requests.

Pagkatapos, mag-test gamit ang cold cache at warm cache. Sa unang pagbisita, dapat ma-download ang fonts nang isang beses. Sa mga susunod na pagbisita, dapat manggaling ang mga ito sa memory o disk cache depende sa browser.

Tingnan kung may layout shift habang pumapalit ang font. Kung tumatalon ang headings, masyadong magkaiba ang metrics ng fallback font mo at web font. Maaari mong bawasan ang nakikitang shift sa pamamagitan ng pagpili ng mas malapit na fallback o paggamit ng mas bagong CSS font metric overrides tulad ng size-adjust, ascent-override, descent-override, at line-gap-override. Mas advanced ang mga ito, ngunit kapaki-pakinabang para sa polished interfaces.

Panghuli, i-test ang pages sa private browsing o may naka-enable na content blockers. Isang benepisyo ng self-hosting ay mas maliit ang posibilidad na aksidenteng i-block ng privacy tools ang typography mo.

Karaniwang pagkakamaling dapat iwasan

Pag-host ng napakaraming weights

Ito ang pinakakaraniwang pagkabigo. Madalas sapat na ang dalawang weights. Karaniwang marami na ang tatlo. Ang lima ay senyales ng design-system smell maliban kung mayroon kang matibay na dahilan.

Pagkalimot sa italics

Kung gumagamit ang content mo ng tunay na emphasis, mag-load ng totoong italic file. Maaaring pangit tingnan ang synthetic italics, lalo na sa long-form editorial content.

Pagpapanatili ng lumang Google CSS link

Sinisira nito ang layunin. Pagkatapos ng migration, walang font request ang dapat pumunta sa Google maliban kung may ibang component na nag-i-inject nito.

Pag-serve ng fonts nang walang long-term caching

Binibigyan ka ng self-hosting ng kontrol. Gamitin ito. Ang fonts ay perpektong kandidato para sa mahabang cache lifetimes.

Pagwawalang-bahala sa legal at documentation work

Kung dati nang binanggit ng privacy policy mo ang Google Fonts o third-party font loading, i-update ito pagkatapos ng migration. Kung nagpapanatili ka ng data-processing inventory, i-update din iyon. Dapat magtugma ang technical change at compliance record.

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

💡 Subukan ito: I-convert ang mga TTF file na na-download mo mula sa Google Fonts sa self-hostable na WOFF2 plus CSS gamit ang Webfont Generator.

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

Isang simpleng migration checklist

1. Ilista ang font families, weights, styles, at scripts na talagang ginagamit mo.
2. Mag-download ng WOFF2 files at kumpirmahin ang license.
3. Mag-subset ng fonts kung limitado ang language needs ng site.
4. Magdagdag ng local @font-face rules na may font-display: swap.
5. Alisin ang lahat ng Google Fonts link, preconnect, at @import references.
6. I-serve ang fonts mula sa sarili mong domain gamit ang long-lived cache headers.
7. I-preload lamang ang pinakamahalagang above-the-fold font, kung sinusuportahan ito ng testing.
8. I-verify sa DevTools na wala nang natitirang Google Fonts requests.
9. I-update ang privacy documentation kung kailangan.

Hindi glamorous na trabaho ang self-hosting ng fonts. Isa itong uri ng maliit na infrastructure cleanup na nagpapababa ng dependency risk, nagpapabuti ng privacy posture, at nagbibigay sa iyo ng mas predictable na rendering. Karaniwang sulit iyon sa isa o dalawang oras na kailangan nito.