FlowingDev

@font-face, explained: ब्राउज़र्स को आपकी typography सिखाना

CSS @font-face rule में महारत हासिल करें ताकि font-display, preloading, unicode-ranges, और variable weights का उपयोग करके custom web fonts को efficiently डिलीवर किया जा सके।

टूल आज़माएँ: @font-face Generator

एक लाइन में

@font-face वो CSS rule है जो वेब browser को custom typography डाउनलोड और render करने की आज़ादी देता है, और आख़िरकार डिज़ाइनर्स को हर कंप्यूटर पर पहले से इंस्टॉल मिलने वाले गिने-चुने "web-safe" fonts के अत्याचार से आज़ाद करता है।

यह कौन सी प्रॉब्लम सॉल्व करता है

अगर आप 90s के आखिर या 2000s की शुरुआत में वेबसाइट्स बना रहे थे, तो web typography एक सूना और बंजर इलाका था। आप पूरी तरह से उन fonts के रहमो-करम पर थे जो यूज़र के ऑपरेटिंग सिस्टम में पड़े होते थे। आप font-family: Arial, Helvetica, sans-serif; लिखते थे और बस भगवान से दुआ करते थे। अगर कोई डिज़ाइनर आपको Photoshop का ऐसा mockup थमा दे जिसमें headlines के लिए एक खूबसूरत, कस्टम serif font हो, तो आपके पास तीन वाहियात ऑप्शंस होते थे:

  1. The Image Hack: Photoshop में headline को स्लाइस करो और उसे <img> टैग की तरह सर्व करो। SEO इससे नफरत करता था। Screen readers इसे देख नहीं सकते थे। बाद में Retina displays ने इन्हें धुंधले कचरे (blurry messes) में बदल दिया।
  2. sIFR (Scalable Inman Flash Replacement): एक शैतानी जुगाड़ (workaround) जो JavaScript का इस्तेमाल करके text ढूंढता था, उसे छुपाता था, और उसकी जगह एक छोटी सी Adobe Flash मूवी embed कर देता था जो बिल्कुल वैसा ही text कस्टम font में render करती थी। यह भारी था, buggy था, और लैपटॉप की बैटरी पी जाता था।
  3. Cufón: एक JavaScript लाइब्रेरी जो font paths को vector graphics में कन्वर्ट करके उन्हें <canvas> पर render करती थी। दिखने में सुंदर, लेकिन आप आसानी से text को सेलेक्ट या कॉपी नहीं कर सकते थे।

W3C ने असल में @font-face को बहुत पहले CSS2 (1998) में ही propose कर दिया था, लेकिन ब्राउज़र्स font formats पर सहमत नहीं हुए, और foundries को पाइरेसी का डर सता रहा था (अगर आपने सर्वर पर .ttf फाइल रख दी, तो कोई भी उसे डाउनलोड कर सकता था)।

2010s के दशक तक, जब Web Open Font Format (WOFF)—एक ऐसा फॉर्मेट जिसे खास तौर पर वेब के लिए compress और तैयार किया गया था—का बड़े पैमाने पर इस्तेमाल शुरू हुआ, तब जाकर @font-face एक प्रैक्टिकल हकीकत बन पाया। आज, @font-face सिर्फ fonts लोड नहीं करता; यह network requests, caching, subsetting, और rendering strategies का एक कॉम्प्लेक्स डांस orchestrate करता है, ताकि आपकी साइट की स्पीड भी सुपरफ़ास्ट रहे और वो दिखे भी बिल्कुल वैसी जैसा डिज़ाइनर ने चाहा था।

यह under the hood कैसे काम करता है

कोर लेवल पर, @font-face सिर्फ instructions का एक सेट है। यह आपके बनाए गए एक नाम को सर्वर पर रखी किसी फाइल से मैप करता है।

Rule की Anatomy

एक मॉडर्न, production-ready @font-face डिक्लेरेशन कुछ ऐसा दिखता है:

