How It Works
What Actually Happens When You Click a Link
Six steps between the click and the page appearing. Knowing them explains why things fail, why pages are slow, and how to spot a link that is not what it claims.
Browser-based clock systems rely on the same web requests described here; Monitask explains employee time clock software from the workplace side.
A page appears and it feels instantaneous. Six things happened, each of which can fail differently, and knowing them explains most of what goes wrong on the web.
Step 1: the address is read
The link has an address behind it, and it need not match the text shown.
This is the basis of nearly every phishing attempt. The visible text says one thing; the address goes somewhere else.
How to check: hover over a link and read the address in the corner of the browser. On a phone, press and hold to see it.
What to read in an address: the domain is the part immediately before the first single slash. Everything before it can be anything at all.
https://accounts.yourbank.com.verify-login.example.net/signin
The real domain here is example.net. The bank's name appears earlier and means nothing. This is the single most useful thing to know about reading links. See scams that target home users.
Step 2: the name becomes a number
Domain names do not identify machines; numeric addresses do.
Your device asks a DNS server to translate the name, and the answer comes back — frequently from a cache rather than a fresh lookup.
When this fails: the connection works, other things work, and pages will not load. DNS is the most common cause of "the internet is broken" when it is not, and changing the DNS server frequently fixes it. See wireless connection problems.
Step 3: a connection is made
Your device opens a connection to that address, over the route the network provides.
Packets travel through a series of intermediate networks, each passing them along. The route is not fixed and can change mid-connection. See how the internet was built.
Latency is the round-trip time for this, and it is a different thing from bandwidth. High bandwidth with high latency feels slow on interactive things and fine for downloads.
Step 4: encryption is negotiated
On an https address, before anything is sent.
The server presents a certificate proving it controls that domain, issued by an authority your device trusts.
Your device checks it — the name matches, the date is valid, the chain leads to something trusted.
Then keys are agreed and everything afterwards is encrypted.
What the padlock actually means: the connection is encrypted and the certificate matches the domain you are on. It does not mean the site is legitimate. Anyone can obtain a certificate for a domain they control, including a fraudster. A padlock on a fake bank site is entirely normal, and treating it as reassurance is a mistake.
When this fails: certificate warnings. Usually a wrong clock on your device, sometimes an expired certificate on the site, occasionally something to take seriously. Do not click through them on anything that matters.
Step 5: the page is requested and sent
Your browser asks for the page and the server responds.
What arrives is usually not one thing. A page today is a document plus dozens or hundreds of additional requests — images, fonts, stylesheets, scripts, tracking, advertising — each requiring its own round trip.
This is why pages are slow. Not usually the connection speed; the number of separate requests, and the work the scripts do afterwards.
And why a content blocker speeds things up so noticeably, particularly on older machines: it removes a large share of those requests and the work they cause. See why computers get slower.
Step 6: the browser builds the page
Parses the document, applies the styling, runs the scripts, and draws the result.
Scripts can request more things, so the page continues loading after it appears.
This is where an old machine struggles. The processing is local, and modern pages ask a great deal of it.
What this explains
"The page won't load but my connection works." Usually DNS.
"It's slow but the speed test is fine." Latency, or the number of requests, not bandwidth.
"It loads then jumps around." Content arriving after the initial render.
"It's fine on my phone but not my laptop." Different DNS, different network path, or a browser difference.
"The padlock is there so it must be safe." It is not what the padlock means.
"It worked yesterday." Routes change, caches expire, certificates lapse.
Practical consequences
Read the domain before clicking, and read it correctly — the part before the first single slash.
Never sign in through a link in a message. Open the site yourself. This one habit defeats most phishing regardless of how convincing the page is.
A padlock proves encryption, not honesty.
Use a content blocker. It is the largest single improvement to browsing speed on most machines, and it removes a genuine security exposure through malicious advertising.
Do not click through certificate warnings on anything involving money or personal data.
Check your device's clock if certificate errors appear everywhere. A wrong clock breaks every secure connection.
Shortened and redirecting links
A shortened link hides the destination entirely until you follow it.
Some services let you preview by adding a character to the address — the convention varies.
Treat an unexpected shortened link as unknown, particularly in a message.
And a link can redirect after you arrive, so the address you checked is not necessarily where you end up. Check the address bar once the page has loaded, especially before entering anything.
The short version
The domain is the part immediately before the first single slash. Everything before it can be made to say anything.
DNS failure is the usual cause of pages not loading on a working connection.
The padlock means encrypted, not legitimate — anyone can get a certificate for a domain they control.
Slowness is usually the number of requests, not the connection speed — which is why a content blocker helps so much.
And never sign in through a link. Open the site yourself, every time.
For broader technical standards and computing references, see NIST Information Technology Laboratory.