Google Fonts ব্যবহার না করে কীভাবে ফন্ট লোকালি হোস্ট করবেন

কেন Google Fonts নিজে হোস্ট করবেন?

Google Fonts ভালো টাইপোগ্রাফি সহজ করে দিয়েছে। একটি stylesheet যোগ করুন, কয়েকটি weight বেছে নিন, পেজ প্রকাশ করুন। বহু বছর ধরে ছোট টিমের জন্য এটিই ছিল যুক্তিসংগত ডিফল্ট।

সমঝোতাটি হলো, প্রতিটি ভিজিটরের ব্রাউজার font CSS এবং font file আনতে একটি থার্ড-পার্টি সার্ভিসের সঙ্গে যোগাযোগ করে। এর দুটি ফল আছে।

প্রথমত, এটি rendering-এর সঙ্গে একটি বাহ্যিক dependency যোগ করে। কোনো ব্যবহারকারীর অঞ্চল বা নেটওয়ার্কে font CSS ধীর, blocked, বা unavailable হলে আপনার পেজ অপেক্ষা করে বা fallback-এ চলে যায়।

দ্বিতীয়ত, এটি একটি privacy প্রশ্ন তৈরি করে। একটি font request ব্যবহারকারীর IP address, user agent, referrer policy context, এবং timing information একটি থার্ড-পার্টির কাছে প্রকাশ করতে পারে। Google Fonts জানায় যে Fonts API-এর মাধ্যমে এটি cookies সেট করে না, কিন্তু “no cookies” আর “no personal data” এক জিনিস নয়। GDPR-এর অধীনে, প্রেক্ষাপট অনুযায়ী IP address এখনও personal data হতে পারে।

প্রতিটি website-এর জন্য fonts self-hosting স্বয়ংক্রিয়ভাবে প্রয়োজনীয় নয়, এবং এটি আইনি পরামর্শ নয়। তবে European sites, public-sector sites, healthcare, education, finance, অথবা অপ্রয়োজনীয় থার্ড-পার্টি requests কমাতে চাওয়া যেকোনো টিমের জন্য local hosting সাধারণত বেশি পরিচ্ছন্ন পছন্দ।

ভালোভাবে করা হলে এটি প্রায়ই performance-ও উন্নত করে। মূল বিষয় হলো “ভালোভাবে করা হলে।” ছয়টি font file /assets/fonts/-এ কপি করে প্রতিটি পেজে সবগুলো load করা hosted service ব্যবহারের চেয়েও খারাপ হতে পারে। আপনি যদি বিস্তৃত performance context চান, আমাদের আগের লেখা বেশিরভাগ সাইটে web fonts এখনও সবচেয়ে সহজ performance win কেন সাধারণ অপচয়ের patternগুলো ব্যাখ্যা করে।

self-host করলে কী বদলায়

আপনি যখন প্রচলিতভাবে Google Fonts ব্যবহার করেন, আপনার পেজ এটি করে:

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

ব্রাউজার প্রথমে fonts.googleapis.com থেকে CSS request করে, তারপর fonts.gstatic.com থেকে font files ডাউনলোড করে।

আপনি self-host করলে, আপনার পেজের 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;
}

এটি থার্ড-পার্টি font request সরিয়ে দেয়। একই সঙ্গে file formats, cache headers, fallback fonts, এবং updates বেছে নেওয়ার দায়িত্বও আপনার ওপর আসে।

এই দায়িত্বকে গুরুত্ব দিয়ে নেওয়া উচিত। Fonts critical rendering path-এ থাকে। দুর্বল font setup invisible text, layout shifts, এবং slow first render ঘটাতে পারে।

Step 1: আপনি বাস্তবে কী ব্যবহার করেন তা audit করুন

কিছু ডাউনলোড করার আগে, আপনার site-এর সত্যিই প্রয়োজন এমন font families, weights, styles, এবং character sets তালিকাভুক্ত করুন।

