How a browser turns a URL into a page

From address bar to HTML

When you press Enter on https://example.com/page:

1. The browser decides if it is a URL or a search, and checks its caches (HTTP cache, service worker).
2. DNS turns the name into an IP address; a TCP connection and TLS handshake follow (with HTTP/3, QUIC does both at once). See the networking lessons.
3. It sends an HTTP request and receives the HTML response, streaming in as it arrives.

A multi-process program

Modern browsers run as several processes for speed and safety:

• a browser process (address bar, tabs, navigation),
• a renderer process per site or tab (parsing, JavaScript, layout, painting),
• a network process, and a GPU process for drawing.

A crashing or malicious page is isolated in its own renderer and cannot read other sites' data.

The rendering pipeline

100%

Figure SDA-RWS-11-1 · Browser rendering pipeline · © forcsguy.com

1. Parse HTML into the DOM (a tree of elements). Parsing is incremental: the browser starts working before the whole file arrives.
2. Parse CSS into the CSSOM. Rendering waits for CSS, because showing unstyled content then restyling would flash. CSS is render-blocking.
3. Combine into the render tree (only visible elements, with computed styles).
4. Layout works out the size and position of every box.
5. Paint draws the boxes into layers.
6. Composite: the GPU assembles layers into the final image. Animating a layer's transform or opacity only needs this last step.

JavaScript on the main thread

• JavaScript runs on the renderer's main thread, one task at a time in an event loop, alongside parsing, layout and input handling. A long script blocks everything, and the page feels frozen.
• A normal <script> is parser-blocking: parsing stops until it downloads and runs. Use defer (run after parsing, in order) or async (run as soon as available) for scripts not needed to build the first view.
• Changing the DOM or styles can trigger reflow (layout again) and repaint. Reading layout values in a loop right after writing styles forces repeated layout (layout thrashing): batch reads and writes.

What makes pages fast

Goal	Techniques
Less to download	Compression (brotli, gzip), image optimisation and modern formats, remove unused JavaScript
Fewer round trips	CDN, HTTP/2 and 3, preconnect, caching with long lifetimes and versioned names
Less blocking	Inline critical CSS, defer scripts, avoid huge CSS and fonts blocking text
Smooth interaction	Break up long tasks, move heavy work to web workers, animate with transform and opacity
Load only what is visible	Lazy-load images and routes

Browsers also cache, preload likely navigations, and can run offline logic with service workers.

Measuring

Use the Core Web Vitals: LCP (when the main content appears), INP (responsiveness to input) and CLS (unexpected layout shifts). Check both lab tests and real-user data, because real devices and networks are slower and more varied than a developer laptop.

Real-world reading