Google Fonts का उपयोग करने के बजाय fonts को locally host कैसे करें

Google Fonts को self-host क्यों करें?

Google Fonts ने अच्छी typography को आसान बना दिया। एक stylesheet जोड़ें, कुछ weights चुनें, और page ship कर दें। वर्षों तक छोटी teams के लिए यही समझदार default था।

Trade-off यह है कि हर visitor का browser font CSS और font files fetch करने के लिए third-party service से संपर्क करता है। इसके दो परिणाम होते हैं।

पहला, यह rendering में एक external dependency जोड़ता है। अगर font CSS धीमा है, blocked है, या user के region या network में उपलब्ध नहीं है, तो आपका page इंतज़ार करता है या fallback पर चला जाता है।

दूसरा, यह privacy का सवाल पैदा करता है। Font request किसी third party को user का IP address, user agent, referrer policy context, और timing information बता सकती है। Google Fonts कहता है कि वह Fonts API के माध्यम से cookies set नहीं करता, लेकिन “no cookies” और “no personal data” एक ही बात नहीं हैं। GDPR के तहत, context में IP address अभी भी personal data हो सकता है।

हर website के लिए fonts self-host करना अपने-आप अनिवार्य नहीं है, और यह legal advice नहीं है। लेकिन European sites, public-sector sites, healthcare, education, finance, या ऐसी कोई भी team जो अनावश्यक third-party requests घटाना चाहती है, उनके लिए local hosting आम तौर पर अधिक साफ़ विकल्प है।

अच्छी तरह किया जाए तो यह अक्सर performance win भी होता है। समस्या “अच्छी तरह” में है। छह font files को /assets/fonts/ में copy करके हर page पर उन सभी को load करना hosted service का उपयोग करने से भी खराब हो सकता है। अगर आप broader performance context चाहते हैं, तो हमारा पहले का लेख कि क्यों web fonts अब भी अधिकांश sites पर सबसे आसान performance win हैं common waste patterns को cover करता है।

Self-host करने पर क्या बदलता है

जब आप Google Fonts को सामान्य तरीके से use करते हैं, तो आपका page यह करता है:

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

Browser पहले fonts.googleapis.com से CSS request करता है, फिर fonts.gstatic.com से font files download करता है।

जब आप self-host करते हैं, तो आपके page को CSS और font files दोनों अपने domain से request करनी चाहिए:

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

यह third-party font request हटा देता है। यह आपको file formats, cache headers, fallback fonts, और updates चुनने के लिए ज़िम्मेदार भी बनाता है।

इस ज़िम्मेदारी को गंभीरता से लेना चाहिए। Fonts critical rendering path पर होते हैं। खराब font setup invisible text, layout shifts, और slow first render का कारण बन सकता है।

चरण 1: Audit करें कि आप वास्तव में क्या use करते हैं

कुछ भी download करने से पहले, उन font families, weights, styles, और character sets की list बनाएं जिनकी आपकी site को सच में ज़रूरत है।

एक typical marketing site को शायद चाहिए:

• Body text के लिए Regular 400
• Headings और buttons के लिए Semibold 600 या bold 700
• Italic 400 केवल तब, जब design वास्तव में italics use करता हो
• केवल Latin character set, जब तक site अधिक languages support न करती हो

पुराने design-system defaults पर संदेह करें। कई sites 300, 400, 500, 600, 700, italics, और multiple scripts load करती हैं, क्योंकि किसी ने font picker में उन्हें कभी चुन लिया था।

Browser DevTools में Network panel खोलें, “font” से filter करें, page reload करें, और देखें कि कौन-सी files request हो रही हैं। फिर font-weight usage के लिए अपनी CSS inspect करें। अगर आपकी CSS कभी 300 use नहीं करती, तो 300 host न करें।

अगर आप बाद में impact review कर रहे हैं, तो Lighthouse मदद कर सकता है, लेकिन उसके score को पूरी कहानी न मानें। उसे diagnostic tool की तरह use करें, judge की तरह नहीं। हमारे पास Lighthouse report को बिना घबराए पढ़ने पर एक अलग guide है, जो font fixes prioritize करते समय उपयोगी है।

चरण 2: सही font files download करें

Google Fonts open-source fonts देता है। आप उन्हें Google Fonts website से या संबंधित font project repository से download कर सकते हैं। License check करें, लेकिन अधिकांश Google Fonts open licenses जैसे SIL Open Font License या Apache License के तहत distribute होते हैं।

