ब्राउज़र कैसे काम करता है

Mutqan Soft QA टीम द्वारा · अपडेट 6 अक्टूबर 2026 · 18 मिनट · शुरुआती

जब आप https://shop.example.com/products/42 टाइप करके Enter दबाते हैं, तो browser वही steps चलाता है जो हर page load के पीछे होते हैं: DNS (Domain Name System) से server का IP address, यानी machine का numeric address, पूछता है; connection खोलकर उसे TLS से encrypt करता है; फिर HTTP request भेजता है और response लेता है। इसके बाद मिले हुए HTML, CSS और JavaScript को screen के pixels में बदलता है। पहला हिस्सा bytes लाता है; दूसरा उन्हें render करता है।

Tester के लिए यह chain एक नक्शा है। हर दिखने वाली failure इसके किसी step पर होती है, और हर step ऐसे सबूत छोड़ता है जिन्हें आप browser में ही देख सकते हैं।

यह क्यों ज़रूरी है

"Site टूटी हुई है" का मतलब हो सकता है गलत server की ओर इशारा करता DNS record, expired certificate, 500 response, 404 लौटाने वाली stylesheet, या ऐसा JavaScript error जिसने click handler रोक दिया। हर एक का owner अलग है और fix भी अलग। जो tester steps जानता है, वह बता सकता है कि इनमें से क्या हुआ और सबूत attach कर सकता है, बजाय ऐसी report के जिस पर कोई action न ले सके।

Steps यह भी दिखाते हैं कि क्या टेस्ट करना है। Page दर्जनों requests और processing के कई stages से बनता है, और हर एक अकेले fail हो सकता है: slow network पर, दूसरे browser में, या पुरानी cached file के साथ।

Page लाना: URL से response तक

Browser address को scheme (https), host (shop.example.com), path, query और fragment में बाँटता है; fragment, जैसे #reviews, कभी server को नहीं भेजा जाता। अगर browser cache में response की fresh copy है, तो browser network को पूरी तरह छोड़ सकता है। नहीं तो network steps क्रम से चलते हैं:

DNS lookup: host name एक IP address बनता है, जैसे 203.0.113.10। जवाब cache होते हैं, इसलिए हो सकता है कि DNS का बदलाव तुरंत न दिखे। अगर name resolve नहीं होता, तो browser अपना error page दिखाता है (Chrome में DNS_PROBE_FINISHED_NXDOMAIN या ERR_NAME_NOT_RESOLVED) और कोई request server तक नहीं पहुँचती।
Connection: browser TCP connection खोलता है, HTTPS के लिए port 443 पर, और बाद की requests के लिए उसे खुला रखता है। HTTP/3 इसकी जगह UDP के ऊपर QUIC इस्तेमाल करता है, जो connection और TLS encryption दोनों को एक ही combined handshake में set up करता है।
TLS handshake: browser और server encryption keys पर सहमत होते हैं, और browser जाँचता है कि server का certificate किसी trusted authority से है, expire नहीं हुआ है और इसी host name के लिए है। कोई जाँच fail हो तो site की जगह पूरे page की warning दिखती है, Chrome में NET::ERR_CERT_DATE_INVALID जैसे code के साथ।
HTTP request: एक method और path, जैसे GET /products/42, साथ में Host और User-Agent जैसे headers और site के लिए stored cookies।
HTTP response: 200, 404 या 500 जैसा status code, Content-Type (file का type, जैसे text/html) और Cache-Control जैसे headers, और body। Redirect (301, 302) browser को Location header वाले URL के साथ पहले step पर वापस भेज देता है।

आज़माएँ: URL पार्सर आज़माएँ: रीडायरेक्ट चेकर

Page बनाना: HTML, CSS, JavaScript, render

