जब आप ब्राउज़र में कोई URL टाइप करते हैं तो क्या होता है?

प्रश्न और दायरा

उस क्षण से जब कोई यूज़र एड्रेस बार में https://shop.example/products?id=42#reviews दर्ज करता है और Enter दबाता है, पेज दिखाई देने तक क्या होता है? URL पार्सिंग, नाम रिज़ॉल्यूशन, कनेक्शन सुरक्षा, HTTP, सर्वर-साइड हैंडलिंग, ब्राउज़र नेविगेशन और रेंडरिंग को कवर करें। यह भी समझाएं कि कैशिंग या कनेक्शन पुनर्चक्रण किन चरणों को छोड़ सकता है।

स्पष्ट मान्यताओं के साथ शुरुआत करें ताकि उत्तर असंगत रास्तों के बीच न भटके। यह एक नया टॉप-लेवल डॉक्यूमेंट नेविगेशन है। इनपुट एक पूर्ण URL है, न कि कोई खोज क्वेरी। कोई सर्विस वर्कर प्रतिक्रिया की आपूर्ति नहीं करता है, कोई भी HTTP प्रतिक्रिया सीधे उपयोग करने के लिए पर्याप्त रूप से ताज़ा नहीं है, कोई संगत कनेक्शन पुन: उपयोग नहीं किया जा सकता है, होस्ट को रिज़ॉल्यूशन की आवश्यकता है, और अंतिम सर्वर प्रतिक्रिया स्थिति 200 के साथ HTML है। वार्म कैश, रीडायरेक्ट और HTTP/3 उस बेसलाइन के बाद की शाखाएं बन जाते हैं।

यह क्रॉस-लेयर फंडामेंटल प्रश्न बैकएंड, क्लाइंट, फुल-स्टैक, इंफ्रास्ट्रक्चर, SRE और सामान्य सॉफ़्टवेयर इंजीनियरिंग साक्षात्कारों के लिए उपयुक्त है। कार्य कैश और प्रोटोकॉल मान्यताओं से वास्तविक पथ प्राप्त करना है, फिर नेटवर्क, सर्वर और रेंडरिंग चरणों को देखने योग्य साक्ष्यों में मैप करना है।

इंटरव्यूअर क्या जांच रहा है

पहला, क्या उम्मीदवार कोई क्रम सुनाने से पहले मान्यताओं को बता सकता है? "DNS, TCP, TLS, HTTP, render" को याद रखने से कैश, सर्विस वर्कर, कनेक्शन पुनर्चक्रण और HTTP/3 छूट जाते हैं। वास्तविक पथ नेविगेशन प्रकार, कैश्ड स्थिति, प्रोटोकॉल बातचीत और प्रतिक्रिया पर निर्भर करता है। एक मजबूत उत्तर एक नियतात्मक बेसलाइन स्थापित करता है और फिर उन स्थितियों का नाम देता है जो इसे बदलती हैं।

दूसरा, क्या उम्मीदवार प्रोटोकॉल सीमाओं को सटीक रख सकता है? #reviews एक URL फ़्रैगमेंट है और इसे HTTP अनुरोध लक्ष्य से बाहर रखा गया है। HTTPS का डिफ़ॉल्ट पोर्ट 443 होता है। DNS एक होस्ट को हल करता है लेकिन हर नेविगेशन पर रूट सर्वर से शुरू होना आवश्यक नहीं है। HTTP/1.1 और HTTP/2 आमतौर पर TCP का उपयोग करते हैं; HTTP/3 QUIC का उपयोग करता है, जो UDP पर चलता है और TLS 1.3 को एकीकृत करता है।

तीसरा, क्या उम्मीदवार नेविगेशन कमिट, संसाधन लोडिंग और स्क्रीन पर पिक्सल के बीच अंतर कर सकता है? पहला बाइट प्राप्त करने से पेज दिखाई नहीं देने लगता है, और नेविगेशन कमिट करने का मतलब यह नहीं है कि हर संसाधन लोड हो गया है। ब्राउज़र अभी भी एक रेंडरर का चयन करता है, HTML को पार्स करता है, सब-रिसोर्स की खोज करता है, DOM और CSSOM का निर्माण करता है, और स्टाइल कैलकुलेशन, लेआउट, पेंट और कंपोज़िटिंग करता है।

