पिछले मॉड्यूल में, आपने एचटीएमएल, सीएसएस, JavaScript, और मीडिया रिसॉर्स को ऑप्टिमाइज़ करने का तरीका सीखा. इस मॉड्यूल में, वेब फ़ॉन्ट ऑप्टिमाइज़ करने के कुछ तरीके खोजें.
वेब फ़ॉन्ट, पेज लोड होने और रेंडरिंग के समय, दोनों पर पेज की परफ़ॉर्मेंस पर असर डाल सकते हैं.
बड़ी फ़ॉन्ट फ़ाइलों को डाउनलोड होने में कुछ समय लग सकता है. इससे फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) पर बुरा असर पड़ सकता है. वहीं, font-display
वैल्यू गलत होने से, पेज के कुल लेआउट शिफ़्ट
(सीएलएस) में अनचाहे लेआउट शिफ़्ट हो सकते हैं.
वेब फ़ॉन्ट को ऑप्टिमाइज़ करने से पहले, हम उनके बारे में चर्चा कर सकते हैं. इसमें आपको यह जानने में मदद मिल सकती है कि ब्राउज़र में इन्हें कैसे खोजा जाता है. इससे यह समझने में मदद मिलेगी कि सीएसएस, कुछ स्थितियों में ग़ैर-ज़रूरी वेब फ़ॉन्ट को वापस लाने से कैसे रोकती है.
डिस्कवरी कैंपेन
पेज के वेब फ़ॉन्ट @font-face
एलान का इस्तेमाल करके स्टाइल शीट में तय किए जाते हैं:
@font-face {
font-family: "Open Sans";
src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2");
}
पिछला कोड स्निपेट, "Open Sans"
नाम के font-family
के बारे में बताता है. साथ ही, यह ब्राउज़र को बताता है कि वेब फ़ॉन्ट रिसॉर्स को कहां ढूंढना है. बैंडविड्थ को बनाए
रखने के लिए, ब्राउज़र वेब फ़ॉन्ट तब तक डाउनलोड नहीं करता, जब तक यह तय न हो जाए कि
मौजूदा पेज के लेआउट को इसकी ज़रूरत है.
h1 {
font-family: "Open Sans";
}
पिछले सीएसएस स्निपेट में, ब्राउज़र "Open Sans"
फ़ॉन्ट फ़ाइल डाउनलोड करता है, क्योंकि यह पेज के एचटीएमएल में मौजूद <h1>
एलिमेंट को पार्स करता है.
preload
अगर आपके @font-face
एलान किसी बाहरी स्टाइल शीट में बताए गए हैं, तो ब्राउज़र उन्हें स्टाइल शीट डाउनलोड करने के बाद ही डाउनलोड करना शुरू कर सकता है.
इससे वेब फ़ॉन्ट को देर से खोजे जाने वाले संसाधन मिलते हैं—लेकिन ब्राउज़र को जल्द ही वेब फ़ॉन्ट खोजने में मदद करने के ऐसे तरीके भी हैं.
preload
डायरेक्टिव का इस्तेमाल करके, वेब फ़ॉन्ट रिसॉर्स के लिए शुरुआती अनुरोध किया जा सकता है. preload
डायरेक्टिव, पेज लोड होने के दौरान वेब फ़ॉन्ट को खोजे जाने लायक बनाता है. ऐसा होने पर, ब्राउज़र तुरंत उन्हें डाउनलोड करना शुरू कर देता है. इसके लिए, स्टाइल शीट के डाउनलोड और पार्स होने का इंतज़ार नहीं किया जाता. preload
डायरेक्टिव, तब तक इंतज़ार नहीं करता, जब तक पेज पर फ़ॉन्ट की ज़रूरत नहीं होती.
<!-- The `crossorigin` attribute is required for fonts—even
self-hosted ones, as fonts are considered CORS resources. -->
<link rel="preload" as="font" href="/fonts/OpenSans-Regular-webfont.woff2" crossorigin>
@font-face
एलानों को इनलाइन करें
आपके पास, पेज लोड होने के दौरान, अपने एचटीएमएल के <head>
में <style>
एलिमेंट का इस्तेमाल करके, @font-face
एलानों के साथ-साथ रेंडर-ब्लॉक करने वाले सीएसएस को इनलाइन करके, फ़ॉन्ट को खोजे जाने लायक बनाया जा सकता है. इस स्थिति में, ब्राउज़र, पेज के लोड होने की शुरुआत में ही वेब फ़ॉन्ट खोज लेता है, क्योंकि उसे किसी बाहरी स्टाइल शीट के डाउनलोड होने तक इंतज़ार करने की ज़रूरत नहीं होती.
@font-face
एलानों को इनलाइन करने के लिए, preload
संकेत का इस्तेमाल करने से ज़्यादा फ़ायदा मिलता है. ऐसा इसलिए, क्योंकि ब्राउज़र सिर्फ़ मौजूदा पेज को रेंडर करने के लिए ज़रूरी फ़ॉन्ट डाउनलोड करता है. इससे इस्तेमाल न किए गए फ़ॉन्ट डाउनलोड करने का जोखिम खत्म हो जाता है.
डाउनलोड करें
वेब फ़ॉन्ट को खोजने और मौजूदा पेज के लेआउट के हिसाब से उनकी ज़रूरत को पक्का करने के बाद, ब्राउज़र उन्हें डाउनलोड कर सकता है. वेब फ़ॉन्ट की संख्या, उनकी एन्कोडिंग, और उनके फ़ाइल आकार से इस बात पर काफ़ी असर पड़ सकता है कि ब्राउज़र से वेब फ़ॉन्ट कितनी तेज़ी से डाउनलोड और रेंडर किया जाता है.
अपने वेब फ़ॉन्ट खुद होस्ट करें
वेब फ़ॉन्ट, Google Fonts जैसी तीसरे पक्ष की सेवाओं की मदद से दिखाए जा सकते हैं. इसके अलावा, इन्हें आपके ऑरिजिन पर खुद होस्ट किया जा सकता है. तीसरे पक्ष की सेवा का इस्तेमाल करते समय, ज़रूरी वेब फ़ॉन्ट डाउनलोड करने से पहले, आपके वेब पेज को सेवा देने वाली कंपनी के डोमेन से कनेक्ट करना होगा. इससे वेब फ़ॉन्ट को खोजने और बाद में उन्हें डाउनलोड करने में देरी हो सकती है.
preconnect
रिसॉर्स संकेत का इस्तेमाल करके, इस ओवरहेड को कम किया जा सकता है. preconnect
का इस्तेमाल करके, ब्राउज़र को क्रॉस-ऑरिजिन से कनेक्शन जल्दी खोलने के लिए कहा जा सकता है, जबकि आम तौर पर ऐसा करने से:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
पिछला एचटीएमएल स्निपेट, ब्राउज़र को fonts.googleapis.com
से और सीओआरएस कनेक्शन को fonts.gstatic.com
से कनेक्ट करने के लिए संकेत देता है. कुछ फ़ॉन्ट प्रोवाइडर—जैसे कि Google Fonts, अलग-अलग ऑरिजिन से सीएसएस और फ़ॉन्ट रिसॉर्स दिखाते हैं.
अपने वेब फ़ॉन्ट को खुद होस्ट करके, तीसरे पक्ष के कनेक्शन की ज़रूरत को खत्म किया जा सकता है. ज़्यादातर मामलों में, किसी क्रॉस-ऑरिजिन से वेब फ़ॉन्ट डाउनलोड करने के बजाय, खुद से होस्ट किए जाने वाले वेब फ़ॉन्ट को ज़्यादा तेज़ी से डाउनलोड किया जाता है. अगर आपको वेब फ़ॉन्ट खुद होस्ट करना है, तो देख लें कि आपकी साइट कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन), एचटीटीपी/2 या एचटीटीपी/3 का इस्तेमाल कर रही हो. साथ ही, अपनी वेबसाइट के लिए ज़रूरी वेब फ़ॉन्ट को कैश मेमोरी में सेव करने के लिए सही हेडर सेट करें.
सिर्फ़ WOFF2 और सिर्फ़ WOFF2 का इस्तेमाल करें
WOFF2 पर सभी ब्राउज़र पर काम करता है. साथ ही, कंप्रेस करने की बेहतरीन सुविधा भी मिलती है, जो WOFF से 30% बेहतर है. फ़ाइल का साइज़ कम होने से, फ़ाइलों को डाउनलोड करने में कम समय लगता है. आधुनिक ब्राउज़र में पूरी तरह काम करने के लिए, आम तौर पर सिर्फ़ WOFF2 फ़ॉर्मैट की ज़रूरत होती है.
अपने वेब फ़ॉन्ट का सबसेट सेट करना
आम तौर पर, वेब फ़ॉन्ट में कई तरह के ग्लिफ़ शामिल होते हैं. ये अलग-अलग भाषाओं में इस्तेमाल किए जाने वाले वर्णों की संख्या को दिखाने के लिए ज़रूरी होते हैं. अगर आपके पेज पर सिर्फ़ एक भाषा में कॉन्टेंट दिखाया जाता है या एक ही वर्णमाला का इस्तेमाल किया जाता है, तो सब-सेटिंग की मदद से अपने वेब फ़ॉन्ट का साइज़ कम किया जा सकता है. ऐसा अक्सर किसी संख्या—या कई तरह के—यूनिकोड कोड पॉइंट के बारे में बताकर किया जाता है.
सबसेट, ग्लिफ़ का छोटा किया गया सेट है जिसे ओरिजनल वेब फ़ॉन्ट फ़ाइल में शामिल किया गया था. उदाहरण के लिए, सभी ग्लिफ़ दिखाने के बजाय, हो सकता है कि आपका पेज लैटिन वर्णों के लिए एक खास सबसेट दिखा दे. ज़रूरी सबसेट के हिसाब से, ग्लिफ़ हटाने से फ़ॉन्ट फ़ाइल का साइज़ काफ़ी कम हो सकता है.
वेब फ़ॉन्ट की सेवा देने वाली कुछ कंपनियां, जैसे कि Google Fonts में, क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके अपने-आप सबसेट ऑफ़र करती हैं. उदाहरण के लिए,
https://fonts.googleapis.com/css?family=Roboto&subset=latin
यूआरएल, Roboto वेब फ़ॉन्ट के साथ ऐसी स्टाइल शीट दिखाता है जिसमें सिर्फ़ लैटिन वर्णमाला का इस्तेमाल किया गया है.
अगर आपने अपने वेब फ़ॉन्ट खुद होस्ट करने का फ़ैसला किया है, तो अगला चरण glyphanger या सबफ़ॉन्ट जैसे टूल का इस्तेमाल करके खुद से ही सबसेट जनरेट करना और होस्ट करना है.
हालांकि, अगर आपके पास अपने वेब फ़ॉन्ट खुद होस्ट करने की सुविधा नहीं है, तो
Google Fonts से मिलने वाले वेब फ़ॉन्ट को सब-सेट किया जा सकता है. इसके लिए, आपको एक और text
क्वेरी स्ट्रिंग पैरामीटर तय करना होगा जिसमें सिर्फ़ आपकी वेबसाइट के लिए ज़रूरी यूनिकोड कोड पॉइंट शामिल हों. उदाहरण के लिए, अगर आपकी साइट पर डिसप्ले वेब फ़ॉन्ट में "आपका स्वागत है" वाक्यांश के लिए, बहुत कम वर्णों की ज़रूरत होती है, तो Google Fonts में इसके सबसेट का अनुरोध करने के लिए, इस यूआरएल का इस्तेमाल करें:
https://fonts.googleapis.com/css?family=Monoton&text=Welcome
. इससे आपकी वेबसाइट पर सिंगल टाइपफ़ेस के लिए, वेब फ़ॉन्ट डेटा की मात्रा बहुत कम हो सकती है.
फ़ॉन्ट रेंडरिंग
ब्राउज़र जब किसी वेब फ़ॉन्ट को खोजकर उसे डाउनलोड कर लेता है, तब उसे
रेंडर किया जा सकता है. डिफ़ॉल्ट रूप से ब्राउज़र, वेब फ़ॉन्ट का इस्तेमाल करने वाले किसी भी टेक्स्ट को तब तक रेंडर नहीं करता, जब तक उसे डाउनलोड नहीं किया जाता. ब्राउज़र के टेक्स्ट रेंडरिंग के तरीके में बदलाव किया जा सकता है. साथ ही, यह कॉन्फ़िगर किया जा सकता है कि font-display
सीएसएस प्रॉपर्टी का इस्तेमाल करके, वेब फ़ॉन्ट पूरी तरह लोड होने तक कौनसा टेक्स्ट दिखाया जाए या नहीं दिखाया जाए.
block
font-display
की डिफ़ॉल्ट वैल्यू block
है. block
में, ब्राउज़र, दिए गए वेब फ़ॉन्ट का इस्तेमाल करने वाले किसी भी टेक्स्ट को रेंडर होने से रोकता है. अलग-अलग ब्राउज़र थोड़ा अलग तरीके से काम करते हैं. फ़ॉलबैक का इस्तेमाल करने से पहले Chromium और Firefox ज़्यादा से ज़्यादा तीन सेकंड तक रेंडरिंग को ब्लॉक करते हैं. जब तक वेब फ़ॉन्ट लोड नहीं हो जाता, तब तक Safari हमेशा के लिए ब्लॉक कर देता है.
swap
swap
, font-display
की सबसे ज़्यादा इस्तेमाल की जाने वाली वैल्यू है. swap
, रेंडरिंग को ब्लॉक नहीं करता है. साथ ही, तय किए गए वेब फ़ॉन्ट में बदलने से पहले, टेक्स्ट को फ़ॉलबैक में तुरंत दिखाता है. इससे वेब फ़ॉन्ट के डाउनलोड होने का इंतज़ार किए बिना, अपना कॉन्टेंट तुरंत दिखाया जा सकता है.
हालांकि, swap
में एक समस्या यह है कि अगर आपकी सीएसएस में बताए गए फ़ॉलबैक वेब फ़ॉन्ट और वेब फ़ॉन्ट में लाइन की ऊंचाई, कर्निंग, और अन्य फ़ॉन्ट मेट्रिक के हिसाब से काफ़ी अंतर होता है, तो इससे लेआउट शिफ़्ट होता है. इसका असर आपकी वेबसाइट के सीएलएस पर पड़ सकता है. ऐसा तब होता है, जब जितना हो सके, वेब फ़ॉन्ट रिसॉर्स लोड करने के लिए preload
संकेत का इस्तेमाल न करें या font-display
की दूसरी वैल्यू का इस्तेमाल न करें.
fallback
font-display
के लिए fallback
वैल्यू,
block
और swap
के बीच का फ़र्क़ है. swap
के उलट, ब्राउज़र किसी फ़ॉन्ट को रेंडर होने से रोकता है. हालांकि, बहुत कम समय के लिए फ़ॉलबैक टेक्स्ट को आपस में बदलें. block
की तरह, हालांकि, ब्लॉक करने की अवधि बहुत कम होती है.
fallback
वैल्यू का इस्तेमाल करके तेज़ी से लोड होने वाले नेटवर्क पर अच्छी तरह से काम किया जा सकता है. ऐसा इसलिए है, क्योंकि अगर वेब फ़ॉन्ट तेज़ी से डाउनलोड होता है, तो वेब फ़ॉन्ट, वह टाइपफ़ेस है जो पेज की शुरुआती रेंडरिंग के समय इस्तेमाल होता है. हालांकि, अगर नेटवर्क धीमा है, तो ब्लॉक करने की अवधि खत्म होने के बाद, फ़ॉलबैक टेक्स्ट पहले देखा जा सकता है. इसके बाद, वेब फ़ॉन्ट आने पर, इसे बदल दिया जाता है.
optional
optional
, सबसे ज़्यादा सख्त font-display
वैल्यू होती है. यह वेब फ़ॉन्ट रिसॉर्स का इस्तेमाल सिर्फ़ तब करती है, जब वह 100 मिलीसेकंड में डाउनलोड हो जाती है. अगर किसी वेब फ़ॉन्ट को लोड होने में ज़्यादा समय लगता है, तो पेज पर उसका इस्तेमाल नहीं किया जाता है. साथ ही, ब्राउज़र मौजूदा नेविगेशन के लिए फ़ॉलबैक टाइपफ़ेस का इस्तेमाल करता है, जबकि वेब फ़ॉन्ट को बैकग्राउंड में डाउनलोड करके, ब्राउज़र की कैश मेमोरी में रखा जाता है.
नतीजे के तौर पर, बाद के पेज नेविगेशन में तुरंत वेब फ़ॉन्ट इस्तेमाल किया जा सकता है, क्योंकि
यह पहले से डाउनलोड है. font-display: optional
, swap
के साथ दिखने वाले लेआउट शिफ़्ट से बचता है. हालांकि, अगर वेब के शुरुआती पेज नेविगेशन में वेब फ़ॉन्ट तय समय से ज़्यादा देर से उपलब्ध होता है, तो कुछ उपयोगकर्ताओं को उन्हें नहीं दिखता.
फ़ॉन्ट डेमो
देखें कि आपको कितना ज्ञान है
ब्राउज़र, वेब फ़ॉन्ट रिसॉर्स कब डाउनलोड करता है (यह मानते हुए कि उसे preload
डायरेक्टिव के साथ फ़ेच नहीं किया जाता)?
सभी मॉडर्न ब्राउज़र पर वेब फ़ॉन्ट दिखाने के लिए, एकमात्र (और सबसे असरदार) फ़ॉर्मैट कौनसा है?
अगला चरण: कोड-स्प्लिट JavaScript
अपने बेल्ट में फ़ॉन्ट ऑप्टिमाइज़ेशन के बारे में जानने के बाद, अब अगले मॉड्यूल पर जाया जा सकता है. इस मॉड्यूल में, आपके उपयोगकर्ताओं के लिए शुरुआती पेज लोड होने की स्पीड बेहतर हो सकती है. साथ ही, कोड स्प्लिटिंग की मदद से JavaScript को लोड होने से रोका जा सकता है. ऐसा करके, किसी पेज के चालू होने के दौरान, आपके बैंडविथ और सीपीयू के बीच के विवाद को जितना हो सके उतना कम रखा जा सकता है. यह ऐसा समय होता है जब उपयोगकर्ताओं की इससे इंटरैक्ट करने की संभावना काफ़ी कम हो जाती है.