Browser HTML को आते-आते ही parse करने लगता है: declared character set (charset) से bytes decode करता है और DOM बनाता है, यानी elements का tree, जिस पर scripts और test tools काम करते हैं। Parser टूटा हुआ markup चुपचाप ठीक कर देता है, इसलिए खराब HTML शायद ही कभी error दिखाता है। Page जिस भी stylesheet, script, image और font की ओर इशारा करता है, वह एक और request बनती है, और इनमें से कोई भी fail हो सकती है जबकि page खुद 200 लौटाता है।

CSS: <head> की stylesheets rendering को block करती हैं। Browser पहले paint से पहले उनका इंतज़ार करता है, और अगर कोई load न हो तो page अपनी styles के बिना दिखता है।
JavaScript: सादा <script src> parser को तब तक रोकता है जब तक script चल न जाए; defer parsing खत्म होने तक रुकता है, async आते ही चलता है। Scripts DOM बदलती हैं, click handlers जोड़ती हैं और data माँगती हैं। Uncaught error उस समय चल रहे code को रोक देता है, इसलिए page पूरा दिख सकता है जबकि कोई button कुछ नहीं करता।
Render: browser हर element की style निकालता है, हर box का layout तय करता है और pixels paint करता है। बाद के बदलाव, जैसे बिना reserved जगह वाली image या script द्वारा जोड़ा गया banner, layout और paint फिर से चलाते हैं, इसीलिए content उछल सकता है।
Milestones: DOMContentLoaded तब होता है जब HTML parse हो चुका हो और deferred scripts चल चुकी हों; load तब, जब images, stylesheets और बाकी resources भी पूरे हो जाएँ।

हर step पर tester क्या देख सकता है

Browser के developer tools (DevTools: Chrome, Edge और Firefox में F12, या Mac पर Cmd+Option+I) लगभग हर step दिखाते हैं; आगे का एक lesson उनके panels दिखाएगा। Network panel हर request की एक row दिखाता है, status, type, size और timing के साथ, और उसकी summary bar DOMContentLoaded और load का समय दिखाती है। यह सिर्फ़ खुले रहने पर record करता है, इसलिए पहले इसे खोलें, फिर reload करें। यह सारी rows को HAR file (HTTP Archive) के रूप में export कर सकता है, यानी एक JSON file जिसे कोई दूसरा व्यक्ति अपने DevTools में खोल सकता है।

Page load के नौ steps: पाँच bytes लाते हैं और चार उन्हें pixels में बदलते हैं, और हर step ऐसा सबूत छोड़ता है जिसे tester browser में जाँच सकता है। वैचारिक मॉडल

Fetch: address से response तक
Page को चाहिए हर stylesheet, script, image और font के लिए दोहराया जाता है
1. 1URL पढ़नाAddress bar; Network panel में request URLhttps://shop.example.com/products/42
2. 2DNS lookupTiming: DNS phaseshop.example.com → 203.0.113.10
  शाखा: Name resolve नहीं हुआ: browser का अपना error pageफ़ेल
3. 3Connect: TCP, फिर TLSTiming: connecting और TLS; certificate viewer
  शाखा: Expired या दूसरे नाम का certificate: पूरे page की warningफ़ेल
4. 4HTTP requestHeaders tab: method, URL, request headers, cookiesGET /products/42
5. 5HTTP responseStatus column, response headers, Response tab200 OK · text/html
  शाखा: 3xx redirect: Location URL के साथ step 1 पर वापस
Render: bytes से pixels तक
1. 6HTML parse करके DOM बनानाPage source, Elements panel; हर linked file नया fetch शुरू करती है
2. 7CSS लागू करनाStylesheet rows; पहला paint इनका इंतज़ार करता है
  शाखा: Stylesheet fail: page अपनी styles के बिना दिखता हैफ़ेल
3. 8JavaScript चलानाConsole; बाद में आने वाले data की Fetch/XHR rows
  शाखा: Uncaught error: कुछ न करने वाला buttonफ़ेल