Web के लिए WOFF2 prefer करें। यह modern browsers में व्यापक रूप से supported है और आम तौर पर TTF या OTF से काफी छोटा होता है। 2026 में public websites के लिए browsers को सीधे TTF serve करना शायद ही उचित हो।

एक sensible directory structure ऐसा दिखता है:

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

Descriptive filenames use करें। छह महीने बाद, font.woff2 परेशान करेगा। inter-latin-600.woff2 boring और useful है।

अगर आपकी site build system use करती है, तो source fonts को किसी साफ़ जगह रखें और build pipeline को optimized files public assets directory में copy करने दें।

चरण 3: जहाँ उचित हो, fonts subset करें

Subsetting का मतलब है वे characters हटाना जिनकी आपको ज़रूरत नहीं है। एक full font में Latin, Cyrillic, Greek, Vietnamese, symbols, और कई OpenType features शामिल हो सकते हैं। अगर आपकी English-only landing page को सिर्फ Latin characters चाहिए, तो subset काफी छोटा हो सकता है।

दो common approaches हैं:

1. Font provider या repository से prebuilt subset use करें।
2. fonttools के pyftsubset जैसे font tool से अपना subset generate करें।

कई teams के लिए prebuilt Latin subsets पर्याप्त होते हैं। Custom subsetting तब उपयोगी है जब आपके pages बहुत constrained हों, जैसे limited text वाला single campaign page, या predictable character coverage वाला product UI।

Multilingual sites के साथ सावधान रहें। Missing glyphs fallback font mixing का कारण बनते हैं, जो broken दिख सकता है और readability को नुकसान पहुँचा सकता है। अगर आप multiple languages support करते हैं, तो एक छोटा subset हर जगह force करने के बजाय font subsets को language routes से map करें।

चरण 4: अपने @font-face rules लिखें

एक minimal 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;
}

यहाँ कुछ details मायने रखती हैं।

अधिकांश content sites के लिए font-display: swap use करें। यह browser को fallback text जल्दी दिखाने और web font आने पर उसे swap करने के लिए कहता है। इससे FOIT का सबसे खराब version बचता है: invisible text का flash।

एक explicit fallback stack set करें। अगर custom font fail हो जाए, तो users को फिर भी readable text मिलना चाहिए। Fallbacks बाद की सोच नहीं हैं; वे design का हिस्सा हैं। अगर आपको sizing, line length, और body text choices फिर से देखने हैं, तो modern web पर readable type की practical guide से शुरू करें।

Weights को सही तरह match करें। अगर आपकी CSS font-weight: 500 मांगती है लेकिन आप केवल 400 और 700 define करते हैं, तो browser बीच का weight synthesize कर सकता है। यह हमेशा भयानक नहीं होता, लेकिन inconsistent दिख सकता है।

चरण 5: External Google Fonts calls हटाएँ

Local font CSS जोड़ने के बाद, अपने templates से पुराने remote calls हटा दें।

इन्हें खोजें:

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

यह भी check करें:

• CMS platforms में theme settings
• Page-builder typography panels
• Third-party widgets
• Tag managers
• पुराने CSS imports जैसे @import url('https://fonts.googleapis.com/...')

आखिरी वाला common है। Fonts के लिए CSS @import आम तौर पर performance के लिए खराब होता है क्योंकि यह discovery delay करता है। अगर आप self-host करते हैं, तो fonts को सीधे अपनी main CSS या early loaded font CSS file में define करें।

Privacy work अक्सर इसलिए fail होता है क्योंकि teams obvious template तो fix कर देती हैं, लेकिन scripts, widgets, और legacy embeds miss कर देती हैं। यही pattern consent work में भी दिखता है; अगर आप broader रूप से third-party surface area घटा रहे हैं, तो 2026 में cookies के लिए क्या बदला पर हमारी guide एक उपयोगी companion है।

चरण 6: Cache headers set करें

Font files static assets हैं। अगर उनके filenames versioned या content-hashed हैं, तो उन्हें aggressively cache किया जाना चाहिए।

एक अच्छा production header है:

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

Long-lived immutable caching केवल तब use करें जब file बदलने पर URL बदलता हो। उदाहरण के लिए:

inter-latin-400.a8f3c2.woff2

या एक versioned path:

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

अगर आप URL बदले बिना /fonts/inter-latin-400.woff2 overwrite करते हैं, तो कुछ users पुरानी file लंबे समय तक रख सकते हैं। जब तक समस्या न बने, यह ठीक है। Versioning problem से बचाती है।