@font-face {
  font-family: 'MyAwesomeFont';
  src: local('MyAwesomeFont Regular'), 
       url('/fonts/myawesomefont.woff2') format('woff2');
  font-weight: 400;
  font-style: normal;
  font-display: swap;
  unicode-range: U+0000-00FF;
}

आइए इस ब्लॉक के अंदर के मैजिक को डिकोड करते हैं।

Formats और WOFF2 की मोनोपॉली

format('woff2') पर गौर करें। पुराने ज़माने में (dark ages), डेवलपर्स को .eot (प्राचीन Internet Explorer के लिए), .ttf (पुराने Safari/Android के लिए), .svg (legacy iOS के लिए), और .woff का एक भारी-भरकम "bulletproof" स्टैक देना पड़ता था।

आज, पूरा वेब WOFF2 पर चलता है। यह Brotli compression का इस्तेमाल करता है, जिससे इसका फाइल साइज़ अपने पुराने वर्ज़न WOFF के मुकाबले लगभग 30% छोटा हो जाता है। क्योंकि WOFF2 को लगभग सारे ब्राउज़र्स का सपोर्ट (ग्लोबली 97% से ज़्यादा) हासिल है, इसलिए आपको आमतौर पर सिर्फ़ एक .woff2 फाइल सर्व करने की ज़रूरत होती है, और अगर आपको बहुत पुरानी एंटरप्राइज़ मशीनों को सपोर्ट करना है तो साथ में एक स्टैण्डर्ड WOFF fallback दे सकते हैं।

Flash को कंट्रोल करना (font-display)

जब किसी ब्राउज़र को कस्टम font में स्टाइल किया गया text मिलता है, लेकिन font फाइल अभी तक पूरी तरह डाउनलोड नहीं हुई होती, तो उसे एक फैसला लेना होता है। क्या वह text को fallback font में दिखाए? या फिर जब तक कस्टम font आ नहीं जाता, तब तक text को छुपा कर रखे?

इससे दो बदनाम acronyms पैदा होते हैं: FOUT (Flash of Unstyled Text) और FOIT (Flash of Invisible Text)। font-display डिस्क्रिप्टर आपको इस बिहेवियर को तय करने (dictate) की ताक़त देता है।

font-display Behavior कब इस्तेमाल करें
auto Browser डिफ़ॉल्ट (आमतौर पर 3 सेकंड तक रेंडरिंग को ब्लॉक करता है)। कभी नहीं, अगर आपको परफॉरमेंस की परवाह है।
swap तुरंत fallback font दिखाता है (FOUT), फिर रेडी होने पर कस्टम font से स्वैप कर देता है। Body text, आर्टिकल्स, UI एलिमेंट्स। यूज़र्स तुरंत पढ़ना शुरू कर सकते हैं।
block कुछ देर के लिए text छुपाता है (FOIT), फिर fallback दिखाता है, फिर स्वैप करता है। Icons या लोगोस जहाँ fallback font टूटे हुए कचरे (gibberish) जैसा दिखता है।
fallback छोटा ब्लॉक, छोटा स्वैप पीरियड। अगर बहुत ज़्यादा टाइम लगता है, तो उस पेज लोड के लिए कस्टम font को पूरी तरह abort कर देता है। स्लो कनेक्शन्स पर डेकोरेटिव text के लिए।
optional बहुत ही छोटा ब्लॉक। अगर font कैश्ड नहीं है या सुपरफ़ास्ट नहीं है, तो यह पूरी तरह हार मान लेता है। ऐसे "nice to have" fonts जहाँ लेआउट की स्टेबिलिटी सबसे ज़्यादा ज़रूरी हो।

unicode-range के साथ Subsetting

एक पूरी font फाइल जिसमें Latin, Cyrillic, Greek, और कॉम्प्लेक्स CJK (Chinese, Japanese, Korean) glyphs हों, उसका साइज़ कई मेगाबाइट्स तक हो सकता है।