4. 9Style, layout, paintScreen; DOMContentLoaded और load का समय
  दोहराता है: DOM, images या fonts बदलने पर फिर चलता है: content उछल सकता है

सरल रूप: bytes और files आते रहने के दौरान ही rendering शुरू हो जाती है, और खुले connections दोबारा इस्तेमाल होते हैं। हर card बताता है कि tester कहाँ देखे।

किसी request से पहले: DNS, connection और certificate failures browser के अपने error page पर एक code दिखाती हैं। कोई HTTP request भेजी ही नहीं गई, इसलिए server के access logs में उसकी कोई entry नहीं होती। Address bar के बाईं ओर का site-information icon certificate खोलता है, उसके issuer और validity dates के साथ।
एक request का Timing view: DNS lookup, connecting, TLS, server का इंतज़ार और download जैसे phases। Browsers में ये नाम थोड़े अलग होते हैं।
Headers और Response tabs: क्या भेजा गया (method, URL, headers, cookies) और क्या लौटा (status, headers, body)। Chrome cache से आई rows पर (disk cache) या (memory cache) लिखता है; "Disable cache" checkbox चालू करने पर DevTools खुले रहने तक हर reload browser cache को छोड़ देता है।
Page source और Elements: View page source (Windows पर Ctrl+U) HTML को ठीक वैसा दिखाता है जैसा वह आया था; Elements panel (Firefox में Inspector) parser की मरम्मत और scripts के बदलावों के बाद का DOM दिखाता है।
Console: JavaScript errors और refuse किए गए resources, file और line के साथ। Rendering problems सिर्फ़ screen पर दिखती हैं, इसलिए screenshots या recording लें।

आज़माएँ: रिक्वेस्ट हेडर इंस्पेक्टर आज़माएँ: HTTP हेडर पार्सर

Worked example: बिना styles वाला product page

Staging (site की test copy, जहाँ release को production तक पहुँचने से पहले जाँचा जाता है) पर release के बाद tester https://staging.shop.example.com/products/42 खोलता है। Text और images दिखते हैं, लेकिन एक सादे column में, default fonts के साथ। Steps पर चलने से कुछ ही मिनटों में कारण मिल जाता है:

Page दिखा, यानी DNS, connection और TLS ठीक चले। Document row 200 है और text पढ़ा जा सकता है, यानी HTML पहुँचा और सही decode हुआ।
app.3f9c1e.css की row 404 है, Content-Type: text/html के साथ: server ने stylesheet की जगह अपना "not found" page भेजा, और Console कहता है कि browser ने उसे refuse किया क्योंकि उसका MIME type, यानी Content-Type में लिखा file type, text/css नहीं है।
यानी HTML ऐसी CSS file की ओर इशारा करता है जो server पर है ही नहीं: या तो file deploy नहीं हुई, या HTML में file का नाम गलत है। यह build या deployment defect है, CSS code का defect नहीं, और हर browser में दिखेगा। Bug report में सबूत यह रहे:

Title:    Staging पर product page बिना styles के: app.3f9c1e.css 404 लौटाता है
URL:      https://staging.shop.example.com/products/42
Build:    web 2.14.0 on staging
Request:  GET https://staging.shop.example.com/assets/app.3f9c1e.css
Response: 404 Not Found, Content-Type: text/html; charset=utf-8
Console:  Refused to apply style from '.../assets/app.3f9c1e.css' because its
          MIME type ('text/html') is not a supported stylesheet MIME type,
          and strict MIME checking is enabled.
Expected: 200 with Content-Type: text/css
Evidence: screenshot; cache disable करके किए गए reload की HAR file

आज़माएँ: Content-Type वैलिडेटर आज़माएँ: HTTP स्टेटस कोड लुकअप

आम गलतियाँ