चौथा, क्या उम्मीदवार डीबग करने के लिए मॉडल का उपयोग कर सकता है? केवल एक क्रम यह उत्तर नहीं दे सकता कि "यह धीमा कहाँ है?" एक उच्च-गुणवत्ता वाला उत्तर DNS, कनेक्ट, TLS, पहला बाइट, डाउनलोड और मुख्य-थ्रेड रेंडरिंग को नेविगेशन टाइमिंग, नेटवर्क पैनल और परफ़ॉर्मेंस ट्रेस में साक्ष्य के रूप में मैप करता है।

पहले स्पष्ट करने योग्य प्रश्न

• क्या इनपुट निश्चित रूप से एक URL है? एक एड्रेस बार खोज इंजन को सामान्य टेक्स्ट भेज सकता है। यह प्रॉम्प्ट स्कीम के साथ एक पूर्ण HTTPS URL प्रदान करता है, इसलिए इसे नेविगेशन के रूप में जारी रखें।
• क्या यह डॉक्यूमेंट नेविगेशन है या इन-ऐप SPA ट्रांज़िशन? history.pushState() को कॉल करना स्वचालित रूप से समान क्रॉस-डॉक्यूमेंट नेविगेशन नहीं चलाता है। बेसलाइन एक नया टॉप-लेवल डॉक्यूमेंट है।
• क्या यह एक कोल्ड या वार्म पाथ है? HTTP और DNS कैश, एक सर्विस वर्कर, प्रीकनेक्ट, या एक मौजूदा HTTP/2 या HTTP/3 कनेक्शन चरणों को हटा सकते हैं। पहले कोल्ड पाथ की व्याख्या करें, फिर शाखाओं की।
• कौन सा प्रोटोकॉल और नेटवर्क वातावरण लागू होता है? HTTP/1.1, HTTP/2 और HTTP/3 अलग-अलग तरीके से कनेक्शन स्थापित करते हैं। एक प्रॉक्सी, VPN, एंटरप्राइज गेटवे, या अनुपलब्ध UDP पथ भी रूट को बदल सकता है।
• क्या प्रतिक्रिया वापस आती है? एक 200 HTML डॉक्यूमेंट, रीडायरेक्ट, डाउनलोड, प्रमाणपत्र त्रुटि और नेटवर्क विफलता विभिन्न शाखाएँ लेते हैं। बेसलाइन 200 HTML का उपयोग करती है।
• "दिखाई देने योग्य" (Visible) का क्या अर्थ है? First paint, largest contentful paint, DOMContentLoaded, और load अलग-अलग मील के पत्थर हैं। यह उत्तर पहली दृश्यता तक पहुँचता है और फिर बाद की लोडिंग का हिसाब रखता है।

30-सेकंड का उत्तर ढांचा

"मैं एक कोल्ड, टॉप-लेवल HTTPS नेविगेशन मानूंगा। ब्राउज़र URL को पार्स करता है और फ़्रैगमेंट को क्लाइंट-साइड रखता है। यह कैश या DNS से एक पता प्राप्त करता है, फिर एक कनेक्शन का पुन: उपयोग करता है या HTTP/1.1 या HTTP/2 के लिए TCP प्लस TLS स्थापित करता है, या HTTP/3 के लिए एकीकृत TLS 1.3 के साथ QUIC स्थापित करता है। यह पाथ और क्वेरी भेजता है। प्रतिक्रिया की जाँच करने और एक रेंडरर का चयन करने के बाद, यह नेविगेशन को कमिट करता है। रेंडरर HTML को पार्स करता है, सब-रिसोर्स लोड करता है, DOM, CSSOM और रेंडर ट्री बनाता है, फिर लेआउट, पेंट और कंपोज़िटिंग करता है। धीमी लोडिंग के लिए, मैं DNS, कनेक्ट/TLS, TTFB, डाउनलोड और मुख्य-थ्रेड समय को अलग करता हूँ।"

