How the Web Works: Browser to Server

How the Web Works: Browser to Server

The web starts with a URL and ends with pixels on a screen. Between those two points, the browser resolves a domain, opens a connection, sends an HTTP request, receives a response, parses the response, and renders the page.

Step 1: URL Resolution

When you enter a URL, the browser first checks its cache and then asks DNS for the IP address. That lookup turns a human-readable domain into a network address the client can contact.

Step 2: Connecting to the Server

The browser opens a connection using TCP, and with HTTPS it also negotiates TLS. This establishes a reliable and encrypted channel before any page data is exchanged.

Step 3: Sending the Request

The browser sends an HTTP request with a method, headers, and sometimes a body. The server uses that request to decide what data to return.

Step 4: Receiving the Response

The response includes a status code, headers, and a body. For HTML, the browser starts parsing immediately and may discover CSS, JavaScript, images, and fonts while it works.

Step 5: Rendering the Page

The browser builds the DOM from HTML, the CSSOM from stylesheets, combines them into a render tree, lays out the page, and paints pixels. JavaScript can block or modify this pipeline, which is why script placement matters.

What Frontend Engineers Should Care About

• DNS lookup time affects first request latency.
• Large JavaScript bundles delay parsing and execution.
• Render-blocking CSS delays first paint.
• Third-party scripts can slow the whole page.
• Caching can remove repeated network work.

The Takeaway

The web is a request-response system layered on top of DNS, TCP, TLS, HTTP, and the browser rendering pipeline. If you understand each step, you can debug slow pages and design frontend systems that load predictably.