How a Browser Renders a Webpage — And Where React, CSR, and SSR Fit In

Published: (March 15, 2026 at 10:02 AM EDT)
3 min read
Source: Dev.to

Source: Dev.to

How a browser processes a request

DNS lookup

The browser checks its cache first. If the resource isn’t cached, it queries the Domain Name System to resolve the domain to an IP address.

example.com → 93.184.216.34

TCP / TLS handshake

A TCP connection is opened to the server. If the site uses HTTPS, a TLS handshake establishes a secure channel.

HTTP request

The browser sends an HTTP request, e.g.:

GET /index.html HTTP/1.1
Host: example.com

Server response

The server streams back the required resources (HTML, CSS, JavaScript, images, fonts, etc.). Because they are often sent in chunks, the browser can start processing them before the entire payload finishes downloading.

How the UI is rendered

Parsing HTML → DOM

As soon as HTML bytes arrive, the parser builds the Document Object Model (DOM) tree.

## Products

Item 1

Resulting structure:

body
 ├── h1
 └── p

Parsing CSS → CSSOM

When or tags are encountered, the browser creates a CSS Object Model (CSSOM) that maps selectors to style rules.

p {
  color: blue;
}

Render tree (DOM + CSSOM)

The DOM and CSSOM are merged into a render tree that contains only the nodes that will be painted (elements like “ or those with display:none are omitted).

Layout (reflow)

The browser calculates each visible element’s geometry—width, height, and X/Y position—so the UI fits the viewport.

Painting

Visual details (colors, borders, text, shadows, images) are rasterised onto layers. Certain elements (sticky headers, popups, transformed elements, animations) are placed on separate layers for GPU‑accelerated compositing.

Compositing

Layers are composited together to produce the final bitmap shown on the screen.

JavaScript execution and blocking

When a “ tag is encountered, HTML parsing pauses:

The browser downloads the script, executes it, then resumes parsing. This is why scripts can block rendering. To mitigate blocking:

Where React, CSR, and SSR fit in

Client‑Side Rendering (CSR)

The server returns a minimal HTML shell and a JavaScript bundle. The browser initially shows an empty page; React then builds the UI on the client.

  

  
// main.js
ReactDOM.createRoot(document.getElementById('root')).render();

Typical flow:

  1. Blank screen →
  2. JavaScript loads →
  3. UI appears (React creates DOM nodes dynamically).

Server‑Side Rendering (SSR)

The server pre‑renders React components into full HTML, so the browser can display meaningful content immediately.

## Products

Item 1

After the HTML is painted, the JavaScript bundle hydrates the page—attaching event listeners and making the UI interactive.

  • Before hydration: button visible but not clickable.
  • After hydration: button becomes interactive.

Comparison

FeatureCSRSSR
Initial HTMLEmpty “Fully rendered markup
First loadBlank screen → UIContent appears instantly
SEOLimitedBetter (searchable HTML)
Rendering locationBrowser (client)Server (initial) + client

Takeaways

  • Understanding the browser’s rendering pipeline lets you optimise performance and avoid render‑blocking pitfalls.
  • Choose CSR for highly interactive single‑page apps where client logic dominates.
  • Choose SSR (or hybrid approaches like Next.js) for faster initial loads and improved SEO.
  • Modern frameworks often combine both, delivering a quick first paint with client‑side interactivity after hydration.
0 views
Back to Blog

Related posts

Read more »

The 49MB web page

Article URL: https://thatshubham.com/blog/news-audit Comments URL: https://news.ycombinator.com/item?id=47390945 Points: 203 Comments: 126...

The 49MB Web Page

Article URL: https://thatshubham.com/blog/news-audit Comments URL: https://news.ycombinator.com/item?id=47390945 Points: 8 Comments: 0...