unicode-range प्रॉपर्टी एक कमाल का ऑप्टिमाइज़ेशन टूल है। यह ब्राउज़र को बताता है, "यह font फाइल सिर्फ़ इन खास कैरेक्टर्स को कवर करती है।" अगर आप unicode-range: U+0000-00FF (Basic Latin) सेट करते हैं, तो ब्राउज़र आपके HTML को पार्स करेगा। अगर उसे कोई Latin कैरेक्टर नहीं मिलता, तो वो font फाइल डाउनलोड ही नहीं करेगा। इससे आप भारी-भरकम fonts को छोटी, भाषा के हिसाब से बंटी हुई बाइट-साइज़ फाइलों में तोड़ सकते हैं, और यूज़र को सिर्फ़ वही लोड करवा सकते हैं जिसकी उसे असल में ज़रूरत है।

Variable Fonts

पहले के समय में, अगर आपको Regular, Italic, Bold, और Bold Italic चाहिए होता था, तो आपको चार अलग-अलग .woff2 फाइलें लोड करनी पड़ती थीं।

Variable fonts "axes of variation" को डिफाइन करके पूरी की पूरी फैमिली को एक ही फाइल में बंडल कर देते हैं। 400 या 700 जैसे स्टैटिक weights के बजाय, एक variable font को 432 या 781 के weight पर भी रेंडर किया जा सकता है। 

@font-face {
  font-family: 'MyVariableFont';
  src: url('/fonts/myfont-var.woff2') format('woff2');
  font-weight: 100 900; /* Accepts any weight between 100 and 900 */
}

Base64 Embedding बनाम Preloading

कभी-कभी नेटवर्क रिक्वेस्ट अपने आप में ही एक bottleneck बन जाती है। ऐसे में आपके पास दो एडवांस्ड स्ट्रैटेजीज़ होती हैं:

  1. Preloading: अपने HTML के <head> में <link rel="preload" href="/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin> डालना ब्राउज़र को यह आदेश देता है कि CSS डाउनलोड करने से पहले ही, font को तुरंत fetch कर ले।
  2. Base64 Embedding: आप बाइनरी font फाइल को एक विशाल text स्ट्रिंग में कन्वर्ट करके सीधे अपने @font-face रूल के url() में पेस्ट कर सकते हैं। यह नेटवर्क रिक्वेस्ट को पूरी तरह से खत्म कर देता है, लेकिन CSS फाइल के साइज़ को करीब 33% बढ़ा देता है। यह पूरे पेज के रेंडर को तब तक ब्लॉक रखता है जब तक CSS डाउनलोड न हो जाए, इसलिए इसे सख़्ती से सिर्फ़ बहुत छोटे, हाइपर-ऑप्टिमाइज़्ड सबसेट fonts (जैसे कोई कस्टम लोगो) के लिए ही रिज़र्व रखा जाता है।

असली दुनिया की कहानियाँ

ई-कॉमर्स का गायब बटन

एक बुटीक ई-कॉमर्स साइट ने अपने यूज़र इंटरफ़ेस के लिए एक कस्टम icon font यूज़ करने का फैसला किया। उन्होंने बिना font-display के एक स्टैण्डर्ड @font-face डिक्लेरेशन इस्तेमाल किया। ऑफिस के फ़ास्ट Wi-Fi कनेक्शन पर सब कुछ शानदार दिख रहा था।

हालाँकि, 3G नेटवर्क वाले मोबाइल यूज़र्स साइट से रिकॉर्ड रेट पर बाउंस हो रहे थे। जब डेवलपर्स ने स्लो नेटवर्क सिम्युलेट किया, तो असली मुजरिम सामने आया: ब्राउज़र "Add to Cart" बटन रेंडर करने से पहले icon font के लोड होने का इंतज़ार कर रहा था। इसके नतीजे में 4-सेकंड का Flash of Invisible Text (FOIT) हो रहा था। यूज़र्स को कंपनी को पैसा देने के लिए बटन दिख ही नहीं रहा था। text के लिए सिर्फ़ font-display: swap; जोड़ना और icon font को preload करना उनके conversion rate को बचा ले गया।

