What happens between typing an address and pressing Enter
Between your keystroke and the page there are half a dozen steps, several computers and a few tenths of a second. Knowing them explains why something is slow and where the problem sits.
You type an address, press Enter, a page appears. It looks instant.
In reality six or seven stages have happened, several computers around the world were involved, and messages went back and forth. All in a few tenths of a second.
The route is worth knowing, because when something goes wrong it almost always breaks at one specific point in this chain.
1. The browser works out what you meant
Before touching the network it decides what you intended. Something with no dots is probably a search. Something shaped like a domain is an address.
Then it checks its HSTS list: domains that declared they’ll only be served over HTTPS. If yours is on it, the request goes out as HTTPS even if you typed http://, with no redirect involved. That’s what stops anyone intercepting that first unencrypted hop.
2. From name to address: DNS
Computers don’t find each other by name but by IP address. Translating bawitools.com into a number is DNS’s job.
The lookup goes in layers, each existing so you don’t have to reach the next:
- The browser’s own cache
- The operating system’s cache
- The
hostsfile, which can force an answer - The DNS server you use — your ISP’s, or a public one
- And if nobody knows: the root servers, then the
.comservers, then the domain’s own
When it works it takes milliseconds. When it fails the symptom is unmistakable: one page won’t load while others do, or the browser sits for a long while on “looking up the site”.
3. Opening the conversation: TCP
With the IP in hand, the browser establishes a connection through the so-called three-way handshake: your computer asks, the server confirms, your computer confirms the confirmation.
Physics rules here. Each round trip costs whatever the signal takes to cover the distance, and that’s latency: the delay no amount of extra bandwidth fixes. A server on the other side of the world has a latency no tariff improves.
That’s the difference between bandwidth and latency, and it explains why a very fast connection can still feel slow.
4. Agreeing on encryption: TLS
If it’s HTTPS — nearly always now — there’s one more negotiation: agree on the cipher, present the certificate, generate the session keys.
The browser checks three things about the certificate: that a trusted authority signed it, that it hasn’t expired, and that it matches the domain you asked for. If any fails, you get the connection-not-private warning.
TLS 1.3 cut this to a single round trip, and for a connection it already knows it can reach zero.
5. The request
Only now is the page actually requested. The browser sends a line like GET /en/blog/ along with some headers: which browser it is, which languages it prefers, which formats it accepts, and whether it already has a cached copy.
That last part matters. If the browser says “I already have the version with this fingerprint”, the server can answer 304 Not Modified — a few bytes — instead of sending the whole page.
6. The server answers
And it answers with a number worth knowing how to read:
| Code | What it means |
|---|---|
| 200 | Here you go |
| 301 | Moved permanently, go here instead |
| 302 | Moved for now |
| 304 | Unchanged, use your copy |
| 403 | It exists, but you can’t see it |
| 404 | It doesn’t exist |
| 500 | It exists, but broke while being generated |
| 503 | The server is overwhelmed |
Redirects cost: each one is another full round trip. That’s why a well-configured site links straight to the final URL instead of chaining hops.
7. Painting the page
The HTML arrives and the visible part begins.
The browser reads it top to bottom, building the document tree. When it hits a stylesheet it stops: without styles it can’t know how anything looks, so CSS blocks painting. When it hits a script it stops too, because that script could modify the document — unless it’s marked async or defer.
With the document and the styles, it calculates the position and size of every element, and finally paints.
That’s why order matters so much: styles at the top, scripts at the end or deferred. A heavy script in the middle of the <head> delays the page’s first appearance even when everything else is ready.
Then the fonts arrive, and with them the flicker of text changing appearance mid-load.
Where to look when it’s slow
With this map, diagnosis becomes concrete. Open F12 → Network and look at the timing column:
- Long “DNS” → resolution problem. Try a different DNS server.
- Long “Connecting” or “SSL” → the server is far away or overloaded. A CDN is the usual answer.
- Long “Waiting” (TTFB) → the server is slow to generate the page. That’s server logic or database, not network.
- Long “Download” → the files are too heavy. Unoptimised images are usually 80 % of it.
- Everything fast but the page takes ages to appear → it’s rendering: blocking scripts, or too much JavaScript ahead of the content.
That distinction saves a lot of time. Optimising images when the problem is TTFB fixes nothing, and it’s a common mistake.
What’s left
Behind every Enter there’s a name lookup, a handshake between machines, a cryptographic negotiation, a request, a response and a drawing process — repeated for every file making up the page, which is usually dozens.
That all of it happens in under a second, reliably, millions of times a day, is one of those things that only seems ordinary because it works.