Typing https://example.com into a browser looks like one tiny action, but a surprising amount of engineering happens before the first pixels appear. Your browser has to understand the URL, discover an address, establish network connections, negotiate security, send an HTTP request, receive a response, and turn bytes into a page.
1. The browser parses the URL
A URL is not just a string. The browser separates the scheme, hostname, optional port, path, query string, and fragment. For example,https://example.com/docs?id=42 means HTTPS is the scheme,example.com is the host, /docs is the path, and?id=42 is the query string.
2. DNS turns a name into an address
Networks route packets using IP addresses, not human-friendly domain names. The browser therefore needs a DNS answer for the hostname. It can often reuse a browser or operating-system cache; otherwise the resolver walks the DNS hierarchy to find an authoritative answer.
A useful mental model is: the domain name is a contact name, while the IP address is the destination. For a deeper explanation, read ourDNS resolution guide.
3. The machine reaches the server
Once an address is known, the operating system decides how to reach it. On a local network this can involve ARP or IPv6 neighbor discovery, then switches, routers, and an ISP carry packets toward the destination. Real requests may cross multiple autonomous systems before reaching a CDN or origin server.
4. HTTPS establishes a secure connection
With HTTPS, the client negotiates TLS with the server. Certificate validation helps the browser verify that the server controls the requested domain, while the handshake establishes symmetric encryption keys for the session. Modern browsers commonly use HTTP/2 or HTTP/3 on top of that secure channel.
5. The browser sends an HTTP request
The request contains a method such as GET, the target path, protocol headers, and often cookies or other metadata. Servers may route the request through a CDN, reverse proxy, load balancer, API gateway, or application service before it reaches the code responsible for generating the response.
6. The server builds the response
A response has a status code, headers, and a body. The body might be HTML, JSON, an image, JavaScript, CSS, or another representation. A cache can sometimes answer immediately; otherwise the application may read a database, call another service, render HTML, or perform authorization checks first.
7. The browser builds the page
The browser parses HTML into a DOM, downloads referenced stylesheets and scripts, computes layout, paints pixels, and schedules additional work. JavaScript can change the DOM, request API data, and trigger more rendering. This is why a page can visibly appear before it is completely finished.
Where latency comes from
A slow page is rarely caused by one magical bottleneck. DNS lookup, connection setup, TLS, server processing, database work, network transfer, script execution, layout, and image decoding can each add time. Performance work is therefore about measuring the whole chain rather than guessing.
A practical debugging checklist
- Use browser DevTools Network to inspect DNS, connection, TTFB, download, and render timings.
- Check whether a CDN or cache is serving static assets close to users.
- Inspect server logs for slow database queries and downstream API calls.
- Reduce unnecessary JavaScript and defer work that is not required for the first screen.
Key takeaway
“Open a website” is really a distributed pipeline: name resolution, routing, secure transport, HTTP, server architecture, and browser rendering all work together. Learning this chain gives you a strong foundation for networking, system design, web performance, and debugging.