चरण-दर-चरण गहन विश्लेषण

चरण 1: एड्रेस-बार इनपुट को वर्गीकृत करें और URL को पार्स करें

ब्राउज़र पहले यह तय करता है कि एड्रेस-बार इनपुट एक नेविगेबल URL है या एक खोज क्वेरी। इस इनपुट में https:// शामिल है, इसलिए इसे एक URL के रूप में पार्स किया गया है। परिणाम है:

ब्राउज़र URL Standard के पार्सिंग और सामान्यीकरण नियमों को भी लागू करता है और नेविगेशन नीति की जाँच करता है। किसी पुराने पेज का अनलोड हैंडलिंग, ब्राउज़र सुरक्षा नीति, या एक अमान्य URL नेटवर्क अनुरोध शुरू होने से पहले परिणाम को बदल सकता है। Enter दबाना तुरंत पैकेट भेजने का पर्याय नहीं है।

चरण 2: निर्धारित करें कि क्या नेटवर्क एक्सेस से बचा जा सकता है

एक वास्तविक ब्राउज़र मौजूदा दस्तावेज़ स्थिति, एक सर्विस वर्कर, HTTP कैश, प्रीलोड स्थिति और पुन: प्रयोज्य कनेक्शन पर विचार करता है। एक ताज़ा लागू कैश्ड प्रतिक्रिया मूल (origin) से संपर्क करने से बच सकती है। एक नियंत्रित सर्विस वर्कर कैश्ड प्रतिक्रिया वापस कर सकता है, अपना स्वयं का फ़ेच निष्पादित कर सकता है, या दोनों को जोड़ सकता है। यहाँ तक कि एक कैश हिट भी ब्राउज़र के सभी कार्यों को समाप्त नहीं करता है: वापस आए HTML को अभी भी पार्सिंग और रेंडरिंग की आवश्यकता हो सकती है।

बेसलाइन यह मानती है कि इनमें से कोई भी शॉर्टकट दस्तावेज़ की आपूर्ति नहीं कर सकता है, इसलिए नेटवर्क एक्सेस जारी रहता है। "प्रत्येक कैश की जाँच करें, फिर DNS करें" जैसे किसी सार्वभौमिक क्रम का दावा करने से बचें। रिस्पॉन्स कैश, DNS कैश और कनेक्शन पूल अलग-अलग स्थिति रखते हैं, और ब्राउज़र कार्यान्वयन कुछ काम काल्पनिक रूप से या समानांतर में कर सकते हैं।

चरण 3: होस्ट को एक सुलभ पते पर रिज़ॉल्व करें

ब्राउज़र या ऑपरेटिंग सिस्टम पहले एक वैध नाम-रिज़ॉल्यूशन परिणाम का उपयोग करता है। मिस होने पर, यह कॉन्फ़िगर किए गए रिकर्सिव रिज़ॉल्वर से पूछता है। वह रिज़ॉल्वर कैश का भी उपयोग करता है और केवल तभी DNS डेलिगेशन का पालन करता है जब उसके पास उत्तर की कमी होती है, अंततः उपयुक्त पता रिकॉर्ड लौटाता है। परिणाम एप्लिकेशन मूल के बजाय CDN या एज सर्वर की ओर ले जा सकता है।

नतीजतन, "ब्राउज़र प्रत्येक लोड पर रूट, टॉप-लेवल-डोमेन और आधिकारिक सर्वरों से पूछताछ करता है" गलत है। क्लाइंट सामान्य रूप से एक रिज़ॉल्वर को रिकर्सिव कार्य सौंपता है, जबकि कैश और रिकॉर्ड TTL यह निर्धारित करते हैं कि आगे के प्रश्नों की आवश्यकता है या नहीं। एक ब्राउज़र एन्क्रिप्टेड DNS का भी उपयोग कर सकता है। यह क्वेरी के ट्रांसपोर्ट और गोपनीयता सीमा को बदलता है, न कि किसी होस्ट को सुलभ सेवा पते पर मैप करने के अंतर्निहित लक्ष्य को।

