Load a page on your phone
Follow one ordinary HTTPS visit over Wi-Fi, from a typed address to a rendered page. Cached information and existing connections can shorten the real sequence.
Give the browser an address
You open a web address. The browser identifies the scheme, host, and requested resource. It may already have useful cached data or an open connection. We begin with a visit that needs network activity so the dependencies are visible; actual browsers can overlap and reuse several steps. Resource dependencies determine which additional work follows the first response.
The address identifies a scheme, host, and resource.
The browser needs a concrete target and protocol context.
Read the complete journey
- 1
Give the browser an address
You open a web address. The browser identifies the scheme, host, and requested resource. It may already have useful cached data or an open connection. We begin with a visit that needs network activity so the dependencies are visible; actual browsers can overlap and reuse several steps. Resource dependencies determine which additional work follows the first response.
Notice: The address identifies a scheme, host, and resource.
Explore The browser
Why: The browser needs a concrete target and protocol context. - 2
Cross the first link
Your phone sends information over Wi-Fi to a local access point and onwards through the broadband connection. A mobile-data visit uses a different access system. Both eventually join IP networks. A Wi-Fi symbol alone establishes neither a working provider connection nor reachability to the requested service. The remaining path must still reach the chosen service.
Notice: The local wireless hop leads to a separate provider connection.
Explore The access network
Why: A working first link is necessary but not sufficient for reachability. - 3
Resolve the service name
A resolver supplies naming records, often from its cache. When necessary it follows referrals to authoritative information. The answer helps identify where to connect. This DNS exchange is itself network traffic and happens beside the later web transaction; the page body does not pass through the DNS server. Caching may shorten the lookup.
Notice: A naming answer can be returned without carrying the page body.
Explore DNS & domain names
Why: Lookup provides information for a later service connection. - 4
Forward packets between networks
Packets cross routers towards the selected destination. Each router uses its local forwarding state. Interconnection agreements and routing protocols make reachability across organisations possible. The route is not guaranteed to be geographically shortest, and packets returning to your phone need not traverse precisely the same sequence. The highlighted path is conceptual rather than a measured route.
Notice: Each router makes a local next-hop decision.
Explore Routers & forwarding
Why: Distributed forwarding links independently operated networks. - 5
Establish the protected connection
The browser and service establish a connection with cryptographic protection and appropriate endpoint checks. Common arrangements use TLS with TCP or TLS-based protection in QUIC. This guards the communication channel; it does not prove the website’s claims are true or remove the need to trust the service with data you send.
Notice: A protected channel has a defined endpoint.
Explore TLS & HTTPS
Why: Encryption and authentication protect the exchange within their stated scope. - 6
Request a resource and receive a response
The browser sends an HTTP request. A server or authorised intermediary returns a response with a status, metadata, and usually a body. That initial document may refer to images, styles, and scripts, requiring additional requests. A cache can answer some requests without contacting the origin each time. Those later requests can take different paths or use caches.
Notice: A document response can refer to more resources.
Explore Web servers & HTTP
Why: HTTP gives the application a shared request-and-response meaning. - 7
Build the visible page
The browser interprets the resources, calculates layout, and paints the page. Scripts may add interaction or request more data. Downloads, parsing, and rendering can overlap, so the first visible content and the completion of all work are different milestones. Network delivery is only one part of the experience. Local processing remains a dependency.
Notice: Resources become layout, pixels, and interaction on the device.
Explore The browser
Why: Receiving bytes alone does not create a usable page.
Does the page body normally travel through the DNS resolver after lookup?
Reveal the explanation
No. DNS supplies naming information. The browser then exchanges application data with a service endpoint through the network; the resolver is not a required transit hop for the page body.
Sources & further reading
Original explanations informed by these sources. Diagrams are conceptual; local systems differ.
- Populating the page: how browsers work MDN Web Docs / Mozilla contributors · Not stated · Source & rights record
- RFC 1034: Domain names — concepts and facilities IETF / RFC Editor; P. Mockapetris · 1987-11 · Source & rights record
- RFC 1812: Requirements for IP Version 4 Routers IETF / RFC Editor; F. Baker (editor) · 1995-06 · Source & rights record
- RFC 9846: The Transport Layer Security (TLS) Protocol Version 1.3 IETF / RFC Editor; E. Rescorla · 2026-07 · Source & rights record
- RFC 9110: HTTP Semantics IETF / RFC Editor; R. Fielding, M. Nottingham, and J. Reschke (editors) · 2022-06 · Source & rights record
- RFC 9114: HTTP/3 IETF / RFC Editor; M. Bishop (editor) · 2022-06 · Source & rights record
Another way through the system.
When a network path breaks
Redundancy helps only when it is usable.
Why the second visit can be faster
The trip that does not need repeating.
Send a photo while moving
Radio is the first part of a much longer trip.
Why a fast link can feel slow
Separate capacity from the waiting between actions.