Typing a web address into a browser looks like one action: enter a URL, press Enter, and wait for the page. Underneath that simple interaction, however, the browser has to solve several different problems before it can display useful content. It has to interpret the URL, determine where the requested website is located, establish a suitable network connection, authenticate the destination when HTTPS is used, send an HTTP request, receive a response, process the returned HTML, and then discover and request many of the additional resources needed to construct the page.
The process is not always identical. Modern browsers can reuse existing connections, use cached DNS information, retrieve content from a cache or content delivery network, and communicate using HTTP/2 or HTTP/3 rather than the older HTTP/1.1 model. DNS itself can also be handled by mechanisms such as DNS over HTTPS or DNS over QUIC. The result is that the familiar sequence of “DNS → TCP → TLS → HTTP” is useful for understanding the architecture, but it is not a complete description of every modern page load. (IETF Datatracker)
What remains consistent is the underlying division of responsibilities. The URL identifies what the browser wants, DNS helps locate the host, transport protocols establish communication, TLS protects HTTPS traffic, HTTP defines the exchange of requests and responses, and the browser turns those responses into the document that a person sees.
The URL Tells The Browser What It Is Looking For
Before contacting a server, the browser has to interpret the address itself.
Consider a URL such as:
https://example.com/articles/networking?topic=dns
It contains several pieces of information. The https portion identifies the URI scheme. example.com is the host. /articles/networking is the path, while topic=dns is a query component. The browser uses these components to determine how the request should be made and what resource is being requested.
The distinction matters because the URL is more than a human-readable website name. The HTTP specifications define the http and https URI schemes, including their relationship to origins, ports and secured communication. For HTTPS, TCP port 443 is the default when no other port is specified, although HTTPS itself is not inherently limited to TCP, as HTTP can also operate over other secured transports such as QUIC. (IETF Datatracker)
The browser may also modify what happens next based on information it already knows. A previously visited domain might have DNS information cached. A browser may already have an open connection to the same origin. A site may have HSTS information telling the browser to use HTTPS directly. Consequently, the fastest page loads can skip or shorten several steps that would otherwise be visible in a simplified explanation.
For developers investigating a particular address, TechTalksX’s URL Component Analyzer can help break a URL into its constituent components and make the structure easier to understand.
DNS Turns A Hostname Into A Network Destination
Humans generally use domain names because names such as example.com are easier to remember than IP addresses. Network communication ultimately needs an address that can be used to reach a destination, so the browser or operating system needs to obtain an appropriate IP address for the hostname.
That is where the Domain Name System comes in.
A DNS lookup can involve several layers of caching and DNS infrastructure. The browser may have information available locally, the operating system may have a cached answer, and a configured recursive resolver may already know the result. If the answer is not available from those caches, the resolver can perform the necessary DNS queries to discover an authoritative answer.
This is why a DNS lookup does not necessarily mean that the browser starts every visit by contacting an authoritative DNS server directly.
MDN describes DNS as an early stage of navigation and notes that the result can be cached so subsequent requests to the same hostname can avoid repeating the entire resolution process. It also points out that a single page can require DNS lookups for multiple hostnames when its images, scripts, fonts, advertising or other resources are served from different domains. (MDN Web Docs)
Modern DNS can also be transported differently. DNS over HTTPS, defined by RFC 8484, maps DNS queries and responses into HTTPS exchanges, providing confidentiality and integrity for the DNS traffic between the client and its DoH server. DNS can also be carried over QUIC through DNS over QUIC, defined by RFC 9250. (IETF Datatracker)
The result is that “DNS lookup” describes a function rather than one fixed network exchange.
TechTalksX DNS Record Explorer
The Browser Still Needs A Route To The Server
Once an IP address has been obtained, the browser has a destination, but that does not mean the server has received anything yet.
The device’s network stack has to send packets toward that destination. Routers along the way examine network-layer information and forward the packets toward the next hop. The exact route can depend on the networks involved, their routing decisions, connectivity arrangements and current conditions.
This is one reason that a website’s physical location is not equivalent to a simple straight-line distance from the visitor. A server can be geographically nearby but reached through a particular set of networks, while another server farther away may be connected through a different path.
For a website using a content delivery network, the IP address presented to the browser may also lead to an edge location rather than the site’s primary origin server. The edge system can potentially serve cached content locally or forward the request to another system when the requested resource is not already available there.
From the browser’s perspective, the important point is that the hostname has been resolved to a destination that can participate in the next stage of communication.
TCP Is One Possible Transport Layer
If the browser is using HTTP over TCP, it needs a TCP connection before sending HTTP data.
TCP establishes a connection using its three-way handshake. The client sends a SYN, the server responds with SYN-ACK, and the client completes the exchange with an ACK. MDN describes this as the traditional TCP setup that occurs before application data can be exchanged. (MDN Web Docs)
For a conventional HTTPS connection using HTTP/1.1 or HTTP/2 over TCP, this creates a sequence in which DNS resolution can be followed by TCP connection establishment and then TLS negotiation.
But modern web traffic has another important option.
HTTP/3 uses QUIC rather than TCP. The IETF describes HTTP/3 as providing HTTP semantics over QUIC, with concurrent streams and transport behavior designed to avoid some limitations associated with TCP. RFC 9110 notes that HTTP/2 introduced multiplexing over TCP, while HTTP/3 uses QUIC as a secure multiplexed transport over UDP. (IETF Datatracker)
That distinction matters because a modern browser may not follow the classic TCP-first sequence at all.
HTTPS Adds Authentication And Encryption
For an HTTPS website, the browser must establish a secure cryptographic connection before normal HTTP data can be exchanged.
TLS is responsible for this security layer. During the handshake, the client and server negotiate cryptographic parameters, and the client verifies that the server’s identity is appropriate for the hostname it is trying to reach. The server presents a certificate that ultimately chains to a trusted certificate authority or another trust anchor recognized by the client.
The purpose is not simply to hide the page contents. HTTPS is also intended to establish that the server being contacted is authorized to represent the requested origin and to protect the integrity of the communication. RFC 9110 specifically requires clients to verify the service identity when establishing a secured HTTPS connection. (IETF Datatracker)
This is why a certificate error is different from an ordinary HTTP error. A server returning a 404 Not Found has successfully participated in an HTTP exchange. A certificate failure can prevent the browser from establishing the authenticated HTTPS channel required to make that exchange safely.
HSTS can alter this process further. A browser that knows a domain requires HTTPS can upgrade an HTTP URL before making the insecure request. MDN explains that HSTS instructs browsers to use HTTPS for subsequent connections and that preload mechanisms can allow supported browsers to enforce HTTPS even before receiving the site’s HSTS header. (MDN Web Docs)
HTTP Finally Asks For The Resource
Once the appropriate connection is ready, the browser can send an HTTP request.
At a simplified level, the request identifies a method, a target resource and a collection of headers describing the request and the client’s capabilities. A typical navigation usually uses the GET method because the browser is asking the server to provide a representation of the requested resource.
The server processes that request and returns an HTTP response. The response contains a status code, headers and potentially a body containing HTML or another representation of the requested resource.
HTTP itself does not dictate that the response must be an entire webpage. It is an application-level protocol for exchanging representations and metadata between clients and servers. RFC 9110 defines HTTP’s core semantics independently of the specific transport version being used. (IETF Datatracker)
This separation is important. HTTP/1.1, HTTP/2 and HTTP/3 can use different transport mechanisms and wire-level behavior while retaining the same fundamental HTTP semantics.
TechTalksX HTTP Status Code Reference
A 200 Response Does Not Mean The Page Is Finished
One of the biggest misconceptions about browsing is that the first successful HTTP response contains everything the browser needs.
Usually, it does not.
The initial HTML document can contain references to stylesheets, JavaScript files, images, fonts, video, iframes and other resources. As the browser parses the document, it discovers these dependencies and schedules additional requests.
MDN describes this process as part of how browsers populate a page: after receiving the initial HTML, the browser parses it and identifies resources that need to be retrieved, potentially involving additional DNS lookups and connections for resources hosted on different domains. (MDN Web Docs)
This creates a second layer of network activity.
A page might therefore involve:
| Stage | What The Browser Needs To Do |
|---|---|
| URL processing | Identify the scheme, host, path and other components |
| Name resolution | Obtain an IP address or usable network destination |
| Connection setup | Establish or reuse an appropriate transport connection |
| Security | Establish or reuse an HTTPS security context when required |
| Initial request | Request the HTML document |
| HTML parsing | Discover linked resources and document structure |
| Subresource requests | Fetch CSS, JavaScript, images, fonts and other assets |
| Rendering | Calculate layout, paint content and update the visible page |
The table is a simplified model. Caches, connection reuse, service workers, preloading, redirects, HTTP/2 multiplexing, HTTP/3 and CDN behavior can change the exact order.
The Server May Not Be The First Place With The Content
When the browser requests a resource, the system answering the request does not necessarily have to retrieve that resource from the website’s application server.
Caching can intervene at several levels.
A browser may already have a valid cached copy. A service worker may intercept a request and provide a locally stored response. A CDN edge server may have a cached copy of a static asset. An intermediary cache can sometimes satisfy a request without contacting the origin.
HTTP’s caching model exists precisely because repeatedly retrieving identical or reusable representations from the origin is inefficient. RFC 9110 defines cache-related semantics alongside the rest of HTTP’s core behavior. (IETF Datatracker)
This means a returning visitor can experience a dramatically different journey from a first-time visitor. The URL may be identical, but the amount of network work required to display it can be substantially smaller.
HTTP/2 And HTTP/3 Change How The Requests Travel
The web’s transport architecture has evolved partly because a modern webpage may require dozens or hundreds of resources.
HTTP/1.1 historically relied heavily on individual request-response exchanges and persistent connections. HTTP/2 introduced multiplexing, allowing multiple streams of HTTP traffic to share a connection. HTTP/3 uses QUIC, which provides multiplexed streams over UDP while incorporating TLS-based security into the QUIC protocol architecture. (IETF Datatracker)
One practical consequence is that a browser does not necessarily need to create a separate traditional TCP connection for every resource.
HTTP/2 can carry concurrent requests over one TCP connection. HTTP/3 can carry multiple streams over QUIC, with the protocol designed to reduce the impact that loss affecting one stream can have on unrelated streams. RFC 9250 describes QUIC’s support for independent streams and its mechanisms for reducing transport-induced delays. (IETF Datatracker)
The result is that the old mental picture of a webpage as a sequence of completely separate downloads is increasingly inaccurate.
The Browser Turns Bytes Into A Document
Receiving the HTML is only the beginning of the browser’s work.
The browser parses the HTML into a document structure and processes stylesheets to determine how elements should appear. JavaScript can modify the document, request additional resources, change styles or trigger application logic. Images and fonts have to be decoded, and the browser has to calculate positions and dimensions before painting pixels to the screen.
This is why network speed alone does not determine how quickly a webpage becomes usable.
A page with a relatively small amount of data can still require significant browser processing. Conversely, a large static file may download quickly without requiring substantial document construction.
The visible webpage is therefore the final product of several systems working together: networking, security, HTTP, caching, server-side processing and browser rendering.
Why The Journey Can Be Different On Every Visit
The sequence described above is a useful conceptual model, but real navigation is highly conditional.
A repeat visit might reuse DNS information and an existing connection. A CDN might serve the HTML or assets from a nearby edge location. Requests might be answered by a service worker without going to the network. HTTP/3 might replace the TCP-based path with QUIC. A redirect might cause the browser to contact another URL before reaching the final destination.
Even the initial URL can produce different results depending on browser state and server configuration.
This is why web performance measurements should be interpreted carefully. A page’s loading time is not simply the sum of “DNS time + download time.” Some operations overlap, some are reused, and some are eliminated by caches or existing connections.
What Happens When Something Goes Wrong?
Each stage can fail independently.
A DNS problem can prevent the browser from finding a usable destination. A routing problem can prevent packets from reaching the destination. A TCP connection can fail or time out. TLS can reject a certificate or fail during negotiation. HTTP can return a redirect, authentication requirement, client error or server error. The server can successfully return HTML while one of its images or scripts fails separately.
That distinction is useful when diagnosing websites.
For example, a page returning 404 Not Found indicates an HTTP-level response from the server or an intermediary. A DNS failure occurs earlier, before the browser has successfully reached an HTTP endpoint. A TLS certificate error occurs during the security establishment stage rather than after a normal HTTP response has been accepted.
Looking at the stage where the failure occurs is often more informative than simply describing the website as “down.”
The Modern Web Is A Chain Of Reused Connections And Services
The classic explanation of a website visit—DNS lookup, TCP handshake, TLS handshake, HTTP request and webpage—remains useful because it exposes the responsibilities of each layer.
It is no longer sufficient as a literal description of every navigation, however.
Browsers cache DNS results and web resources. Connections can be reused. HTTP/2 multiplexes streams over a connection. HTTP/3 uses QUIC rather than TCP. DNS can itself be transported through HTTPS or QUIC. CDNs can answer requests close to users, while service workers can sometimes respond without making a network request at all. (IETF Datatracker)
These technologies do not eliminate the fundamental journey from a human-readable web address to usable content. They make parts of that journey shorter, more concurrent, more secure or more reusable.
That is the key reason a modern webpage can appear almost instantly even though many technical operations are involved.
Frequently Asked Questions
Why does a browser need DNS before visiting a website?
The hostname in a URL is designed for human use, while network communication needs an address that can be routed. DNS provides the mechanism for resolving a hostname into an IP address or other usable destination information. In practice, cached DNS information can mean the browser does not need to perform a full lookup for every visit. (MDN Web Docs)
Does HTTPS happen before the HTTP request?
For a conventional HTTPS connection, the secure channel must be established before protected HTTP application data is exchanged. TLS authenticates the server and establishes cryptographic protection for the communication. HTTP/3 changes the transport architecture by using QUIC, which integrates TLS into its connection establishment rather than following the traditional TCP-then-TLS sequence. (IETF Datatracker)
Does every website visit require a new TCP connection?
No. Connections can be reused, and HTTP/2 is specifically designed to multiplex multiple HTTP exchanges over a connection. HTTP/3 uses QUIC instead of TCP. Browser and server behavior, caching and connection state determine how much connection setup is actually necessary for a particular navigation. (IETF Datatracker)
Why does a webpage make so many requests?
The initial HTML document commonly references other resources such as CSS, JavaScript, images, fonts and embedded content. The browser discovers those references while processing the document and can request them as part of constructing the page. Different resources may also come from different hostnames, requiring additional DNS resolution or connections. (MDN Web Docs)
Conclusion
A website visit is not a single request traveling directly from a browser to a server. It is a chain of coordinated systems that begins with interpreting a URL and can involve DNS resolution, routing, transport protocols, TLS authentication, HTTP semantics, caches, CDNs and finally browser rendering.
The traditional DNS-to-TCP-to-TLS-to-HTTP sequence still explains the basic architecture, but modern browsers can reuse connections, serve content from caches, use HTTP/2 multiplexing or HTTP/3 over QUIC, and resolve DNS through encrypted protocols. (IETF Datatracker)
What the user sees as “opening a website” is therefore the final visible result of several separate processes. Understanding those layers makes seemingly unrelated problems—DNS errors, certificate warnings, HTTP status codes, slow resources and long page-rendering times—easier to place within the larger journey from a URL to a webpage.