चरण 4: एक सुरक्षित कनेक्शन का पुन: उपयोग करें या स्थापित करें

उम्मीदवार पते उपलब्ध होने के साथ, ब्राउज़र पहले लक्ष्य के साथ संगत कनेक्शन का पुन: उपयोग करने का प्रयास करता है। यदि कोई उपलब्ध नहीं है, तो पथ चयनित HTTP संस्करण पर निर्भर करता है:

• HTTP/1.1 या HTTP/2 आमतौर पर TCP स्थापित करता है और फिर एक TLS हैंडशेक करता है। TLS होस्ट के विरुद्ध प्रमाणपत्र को मान्य करता है, क्रिप्टोग्राफ़िक मापदंडों पर बातचीत करता है, और HTTP/2 या HTTP/1.1 का चयन करने के लिए ALPN का उपयोग कर सकता है।
• HTTP/3 QUIC का उपयोग करता है। QUIC UDP पर चलता है और TLS 1.3 हैंडशेक को कनेक्शन स्थापना में एकीकृत करता है, इसलिए TCP थ्री-वे हैंडशेक HTTPS के लिए सार्वभौमिक नहीं है।
• यदि कोई उपयोगी QUIC/UDP पथ अनुपलब्ध है, तो एक क्लाइंट TCP-आधारित HTTP पर वापस आ सकता है। सटीक रेस और फ़ॉलबैक नीति ब्राउज़र कार्यान्वयन विवरण है; एक निश्चित समयरेखा का आविष्कार न करें।

IP रूटिंग, स्थानीय लिंक, NAT, एक प्रॉक्सी, या एक VPN सभी पैकेट वितरित करने में भाग ले सकते हैं। समय-सीमित साक्षात्कार में, साक्षात्कारकर्ता द्वारा पूछे जाने तक प्रत्येक नेटवर्क हॉप का विस्तार किए बिना उन परतों को स्वीकार करें।

चरण 5: HTTP भेजें और सर्वर प्रतिक्रिया को संभालें

एक बार कनेक्शन उपयोग योग्य हो जाने के बाद, ब्राउज़र अनुरोध का निर्माण करता है। एक HTTP/1.1 टेक्स्ट प्रतिनिधित्व महत्वपूर्ण सिमेंटिक्स को कैप्चर करता है:

GET /products?id=42 HTTP/1.1
Host: shop.example
Accept: text/html

अनुरोध लक्ष्य में पाथ और क्वेरी शामिल हैं, #reviews नहीं। ब्राउज़र यह तय करता है कि डोमेन, पाथ, SameSite, सुरक्षा और संबंधित नियमों के अनुसार प्रत्येक कुकी को संलग्न करना है या नहीं, और सामग्री-बातचीत या कैश-सत्यापन फ़ील्ड जोड़ सकता है। "ब्राउज़र सभी कुकीज़ भेजता है" बहुत व्यापक है। HTTP/2 और HTTP/3 इस HTTP/1.1 वायर फ़ॉर्मेट का उपयोग नहीं करते हैं, लेकिन मेथड, लक्ष्य, फ़ील्ड और प्रतिक्रिया सिमेंटिक्स के प्रत्यक्ष समकक्ष होते हैं।

अनुरोध किसी एप्लिकेशन, कैश और डेटाबेस से पहले CDN, रिवर्स प्रॉक्सी या लोड बैलेंसर तक पहुंच सकता है। एक साधारण सर्वर सीधे उत्तर दे सकता है। उन घटकों को संभावित आर्किटेक्चर के रूप में समझें, अनिवार्य चरणों के रूप में नहीं। प्रतिक्रिया में एक स्थिति, फ़ील्ड और सामग्री होती है। एक रीडायरेक्ट नए स्थान की ओर एक बाद का नेविगेशन शुरू करता है। एक 304 Not Modified मौजूदा कैश्ड प्रतिक्रिया के साथ संयोजित होता है। बेसलाइन 200, एक HTML सामग्री प्रकार और एक प्रतिक्रिया बॉडी प्राप्त करती है।

चरण 6: ब्राउज़र नेविगेशन को कमिट करें

