font-display swap क्या है: web font बिना layout shift के

font-display swap की तुलना block, fallback और optional से, साथ में font preload, Google Fonts बनाम self-hosting और size-adjust fallbacks।

इस लेख में

font-display: swap browser को कहता है कि text तुरंत fallback font में दिखाए, और web font जब भी आए तब उसे बदल दे। यह अदृश्य text के इंतज़ार को हटाता है, पर layout shift नहीं हटाता: जब web font fallback से चौड़ा या ऊँचा हो, तो swap के समय text दोबारा लगता है। तेज़ text और स्थिर layout, दोनों पाने के लिए swap सेट करें, font जल्दी लोड करें, और size-adjust से fallback font का आकार web font से मिलाएँ। नीचे के हिस्सों में font-display की पाँच values की तुलना है, और हर चरण का कोड।

font-display swap क्या करता है

swap font face को “बहुत छोटा block period और असीमित swap period” देता है (MDN, आखिरी बार 10 सितंबर 2026 को बदला गया)। सीधी भाषा में, text ज़्यादा देर तक छिपा नहीं रहता, और web font जब भी लोड पूरा हो, चाहे एक मिनट बाद ही क्यों न हो, इस्तेमाल होता है।

MDN इन दो अवधियों को ऐसे परिभाषित करता है। block period में, जो element ऐसा font इस्तेमाल करता है जो लोड नहीं हुआ, उसे अदृश्य fallback से दिखाना होता है। swap period में वह दिखने वाले fallback से दिखता है, और जो font समय पर लोड हो जाए वह सामान्य रूप से इस्तेमाल होता है। आम नाम हैं FOIT (flash of invisible text, यानी block period) और FOUT (flash of unstyled text, यानी swap)।

font-display न लिखने पर browser खुद तय करता है। web.dev की font guide (अक्टूबर 2022) के अनुसार Chromium पर आधारित browsers और Firefox, अगर font लोड न हो, तो 3 सेकंड तक text रोकते हैं, और Safari इसे अनिश्चित काल तक रोकता है (web.dev)। इसे उन versions का व्यवहार मानें और जिन browsers को आप सपोर्ट करते हैं उन्हें जाँचें।

font-display जनवरी 2020 से नई Baseline सुविधा है और जुलाई 2022 से व्यापक रूप से उपलब्ध है; web-features इसे Chrome 60, Firefox 58, Safari 11.1 और Safari iOS 11.3 से सूचीबद्ध करता है (web-features 3.44.0, 22 अक्टूबर 2026)।

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

font-display की values की तुलना

पाँचों values का फ़र्क इस बात में है कि text कितनी देर अदृश्य रहता है, और देर से आने वाले font को कितनी देर तक बदला जा सकता है। web.dev की तालिका से periods:

Value Block period Swap period किसके लिए
auto browser तय करता है browser तय करता है कोई स्पष्ट चुनाव नहीं (default)
block 2 से 3 सेकंड असीमित शायद ही कभी: font लोड होते समय text छिपा रहता है
swap 0 ms असीमित headings और brand text, जो web font इस्तेमाल करें
fallback 100 ms 3 सेकंड समझौता: छोटा block period, छोटा swap period
optional 100 ms कोई नहीं body text, जहाँ सटीक font से ज़्यादा स्थिर layout मायने रखता है
font-display के मानों की ब्लॉक और स्वैप अवधि: auto ब्राउज़र पर निर्भर है, block 2 से 3 s टेक्स्ट छिपाता है, swap में ब्लॉक अवधि नहीं है, fallback 100 ms रोकता है और 3 s तक स्वैप होने देता है, optional 100 ms रोकता है और स्वैप नहीं करता

web.dev swap सुझाता है जब text तुरंत दिखना चाहिए और web font में दिखना चाहिए, बशर्ते font इतनी जल्दी पहुँचे कि layout shift न हो। सबसे अच्छा प्रदर्शन optional देता है, पर इसकी कीमत यह है कि web font देर से आए तो इस्तेमाल नहीं होगा। web.dev branding और खास elements के लिए swap, और body text के लिए optional सुझाता है (web.dev)। यह बँटवारा सिफ़ारिश है; कोई specification इसे अनिवार्य नहीं करती।

