What Actually Happens When You Click a Link?

Or: A Lot Happens Between Click and Website

You see a link. You click it. A fraction of a second later, a webpage appears.

From your perspective: click → website. But your computer just resolved a domain name, established an encrypted connection, verified a digital certificate, sent a request to a server, received HTML, discovered dozens of additional resources, downloaded and executed code, calculated a page layout, and turned all of it into pixels.

And there's a good chance it contacted several different servers while doing it.

Let's slow the whole thing down.

The URL Is More Than a Website Name

When you click "Read More," you aren't clicking the internet — you're clicking a URL. It might look like https://example.com/articles/cats. That single line contains three pieces of meaningful information.

The first part — https — is the protocol, describing how the browser should communicate. The second — example.com — is the domain name, identifying the site. The third — /articles/cats — identifies a specific resource within that site. Think of it like a mailing address: the domain gets you to the right building, the path tells you what you're asking for once you arrive.

But computers don't route traffic using names like example.com. They need numerical network addresses. So before the browser can ask the website for anything, it first has to figure out where the website actually is.

Step 1: DNS — Finding the Address

The Domain Name System converts human-readable domain names into the IP addresses computers use to find each other on the network. Your browser needs an answer to: "Where is example.com?"

Before going out to ask, it checks what it already knows. The browser may have cached the answer from a recent visit. The operating system may have cached it. If a usable answer is already available, this step is skipped. If not, your computer sends a DNS query to a resolver, which works through the DNS hierarchy to find the authoritative answer for the domain.

The resolver returns an IP address. Now the browser has somewhere to go.

Notice what's happened: you've clicked once, and before a single byte of the actual webpage has arrived, your computer has already communicated with separate infrastructure just to learn where to send the request.

Step 2: Establishing a Connection

An IP address isn't a connection — it's a destination. The browser now needs to establish a way to exchange information with the server.

Most web connections have historically used TCP (Transmission Control Protocol), which begins with a handshake: the browser and server exchange a short sequence of messages confirming they can communicate. Newer connections may use QUIC, a protocol underlying HTTP/3 that operates differently but serves the same purpose. Either way, the goal is to establish a reliable two-way channel.

But you don't just want a connection. You want a secure one.

Step 3: TLS — The Encrypted Channel

Modern URLs begin with https://, and the S matters. It means the connection is protected by TLS (Transport Layer Security), which provides three things: encryption so observers can't read the conversation, integrity so tampering can be detected, and authentication so the browser can verify it's talking to the right site.

Before encrypted traffic flows, the browser and server complete a TLS handshake. As part of this, the server presents a digital certificate — a credential issued by a trusted certificate authority that helps confirm the server's identity. The browser checks whether the certificate applies to the domain you're visiting, whether it's within its valid dates, and whether it traces back to an authority the browser trusts.

If something is wrong, that's when you see the "Your connection is not private" warning. The browser isn't complaining about the website's design — it's saying it can't establish the identity relationship it expected.

Once TLS succeeds, everything flowing between your browser and the server is encrypted. Someone watching network traffic can see that you're communicating with a server, but not what you're saying or receiving.

We've now handled DNS, connection, and encryption — and the webpage still hasn't started loading.

Step 4: The HTTP Request

With a secure connection established, the browser sends an HTTP request: "Please give me /articles/cats." Along with that basic ask, the request may carry cookies, authentication information, language preferences, information about what content types the browser accepts, and various other headers that web servers use to tailor their responses.

The server receives the request and figures out what to return. For a simple site, it may retrieve a file. For a complex one, the request can trigger a chain of work — querying a database for content, checking a session store for your login, calling an API for recommendations, assembling pieces from multiple sources — before a response is ready.

Step 5: The Response

The server responds with an HTTP status code and, if things went well, the requested content. You've probably seen 404 Not Found, but that's one member of a larger family. 200 OK means success. 3xx codes are redirects. 4xx codes indicate client-side issues. 5xx codes indicate server-side problems. These numbers are the server's concise way of telling the browser what happened before any content is considered.