जैसे ही प्रतिक्रिया आती है, ब्राउज़र उसकी स्थिति, सामग्री प्रकार, डाउनलोड निर्णय और सुरक्षा नीति को संभालता है, फिर गंतव्य के लिए एक उपयुक्त रेंडरर चुनता है। Chromium नेविगेशन कमिट करने को दस्तावेज़ लोड करने से अलग करता है। कमिट प्रतिक्रिया को एक रेंडरर में स्थानांतरित करता है और वर्तमान दस्तावेज़ का स्वामित्व बदलता है; शेष को पढ़ना, पार्स करना, स्क्रिप्ट और सब-रिसोर्स इसके बाद भी जारी रह सकते हैं।

एक त्रुटि स्थिति का अर्थ हमेशा "कोई पेज नहीं" नहीं होता है। सर्वर से एक HTML त्रुटि प्रतिक्रिया नया दस्तावेज़ बन सकती है। प्रमाणपत्र विफलता, कनेक्शन विफलता या ब्राउज़र ब्लॉक इसके बजाय ब्राउज़र-जनरेटेड त्रुटि पेज उत्पन्न कर सकता है। यह कहना कि नेविगेशन केवल स्थिति 200 के लिए कमिट होता है, बहुत निरपेक्ष है।

चरण 7: पार्स करें, लोड करें और स्क्रीन पर पिक्सल रखें

रेंडरर वृद्धिशील रूप से HTML को DOM में पार्स करता है। जब यह स्टाइलशीट, स्क्रिप्ट, फ़ॉन्ट, चित्र और अन्य संदर्भों का सामना करता है, तो यह सब-रिसोर्स अनुरोधों को शेड्यूल करता है। वे संसाधन DNS उत्तरों और कनेक्शनों का पुन: उपयोग कर सकते हैं, या अन्य मूल से आ सकते हैं जिनके लिए अधिक नाम रिज़ॉल्यूशन और कनेक्शन कार्य की आवश्यकता होती है। प्रत्येक सब-रिसोर्स अनिवार्य रूप से पूर्ण हैंडशेक अनुक्रम को दोहराता नहीं है।

CSS को पार्स करने से CSSOM उत्पन्न होता है। DOM और CSSOM दृश्यमान सामग्री के लिए एक रेंडर ट्री में योगदान करते हैं, जिसके बाद स्टाइल गणना, लेआउट और पेंट होता है; ब्राउज़र फिर परतों को प्रदर्शित पिक्सल में संयोजित करता है। उपयुक्त defer, async, या मॉड्यूल व्यवहार के बिना एक क्लासिक स्क्रिप्ट HTML पार्सिंग को अवरुद्ध कर सकती है, और CSS पहली रेंडरिंग को प्रभावित करता है। फर्स्ट पेंट प्रत्येक छवि या एसिंक्रोनस स्क्रिप्ट के पूरा होने से पहले हो सकता है। DOMContentLoaded कुछ सब-रिसोर्स के load पूरा होने से पहले भी हो सकता है।

#reviews फ़्रैगमेंट सर्वर को नहीं भेजा गया था। एक बार दस्तावेज़ लक्षित हो जाने के बाद, ब्राउज़र मिलान करने वाले तत्व पर स्क्रॉल कर सकता है। यदि स्क्रिप्ट उस तत्व को बाद में बनाती है, तो अंतिम व्यवहार पेज कोड पर भी निर्भर करता है।

चरण 8: चरण-विशिष्ट साक्ष्य के साथ "धीमेपन" का निदान करें

पहले यह निर्धारित करें कि क्या उपयोगकर्ता DNS विफलता, कनेक्शन विफलता, खाली पेज, विलंबित सामग्री, या अवरुद्ध इंटरैक्शन देखता है। फिर लक्षण को चरणों में मैप करें:

एक पेज प्रारंभिक ट्राइएज के लिए अपने नेविगेशन रिकॉर्ड का निरीक्षण कर सकता है:

const [nav] = performance.getEntriesByType("navigation");

