There is a classic interview question: "what happens when you type a URL and press Enter?" For years my honest answer would have been "the page loads". I knew the acronyms, DNS and TCP and TLS, but only as names. What I was missing was the story, the actual sequence of events between the keypress and the first pixel on screen. Once I learned it, many performance problems that used to confuse me suddenly had clear explanations.
So here is the story, told the way I wish someone had told me. You type an address, you press Enter, and for the next few hundred milliseconds your browser works through a checklist that has not really changed in thirty years: find the server, open a connection, secure the connection, ask for the page, then turn a wall of text into pixels. Every step is a place where time can quietly disappear, and that is exactly why the steps are worth knowing.
First, find the server
The address you typed is a name, and names mean nothing to the network. The internet moves traffic between numeric IP addresses, so before anything else, the browser has to translate example.com into something like 93.184.216.34. That translation system is DNS. The simplest way to describe it is a phone book spread across thousands of servers around the world.
A full lookup happens in several steps. Your machine asks a resolver, which is usually run by your internet provider or a public service like Google or Cloudflare. If the resolver does not already know the answer, it asks other DNS servers, level by level, until it reaches the servers responsible for that domain. The good news is that answers get cached at every step, in your browser, in your operating system and in the resolver itself, and each copy expires after a set time. A popular site usually resolves instantly from a nearby cache. An unknown site might need a real trip across the world before the browser even knows where to send the request.
Second, open a connection
With an IP address in hand, the browser can finally talk to the server, but it cannot simply shout "give me the page" right away. First the two machines set up a TCP connection, and they do it with a short exchange called the three-way handshake. Your machine says "I would like to talk", the server answers "I hear you, go ahead", and your machine confirms "great, starting now". Three messages, and only then does a reliable channel exist between them.
This exchange sounds like something you could skip, but you cannot, because TCP is what makes the internet dependable. The network underneath drops packets, duplicates them and delivers them in the wrong order. TCP hides all of that by numbering every piece of data and resending whatever gets lost. The handshake is how the two sides agree on the starting numbers, so the counting works. The cost is one full round trip before any real data flows. This is why physical distance to the server still matters, even with a fast connection. It is also why CDNs place servers near users: you cannot make light travel faster, but you can make the trip shorter.
Third, secure the connection
For an https address there is one more negotiation before the first real byte. It is called the TLS handshake, and it has two jobs. The first job is proving that you are talking to the right server. The server presents a certificate, which is a signed statement from an organization your browser already trusts, saying that this server really does speak for that domain. Your browser checks the signatures, and this check is the machinery behind every certificate warning you have ever clicked through, hopefully after reading it.
The second job is agreeing on encryption keys. The two sides perform a key exchange, which is clever math that lets them arrive at a shared secret even while someone watches every message between them. From that point on, everything they send is encrypted. All of this costs roughly one more round trip, and then, at last, the browser can ask for what you wanted.
Fourth, ask for the page
The request itself is very simple after all that setup. The browser sends an HTTP request, which is plain text that says, more or less, "GET / and here is who is asking". The server replies with a status code, response headers and the HTML itself. After three phases of pure plumbing, this is the first moment the conversation is about actual content.
It is also the moment where the server can be slow. Everything up to now was network delay, but the gap between request and response is your application: routing, database queries, template rendering, all of it happening while the browser waits. When developers talk about server response time or "time to first byte", this pause is the thing they are measuring.
Fifth, turn text into pixels
Now the browser has HTML, and the most interesting work starts. It parses the document from top to bottom, building a tree of elements called the DOM. As it reads, it keeps finding more things it needs. A stylesheet link, an image, a script tag: each one triggers another download, and some of them change how the browser behaves.
Two of these downloads are special because they can pause everything. CSS blocks rendering, because the browser refuses to paint anything before it knows how the page should look. A flash of unstyled content would be worse than a short wait. Classic script tags are even more disruptive, because JavaScript can rewrite the document while it is being parsed. So the parser must stop, fetch the script, run it, and only then continue. This is why "put CSS early, load scripts with defer" became standard performance advice long ago. Fonts have their own version of this problem, where browsers hide or swap text while the real font downloads.
Once the browser has the DOM and the styling information, it runs layout, calculating where every element sits and how big it is. Then it paints, filling in actual pixels and combining the layers into a frame. That frame, the first one with real content in it, is the moment this whole story has been building toward. From keypress to this point is often under a second, and inside that second there was a distributed name lookup, two negotiated handshakes, an application doing real work and a rendering engine laying out a document.
Why the story is worth knowing
The practical value is that "the site is slow" stops being one big mystery and becomes five small questions. Slow for everyone or only for far-away users? Look at network round trips and CDN placement. Long wait before the first byte? That is the server's part, so go look at the backend. Page arrives fast but appears late? Now you are hunting render-blocking CSS and scripts. Each phase leaves its own kind of evidence, and the waterfall chart in DevTools will show you exactly which one is taking the time.
And the next time someone asks you the interview question, you will have something better than acronyms. You will have the story: find the server, open a connection, secure it, ask for the page, then build the page from text. Everything else in web performance is a detail on top of those five steps.