Step बताए बिना "page load नहीं हो रहा" report करना: browser का error page, HTTP error status और 200 के बाद टूटा page अलग-अलग defects हैं, जिनके owners अलग हैं।
सिर्फ़ भरे हुए cache के साथ टेस्ट करना। Cache disable करके reload करें, और एक बार नई private window में भी जाँचें, जो आपकी cookies और cached files के बिना शुरू होती है।
सिर्फ़ status code पर भरोसा करना: 200 में भी error page हो सकता है।
Problem दिखने के बाद DevTools खोलना, जब Network panel ने कुछ record ही नहीं किया होता, या Console कभी न खोलना।
यह मान लेना कि हर failure application code में है। DNS, certificates, CDNs (content delivery networks, जो user के पास के servers से files की copies देते हैं) और caches भी fail होते हैं, और DNS व certificate failures में server के access logs कुछ नहीं दिखाते।

QA का नज़रिया

Bug file करने से पहले failure को किसी step पर रखें: browser का अपना error page (DNS, connection, TLS), document का status, fail हुई sub-request, console error, या सब load होने के बाद rendering problem। यही एक फ़ैसला team को बताता है कि किसे देखना चाहिए: DNS और certificates संभालने वाले, back-end या front-end developers, या deployment pipeline।

Exact URL, fail हुई request का status और Content-Type, console message, browser और उसका version, और cache disabled था या नहीं, यह सब record करें। कई requests शामिल हों तो HAR file मदद करती है, लेकिन उसमें cookies, tokens और personal data हो सकते हैं (Chrome default रूप से cookie और authorization headers छोड़ देता है; दूसरे browsers शायद न छोड़ें), इसलिए attach करने से पहले secrets हटा दें। जब कारण page के बाहर हो तो जल्दी पूछें: "क्या नई asset files उन्हें इस्तेमाल करने वाले HTML से पहले deploy होती हैं?"

अभ्यास

छह symptoms को page-load steps पर रखें

आपका काम

आप https://shop.example.com पर एक web shop टेस्ट कर रहे हैं। नीचे दी गई हर observation के लिए page load का वह step बताएँ जहाँ failure होती है, और bug report में attach होने वाला सबूत लिखें।

सामग्री

1. सिर्फ़ office network पर browser shop.example.com के लिए
   ERR_NAME_NOT_RESOLVED दिखाता है।
2. पूरे page की warning कहती है कि connection private नहीं है; certificate
   कल expire हो गया।
3. /checkout पर server का error page दिखता है; document row 500 है।
4. Page ठीक दिखता है, लेकिन "Add to cart" कुछ नहीं करता। Console:
   Uncaught TypeError: Cannot read properties of null (reading 'addEventListener')
5. हर product page पर Arabic product names "Ø§Ù„..." जैसे दिखते हैं।
6. Promotional banner आने पर price block नीचे खिसक जाता है।

चरण

तय करें कि browser HTTP request भेजने तक पहुँचा या नहीं।
अगर पहुँचा, तो document response, sub-request, HTML parsing, JavaScript और rendering में से चुनें।
हर observation के लिए step और सबूत लिखें।

मॉडल उत्तर दिखाएँ

मॉडल उत्तर

1. DNS lookup: कोई request server तक नहीं पहुँची। सबूत: error code, आप किस network पर थे, और उस network व किसी दूसरे network पर nslookup shop.example.com (DNS से address पूछने वाला command) का output।

2. TLS handshake। सबूत: error code के साथ warning page (Chrome में NET::ERR_CERT_DATE_INVALID), certificate की validity dates, और टेस्ट की तारीख़ व समय।

3. Document response: request server तक पहुँची और वहीं fail हुई। सबूत: method, URL, 500 status, response body और exact समय, ताकि developer log entry ढूँढ सके।

4. JavaScript: script ने ऐसा element ढूँढा जो वहाँ नहीं था (अभी DOM में नहीं आया था, या उसकी id बदल गई), इसलिए click handler कभी जुड़ा ही नहीं। सबूत: file और line के साथ पूरा console message।