console.table({
  dns: nav.domainLookupEnd - nav.domainLookupStart,
  connect: nav.connectEnd - nav.connectStart,
  ttfb: nav.responseStart - nav.requestStart,
  download: nav.responseEnd - nav.responseStart,
  protocol: nav.nextHopProtocol,
});

ये अंतर अवलोकन बिंदु हैं, स्वचालित मूल कारण नहीं। पुन: उपयोग किए गए कनेक्शन कुछ टाइमस्टैम्प को बराबर कर सकते हैं। एक सर्विस वर्कर, कैश, रीडायरेक्ट या प्रॉक्सी भी उनके अर्थ को बदल सकता है। जब भी TTFB अधिक हो, डेटाबेस को दोष देने के बजाय ब्राउज़र नेटवर्क पैनल, सर्वर-साइड ट्रेसिंग और परफ़ॉर्मेंस ट्रेस के साथ परिकल्पना को मान्य करें।

मजबूत नमूना उत्तर

"मैं एक कोल्ड बेसलाइन को परिभाषित करूँगा: बिना किसी सर्विस वर्कर प्रतिक्रिया, HTTP कैश हिट या पुन: प्रयोज्य कनेक्शन के साथ एक नया टॉप-लेवल HTTPS नेविगेशन, जो 200 HTML प्रतिक्रिया में समाप्त होता है।

ब्राउज़र https://shop.example/products?id=42#reviews को HTTPS स्कीम, होस्ट, डिफ़ॉल्ट पोर्ट 443, पाथ, क्वेरी और फ़्रैगमेंट में पार्स करता है। फ़्रैगमेंट क्लाइंट-साइड रहता है, इसलिए अनुरोध लक्ष्य /products?id=42 है। ब्राउज़र या OS तब DNS कैश का उपयोग करता है या रिकर्सिव रिज़ॉल्वर से पूछता है। रिज़ॉल्वर उत्तरों को कैश भी करता है, इसलिए प्रत्येक नेविगेशन पर रूट, TLD और आधिकारिक सर्वरों से संपर्क करना आवश्यक नहीं है।

पता प्राप्त करने के बाद, ब्राउज़र पहले पुन: प्रयोज्य कनेक्शन की जाँच करता है। HTTP/1.1 या HTTP/2 आमतौर पर TCP प्लस TLS का उपयोग करता है और सर्वर प्रमाणपत्र को मान्य करता है। HTTP/3 QUIC हैंडशेक में एकीकृत TLS 1.3 के साथ UDP पर QUIC का उपयोग करता है, इसलिए मैं प्रत्येक HTTPS अनुरोध के लिए TCP को अनिवार्य नहीं कहूंगा। एक बार कनेक्ट होने के बाद, ब्राउज़र पाथ और क्वेरी के साथ GET भेजता है लेकिन कोई फ़्रैगमेंट नहीं। एक CDN, लोड बैलेंसर और एप्लिकेशन इसे संभाल सकते हैं, या एक सर्वर सीधे उत्तर दे सकता है, स्थिति, प्रतिक्रिया फ़ील्ड और HTML लौटा सकता है।

ब्राउज़र प्रतिक्रिया प्रकार और सुरक्षा नीति की जाँच करता है, एक रेंडरर का चयन करता है, और नेविगेशन को कमिट करता है। रेंडरर वृद्धिशील रूप से HTML को DOM में पार्स करता है और CSS, JavaScript, फ़ॉन्ट और छवियों की खोज करता है। वे संसाधन कनेक्शन या कैश का पुन: उपयोग कर सकते हैं। DOM और CSSOM रेंडर ट्री को फीड करते हैं, जिसके बाद लेआउट, पेंट और कंपोज़िटिंग होती है। सभी संसाधनों के समाप्त होने से पहले पहली दृश्यता हो सकती है, और ब्राउज़र तब #reviews को दस्तावेज़ के आंतरिक लक्ष्य के रूप में लागू कर सकता है।