मल्टी-मेगाबाइट Typography की ट्रैजेडी

एक पॉपुलर टेक ब्लॉग ने internationalization सपोर्ट करने का सोचा। उनकी स्लीक typography कंसिस्टेंट रहे, इसके लिए उन्होंने एक भारी-भरकम Noto Sans font जोड़ दिया जो पूरे CJK (Chinese, Japanese, Korean) कैरेक्टर्स को कवर करता था। font फाइल लगभग 6MB की थी।

अचानक, US में प्लेन इंग्लिश आर्टिकल्स पढ़ने वाले यूज़र्स सुस्त लोड टाइम्स की शिकायत करने लगे। उनके ब्राउज़र्स JavaScript के बारे में एक आर्टिकल पढ़ने के लिए 6MB के जापानी और कोरियन glyphs डाउनलोड कर रहे थे। टीम ने unicode-range इम्प्लीमेंट किया। उन्होंने font को एक 30KB के Latin सबसेट और एक 5.9MB के CJK सबसेट में बाँट दिया। ब्राउज़र ने इंग्लिश रीडर्स के लिए अपने आप सिर्फ़ 30KB की फाइल रिक्वेस्ट की, और परफॉरमेंस की समस्या तुरंत ठीक हो गई।

झटकेदार रिडिज़ाइन

एक डिज़ाइन एजेंसी ने क्लासिक sans-serif font के नौ अलग-अलग weights का इस्तेमाल करके एक बेहतरीन एडिटोरियल लेआउट तैयार किया। डेवलपर ने पूरी मेहनत से नौ अलग-अलग .woff2 फाइलें एक्सपोर्ट कीं और नौ @font-face रूल्स लिखे।

चूँकि ब्राउज़र्स फाइलों को asynchronously डाउनलोड करते हैं, पेज झटके खाते हुए (stutter) लोड होता था। 300 weight लोड होता, फिर 700, फिर 400, जिससे लेआउट अजीब तरीके से हिलता था और एक सेकंड में चार-पाँच बार text रैपिंग को रीकैलकुलेट करता था। डेवलपर ने उन नौ फाइलों को हटाकर एक सिंगल Variable Font (.woff2-variations) लगा दिया। वह सिंगल फाइल उन नौ फाइलों के कुल साइज़ से 40% छोटी थी, एक ही रिक्वेस्ट में लोड हो गई, और पूरे पेज को एक सिंगल, स्मूथ पेंट में रेंडर कर दिया।

सामान्य गलतियाँ और जाल

  • मॉडर्न ब्राउज़र्स को प्राचीन font formats सर्व करना: .ttf, .eot, और .svg fonts सर्व करना बंद करें, जब तक कि आपके पास IE8 या दस साल पुराने Android डिवाइस को सपोर्ट करने की कोई ठोस, डेटा-ड्रिवन वजह न हो। सिर्फ WOFF2 पर टिके रहें।
  • Preloads पर crossorigin भूल जाना: अगर आप किसी font के लिए <link rel="preload"> इस्तेमाल करते हैं, तो आपको crossorigin एट्रिब्यूट ज़रूर लगाना चाहिए, भले ही font आपके अपने डोमेन पर होस्टेड हो। ब्राउज़र की सिक्योरिटी स्पेसिफिकेशन्स के कारण, fonts एनोनिमस मोड CORS का इस्तेमाल करके fetch किए जाते हैं। अगर आप यह एट्रिब्यूट छोड़ देते हैं, तो ब्राउज़र font को दो बार डाउनलोड करेगा।
  • भारी-भरकम body fonts को Base64 एन्कोड करना: एक 100KB के font को सीधे अपने CSS में embed करने से आपका CSS पेलोड सूज (inflate) जाता है और रेंडरिंग ब्लॉक हो जाती है। सिर्फ़ बहुत छोटे fonts को एन्कोड करें (जैसे लोगो के लिए यूज़ होने वाला 5KB का सबसेट)।
  • font-display को इग्नोर करना: ब्राउज़र डिफ़ॉल्ट्स के भरोसे बैठना लगभग हमेशा स्लो कनेक्शन्स वाले यूज़र्स को सज़ा देता है। रीडिंग को एस्थेटिक्स से ज़्यादा प्रायोरिटी देने के लिए body text के लिए साफ़ तौर पर font-display: swap डिक्लेयर करें।
  • पेज के हर font को preload करना: Preloading एक हाई-प्रायोरिटी इंस्ट्रक्शन है। अगर आप किसी ऐसे bold, italic हेडलाइन font को preload करते हैं जो पेज में सबसे नीचे है, तो आप पेज के टॉप को लोड करने के लिए ज़रूरी क्रिटिकल JavaScript और CSS से नेटवर्क बैंडविड्थ चुरा रहे हैं। सिर्फ़ "hero" font को ही preload करें।
  • local() पर हद से ज़्यादा भरोसा करना: local('Helvetica') का इस्तेमाल ब्राउज़र को यह बताता है कि अगर लोकल कॉपी मौजूद है तो उसे यूज़ करे। लेकिन, Mac, Windows, और Linux के बीच font नेमिंग कन्वेंशन्स बहुत अलग होते हैं। जो आपको local('Helvetica Neue Bold') लगता है, वो किसी दूसरे OS पर चुपचाप फेल हो सकता है।

