टाइम टू फ़र्स्ट बाइट मेट्रिक को ऑप्टिमाइज़ करने का तरीका जानें.
टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी), वेब परफ़ॉर्मेंस की बुनियादी मेट्रिक है. यह उपयोगकर्ता अनुभव की हर बेहतर मेट्रिक से पहले मिलती है. जैसे, फ़र्स्ट कॉन्टेंटफ़ुल पेंट (एफ़सीपी) और सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी). इसका मतलब है कि ज़्यादा टीटीएफ़बी वैल्यू वाली मेट्रिक की वजह से, इसे फ़ॉलो करने वाली मेट्रिक को ज़्यादा समय तक देखा जा सकता है.
हमारा सुझाव है कि आपका सर्वर, नेविगेशन के अनुरोधों का जवाब तेज़ी से दे, ताकि उपयोगकर्ताओं के 75वें पर्सेंटाइल को "अच्छी" थ्रेशोल्ड के अंदर एफ़सीपी का अनुभव हो. मोटे तौर पर, यह ज़रूरी है कि ज़्यादातर साइटों को 0.8 सेकंड या उससे कम टीटीएफ़बी बनाना चाहिए.
टीटीएफ़बी को मेज़र करने का तरीका
टीटीएफ़बी को ऑप्टिमाइज़ करने से पहले, आपको यह जानना होगा कि इसका आपकी वेबसाइट के उपयोगकर्ताओं पर क्या असर पड़ता है. आपको TTFB को देखने के मुख्य स्रोत के रूप में फ़ील्ड डेटा पर भरोसा करना चाहिए, क्योंकि रीडायरेक्ट से प्रभावित होता है, जबकि लैब में काम करने वाले टूल का आकलन अक्सर फ़ाइनल यूआरएल का इस्तेमाल करके किया जाता है. इसलिए, यह अतिरिक्त देरी नहीं दिखती.
PageSpeed Insights, ऐसी सार्वजनिक वेबसाइटों के लिए फ़ील्ड और लैब, दोनों की जानकारी पाने का एक तरीका है जो Chrome के लिए उपयोगकर्ता अनुभव से जुड़ी रिपोर्ट में उपलब्ध है.
असली उपयोगकर्ताओं के लिए TTFB, पता लगाएं कि आपके असली उपयोगकर्ताओं को कैसा अनुभव मिल रहा है सेक्शन में दिखाया जाता है:
सर्वर रिस्पॉन्स टाइम ऑडिट में टीटीएफ़बी का सबसेट दिखाया गया है:
फ़ील्ड और लैब, दोनों में टीटीएफ़बी को मापने के ज़्यादा तरीकों के बारे में जानने के लिए, टीटीएफ़बी मेट्रिक पेज देखें.
Server-Timing की मदद से फ़ील्ड में ज़्यादा टीटीएफ़बी को डीबग करें
Server-Timing रिस्पॉन्स हेडर का इस्तेमाल आपके ऐप्लिकेशन बैकएंड में उन अलग-अलग बैकएंड प्रोसेस को मापने के लिए किया जा सकता है जिनकी वजह से इंतज़ार का समय बढ़ सकता है. हेडर वैल्यू के स्ट्रक्चर में ज़रूरत के हिसाब से बदलाव होता है. साथ ही, यह आपके तय किए गए हैंडल के हिसाब से भी काम करता है. वैकल्पिक वैल्यू में dur के ज़रिए अवधि की वैल्यू शामिल होती है. साथ ही, desc की मदद से ऐसी जानकारी शामिल होती है जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है.
Serving-Timing का इस्तेमाल, कई ऐप्लिकेशन बैकएंड प्रोसेस को मेज़र करने के लिए किया जा सकता है. हालांकि, कुछ ऐसी प्रोसेस हैं जिन पर आपको खास ध्यान देने की ज़रूरत पड़ सकती है:
- डेटाबेस क्वेरी
- सर्वर साइड रेंडरिंग में लगने वाला समय, अगर लागू हो
- डिस्क आगे-पीछे करना
- Edge सर्वर कैश मेमोरी हिट/मिस (अगर सीडीएन का इस्तेमाल कर रहे हैं)
Server-Timing एंट्री के सभी हिस्से कोलन लगाकर अलग किए जाते हैं और एक से ज़्यादा एंट्री को कॉमा लगाकर अलग किया जा सकता है:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
हेडर को आपके ऐप्लिकेशन बैकएंड की पसंद की भाषा का इस्तेमाल करके सेट किया जा सकता है. उदाहरण के लिए, PHP में हेडर को इस तरह सेट किया जा सकता है:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStarTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
जब यह हेडर सेट होता है, तब यह ऐसी जानकारी दिखाएगा जिसका इस्तेमाल लैब और फ़ील्ड, दोनों में किया जा सकता है.
फ़ील्ड में, Server-Timing रिस्पॉन्स हेडर सेट वाला कोई भी पेज, नेविगेशन समय एपीआई में serverTiming प्रॉपर्टी को अपने-आप भर देगा:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
लैब में, Server-Timing रिस्पॉन्स हेडर का डेटा, Chrome DevTools में नेटवर्क टैब के टाइम पैनल में दिखेगा:
Chrome DevTools के नेटवर्क टैब में, Server-Timing रिस्पॉन्स हेडर को विज़ुअलाइज़ किया गया है. यहां, Server-Timing का इस्तेमाल यह मापने के लिए किया जाता है कि किसी संसाधन का अनुरोध, सीडीएन कैश में हिट हुआ है या नहीं. साथ ही, यह भी पता लगाया जाता है कि अनुरोध को सीडीएन के एज सर्वर और उसके बाद ऑरिजिन पर पहुंचने में कितना समय लगता है.
एक बार उपलब्ध डेटा का विश्लेषण करके यह पक्का कर लें कि आपके पास समस्या वाला TTFB है, तो आप उस समस्या को ठीक कर सकते हैं.
TTFB को ऑप्टिमाइज़ करने के तरीके
TTFB को ऑप्टिमाइज़ करने का सबसे चुनौतीपूर्ण पहलू यह है कि वेब के फ़्रंटएंड स्टैक हमेशा एचटीएमएल, सीएसएस, और JavaScript वाले होते हैं, लेकिन बैकएंड स्टैक में काफ़ी अंतर हो सकता है. ऐसे बहुत सारे बैकएंड स्टैक और डेटाबेस प्रॉडक्ट हैं जिनकी अपनी ऑप्टिमाइज़ेशन तकनीकें होती हैं. इसलिए, यह गाइड सिर्फ़ स्टैक से जुड़े दिशा-निर्देशों पर फ़ोकस करने के बजाय, ज़्यादातर आर्किटेक्चर पर लागू होने वाली चीज़ों पर फ़ोकस करेगी.
प्लैटफ़ॉर्म के हिसाब से सलाह
अपनी वेबसाइट के लिए जिस प्लैटफ़ॉर्म का इस्तेमाल किया जाता है उससे टीटीएफ़बी पर काफ़ी असर पड़ सकता है. उदाहरण के लिए, WordPress की परफ़ॉर्मेंस पर, प्लगिन की संख्या, क्वालिटी या इस्तेमाल की जाने वाली थीम का असर पड़ता है. जब प्लैटफ़ॉर्म को पसंद के मुताबिक बनाया जाता है, तो दूसरे प्लैटफ़ॉर्म पर भी इसका असर पड़ता है. वेंडर से जुड़ी सलाह पाने के लिए, अपने प्लैटफ़ॉर्म के दस्तावेज़ देखें. इससे आपको इस पोस्ट में दी गई सामान्य परफ़ॉर्मेंस से जुड़ी सलाह मिल सकती है. सर्वर से जवाब मिलने में लगने वाले समय को कम करने के लिए, लाइटहाउस ऑडिट में स्टैक से जुड़े सीमित निर्देश भी शामिल किए गए हैं.
होस्टिंग, होस्टिंग, होस्टिंग
ऑप्टिमाइज़ेशन के अन्य तरीकों के बारे में सोचने से पहले, आपको होस्टिंग का ध्यान रखना चाहिए. यहां कुछ खास निर्देश नहीं दिए जा सकते, लेकिन एक सामान्य नियम यह पक्का करना है कि आपकी वेबसाइट का होस्ट, आपके वेबसाइट पर भेजे जाने वाले ट्रैफ़िक को मैनेज कर सके.
शेयर की गई होस्टिंग सेवा आम तौर पर धीमी होगी. अगर आपके पास कोई ऐसी छोटी निजी वेबसाइट है जिसमें ज़्यादातर स्टैटिक फ़ाइलें दिखती हैं, तो यह ठीक रहता है. साथ ही, फ़ॉलो की जाने वाली कुछ ऑप्टिमाइज़ेशन तकनीकों से टीटीएफ़बी को जितना हो सके उतना कम करने में मदद मिलेगी.
हालांकि, अगर कई उपयोगकर्ताओं वाला कोई बड़ा ऐप्लिकेशन चलाया जा रहा है, जिसमें मनमुताबिक बनाना, डेटाबेस क्वेरी करना, और सर्वर साइड से की जाने वाली अन्य कार्रवाइयां शामिल हैं, तो फ़ील्ड में टीटीएफ़बी को कम करने के लिए होस्टिंग का विकल्प अहम हो जाता है.
सर्वर देने वाली संस्था चुनते समय, इन बातों का ध्यान रखें:
- आपके ऐप्लिकेशन के इंस्टेंस को कितनी मेमोरी असाइन की गई है? अगर आपके ऐप्लिकेशन में कम मेमोरी है, तो उसकी मेमोरी कम हो जाएगी और उसे पेजों को तेज़ी से लोड करने में परेशानी होगी.
- क्या सर्वर देने वाली संस्था, आपके बैकएंड स्टैक को अप-टू-डेट रखती है? ऐप्लिकेशन की बैकएंड भाषाओं, एचटीटीपी लागू करने, और डेटाबेस सॉफ़्टवेयर के नए वर्शन रिलीज़ होने पर, समय के साथ उस सॉफ़्टवेयर की परफ़ॉर्मेंस बेहतर होगी. यह ज़रूरी है कि होस्टिंग की सेवा देने वाली किसी ऐसी कंपनी के साथ साझेदारी की जाए जो इस तरह के ज़रूरी रखरखाव को प्राथमिकता देती हो.
- अगर आपकी ऐप्लिकेशन में कुछ खास ज़रूरतें हैं और आपको सर्वर कॉन्फ़िगरेशन फ़ाइलों का सबसे निचले लेवल का ऐक्सेस चाहिए, तो पूछें कि अपने ऐप्लिकेशन इंस्टेंस के बैकएंड को पसंद के मुताबिक बनाना है या नहीं.
ऐसी कई कंपनियां हैं जो आपके लिए इन चीज़ों का ध्यान रखेंगे. हालांकि, अगर आपको होस्टिंग की सेवा देने वाली मौजूदा कंपनियों के मुकाबले लंबी TTFB वैल्यू दिखने लगती है, तो इसका मतलब यह हो सकता है कि आपको अपने मौजूदा होस्टिंग प्रोवाइडर की क्षमताओं का फिर से आकलन करना होगा, ताकि आप उपयोगकर्ताओं को बेहतर अनुभव दे सकें.
कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) का इस्तेमाल करना
सीडीएन के इस्तेमाल से जुड़ा विषय, पहले से मौजूद है. हालांकि, इसकी खास वजह हो सकती है: आपके पास एक बहुत अच्छी तरह से ऑप्टिमाइज़ किया गया ऐप्लिकेशन बैकएंड हो सकता है, लेकिन आपके ऑरिजिन सर्वर से दूर रहने वाले उपयोगकर्ताओं को फ़ील्ड में अब भी ज़्यादा टीटीएफ़बी का सामना करना पड़ सकता है.
सीडीएन, सर्वर के डिस्ट्रिब्यूटेड नेटवर्क का इस्तेमाल करके आपके ऑरिजिन सर्वर से उपयोगकर्ता की नज़दीकी की समस्या को हल करते हैं. ये सर्वर, सर्वर के उन संसाधनों को कैश मेमोरी में सेव करते हैं जो आपके उपयोगकर्ताओं के करीब होते हैं. इन सर्वर को एज सर्वर कहा जाता है.
सीडीएन सेवा देने वाली कंपनियां, एज सर्वर के अलावा भी कई फ़ायदे दे सकती हैं:
- सीडीएन सेवा देने वाली कंपनियां आम तौर पर, बहुत तेज़ी से डीएनएस रिज़ॉल्यूशन की सुविधा देती हैं.
- सीडीएन, एचटीटीपी/2 या एचटीटीपी/3 जैसे मॉडर्न प्रोटोकॉल का इस्तेमाल करके, एज सर्वर से आपका कॉन्टेंट पेश करेगा.
- एचटीटीपी/3 खास तौर पर यूडीपी प्रोटोकॉल का इस्तेमाल करके, टीसीपी में मौजूद हेड-ऑफ़-लाइन ब्लॉक करने की समस्या (जिस पर एचटीटीपी/2 निर्भर करता है) को हल करता है.
- सीडीएन, TLS का मॉडर्न वर्शन भी उपलब्ध कराएगा. इससे, TLS से बातचीत के दौरान इंतज़ार का समय कम हो जाता है. खास तौर पर, TLS 1.3 को इस तरह से डिज़ाइन किया गया है कि TLS की मदद से होने वाले मोल-भाव को जितना हो सके उतना छोटा रखा जा सके.
- सीडीएन सेवा देने वाली कुछ कंपनियां, अक्सर "एज वर्कर" नाम की सुविधा उपलब्ध कराती हैं. यह सुविधा Service Worker API से मिलते-जुलते एपीआई का इस्तेमाल करती है. इसकी मदद से, अनुरोधों को रोका जाता है, एज कैश मेमोरी में रिस्पॉन्स को प्रोग्राम के हिसाब से मैनेज किया जाता है या जवाबों को फिर से लिखा जाता है.
- सीडीएन प्रोवाइडर, कंप्रेशन के लिए ऑप्टिमाइज़ करने में काफ़ी अच्छे होते हैं. अपने-आप कंप्रेस करने की प्रोसेस मुश्किल होती है. हालांकि, डाइनैमिक तरीके से जनरेट हुए मार्कअप की वजह से, कुछ मामलों में जवाब मिलने में ज़्यादा समय लग सकता है. इस तरह के मार्कअप को तुरंत कंप्रेस करना ज़रूरी होता है.
- सीडीएन प्रोवाइडर, स्टैटिक रिसॉर्स के लिए कंप्रेस किए गए जवाबों को अपने-आप कैश मेमोरी में सेव करेंगे. इससे, कंप्रेस करने का अनुपात और रिस्पॉन्स टाइम का बेहतर कॉम्बिनेशन मिलता है.
सीडीएन अपनाने में आसान से लेकर अहम लग सकते हैं, लेकिन अगर आपकी वेबसाइट पहले से ही टीटीएफ़बी का इस्तेमाल नहीं कर रही है, तो इसे ऑप्टिमाइज़ करने के लिए अपनी प्राथमिकता तय करनी चाहिए.
जहां भी मुमकिन हो वहां, कैश मेमोरी में सेव किए गए कॉन्टेंट का इस्तेमाल किया
सीडीएन, कॉन्टेंट को एज सर्वर पर कैश मेमोरी में सेव करने की अनुमति देते हैं. ये ऐसे सर्वर होते हैं जो वेबसाइट पर आने वाले लोगों के नज़दीक होते हैं. हालांकि, इसके लिए ज़रूरी है कि कॉन्टेंट को सही Cache-Control एचटीटीपी हेडर के साथ कॉन्फ़िगर किया गया हो. यह दर्शकों की पसंद को ध्यान में रखकर बनाए गए कॉन्टेंट के लिए सही नहीं है, लेकिन ऑरिजिन पर वापस जाने से सीडीएन की वैल्यू काफ़ी कम हो सकती है.
ऐसी साइटों के लिए जो अपना कॉन्टेंट बार-बार अपडेट करती हैं, भले ही उनके कैश मेमोरी में कम समय लगे, इस वजह से व्यस्त साइटों की परफ़ॉर्मेंस बेहतर हो सकती है. इसकी वजह यह है कि इस दौरान, ऑरिजिन सर्वर पर सिर्फ़ पहले आने वाले व्यक्ति को ही पूरी तरह से इंतज़ार के समय का अनुभव मिलता है. हालांकि, वेबसाइट पर आने वाले दूसरे सभी लोग किनारे के सर्वर से कैश मेमोरी में सेव किए गए रिसॉर्स का फिर से इस्तेमाल कर सकते हैं. कुछ सीडीएन, साइट रिलीज़ पर कैश मेमोरी को अमान्य करने की अनुमति देते हैं. इससे, यह दोनों तरीकों का बेहतर तरीके से इस्तेमाल किया जा सकता है. हालांकि, कैश मेमोरी में ज़्यादा समय लगता है, लेकिन ज़रूरत पड़ने पर तुरंत अपडेट हो जाता है.
यहां तक कि कैशिंग को सही तरीके से कॉन्फ़िगर किए जाने पर भी, आंकड़ों के मेज़रमेंट के लिए, यूनीक क्वेरी स्ट्रिंग पैरामीटर का इस्तेमाल करके इसे अनदेखा किया जा सकता है. सीडीएन के लिए, एक जैसा कॉन्टेंट अलग-अलग लग सकता है. इस वजह से, कैश मेमोरी में सेव किया गया वर्शन इस्तेमाल नहीं किया जाएगा.
ऐसा हो सकता है कि पुराने या कम देखे गए कॉन्टेंट को कैश मेमोरी में सेव न किया जाए. इसकी वजह से कुछ पेजों पर अन्य पेजों के मुकाबले ज़्यादा TTFB वैल्यू मिल सकती है. कैश मेमोरी में सेव होने का समय बढ़ाने से, इसके असर को कम किया जा सकता है. हालांकि, इस बात का ध्यान रखें कि कैश मेमोरी में डेटा ज़्यादा समय तक सेव रखने पर, ऐसा कॉन्टेंट दिखने की संभावना बढ़ जाती है जो पुराना हो सकता है.
कैश मेमोरी में सेव किए गए कॉन्टेंट का असर, सिर्फ़ सीडीएन इस्तेमाल करने वालों पर ही नहीं पड़ता. कैश मेमोरी में सेव किए गए कॉन्टेंट को दोबारा इस्तेमाल न करने पर, सर्वर इन्फ़्रास्ट्रक्चर को महंगे डेटाबेस लुकअप से कॉन्टेंट जनरेट करना पड़ सकता है. अक्सर ऐक्सेस किए जाने वाले डेटा या पहले से कैश मेमोरी में सेव किए गए पेजों की परफ़ॉर्मेंस अक्सर बेहतर होती है.
एक से ज़्यादा पेज पर रीडायरेक्ट करने से बचें
बहुत ज़्यादा टीटीएफ़बी में होने वाला एक आम योगदान रीडायरेक्ट है. रीडायरेक्ट तब होते हैं, जब किसी दस्तावेज़ के लिए नेविगेशन के अनुरोध को ऐसा रिस्पॉन्स मिलता है जिससे ब्राउज़र को पता चलता है कि संसाधन किसी दूसरी जगह पर मौजूद है. एक रीडायरेक्ट, नेविगेशन के अनुरोध में इंतज़ार का समय ज़रूर जोड़ सकता है. हालांकि, अगर वह रीडायरेक्ट किसी ऐसे रिसॉर्स पर ले जाता है जिसकी वजह से एक और रीडायरेक्ट शुरू होता है, तो यह प्रोसेस और भी खराब हो सकती है. इसका असर खास तौर पर उन साइटों पर पड़ सकता है जिन्हें विज्ञापनों या न्यूज़लेटर से बड़ी संख्या में लोग मिलते हैं. इसकी वजह यह है कि वे मेज़रमेंट के लिए, अक्सर आंकड़ों की सेवाओं का इस्तेमाल करती हैं. डायरेक्ट कंट्रोल में रीडायरेक्ट को बंद करने से, एक अच्छा टीटीएफ़बी हासिल करने में मदद मिल सकती है.
रीडायरेक्ट दो तरह के होते हैं:
- सेम-ऑरिजिन रीडायरेक्ट, जहां आपकी वेबसाइट पर पूरी तरह से रीडायरेक्ट होता है.
- क्रॉस-ऑरिजिन रीडायरेक्ट, जहां रीडायरेक्ट शुरुआत में किसी दूसरे ऑरिजिन पर होता है. उदाहरण के लिए, आपकी वेबसाइट पर पहुंचने से पहले. जैसे, सोशल मीडिया के यूआरएल को छोटा करने वाली किसी सेवा से.
आपको एक ही ऑरिजिन वाले रीडायरेक्ट को हटाने पर फ़ोकस करना है, क्योंकि इस पर आपका सीधा कंट्रोल होगा. इसमें आपको अपनी वेबसाइट पर मौजूद लिंक की जांच करके यह देखना होगा कि उनमें से किसी लिंक की वजह से, 302 या 301 रिस्पॉन्स कोड तो नहीं मिल रहा है. अक्सर ऐसा https:// स्कीम को शामिल न करने की वजह से हो सकता है (इसलिए, ब्राउज़र डिफ़ॉल्ट रूप से http:// पर सेट हो जाते हैं, जो बाद में रीडायरेक्ट हो जाते हैं) या बाद में लगने वाले स्लैश, यूआरएल में सही तरीके से शामिल नहीं किए जाते या उन्हें बाहर नहीं रखा जाता.
क्रॉस-ऑरिजिन रीडायरेक्ट काफ़ी मुश्किल काम होते हैं, क्योंकि ये अक्सर आपके कंट्रोल से बाहर होते हैं. हालांकि, जहां हो सके वहां एक से ज़्यादा रीडायरेक्ट से बचने की कोशिश करें. उदाहरण के लिए, लिंक शेयर करते समय कई लिंक छोटा करने वाले टूल का इस्तेमाल करना. पक्का करें कि विज्ञापन देने वालों या न्यूज़लेटर को दिया गया यूआरएल सही फ़ाइनल यूआरएल हो. ऐसा इसलिए, ताकि उन सेवाओं में इस्तेमाल होने वाले रीडायरेक्ट के यूआरएल में दूसरा रीडायरेक्ट न जोड़ा जाए.
रीडायरेक्ट समय का एक और अहम सोर्स, एचटीटीपी-टू-एचटीटीपीएस रीडायरेक्ट से हो सकता है. इससे बचने का एक तरीका यह है कि आप Strict-Transport-Security हेडर (एचएसटीएस) का इस्तेमाल करें. यह ऑरिजिन की पहली विज़िट पर ही एचटीटीपीएस को लागू करेगा. इसके बाद, आने वाले समय में वेबसाइट पर आने वाले लोगों के लिए, एचटीटीपीएस स्कीम से तुरंत ऑरिजिन ऐक्सेस करने के लिए ब्राउज़र को बताएगा.
एचएसटीएस की अच्छी नीति लागू करने के बाद, अपनी साइट को एचएसटीएस प्रीलोड सूची में जोड़कर, साइट पर पहली बार विज़िट करने के दौरान तेज़ी से काम किया जा सकता है.
ब्राउज़र पर मार्कअप स्ट्रीम करें
स्ट्रीम होने के दौरान, मार्कअप को बेहतर तरीके से प्रोसेस करने के लिए ब्राउज़र ऑप्टिमाइज़ किए जाते हैं. इसका मतलब है कि सर्वर से मार्कअप होते ही उसे अलग-अलग हिस्सों में मैनेज किया जाता है. बड़े मार्कअप पेलोड की समस्या के लिए यह ज़रूरी है. इसका मतलब है कि ब्राउज़र, मार्कअप के हिस्सों को धीरे-धीरे पार्स कर सकता है. यह पार्स करने से पहले, पूरी तरह से जवाब आने का इंतज़ार नहीं करता.
हालांकि, स्ट्रीमिंग मार्कअप को हैंडल करने के लिए ब्राउज़र बहुत अच्छे होते हैं, लेकिन इसके लिए यह ज़रूरी है कि आप स्ट्रीम में होने वाली बातचीत को जारी रखें, ताकि मार्कअप के शुरुआती हिस्से जल्द से जल्द ऐक्सेस किए जा सकें. अगर बैकएंड में कोई समस्या है, तो इसमें समस्या है. बैकएंड स्टैक कई तरह के होते हैं. इसलिए, हर स्टैक और हर स्टैक में आने वाली समस्याओं के बारे में जानकारी देना, इस गाइड के दायरे से बाहर की बात है.
उदाहरण के लिए, प्रतिक्रिया देने वाले और ऐसे दूसरे फ़्रेमवर्क ने सर्वर-साइड रेंडरिंग के लिए सिंक्रोनस तरीके का इस्तेमाल किया है जो सर्वर पर मांग पर मार्कअप रेंडर कर सकते हैं. हालांकि, React के नए वर्शन में स्ट्रीमिंग मार्कअप के लिए सर्वर के तरीके लागू किए गए हैं, क्योंकि यह रेंडर हो रहा है. इसका मतलब है कि आपको जवाब को भेजने से पहले, React Server API का इस्तेमाल करके पूरे जवाब को रेंडर करने के लिए इंतज़ार करने की ज़रूरत नहीं है.
ब्राउज़र पर मार्कअप तेज़ी से स्ट्रीम हो, यह पक्का करने का एक और तरीका है स्टैटिक रेंडरिंग पर भरोसा करना, जो बिल्ड के दौरान एचटीएमएल फ़ाइलें जनरेट करता है. पूरी फ़ाइल तुरंत उपलब्ध होने पर, वेब सर्वर तुरंत फ़ाइल भेजना शुरू कर सकते हैं और एचटीटीपी की इस तरह की समस्या की वजह से स्ट्रीमिंग मार्कअप हो जाएगा. यह तरीका हर वेबसाइट के हर पेज के लिए सही नहीं होता, जैसे कि ऐसे पेज जिन्हें उपयोगकर्ता अनुभव के तौर पर डाइनैमिक रिस्पॉन्स की ज़रूरत होती है. हालांकि, यह उन पेजों के लिए फ़ायदेमंद हो सकता है जिन पर किसी व्यक्ति को अपनी पसंद के मुताबिक मार्कअप बनाने की ज़रूरत नहीं होती.
सर्विस वर्कर का इस्तेमाल करना
Service Worker API, दस्तावेज़ और लोड होने वाले संसाधनों, दोनों के लिए TTFB पर काफ़ी असर डाल सकता है. इसकी वजह यह है कि सर्विस वर्कर, ब्राउज़र और सर्वर के बीच प्रॉक्सी के तौर पर काम करता है. हालांकि, आपकी वेबसाइट के TTFB पर असर पड़ता है या नहीं, यह इस बात पर निर्भर करता है कि आपने सर्विस वर्कर को कैसे सेट अप किया है और वह सेट अप आपके ऐप्लिकेशन की ज़रूरी शर्तों के मुताबिक है या नहीं.
- ऐसेट के लिए, फिर से पुष्टि करते समय पुरानी रणनीति का इस्तेमाल करें. अगर कोई ऐसेट सर्विस वर्कर कैश में है, चाहे दस्तावेज़ के लिए ज़रूरी दस्तावेज़ या संसाधन हो, तो दोबारा पुष्टि करने के दौरान पुरानी हो चुकी रणनीति से उस रिसॉर्स को पहले कैश मेमोरी से डाउनलोड किया जाएगा. इसके बाद, उस ऐसेट को बैकग्राउंड में डाउनलोड किया जाएगा और आने वाले समय में होने वाले इंटरैक्शन के लिए कैश मेमोरी से सेव किया जाएगा.
- अगर आपके पास दस्तावेज़ में मौजूद ऐसे संसाधन हैं जो अक्सर बदलते नहीं हैं, तो दोबारा पुष्टि करने के दौरान पुरानी जानकारी वाली रणनीति का इस्तेमाल करने से, पेज का TTFB तुरंत बन सकता है. हालांकि, अगर आपकी वेबसाइट डाइनैमिक रूप से जनरेट किया गया मार्कअप भेजती है, तो यह ठीक से काम नहीं करता. उदाहरण के लिए, ऐसा मार्कअप जो उपयोगकर्ता की पुष्टि किए जाने के आधार पर बदलता है. ऐसे मामलों में, आपको हमेशा नेटवर्क को पहले हिट करना चाहिए, ताकि दस्तावेज़ जितना हो सके उतना नया हो.
- अगर आपका दस्तावेज़ ऐसे गैर-ज़रूरी संसाधन लोड करता है जो कुछ समय के बाद बदलते हैं, लेकिन पुराने संसाधन फ़ेच करने से उपयोगकर्ता अनुभव पर ज़्यादा असर नहीं पड़ेगा, जैसे कि चुनिंदा इमेज या अन्य संसाधन जो बहुत ज़रूरी नहीं हैं, तो दोबारा पुष्टि करने की पुरानी रणनीति का इस्तेमाल करके उन संसाधनों के लिए TTFB को काफ़ी कम किया जा सकता है.
- क्लाइंट के रेंडर किए गए ऐप्लिकेशन के लिए, ऐप्लिकेशन शेल मॉडल का इस्तेमाल करें. यह मॉडल उन एसपीए के लिए सबसे सही होता है जहां सर्विस वर्कर कैश से पेज का "शेल" तुरंत डिलीवर किया जा सकता है. साथ ही, पेज का डाइनैमिक कॉन्टेंट, पेज के लाइफ़साइकल के दौरान अपने-आप पॉप्युलेट होता है और रेंडर होता है.
ज़रूरी संसाधनों को रेंडर करने के लिए 103 Early Hints का इस्तेमाल करें
आपके ऐप्लिकेशन के बैकएंड को चाहे कितनी भी अच्छी तरह से ऑप्टिमाइज़ किया गया हो, फिर भी रिस्पॉन्स तैयार करने के लिए सर्वर को काफ़ी काम करना पड़ सकता है. इसमें डेटाबेस का महंगा (अब भी ज़रूरी) काम शामिल है, जो नेविगेशन रिस्पॉन्स को जल्द से जल्द पहुंचने में देरी करता है. इसका संभावित असर यह होता है कि रेंडर करने के लिए ज़रूरी कुछ संसाधनों में देरी हो सकती है. जैसे कि सीएसएस या कुछ मामलों में JavaScript, जो क्लाइंट पर मार्कअप रेंडर करता है.
103 Early Hints हेडर एक शुरुआती रिस्पॉन्स कोड है जिसे सर्वर, ब्राउज़र को तब भेज सकता है, जब बैकएंड मार्कअप तैयार करने में व्यस्त हो. इस हेडर का इस्तेमाल ब्राउज़र को यह संकेत देने के लिए किया जा सकता है कि मार्कअप तैयार होने के दौरान, पेज को डाउनलोड शुरू करने के लिए ज़रूरी संसाधन मौजूद हैं. ये संसाधन रेंडर होने के लिए बहुत ज़रूरी हैं. काम करने वाले ब्राउज़र के लिए, इसका असर दस्तावेज़ को तेज़ी से रेंडर करने (सीएसएस) और मुख्य पेज के फ़ंक्शन (JavaScript) की उपलब्धता को तेज़ी से बढ़ाने में हो सकता है.
नतीजा
बैकएंड ऐप्लिकेशन स्टैक के कई कॉम्बिनेशन उपलब्ध होते हैं. इसलिए, ऐसा कोई भी लेख नहीं है जिसमें अपनी वेबसाइट के टीटीएफ़बी को कम करने के लिए, ऐसी सभी चीज़ों को शामिल किया जा सके. हालांकि, यहां कुछ ऐसे विकल्प दिए गए हैं जिन्हें आज़माकर सर्वर साइड पर चीज़ों को थोड़ा और तेज़ी से आज़माया जा सकता है.
हर मेट्रिक को ऑप्टिमाइज़ करने का तरीका काफ़ी हद तक एक जैसा है: फ़ील्ड में अपने TTFB को मापें, वजहों का विश्लेषण करने के लिए लैब टूल का इस्तेमाल करें, और फिर जहां संभव हो ऑप्टिमाइज़ेशन लागू करें. यहां मौजूद हर तकनीक आपके लिए कारगर नहीं हो सकती, लेकिन कुछ तरीके जरूर काम आएंगे. हमेशा की तरह, आपको फ़ील्ड के डेटा पर बारीकी से नज़र रखनी होगी. साथ ही, उपयोगकर्ता को जितना हो सके उतना तेज़ अनुभव पाने के लिए, ज़रूरत के मुताबिक बदलाव करने होंगे.
यह हीरो इमेज है: टेलर विक ने, Unस्प्लैश से लिया है.