धीमे पेज के लिए, मैं चरणबद्ध तरीके से साक्ष्य एकत्र करूँगा: DNS, कनेक्ट, TTFB और डाउनलोड के लिए नेविगेशन टाइमिंग; प्रोटोकॉल, कैश और रीडायरेक्ट के लिए नेटवर्क पैनल; और मुख्य-थ्रेड स्क्रिप्ट, स्टाइल, लेआउट और पेंट के लिए एक परफ़ॉर्मेंस ट्रेस। यह एक निश्चित पाइपलाइन को दोहराने के बजाय नाम रिज़ॉल्यूशन, नेटवर्क और सर्वर समय और ब्राउज़र रेंडरिंग को अलग करता है।"

सामान्य गलतियाँ

• एक निश्चित अनुक्रम को प्रत्येक वास्तविक पथ मानना → कैश, सर्विस वर्कर और पुन: उपयोग किए गए कनेक्शन नेटवर्क कार्य को छोड़ देते हैं → एक कोल्ड बेसलाइन बताएं और फिर उन स्थितियों का नाम दें जो इसे छोटा करती हैं।
• यह दावा करना कि HTTPS हमेशा TCP से शुरू होता है → HTTP/3 एकीकृत TLS 1.3 के साथ UDP पर QUIC का उपयोग करता है → TCP-आधारित HTTP को QUIC-आधारित HTTP से अलग करें।
• सर्वर को #reviews भेजना → HTTP लक्ष्य फ़्रैगमेंट को बाहर करता है → /products?id=42 भेजें और फ़्रैगमेंट को क्लाइंट-साइड रखें।
• यह दावा करना कि ब्राउज़र हर बार रूट DNS सर्वर से पूछताछ करता है → क्लाइंट, रिकर्सिव रिज़ॉल्वर और डेलिगेशन चेन सभी कैश का उपयोग कर सकते हैं → अनिवार्य क्वेरी अनुक्रम का आविष्कार किए बिना रिकर्सन और डेलिगेशन की व्याख्या करें।
• प्रत्येक सब-रिसोर्स के लिए DNS, TCP और TLS को दोहराना → समान-मूल (same-origin) कनेक्शन और कैश्ड स्थिति अक्सर पुन: प्रयोज्य होती हैं → केवल नए मूल, पुरानी स्थिति या असंगत कनेक्शन के लिए काम जोड़ें।
• CDN, माइक्रोसर्विस, कैश और डेटाबेस को अनिवार्य बनाना → सर्वर टोपोलॉजी भिन्न होती है → "के माध्यम से गुजर सकता है" कहें और केवल वास्तविक आर्किटेक्चर के लिए विस्तार करें।
• प्राप्त HTML की तुलना पूर्ण पेज से करना → कमिट, पार्स, फर्स्ट पेंट, DOMContentLoaded, और load अलग-अलग मील के पत्थर हैं → चर्चा किए जा रहे पूर्णता बिंदु को परिभाषित करें।
• परफ़ॉर्मेंस का निदान किए बिना प्रोटोकॉल का नामकरण करना → उत्तर कोई इंजीनियरिंग निर्णय नहीं दिखाता है → DNS, कनेक्ट, TTFB, डाउनलोड और रेंडरिंग को देखने योग्य साक्ष्यों में मैप करें।

फ़ॉलो-अप प्रश्न

फ़ॉलो-अप 1: जब कोई ताज़ा HTTP कैश प्रविष्टि या सर्विस वर्कर उपलब्ध हो तो क्या बदलता है?

एक ताज़ा कैश प्रविष्टि मूल से संपर्क किए बिना प्रतिक्रिया की आपूर्ति कर सकती है। एक पुरानी प्रविष्टि के लिए सशर्त अनुरोध और 304 प्रतिक्रिया की आवश्यकता हो सकती है। एक सर्विस वर्कर अपनी स्वयं की कैश्ड प्रतिक्रिया लौटा सकता है, एक फ़ेच को अग्रेषित कर सकता है, या दोनों को जोड़ सकता है। स्रोत की परवाह किए बिना, ब्राउज़र को अभी भी दस्तावेज़ को कमिट, पार्स और रेंडर करना पड़ सकता है। "कैश का मतलब है कि कुछ नहीं होता" कहने के बजाय कैश स्रोत और सत्यापन स्थिति निर्दिष्ट करें।