Lighthouse भी यह जाँचता है। उसका Font display insight (अक्टूबर 2025) माँगता है कि text दिखता रहे इसके लिए font-display को swap या optional सेट करें, और swap के लिए layout shift घटाने हेतु font metrics overrides का सुझाव देता है (Chrome for Developers)।

जो font ज़रूरी है उसे preload करें

Preload font का download पहले शुरू करता है, जिससे fallback पर बिताया समय घटता है। self-hosted font के preload के लिए as="font", MIME type और crossorigin चाहिए:

<link rel="preload" href="/fonts/brand.woff2" as="font" type="font/woff2" crossorigin>

MDN कहता है कि font preload के लिए crossorigin ज़रूरी है, और उसे request के CORS mode से मेल खाना होगा, “भले ही fetch cross-origin न हो”, क्योंकि fonts anonymous CORS mode में लिए जाते हैं (MDN, मई 2026)।

Preload केवल वही करें जो पहली स्क्रीन को चाहिए। web.dev चेतावनी देता है कि preload unicode-range declarations को नज़रअंदाज़ करता है, इसलिए सावधानी से इस्तेमाल करें तो एक ही font format लोड करें। जो fonts तुरंत नहीं चाहिए उनके लिए इसे छोड़ दें। Preload जनवरी 2021 से नई Baseline सुविधा है और जुलाई 2023 से व्यापक रूप से उपलब्ध (web-features 3.44.0)।

Google Fonts या self-hosting

Google Fonts के लिए stylesheet URL में display parameter जोड़ें, और दोनों font origins से जल्दी connect करें:

<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=Crimson+Pro&display=swap" rel="stylesheet">

display parameter वही पाँच values लेता है, और Google का documentation कहता है कि default auto है और आम तौर पर कोई दूसरी value बेहतर होती है (Google Fonts, जुलाई 2024 अपडेट)। font files के preconnect पर crossorigin चाहिए, क्योंकि “stylesheets के विपरीत, font files को CORS connection पर भेजा जाना चाहिए” (web.dev)।

Google Fonts तेज़ है या self-hosting? web.dev कहता है कि अंतर उतना “साफ़” नहीं जितना दिखता है: उसके उद्धृत Web Almanac डेटा में third-party fonts first-party fonts से तेज़ रेंडर हुए, और self-hosting CDN और HTTP/2 के साथ जीतने की ज़्यादा संभावना रखता है। self-host करें तो optimization की ज़िम्मेदारी आपकी है: WOFF2 दें (web.dev के अनुसार यह WOFF से 30% बेहतर compress होता है), unicode-range से subset करें, और पहले font का license जाँचें।

fallback font से layout shift रोकें

swap पर layout shift इसलिए होता है क्योंकि fallback font और web font के metrics अलग हैं, और समाधान है fallback को उसके हिसाब से समायोजित करना। web.dev की CLS guide “उन fonts को जो अपने शुरुआती fallback से बड़े या छोटे रेंडर होते हैं” layout shifts का कारण गिनती है, और अच्छा CLS मान 0.1 या कम है (web.dev, अप्रैल 2023)। सभी कारणों के बारे में और जानने के लिए cumulative layout shift गाइड देखें।

संकरे फ़ॉलबैक फ़ॉन्ट में हेडलाइन दो पंक्तियों में आती है; चौड़ा वेब फ़ॉन्ट आने पर वह तीन पंक्तियों में हो जाती है और नीचे का बटन खिसक जाता है, यही लेआउट शिफ्ट है

उपकरण एक दूसरा @font-face है जो local font की ओर इशारा करता है और उसे scale करता है। size-adjust glyph outlines और metrics को प्रतिशत से scale करता है, और ascent-override, descent-override और line-gap-override line box तय करते हैं:

@font-face {
  font-family: "Poppins fallback";
  src: local("Arial");
  size-adjust: 60.85%;
}

body {
  font-family: "Poppins", "Poppins fallback", sans-serif;
}

60.85% एक font जोड़ी, Poppins और Arial, के लिए है, इसलिए अपना मान आपको निकालना होगा। Chrome का लेख कहता है कि size-adjust web font की औसत character width को fallback की औसत character width से भाग देकर मिलता है (यहाँ 538.01 / 884.14 = 60.85%), और यह ज़्यादातर मामलों में केवल अनुमान हो सकता है; तीन override descriptors web font के ascent, descent और line gap को units per em और size-adjust के मान से भाग देकर निकाले जाते हैं। इन्हें अपने font के लिए उस लेख (फ़रवरी 2023 अपडेट) में बताए tools से निकालें: Fontaine, Capsize, next/font (Next 13 से), या @nuxtjs/fontaine (Chrome for Developers)। भरोसा करने से पहले browser में नतीजा जाँचें।