5. HTML parsing: UTF-8 bytes गलत character set से decode हुए। सबूत: Content-Type response header (क्या उसमें charset=utf-8 है?) और page source में <meta charset>। अगर दोनों UTF-8 बताते हैं, तो names server पर ही बिगड़ चुके थे, जैसे database में, और defect back end का है।

6. Render: banner पहले paint के बाद बिना reserved जगह के जुड़ता है, इसलिए layout फिर चलता है। सबूत: screen recording, browser और window size।

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

क्या web applications टेस्ट करने के लिए networking जानना ज़रूरी है?

गहराई से नहीं। आपको steps का क्रम और हर step fail होने पर कैसा दिखता है, यह जानना चाहिए, ताकि problem की जगह पहचान सकें और सही सबूत जुटा सकें। Roadmap का HTTP module requests, responses, headers और caching में और गहराई तक जाता है।

Page मेरे लिए चलता है पर colleague के लिए नहीं, ऐसा क्यों?

आप दोनों के बीच कोई step अलग है: अलग DNS जवाब (office network, VPN, hosts file की कोई entry), अलग cached copy, अलग cookies, दूसरा browser या कोई extension। दोनों के Network panels मिलाएँ; जो पहली row अलग है, वहीं से शुरू करना अच्छा है।

क्या हर browser में यही होता है?

क्रम Chrome, Edge, Firefox और Safari में एक जैसा है, क्योंकि यह साझा standards पर चलता है: WHATWG के HTML और Fetch standards, और HTTP व TLS specifications। Error messages, DevTools के नाम और timing की बारीकियाँ अलग होती हैं। इससे भी अहम बात यह है कि हर browser engine (Chrome और Edge में Blink, Firefox में Gecko, Safari में WebKit) इन standards को अपनी कमियों और bugs के साथ लागू करता है, और cross-browser testing इसी वजह से होती है।

संदर्भ

HTML Living StandardWHATWGHTML भाषा, नामित कैरेक्टर रेफ़रेंस (एंटिटी) और ब्राउज़रों के पार्सिंग नियमों सहित।
Fetch StandardWHATWGCORS को परिभाषित करता है: प्रीफ़्लाइट रिक्वेस्ट, Access-Control-* हेडर और कौन-से रिस्पॉन्स ब्राउज़र पेज को दिखा सकता है।
RFC 9110: HTTP SemanticsIETF · 2022HTTP मेथड, हेडर फ़ील्ड, स्टेटस कोड और कंटेंट निगोशिएशन के अर्थ, वायर वर्ज़न से स्वतंत्र।
RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3IETF · 2018TLS 1.3 हैंडशेक और रिकॉर्ड प्रोटोकॉल जो HTTPS ट्रैफ़िक की रक्षा करते हैं।

ब्राउज़र कैसे काम करता है

यह क्यों ज़रूरी है

Page लाना: URL से response तक

Page बनाना: HTML, CSS, JavaScript, render

हर step पर tester क्या देख सकता है

Worked example: बिना styles वाला product page

आम गलतियाँ

QA का नज़रिया

अभ्यास

छह symptoms को page-load steps पर रखें

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

संदर्भ

Mutqan tools से अभ्यास करें

URL पार्सर

रीडायरेक्ट चेकर

रिक्वेस्ट हेडर इंस्पेक्टर

HTTP हेडर पार्सर

Content-Type वैलिडेटर

HTTP स्टेटस कोड लुकअप

और गहराई से

इस topic में आपकी प्रगति

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics

यह क्यों ज़रूरी है

Page लाना: URL से response तक

Page बनाना: HTML, CSS, JavaScript, render

हर step पर tester क्या देख सकता है

Worked example: बिना styles वाला product page

आम गलतियाँ

QA का नज़रिया

अभ्यास

छह symptoms को page-load steps पर रखें

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

संदर्भ

Mutqan tools से अभ्यास करें

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा

इस topic से पहले

अगले topics

इस मॉड्यूल के दूसरे topics