फ़ॉलो-अप 2: HTTP/3 पथ HTTP/2 से कैसे भिन्न है?

HTTP/2 आमतौर पर TCP पर TLS के ऊपर चलता है। HTTP/3 QUIC के लिए HTTP सिमेंटिक्स को मैप करता है; QUIC UDP पर चलता है और TLS 1.3 को एकीकृत करता है। दोनों एक कनेक्शन पर समवर्ती स्ट्रीम का समर्थन करते हैं, लेकिन एक HTTP/3 स्ट्रीम के लिए ट्रांसपोर्ट लॉस असंबंधित स्ट्रीम को एकल TCP बाइट स्ट्रीम की रिकवरी के लिए प्रतीक्षा करने के लिए मजबूर नहीं करता है। यदि कोई उपयोगी QUIC पथ उपलब्ध नहीं है, तो क्लाइंट TCP-आधारित HTTP का उपयोग कर सकता है।

फ़ॉलो-अप 3: यदि सर्वर किसी अन्य होस्ट को 301 लौटाता है तो कौन से चरण दोहराए जाते हैं?

ब्राउज़र रीडायरेक्ट और Location को प्रोसेस करता है, नए URL को पार्स करता है, और रीडायरेक्ट और सुरक्षा नीति लागू करता है। यदि नए होस्ट के पास कोई उपयोगी DNS उत्तर या संगत कनेक्शन नहीं है, तो नाम रिज़ॉल्यूशन और कनेक्शन स्थापना की फिर से आवश्यकता होती है; पुन: प्रयोज्य स्थिति उन चरणों को हटा सकती है। यह तब तक दूसरा अनुरोध भेजता है जब तक कि उसे अंतिम प्रतिक्रिया नहीं मिल जाती या वह रीडायरेक्ट सीमाओं तक नहीं पहुंच जाता। HTTP सिमेंटिक्स के तहत, बिना फ़्रैगमेंट वाला Location मूल फ़्रैगमेंट को इनहेरिट करता है; अपने स्वयं के फ़्रैगमेंट वाला Location नए का उपयोग करता है। दोनों में से कोई भी फ़्रैगमेंट HTTP अनुरोध लक्ष्य में शामिल नहीं है।

फ़ॉलो-अप 4: DNS और TTFB तेज़ हैं, लेकिन पेज खाली रहता है। आप सबसे पहले क्या निरीक्षण करते हैं?

नेटवर्क साक्ष्य ने खोज को पहले ही संकीर्ण कर दिया है। पुष्टि करें कि HTML आ गया है और सामग्री प्रकार या सुरक्षा नीति ने आवश्यक संसाधनों को अवरुद्ध नहीं किया है। फिर लंबे कार्यों, सिंक्रोनस स्क्रिप्ट, स्टाइलशीट, फ़ॉन्ट और महंगे लेआउट के लिए परफ़ॉर्मेंस ट्रेस का निरीक्षण करें। DNS को फिर से अनुकूलित करने के बजाय, पिक्सल को रोकने वाली पहली निर्भरता खोजने के लिए फर्स्ट पेंट को महत्वपूर्ण-संसाधन वॉटरफ़ॉल और मुख्य-थ्रेड समयरेखा के साथ संरेखित करें।

फ़ॉलो-अप 5: DOMContentLoaded के बाद भी चित्र क्यों गायब हो सकते हैं?

DOMContentLoaded दस्तावेज़ पार्सिंग और प्रासंगिक ब्लॉकिंग स्क्रिप्ट को कवर करता है; यह प्रत्येक छवि और अन्य सब-रिसोर्स की प्रतीक्षा नहीं करता है। load दस्तावेज़ और निर्भर संसाधनों के पूरा होने के करीब है, लेकिन लेज़ी लोडिंग, बाद के स्क्रिप्ट फ़ेच और निरंतर अपडेट अभी भी इसके बाद हो सकते हैं। एक घटना को "सब कुछ पूरा हो गया है" मानने के बजाय एक ऐसा परफ़ॉर्मेंस मील का पत्थर चुनें जो उपयोगकर्ता-दृश्यमान लक्ष्य से मेल खाता हो।