একটি সাধারণ marketing site-এ প্রয়োজন হতে পারে:

• body text-এর জন্য Regular 400
• headings এবং buttons-এর জন্য Semibold 600 বা bold 700
• design সত্যিই italics ব্যবহার করলে শুধু Italic 400
• site আরও ভাষা support না করলে শুধু Latin character set

পুরনো design-system defaults নিয়ে সতর্ক থাকুন। অনেক site 300, 400, 500, 600, 700, italics, এবং multiple scripts load করে, কারণ কেউ একবার font picker-এ সেগুলো select করেছিল।

Browser DevTools-এ Network panel খুলুন, “font” দিয়ে filter করুন, page reload করুন, এবং কোন files request হচ্ছে দেখুন। তারপর font-weight usage-এর জন্য আপনার CSS inspect করুন। আপনার CSS যদি কখনও 300 ব্যবহার না করে, 300 host করবেন না।

পরে impact review করলে Lighthouse সাহায্য করতে পারে, কিন্তু এর score-কে পুরো গল্প হিসেবে ধরবেন না। এটিকে diagnostic tool হিসেবে ব্যবহার করুন, বিচারক হিসেবে নয়। font fixes অগ্রাধিকার দেওয়ার সময় কাজে লাগতে পারে এমন একটি আলাদা guide আমাদের আছে: আতঙ্কিত না হয়ে Lighthouse report পড়ার উপায়।

Step 2: সঠিক font files ডাউনলোড করুন

Google Fonts open-source fonts দেয়। আপনি Google Fonts website থেকে বা সংশ্লিষ্ট font project repository থেকে সেগুলো ডাউনলোড করতে পারেন। License পরীক্ষা করুন, তবে বেশিরভাগ Google Fonts SIL Open Font License বা Apache License-এর মতো open licenses-এর অধীনে বিতরণ করা হয়।

Web-এর জন্য WOFF2 পছন্দ করুন। এটি modern browsers-এ ব্যাপকভাবে supported এবং সাধারণত TTF বা OTF-এর তুলনায় অনেক ছোট। 2026 সালে public websites-এর জন্য browsers-এ সরাসরি TTF serve করা খুব কম ক্ষেত্রেই যুক্তিযুক্ত।

একটি যুক্তিসংগত directory structure এমন হতে পারে:

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

বর্ণনামূলক filenames ব্যবহার করুন। ছয় মাস পরে font.woff2 বিরক্তিকর হবে। inter-latin-600.woff2 সাদামাটা এবং উপযোগী।

আপনার site যদি build system ব্যবহার করে, source fonts পরিষ্কার কোনো জায়গায় রাখুন এবং build pipeline দিয়ে optimized files public assets directory-তে copy করান।

Step 3: উপযুক্ত হলে fonts subset করুন

Subsetting মানে আপনার প্রয়োজন নেই এমন characters সরিয়ে দেওয়া। একটি full font-এ Latin, Cyrillic, Greek, Vietnamese, symbols, এবং অনেক OpenType features থাকতে পারে। আপনার English-only landing page-এর যদি শুধু Latin characters প্রয়োজন হয়, subset উল্লেখযোগ্যভাবে ছোট হতে পারে।

দুটি common approach আছে:

1. font provider বা repository থেকে prebuilt subset ব্যবহার করুন।
2. fonttools-এর pyftsubset-এর মতো font tool দিয়ে নিজের subset তৈরি করুন।

অনেক টিমের জন্য prebuilt Latin subsets যথেষ্ট। Custom subsetting তখন উপযোগী, যখন আপনার খুব constrained pages থাকে, যেমন limited text-সহ একটি single campaign page, অথবা predictable character coverage-সহ product UI।