For a typical webpage, the first major piece of content is HTML — HyperText Markup Language, which describes the structure of the page: headings, paragraphs, links, images, forms. The browser receives this and begins parsing it.

Then it discovers the page isn't finished.

Step 6: Loading Everything Else

HTML is usually just the beginning. As the browser parses it, it finds references to other resources: stylesheets, scripts, fonts, images, icons. Each may require a separate request. A complex modern webpage can involve dozens or hundreds of individual network requests to fully load what you see as one page.

CSS (Cascading Style Sheets) handles presentation — telling the browser what everything should look like: fonts, colors, spacing, positioning. Without it, pages would be raw, unstyled structure. JavaScript handles behavior — code that runs inside the browser and can respond to clicks, update content without reloading the page, fetch new data, run animations, and power entire web applications.

When the browser downloads JavaScript, it executes that code locally on your computer. Not everything a website does happens on a remote server. Some of the application runs right in your browser.

Step 7: Layout and Rendering

With HTML, CSS, and JavaScript parsed, the browser builds internal representations of the page structure and styling, then calculates layout: how wide is each element, where does it go, what happens when the window is 800 pixels wide instead of 1400? It then composites everything — text, backgrounds, images, borders, animations — into the pixels you see on screen. Modern browsers offload parts of this to the GPU, particularly compositing, animations, and video.

This is also where our earlier articles connect: the browser creates visual content that becomes part of the composed desktop image the window compositor sends to your display.

Where the Content Actually Comes From

The HTML may come from one server. The images may come from a CDN — a Content Delivery Network that keeps copies of content in geographically distributed locations so you can receive them from infrastructure closer to you. The analytics script may come from a third-party service. The embedded video from another. The comment system from yet another.

The webpage that looks like one unified thing is often assembled from resources delivered by multiple organizations and locations. And each of those third-party resources may introduce additional network requests of their own.

Caching: Not Doing the Work Again

Fortunately, browsers don't download everything from scratch every time. They maintain caches of previously retrieved resources. If the same logo appears on every page, the browser reuses its stored copy instead of downloading it again. The same applies to stylesheets, scripts, and fonts.

DNS answers are cached too. Your OS and browser remember recent lookups so they don't repeat the full resolution process for every request to the same domain. Servers cache generated pages. CDNs cache content. Modern computing can be summarized as: do the expensive thing once and desperately try not to do it again.

Why This Can Still Feel Slow

A faster internet connection helps, but beyond a certain point it stops being the bottleneck. Loading a page involves DNS lookups, connection establishment, TLS negotiation, server processing time, and sequential discovery of additional resources — and each of those takes time regardless of your download speed. A wider road doesn't help when your route involves twenty traffic lights.

This is why web performance engineering obsesses over milliseconds. Humans notice latency faster than we notice other delays — shaving 200ms off a page load genuinely changes how the experience feels.

The Bard's Take

Clicking a link looks like one of the simplest things you do on a computer. You click; the page appears. But your computer resolved a name through a distributed global directory, established an encrypted authenticated channel with a server it had never spoken to before, fetched HTML that led it to discover dozens of additional resources, downloaded and executed code, calculated where every element belongs on your screen, and composited the result into pixels.

All of it may have happened in well under a second.

That's what modern technology looks like when it's working correctly — not simple, but made to feel that way. The systems underneath have been refined for decades around making this absurdly complicated process feel instantaneous. All those pieces of hardware and software scattered across potentially thousands of miles quietly cooperated to answer your request.

And if everything went right, you never noticed any of them. You just got the page.

Sources

• What Happens in a TLS Handshake? — Cloudflare
• How Browsers Work — MDN Web Docs
• Domain Name System — Wikipedia — Wikipedia
• What Is HTTPS, and Why Should I Care? — How-To Geek