What you'll learn
Quick Answer
Typing a URL triggers a DNS lookup that turns the domain into an IP address, a TCP connection to that address, a TLS handshake for HTTPS, and then an HTTP request. The server replies with HTML, which the browser parses into a DOM, fetches the CSS, JavaScript and images it references, builds a render tree, calculates layout and paints pixels. Understanding these steps is what lets you place a bug at the right layer instead of guessing.
Step One: DNS Turns a Name Into an Address
Computers route by IP address, not by name. So the first job is translating priodemy.com into something like 162.241.169.234.
The browser checks a series of caches before asking anyone: its own cache, the operating system cache, the hosts file, then your configured resolver — usually your ISP's, or a public one like 8.8.8.8.
If none of them know, the resolver walks the hierarchy: a root server points it to the .com nameservers, which point to the domain's authoritative nameservers, which finally return the address. The answer is cached at each level according to its TTL.
Browser cache → OS cache → hosts file → resolver cache
→ root → .com → authoritative nameserver → IPThat caching explains a thing that confuses people during deployments: after changing DNS, some visitors reach the new server and others still hit the old one for hours. Nothing is broken — caches are expiring at different times. It is also why the fix for many odd site issues really is flushing the DNS cache.
Step Two: Connecting, and Then Securing It
With an IP address, the browser opens a TCP connection — the protocol that guarantees your data arrives complete and in order. It begins with a three-way handshake:
Browser → SYN "can we talk?"
Server → SYN-ACK "yes, can we?"
Browser → ACK "yes"That is one full round trip before a single byte of your request moves. On a connection with 100ms latency, that is 100ms spent on nothing but agreeing to talk — which is why latency, not bandwidth, dominates how fast a site feels.
For HTTPS a TLS handshake follows: the server presents its certificate, the browser verifies it against trusted authorities, and they agree on encryption keys. This costs another round trip or two.
This is measurable and worth knowing as a debugging skill. In curl's timing output, a large gap between time_connect and time_appconnect is TLS negotiation, and a slow TLS handshake usually means the server is physically far from the visitor. That is exactly the problem a CDN solves — terminating TLS at a nearby edge node rather than across the world.
Step Three: The HTTP Request and Response
Now the actual conversation happens. The browser sends a request:
GET /courses/python HTTP/1.1
Host: priodemy.com
User-Agent: Mozilla/5.0 ...
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, br
Cookie: session_id=abc123The Host header matters more than it looks: one IP address usually serves many sites, and this is how the server knows which one you want.
The server replies with a status line, headers and a body:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Cache-Control: max-age=3600
<!DOCTYPE html>...Between your browser and the server there may be several hops — a CDN edge, a load balancer, a reverse proxy — any of which can answer from cache without troubling the application at all. That is why a well-cached page can return in milliseconds while a cache miss takes far longer.
Step Four: Turning HTML Into Pixels
The browser receives HTML as a stream and parses it into the DOM, a tree of nodes. Whenever it meets a reference to CSS, JavaScript or an image, it requests that too — so one page is normally dozens of requests.
Two behaviours here explain most performance advice you have read.
CSS blocks rendering. The browser will not paint until it has the stylesheets, because painting first would show unstyled content and then violently reflow. So a slow stylesheet delays the entire page appearing.
Classic scripts block parsing. A plain <script> in the head stops HTML parsing while it downloads and runs, because it might modify the document. defer tells the browser to keep parsing and run the script after the document is ready; async runs it as soon as it arrives. This is why the advice is to defer scripts or put them at the end of the body.
The browser then combines the DOM and CSS into a render tree, computes layout (where everything goes), and paints the pixels. Changing something that affects geometry forces a re-layout of that part of the page, which is why animating transform and opacity is smooth while animating width or top is not.
Why This Is Worth Knowing
The reason this question is asked in interviews is not trivia. Knowing the sequence lets you locate a fault instead of guessing.
- Site unreachable but the server is running — suspect DNS. Does the domain resolve to the right IP?
- Certificate warnings — TLS layer, not your application.
- Slow first byte with a fast page afterwards — the server is slow to respond, so look at the backend or its distance from the user, not the frontend.
- Fast first byte with a slow page — the response arrived quickly but rendering is blocked. Look at render-blocking CSS and scripts.
- Works in one browser, not another — usually caching or cookies, both of which are per-browser.
- Works in curl but not the browser — a browser-only rule such as CORS or a mixed-content block.
Each of those maps directly onto a step above. That mapping is the real value of the whole exercise, and it is what separates methodical debugging from changing things at random until the symptom disappears.