Fonts को correct MIME type के साथ भी serve करें:

Content-Type: font/woff2

Most modern hosting platforms इसे automatically handle करते हैं, लेकिन verify करना उचित है।

चरण 7: केवल critical font को preload करने पर विचार करें

Preloading browser को important font पहले discover करने में मदद कर सकता है:

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

इसे sparingly use करें। Primary above-the-fold text font preload करें, हर font weight नहीं। Over-preloading CSS, images, और JavaScript से compete करता है।

Same-origin fonts के लिए भी font preloads पर crossorigin include करें। Font fetching CORS mode use करती है, और इसे omit करने से कुछ setups में duplicate downloads हो सकते हैं।

अगर आप unsure हैं, तो test करें। Checklist ने कहा है इसलिए preloads को cargo-cult न करें।

चरण 8: Privacy और performance test करें

Testing straightforward है।

DevTools खोलें, cache disabled रखकर page reload करें, और Network panel में इनसे filter करें:

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

आपको font files अपने domain से served दिखनी चाहिए और Google Fonts requests नहीं दिखनी चाहिए।

फिर cold cache और warm cache के साथ test करें। First visit पर fonts एक बार download होने चाहिए। Later visits पर वे browser के अनुसार memory या disk cache से आने चाहिए।

Font swap in होने पर layout shift check करें। अगर headings jump करती हैं, तो आपके fallback font metrics web font से बहुत अलग हैं। आप closer fallback चुनकर या newer CSS font metric overrides जैसे size-adjust, ascent-override, descent-override, और line-gap-override use करके visible shift घटा सकते हैं। ये अधिक advanced हैं, लेकिन polished interfaces के लिए उपयोगी हैं।

अंत में, pages को private browsing में या content blockers enabled रखकर test करें। Self-hosting का एक benefit यह है कि privacy tools आपकी typography को accidentally block करने की संभावना कम रखते हैं।

बचने योग्य common mistakes

बहुत सारे weights host करना

यह सबसे common failure है। दो weights अक्सर पर्याप्त होते हैं। तीन आम तौर पर काफी हैं। पाँच design-system smell है, जब तक आपके पास कोई strong reason न हो।

Italics भूल जाना

अगर आपका content real emphasis use करता है, तो real italic file load करें। Synthetic italics खराब दिख सकते हैं, खासकर long-form editorial content में।

पुराना Google CSS link बनाए रखना

यह उद्देश्य को ही विफल कर देता है। Migration के बाद कोई font request Google पर नहीं जानी चाहिए, जब तक कोई दूसरा component उसे inject न कर रहा हो।

Fonts को long-term caching के बिना serve करना

Self-hosting आपको control देता है। उसका उपयोग करें। Fonts long cache lifetimes के लिए ideal candidates हैं।

Legal और documentation work को ignore करना

अगर आपकी privacy policy में पहले Google Fonts या third-party font loading का mention था, तो migration के बाद उसे update करें। अगर आप data-processing inventory maintain करते हैं, तो उसे भी update करें। Technical change और compliance record में consistency होनी चाहिए।

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

💡 इसे आज़माएँ: Google Fonts से डाउनलोड की गई TTF फ़ाइलों को Webfont Generator की मदद से स्व-होस्ट किए जा सकने वाले WOFF2 और CSS में बदलें।

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

एक simple migration checklist

1. उन font families, weights, styles, और scripts की list बनाएं जिन्हें आप वास्तव में use करते हैं।
2. WOFF2 files download करें और license confirm करें।
3. अगर site की language needs सीमित हैं, तो fonts subset करें।
4. font-display: swap के साथ local @font-face rules जोड़ें।
5. सभी Google Fonts link, preconnect, और @import references हटाएँ।
6. Long-lived cache headers के साथ fonts को अपने domain से serve करें।
7. Testing support करे तो केवल सबसे important above-the-fold font preload करें।
8. DevTools में verify करें कि कोई Google Fonts requests बाकी नहीं हैं।
9. ज़रूरत हो तो privacy documentation update करें।

Fonts self-host करना glamorous work नहीं है। यह उस तरह का छोटा infrastructure cleanup है जो dependency risk घटाता है, privacy posture सुधारता है, और आपको अधिक predictable rendering देता है। इसमें लगने वाला एक-दो घंटा आम तौर पर सार्थक होता है।