Multilingual sites-এর ক্ষেত্রে সতর্ক থাকুন। Missing glyphs fallback font mixing ঘটায়, যা ভাঙা দেখাতে পারে এবং readability ক্ষতিগ্রস্ত করতে পারে। আপনি যদি multiple languages support করেন, একটিমাত্র tiny subset সব জায়গায় চাপিয়ে দেওয়ার বদলে language routes অনুযায়ী font subsets map করুন।

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

এখানে কয়েকটি detail গুরুত্বপূর্ণ।

বেশিরভাগ content sites-এর জন্য font-display: swap ব্যবহার করুন। এটি browser-কে fallback text দ্রুত দেখাতে বলে, তারপর web font এলে সেটিতে swap করে। এতে FOIT-এর সবচেয়ে খারাপ version—flash of invisible text—এড়ানো যায়।

একটি explicit fallback stack সেট করুন। Custom font fail করলে ব্যবহারকারীরা যেন এখনও readable text পান। Fallbacks কোনো afterthought নয়; এগুলো design-এর অংশ। Sizing, line length, এবং body text choices পুনর্বিবেচনা করতে হলে শুরু করুন modern web-এ readable type-এর একটি practical guide দিয়ে।

Weights সঠিকভাবে match করুন। আপনার CSS যদি font-weight: 500 চায় কিন্তু আপনি শুধু 400 এবং 700 define করেন, browser intermediate weight synthesize করতে পারে। এটি সবসময় ভয়াবহ নয়, তবে inconsistent দেখাতে পারে।

Step 5: বাহ্যিক 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">

এগুলোও পরীক্ষা করুন:

• 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 বিলম্বিত করে। আপনি self-host করলে fonts সরাসরি আপনার main CSS-এ বা early loaded font CSS file-এ define করুন।

Privacy কাজ প্রায়ই ব্যর্থ হয়, কারণ টিমগুলো obvious template ঠিক করে কিন্তু scripts, widgets, এবং legacy embeds মিস করে। Consent কাজেও একই pattern দেখা যায়; আপনি যদি আরও বিস্তৃতভাবে third-party surface area কমান, তাহলে 2026 সালে cookies নিয়ে কী বদলেছে বিষয়ক আমাদের guide একটি উপযোগী সহচর।

Step 6: Cache headers সেট করুন

Font files static assets। filenames versioned বা content-hashed হলে এগুলো aggressive ভাবে cache করা উচিত।

একটি ভালো production header হলো:

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

শুধু তখনই long-lived immutable caching ব্যবহার করুন, যখন file বদলালে URL-ও বদলায়। উদাহরণস্বরূপ:

inter-latin-400.a8f3c2.woff2

অথবা versioned path:

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

আপনি URL না বদলে /fonts/inter-latin-400.woff2 overwrite করলে, কিছু user দীর্ঘ সময় পুরনো file রেখে দিতে পারেন। সমস্যা না হওয়া পর্যন্ত এটি ঠিকই থাকে। Versioning সমস্যা এড়ায়।

সঠিক MIME type সহ fonts serve করুন:

Content-Type: font/woff2

বেশিরভাগ modern hosting platforms এটি automatically handle করে, তবে verify করা ভালো।

Step 7: শুধু critical font preload করার কথা বিবেচনা করুন

Preloading browser-কে গুরুত্বপূর্ণ font আগে discover করতে সাহায্য করতে পারে:

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

এটি সংযতভাবে ব্যবহার করুন। প্রতিটি font weight নয়, primary above-the-fold text font preload করুন। Over-preloading CSS, images, এবং JavaScript-এর সঙ্গে compete করে।

Same-origin fonts হলেও font preloads-এ crossorigin include করুন। Font fetching CORS mode ব্যবহার করে, এবং এটি বাদ দিলে কিছু setup-এ duplicate downloads হতে পারে।

নিশ্চিত না হলে test করুন। কোনো checklist বলেছে বলে preloads cargo-cult করবেন না।

Step 8: Privacy এবং performance test করুন

Testing straightforward।

DevTools খুলুন, cache disabled রেখে page reload করুন, এবং Network panel-এ এগুলোর জন্য filter করুন:

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

