What Happens When You Press Enter in a Browser?
Pressing Enter after typing a URL looks like one action. It is not. The browser has to decide what the input means, find the destination, establish or reuse a connection, ask a server for a document, and turn the response into pixels.
That sequence is useful as a map, but it is not a promise that every page load follows the same path. A cached response may avoid the network. A reused HTTP/2 or HTTP/3 connection may avoid new handshakes. A service worker may intercept the navigation. A server-rendered page may be visible before its JavaScript becomes interactive.
This is Part 1 of the How the Web Works series. The later articles take the most important sections of this map apart. This article stays focused on the order of events and on how to find the layer responsible when a page is slow or broken.
Quick Answer
When you press Enter, the browser usually does something close to this:
Address bar input
↓
URL parsing and browser security checks
↓
DNS, unless a usable answer is already cached
↓
Reuse or establish TCP/TLS, or use QUIC for HTTP/3
↓
Send an HTTP request
↓
CDN, proxy, load balancer, and application server
↓
Receive HTML and discover more resources
↓
Build DOM/CSSOM, calculate layout, paint, and composite
↓
Run JavaScript and hydrate interactive UI
The important debugging habit is to ask which step is slow or incorrect, rather than saying that “the website” is slow.
1. The Browser Interprets the Input
The address bar accepts more than URLs. The input might be a search query, a bookmark keyword, a local file, or a complete URL. If it is a URL, the browser separates it into its meaningful parts:
https://suriyaprakash.in/blog/engineering?tag=dns#intro
\___/ \_______________/\_______________/\______/
scheme host path/query fragment
The fragment is handled locally. The server receives /blog/engineering?tag=dns, not #intro. After the document loads, the browser looks for an element with the matching ID and scrolls to it.
Before making a request, the browser can also apply HSTS, normalize the URL, consult a service worker, and check whether an existing page or response can be reused. This is why a “page load” is not always a fresh DNS lookup followed by a fresh TLS handshake.
2. DNS Finds an Address
The browser needs an IP address before it can connect to a hostname. It may find one in a browser cache, operating-system cache, local network cache, or recursive resolver.
On a cache miss, a recursive resolver follows referrals toward the authoritative nameserver:
Recursive resolver
↓
Root server → TLD server → Authoritative server
↓
A/AAAA answer returned and cached according to TTL
The full delegation path is only one possible path. In practice, cached answers make most lookups much shorter. A DNS problem can therefore be local to one resolver, caused by stale data, caused by incorrect delegation, or caused by the authoritative record itself.
Useful first checks are:
nslookup suriyaprakash.in
Compare the answer from your normal resolver with an independent resolver and, when necessary, the authoritative server. Do not assume that “DNS propagation” is a single global process.
3. The Browser Reuses or Establishes a Connection
If the browser already has a usable connection to the origin, it may reuse it. Otherwise, the transport depends on the negotiated HTTP version:
| HTTP version | Transport | Important detail |
|---|---|---|
| HTTP/1.1 | TCP | Separate requests are commonly spread across connections |
| HTTP/2 | TCP | Multiple streams share one connection |
| HTTP/3 | QUIC over UDP | Streams avoid TCP-level cross-stream blocking |
For HTTPS over TCP, the browser normally completes a TCP handshake and then a TLS handshake. TLS authenticates the server and establishes encryption. The browser checks the certificate, hostname, validity period, chain, and applicable trust policy.
That distinction matters when debugging. A DNS answer can be correct while the certificate is wrong. A certificate can be valid while the origin is unreachable. A successful TLS connection can still be followed by an HTTP 502 from a proxy.
4. The Request Crosses Infrastructure
The browser sends a request containing the method, path, headers, cookies, and negotiation preferences. The request may pass through several components before application code runs:
Browser
↓
CDN edge / WAF
↓
Load balancer or reverse proxy
↓
Application server
↓
Database, cache, or external API
The public server is often not the process that renders the page. A CDN may serve a cache hit without contacting the origin. A reverse proxy may terminate TLS, redirect HTTP, apply a rate limit, or add forwarding headers. The application may then authenticate the request, load data, and render HTML.
For a server-rendered React application, the browser may receive useful HTML before it receives all JavaScript. That makes the page visible early, but it does not necessarily make every button interactive immediately.
5. The Browser Turns Bytes into a Page
The browser starts parsing HTML as bytes arrive. It discovers stylesheets, scripts, images, fonts, and other resources while the document is still downloading.
HTML → DOM
CSS → CSSOM
DOM + CSSOM → Render tree
Render tree → Layout → Paint → Composite
CSS can delay rendering because the browser needs to know how content should look. A normal script can pause HTML parsing. Large images, fonts, third-party scripts, and JavaScript execution can all affect the time until the page feels usable.
In an SSR application, hydration is a separate milestone. The server has already sent markup; the client now attaches event handlers and application state to that markup. A page can therefore look complete while still being temporarily non-interactive.
A Better Way to Debug a Slow Load
Start with the browser Network panel and separate the timeline:
Queueing / cache
DNS
Connection
TLS
Request waiting / TTFB
Response download
Parsing and rendering
JavaScript execution
Then test the layer that looks suspicious:
curl -I https://suriyaprakash.in/blog/engineering
curl -v https://suriyaprakash.in/blog/engineering
Ask these questions in order:
- Did the browser use a cached response or make a network request?
- Did DNS return the expected address from more than one resolver?
- Was the connection reused, or did the browser pay for TCP and TLS?
- Was the delay before the server responded or while downloading the response?
- Did a CDN or reverse proxy serve the request?
- Is the HTML slow, or are the resources attached to it slow?
- Is the page visible but waiting for hydration?
This ordering prevents a frontend symptom from being blamed on the database, or a TLS failure from being blamed on React.
FAQ
Does pressing Enter always trigger a DNS lookup?
No. The browser checks its own cache, the operating-system cache, and the local network before asking a recursive resolver. Cached answers also cut the lookups short, so many page loads never walk the full delegation path from root to authoritative server.
Why can a page be visible but not interactive?
For a server-rendered application, the browser can paint the HTML the server sent while the JavaScript is still downloading and executing. Hydration then attaches event handlers and application state to the existing markup. Until that finishes, the page can look complete but buttons may not respond.
Is "DNS propagation" a single global process?
No. Each resolver caches and refreshes answers independently according to the record's TTL. Different resolvers can legitimately see different answers at different times. If you see an inconsistency, compare your normal resolver with an independent one and, when necessary, with the authoritative server.
Why does curl behave differently from the browser?
A browser applies service workers, browser caches, HSTS, cookies, and client hints before and during a request. curl sends a plain request with no history. If the results differ, check whether the browser reused a cached response or a connection, and compare the exact headers each side sends.
Does the server receive the fragment part of a URL?
No. The fragment after # is handled locally by the browser, which uses it to find an element with a matching ID after the document loads. The server receives the path and query string only.
Can a page be slow even though every step below is healthy?
Yes. Each layer can fail on its own, so a correct DNS answer does not guarantee a working certificate, and a working connection does not guarantee a healthy origin. That is why the debugging habit from this article is to identify the slow step first, not to assume the whole path is at fault.
What This Article Deliberately Leaves Out
The rest of the series goes deeper into the individual layers: HTTP semantics, DNS caching and delegation, TLS, server-side request handling, browser rendering, and production debugging.
The goal here is not to memorize every protocol detail. It is to keep the whole path in your head while investigating one failure. If a request is slow, identify the boundary first. If a request is unauthorized, separate identity from permissions. If a page is visible but not interactive, separate rendering from hydration.
Final Mental Model
User presses Enter
↓
Browser interprets and secures the URL
↓
Name resolves to an address, often from cache
↓
Connection is reused or established
↓
HTTP request crosses infrastructure
↓
Server creates a response
↓
Browser parses HTML and discovers resources
↓
DOM + CSSOM become pixels
↓
JavaScript makes the page interactive
A useful mental model is not a list of steps that must always happen. It is a way to locate responsibility. Once the browser, network, infrastructure, server, and rendering engine are separated, “the site is broken” becomes a question that can actually be tested.
Series: How the Web Works
Part 1 of 7