MDN browser-compat-data 8.1.7 (अक्टूबर 2026) के अनुसार descriptor के हिसाब से समर्थन:

Descriptor Chrome Firefox Safari
size-adjust 92 92 17
ascent-override, descent-override, line-gap-override 87 89 समर्थित नहीं

web-features तीनों overrides को Baseline में नहीं रखता, इसलिए iPhone पर Safari उन्हें नज़रअंदाज़ करता है और थोड़ा shift अब भी हो सकता है। fallback font भी device के हिसाब से बदलता है: Chrome का लेख बताता है कि Android के Roboto fallback को Arial से अलग मान चाहिए।

फ़ोन पर LCP text पर असर

जब सबसे बड़ा element text हो, तब web fonts Largest Contentful Paint को देर कर सकते हैं। web.dev की LCP guide कहती है कि text को तभी रेंडर माना जाता है जब block period खत्म हो; इसलिए web font वाला text दिखने तक कोई छोटा element LCP के रूप में रिपोर्ट हो सकता है। वह <p> और <h1> जैसे block-level text elements को LCP उम्मीदवार मानती है, और अच्छा LCP 2.5 सेकंड या कम है (web.dev, सितंबर 2025)।

जिस पेज का LCP web font वाला heading है, वहाँ धीमे फ़ोन नेटवर्क पर font का download बाकी सब से होड़ करता है, इसलिए swap या preload की मेहनत के लायक है। LCP element कैसे पढ़ें, यह Lighthouse मोबाइल audit गाइड में है, और LCP धीमा होने के दूसरे कारण मोबाइल पेज स्पीड टेस्ट गाइड में।

फ़ोन-आकार के पेज पर नतीजा जाँचें

बदलाव के बाद cold load पर पेज देखें। फ़ोन की चौड़ाई पर cache बंद करके reload करें और देखें कि font आने पर heading उछलता है या नहीं। Mobile View Extension tab को फ़ोन के user agent, screen size और pixel ratio के साथ दोबारा लोड करता है, इसलिए आप mobile layout और कौन सा fallback font दिख रहा है, यह देख सकते हैं। यह लोड समय, layout shift या किसी speed metric को नहीं नापता, और आपके desktop के fonts और connection का इस्तेमाल करता है, इसलिए फ़ोन का fallback font अलग दिख सकता है। Lighthouse और field data से नापें।

अक्सर पूछे जाने वाले सवाल

font-display swap क्या करता है?

यह text को तुरंत fallback font में दिखाता है, और font लोड होने पर उसे web font से बदल देता है; यह बदलाव कितनी भी देर से हो, उस पर कोई सीमा नहीं। block period बेहद छोटा है और swap period असीमित (MDN)।

font-display में swap बेहतर है या optional?

हर जगह कोई भी बेहतर नहीं: swap हमेशा आपके web font पर खत्म होता है, पर layout को हिला सकता है; optional shift रोकता है, पर धीमे लोड पर web font छोड़ सकता है। web.dev branding के लिए swap और body text के लिए optional सुझाता है।

क्या font-display swap layout shift का कारण बनता है?

बन सकता है। जब fallback और web font के metrics अलग हों, तो swap text का आकार और line height बदलता है और content को हिला सकता है, जिसे web.dev layout shifts का कारण गिनता है। size-adjust से fallback मिलाने पर यह असर घटता है।

क्या web fonts को preload करना चाहिए?

पहली स्क्रीन को चाहिए वाले एक या दो fonts को as="font" और crossorigin के साथ preload करें। web.dev इसे संयम से इस्तेमाल करने की सलाह देता है, क्योंकि preload unicode-range को नज़रअंदाज़ करता है।

अपनी अगली वेबसाइट को मोबाइल व्यू में देखें।

मोबाइल व्यू Chrome एक्सटेंशन जोड़ें और जिस टैब पर आप काम कर रहे हैं, उसी के डिवाइस प्रीव्यू खोलें।