What happens when you visit a URL
You press Enter, and a few hundred milliseconds later there is a page. In that gap your computer finds a stranger's machine somewhere on Earth, proves it is the right one, asks it a question and draws the answer. Nine steps, every time.
You press Enter
Before a single byte leaves your machine, the browser has to work out what you actually meant. That address bar is doing more interpretation than it lets on.
Every URL is the same six parts
A URL is a set of instructions with a strict grammar: which protocol to speak, who to ask, which door to knock on, what to ask for, and a couple of extras. Most of the time you only type the middle bit and the browser fills in the rest.
Is that an address or a question?
The address bar is also a search box, so the browser has to guess. Roughly: if what
you typed parses as a host name — it has a dot, no spaces, a plausible ending — it is
treated as an address. Otherwise it goes to your search engine. This is why
my server searches and my-server sometimes tries to load a
website that does not exist.
The upgrade you never see
Type techthings.work and you get https:// without asking.
Partly that is browsers defaulting to secure, and partly it is HSTS:
a site can publish a rule saying “never speak to me unencrypted again”, which the
browser remembers and applies before any connection is attempted. Major sites are
also on a preload list baked into the browser itself, so the very first visit is
protected too.
The takeaway At the end of this step the browser has one thing it actually needs: a host name. It still has no idea where in the world that is.
Finding the address
Computers do not route to names, they route to numbers. Turning
techthings.work into something like 104.21.44.9 is the job
of DNS — a global lookup system built on the idea that nobody needs to know
everything, only who to ask next.
The records that matter
| Record | What it holds | Used for |
|---|---|---|
A / AAAA | An IPv4 or IPv6 address | The actual destination |
CNAME | Another name to look up instead | Pointing a name at a hosting provider |
MX | Mail servers for the domain | Email delivery, not web |
TXT | Arbitrary text | Domain ownership proofs, SPF, DKIM |
NS | Which nameservers are authoritative | The delegation itself |
Why DNS changes “take 24 hours”
Every answer carries a TTL — how long it may be cached. Change a record and the world does not find out until the old answer expires everywhere it was stored. Nothing is broken; you are simply waiting for other people's caches. If you know a change is coming, drop the TTL to a few minutes a day beforehand.
Who sees your lookups
Classic DNS is plain text on port 53, so your resolver — and anyone between you and it — sees every name you visit, even though the pages themselves are encrypted. DNS over HTTPS and DNS over TLS wrap those queries up, which is why browsers started sending them to their own resolvers by default, and why that decision was so contentious for network filtering.
The takeaway DNS is a directory, not a doorway. Getting an answer here proves the name exists — it says nothing about whether the machine at that address is up, or is the right one.
Opening a connection
You have an address. Now two machines that have never met have to agree they are talking to each other. Everything in this step is priced in round trips — and a round trip to another continent costs more than any amount of bandwidth can buy back.
Why the protocol version matters so much
Each generation of the web's plumbing has mostly been an argument about how to do fewer round trips before any real data moves.
QUIC, and why it is not TCP
HTTP/3 runs on QUIC, which is built on UDP and folds the transport and encryption handshakes into one. It also fixes a subtle problem: in HTTP/2 many requests share one TCP connection, so a single lost packet stalls all of them — head-of-line blocking. QUIC keeps the streams genuinely independent, which matters far more on a flaky connection than on a fast one.
The takeaway Latency is the tax on every interaction and you cannot pay it off with a faster line. This is the entire reason content delivery networks exist — see step 06.
Proving it is really them
You are now connected to something at that address. TLS is the step that establishes it is the right something, and that nobody in between can read or alter what follows. It is where the padlock comes from — and where most of the misunderstandings about it live.
What a certificate actually proves
A certificate is a public key plus a name, signed by somebody your device already trusts. The trust is not in the site — it is in the chain above it.
The name in the clear
One detail catches people out: the host name is sent in the very first message, before encryption is up, so that servers hosting thousands of sites on one address know which certificate to present. Anyone watching can see which site you are visiting, just not what you did there. Encrypted Client Hello is the fix, and it is still rolling out.
The takeaway TLS answers one question — “am I really talking to the holder of this name, privately?” Every other question about trust is yours to answer.
Asking for the page
After all that setup, the conversation itself is startlingly simple: a few lines of text going one way, a few lines and a document coming back. HTTP has barely changed in shape since 1996 — only in how efficiently it is packed on the wire.
It is never one request
The HTML you get back is a shopping list. Inside it are references to stylesheets, scripts, fonts, images and often a dozen third-party services, each of which is another request — and anything on a new host name means another DNS lookup, another handshake, another certificate. A typical page today makes 50 to 100 requests to build one screen.
HTTP/2 and HTTP/3 make that survivable by multiplexing: all those requests share one connection instead of queuing six at a time. It is why “reduce the number of files” is much weaker advice than it was fifteen years ago, and why “reduce the number of domains” is still good advice.
The verbs you actually meet
| Method | Means | Notes |
|---|---|---|
GET | Give me this | Should never change anything. Safe to repeat, cache and bookmark. |
POST | Here is something, do it | Submitting a form. Repeating it repeats the action — hence “do not press back”. |
HEAD | Just the headers | Checking whether something changed without downloading it. |
OPTIONS | What am I allowed to do? | The invisible pre-flight request behind cross-origin calls. |
The takeaway Steps 2 to 4 were all setup. This is the only part that carries what you actually asked for — and it is plain, readable text underneath the encryption.
Who actually answers
“The server” is a comfortable fiction. What answered you was almost certainly a cache in a data centre near your city, holding a copy of a page that was built somewhere else entirely — and that arrangement is most of why the modern web feels fast.
Static and dynamic are treated very differently
A logo, a stylesheet or an article that rarely changes can sit at the edge for months and be served to millions of people without the origin hearing about it. Your account page cannot — it is different for every visitor, so it has to be built fresh, which means paying the full distance to the origin and the cost of the database query behind it. Most sites are a mixture, and the split is why one part of a site feels instant and another part does not.
Why a site can be “down” only for some people
Because there is no single server. One edge location having a bad day, one DNS answer pointing at a decommissioned address, one region failing health checks — all of these look like “the site is down” to a subset of the world and completely fine to everyone else. It is also why your first instinct should be to check from a second network before you believe anybody's status page.
The takeaway A domain name is not a machine. It is a promise that something will answer, and a great deal of engineering exists to make sure that something is near you.
Building the page
What arrives is a stream of text. Turning it into something you can look at is the browser's own job, and it is the most complicated piece of software on your computer after the operating system.
Progressive, not all at once
The browser does not wait for the whole document. It parses as bytes arrive, starts fetching images and stylesheets the moment it sees them, and paints something as soon as it reasonably can. That is why a page appears in stages, and why the order of things in your HTML has a direct effect on how quickly it feels ready.
The numbers people measure
| Metric | The question it answers | Good |
|---|---|---|
| TTFB | How long until the server said anything at all? Steps 2–6. | < 0.8 s |
| First Contentful Paint | When did something appear? | < 1.8 s |
| Largest Contentful Paint | When did the main thing appear? | < 2.5 s |
| Interaction to Next Paint | When I tap something, does it respond? | < 200 ms |
| Cumulative Layout Shift | Did the page move under my finger? | < 0.1 |
The takeaway A page that arrived quickly can still feel slow. Everything up to step 06 decides when the bytes land; this step decides when the page is usable.
The second visit
Almost nothing you have just read happens again. The web's real performance trick is not doing work faster — it is remembering that the work was already done.
Cache-Control: max-age=600 means “do not even ask me for ten minutes”.
An ETag means “ask, but I will probably just say 304”.
Why cached files can be stale forever
Long cache lifetimes are wonderful right up to the moment you change something. The
standard answer is to never change a file — change its name. Build tools stamp a hash
into filenames (site.4f2a1c.css) so a new version is a genuinely new URL
with no cached copy, and the old one can be cached for a year without risk.
Cookies: how a stateless protocol remembers you
HTTP has no memory — every request stands alone. A cookie is the server handing you a
small piece of text and asking you to present it every time. That is the entire basis
of being “logged in”. The meaningful attributes are HttpOnly (scripts
cannot read it, so a cross-site script cannot steal your session), Secure
(never sent unencrypted) and SameSite (not sent when another site triggers
the request, which kills a whole class of attack).
The other caches nobody mentions
- The connection itself is reused. Later requests to the same host skip steps 3 and 4 entirely.
- DNS answers are held for their TTL, so step 2 usually costs nothing.
- Service workers can intercept requests in the browser and answer from local storage — the mechanism behind sites that still work offline.
- Preconnect and prefetch hints let a page do steps 2–4 for a host before anything is requested from it.
The takeaway “Have you tried a hard refresh?” is the most useful question in web support precisely because so much of this is remembered rather than recomputed.
When it goes wrong
Browser errors look like noise, but each one is a precise statement about which of the previous eight steps failed. Once you can place the error, the fix is usually obvious.
Thirty seconds of triage
The error message, decoded
| What you see | Step | What it actually means |
|---|---|---|
NXDOMAIN | 02 | That name does not exist. A typo, an expired domain, or a record that was never created. |
ERR_CONNECTION_TIMED_OUT | 03 | The name resolved, but nothing at that address answered. A firewall, or a machine that is off. |
ERR_CONNECTION_REFUSED | 03 | Something is there and actively said no. Usually the right server with the wrong port, or a service that is not running. |
ERR_CERT_DATE_INVALID | 04 | An expired certificate — or your own clock being wrong, which is worth checking first. |
ERR_CERT_AUTHORITY_INVALID | 04 | The chain does not lead anywhere trusted. Self-signed, or something is intercepting your traffic. |
403 Forbidden | 05 | It exists, and you are not allowed it. Permissions, or a geographic or bot block. |
404 Not Found | 05 | The server is perfectly healthy. The path is wrong. |
500 / 502 / 504 | 05–06 | The application crashed, the proxy got a bad answer from the origin, or the origin took too long. All their side. |
| Blank page, no error | 07 | It arrived and failed to render. Open the console — this is nearly always a JavaScript error. |
| “It works for me” | 08 | Someone is looking at a cached copy. Hard refresh, or check in a private window. |
Where to look for the truth
- The network tab in developer tools shows every request, its status and exactly where the time went. It answers more questions than any other tool.
- A private window removes cookies, extensions and most caching in one move.
- A second network — tethering to a phone — separates “the internet” from “this office”.
digornslookuptells you what DNS really says, rather than what your machine remembered ten minutes ago.
The takeaway You now have nine places to point at. “The internet is broken” is never a diagnosis — but “DNS resolves, the connection refuses” very much is.