यह आपके रडार पर क्यों होना चाहिए

वेब डेवलपमेंट हमेशा से एस्थेटिक्स और परफॉरमेंस के बीच एक रस्साकशी रहा है। आप एक ब्रांड बना रहे हैं, और typography उस ब्रांड की आवाज़ है। लेकिन आप सॉफ्टवेयर भी बना रहे हैं, और किसी खराब सबवे कनेक्शन वाले यूज़र के लिए एक-एक किलोबाइट मायने रखता है।

एकदम परफेक्ट @font-face रूल लिखना कुख्यात रूप से थकाऊ (tedious) काम है। इसके लिए ब्राउज़र quirks, MIME types, subsetting सिंटैक्स, और कम्प्रेशन फॉर्मेट्स की गहरी समझ चाहिए। एक मॉडर्न जनरेटर सिर्फ़ आपके लिए CSS सिंटैक्स नहीं लिखता; वह बेस्ट प्रैक्टिसेस को एन्कोड करता है। यह अपने आप WOFF2 फाइलें जनरेट करता है, वेरिएबल axes स्ट्रक्चर करता है, सही font-display fallbacks अप्लाई करता है, और नेटवर्क bottlenecks को बायपास करने के लिए बिलकुल सटीक Base64 या preload टैग्स आउटपुट करता है। यह सुनिश्चित करता है कि जब आपकी एप्लीकेशन बोले, तो ब्राउज़र को असल में पता हो कि शब्दों का उच्चारण कैसे करना है।

और गहराई में जाएँ

  • MDN Web Docs: @font-face - रूल के सिंटैक्स और कम्पैटिबिलिटी पर सबसे भरोसेमंद गाइड।
  • W3C CSS Fonts Module Level 4 - ऑफिशियल स्पेसिफिकेशन जो बताता है कि ब्राउज़र्स @font-face, variable fonts, और fallback मैकेनिज़्म को कैसे लागू करते हैं।
  • Optimize WebFont loading and rendering (web.dev) - web fonts, FOIT, और FOUT के परफॉरमेंस पर पड़ने वाले असर के बारे में Google की ऑफिशियल गाइड।
  • MDN Variable Fonts Guide - variable web fonts के इस्तेमाल के फायदों और सिंटैक्स की गहरी जानकारी (deep dive)।
  • W3C Specification for font-display - ब्राउज़र्स font रेंडरिंग टाइमलाइन को कैसे मैनेज करते हैं, इसकी सटीक टेक्निकल डिटेल्स।

थ्योरी हो गई। अब हाथ आज़माइए — 100% आपके ब्राउज़र में।

टूल आज़माएँ: @font-face Generator