আপনার নিজের domain থেকে served font files দেখা উচিত এবং কোনো Google Fonts requests থাকা উচিত নয়।

তারপর cold cache এবং warm cache দিয়ে test করুন। প্রথম visit-এ fonts একবার download হওয়া উচিত। পরের visits-এ browser অনুযায়ী সেগুলো memory বা disk cache থেকে আসা উচিত।

Font swap হওয়ার সময় layout shift হচ্ছে কি না দেখুন। Headings jump করলে, আপনার fallback font metrics web font থেকে অনেক আলাদা। কাছাকাছি fallback বেছে নিয়ে বা size-adjust, ascent-override, descent-override, এবং line-gap-override-এর মতো নতুন CSS font metric overrides ব্যবহার করে visible shift কমানো যায়। এগুলো একটু advanced, তবে polished interfaces-এর জন্য উপযোগী।

শেষে, private browsing-এ বা content blockers enabled রেখে pages test করুন। Self-hosting-এর একটি সুবিধা হলো privacy tools আপনার typography ভুলবশত block করার সম্ভাবনা কম।

এড়ানোর মতো সাধারণ ভুল

অতিরিক্ত weights host করা

এটি সবচেয়ে সাধারণ ব্যর্থতা। দুইটি weights প্রায়ই যথেষ্ট। তিনটি সাধারণত অনেক। শক্ত কারণ না থাকলে পাঁচটি design-system smell।

Italics ভুলে যাওয়া

আপনার content যদি real emphasis ব্যবহার করে, একটি real italic file load করুন। Synthetic italics খারাপ দেখাতে পারে, বিশেষ করে long-form editorial content-এ।

পুরনো Google CSS link রেখে দেওয়া

এতে উদ্দেশ্যটাই ব্যর্থ হয়। Migration-এর পরে, অন্য কোনো component inject না করলে কোনো font request Google-এ যাওয়া উচিত নয়।

Long-term caching ছাড়া fonts serve করা

Self-hosting আপনাকে control দেয়। সেটি ব্যবহার করুন। Fonts long cache lifetimes-এর জন্য আদর্শ candidate।

Legal এবং documentation কাজ উপেক্ষা করা

আপনার privacy policy-তে আগে Google Fonts বা third-party font loading উল্লেখ থাকলে, migration-এর পরে সেটি update করুন। আপনি data-processing inventory maintain করলে সেটিও update করুন। Technical change এবং compliance record একসঙ্গে মেলানো উচিত।

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

💡 এটি চেষ্টা করুন: Google Fonts থেকে ডাউনলোড করা TTF ফাইলগুলোকে Webfont Generator দিয়ে স্ব-হোস্টযোগ্য WOFF2 এবং CSS-এ রূপান্তর করুন।

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

একটি সহজ migration checklist

1. আপনি বাস্তবে যে font families, weights, styles, এবং scripts ব্যবহার করেন তা list করুন।
2. WOFF2 files download করুন এবং license confirm করুন।
3. Site-এর language needs limited হলে fonts subset করুন।
4. font-display: swap সহ local @font-face rules যোগ করুন।
5. সব Google Fonts link, preconnect, এবং @import references সরান।
6. Long-lived cache headers সহ আপনার নিজের domain থেকে fonts serve করুন।
7. Testing support করলে শুধু সবচেয়ে গুরুত্বপূর্ণ above-the-fold font preload করুন।
8. DevTools-এ verify করুন যে কোনো Google Fonts requests বাকি নেই।
9. প্রয়োজন হলে privacy documentation update করুন।

Self-hosting fonts আকর্ষণীয় কাজ নয়। এটি সেই ধরনের ছোট infrastructure cleanup, যা dependency risk কমায়, privacy posture উন্নত করে, এবং rendering আরও predictable করে। এতে সাধারণত যে এক-দুই ঘণ্টা লাগে, তা সার্থক।