What Happens When a Page Loads

"The site feels slow" is one of the least useful sentences in web work, because a page load is not one thing. It's a relay race with roughly a dozen handoffs — DNS resolution, connection setup, server work, download, parsing, rendering — and the baton can be dropped at any of them. A site can have a lightning-fast server and still feel sluggish because of a render-blocking stylesheet, or a bloated theme and still feel fast because everything after the first paint is deferred well.

Once you know the sequence, you stop guessing. You can look at a waterfall chart in your browser's developer tools and say "the server took 1.8 seconds to answer — that's a backend problem, no image optimizer will fix it" or "the HTML arrived in 200ms but nothing painted for 3 seconds — that's a front-end problem, no hosting upgrade will fix it." This post walks the whole chain, in order, with the practical implications for anyone running a site.

Step 1: DNS — Finding the Server's Address

The browser has a domain name; it needs an IP address. It asks the operating system, which asks a resolver (usually your ISP's or a public one like 1.1.1.1), which may need to ask the domain's authoritative nameservers. This whole negotiation typically takes 20–120 milliseconds on a first visit and roughly zero on repeat visits, because the answer is cached at several layers.

What matters for a site owner:

• Nameserver quality matters more than people think. If your DNS is hosted on a slow or geographically distant nameserver, every first-time visitor pays a tax before your site has done anything. Anycast DNS providers (Cloudflare, Route 53, most modern registrars' premium DNS) answer from a server near the visitor.
• Low TTLs are a self-inflicted wound if left permanently. A TTL of 300 seconds is great during a migration; leaving it there forever means resolvers throw away the answer every five minutes and re-ask. For stable records, TTLs of an hour or more are reasonable.
• Every extra domain repeats this cost. If your page loads assets from six third-party domains, that's up to six additional DNS lookups. This is why consolidating assets onto fewer hostnames still pays off.

Step 2: TCP and TLS — Shaking Hands

With an IP address in hand, the browser opens a TCP connection (one round trip) and negotiates TLS encryption (one more round trip on modern TLS 1.3; two on the older 1.2). A "round trip" is the time for a packet to reach the server and come back — maybe 15ms to a nearby server, 150ms or more across an ocean.

This is the step where physical distance becomes unavoidable arithmetic. Three round trips at 150ms each is 450ms of dead time before a single byte of your page has been requested. Two things attack this:

• CDNs and edge networks terminate the connection near the visitor, so those round trips happen over a 10ms hop instead of a 150ms one — even if the origin server is far away.
• HTTP/2 and HTTP/3 reuse one connection for many resources, so the handshake tax is paid once per domain instead of per file. HTTP/3 (QUIC) folds the transport and encryption handshakes together, saving another round trip. Any decent host provides these by default now; if yours doesn't, that's a signal about the host.

Step 3: The Server Thinks — Time to First Byte

Now the browser sends the actual request, and the server has to produce a response. For a static file, that's near-instant. For a WordPress page without caching, the server boots PHP, loads WordPress core, loads every active plugin, runs the theme, and makes dozens of database queries — routinely 300ms to 2+ seconds of pure computation.

The metric that captures steps 1–3 combined is TTFB (Time to First Byte). It's the single most diagnostic number in a waterfall:

• TTFB under ~200ms: backend is healthy (or page caching is doing its job). Look at the front end for problems.
• TTFB 200–600ms: acceptable, but full-page caching would probably help.
• TTFB over 800ms: the backend is your bottleneck. No amount of image compression or JavaScript minification will fix this — it happens before any of that.

Full-page caching is the great equalizer here: a cached HTML response skips PHP and the database entirely, turning a 1.5-second TTFB into 50ms. This is the single biggest reason "managed WordPress hosting" tends to feel faster — it's not magic hardware, it's aggressive caching configured correctly.

Step 4: HTML Arrives and Parsing Begins

The browser doesn't wait for the full HTML document. It starts parsing as bytes stream in, building the DOM (Document Object Model) — the tree structure representing your page. As it parses, it discovers other resources it needs: stylesheets, scripts, fonts, images.

Two parser behaviors are worth knowing because they explain most "why is nothing showing up" mysteries:

• The preload scanner runs ahead. A secondary, lightweight scanner races through the raw HTML looking for URLs to fetch, even while the main parser is blocked. This is why resources referenced directly in HTML load early, while resources referenced from inside CSS files (like background images and fonts) or injected by JavaScript load late — the scanner can't see them. A font declared in a CSS file that's imported by another CSS file can start downloading embarrassingly late in the load.
• Classic script tags block parsing. A plain script tag without defer or async stops the HTML parser cold: the script might document.write something, so the browser must download and execute it before continuing. One slow third-party script in the head of the page can freeze the entire parse. This is why "defer your JavaScript" appears in every performance guide — it lets the parser finish and runs scripts afterward, in order.

Step 5: CSS Blocks Rendering (On Purpose)

Here's the part that surprises people: the browser will not paint anything until it has downloaded and parsed all render-blocking CSS. This is deliberate. Painting the page unstyled and then restyling it would produce a flash of ugly, jumping content, so the browser waits for the CSSOM (the CSS equivalent of the DOM) to be complete before rendering.

The practical consequences:

• Every stylesheet in the head of your page is a gate between your visitor and seeing anything. Ten plugin stylesheets = ten gates (mitigated but not eliminated by HTTP/2 multiplexing).
• This is the actual problem that critical CSS techniques solve: inline the small amount of CSS needed for the visible top of the page, and load the rest without blocking.
• Unused CSS isn't just wasted bytes — it's wasted parse time inside the blocking window. A 400KB stylesheet where the page uses 30KB delays first paint for everyone.

Step 6: Layout, Paint, Composite — Pixels at Last

With DOM and CSSOM in hand, the browser combines them into a render tree, then does three jobs:

1. Layout (reflow): compute where every box goes and how big it is. This is geometry — widths, heights, positions.
2. Paint: fill in the pixels — text, colors, borders, shadows, images — into layers.
3. Composite: stack the layers together, on the GPU, into the final frame you see.

The first time this completes for meaningful content, you get the moment users perceive as "the page loaded" — which is what Largest Contentful Paint (LCP) measures: when the biggest visible element (usually a hero image or headline) is painted. Google's threshold for "good" is 2.5 seconds, and now you can see the whole budget: DNS + connection + TTFB + HTML download + blocking CSS + the LCP image itself, all inside 2.5 seconds. Each step you shave leaves room for the others.

Layout is also where Cumulative Layout Shift (CLS) is born. When an image without declared dimensions finishes loading, or a late web font swaps in at a different size, or an ad injects itself, the browser re-runs layout and content jumps. The fixes are mundane and effective: width and height attributes on images, reserved space for ads and embeds, and font-display: swap with well-matched fallback fonts.

Step 7: JavaScript Wakes Up

Meanwhile, deferred scripts execute once parsing finishes. On many modern sites this is the most expensive phase of the entire load — not downloading the JavaScript, but executing it. A mid-range phone can spend 3–5 seconds of CPU time parsing and running a heavy script bundle, during which the page looks done but ignores taps and clicks.

That gap between "looks interactive" and "is interactive" is what Interaction to Next Paint (INP) penalizes. The main thread is single-lane: while JavaScript runs, nothing else — not scrolling handlers, not click responses, not rendering — gets through. The fixes, in order of effectiveness:

• Ship less JavaScript. Audit plugins and third-party tags; each one you remove is CPU time returned to your visitors.
• Defer what you can't remove. Analytics, chat widgets, and social embeds rarely need to run before first paint.
• Break up long tasks. Anything holding the main thread for more than ~50ms shows up as jank.

Reading a Waterfall Like a Mechanic

Open DevTools (F12), go to the Network tab, and reload. The diagnostic shortcuts:

The Honest Summary

A page load is a pipeline: name resolution, connection, server work, download, parse, style, layout, paint, script. Every performance technique you've ever heard of — CDNs, caching, critical CSS, deferred JavaScript, image optimization, preloading — is just an attack on one specific stage of that pipeline. Which is exactly why generic advice fails: applying an image optimizer to a site with a 2-second TTFB is treating the wrong stage.

So before you install another performance plugin, spend ten minutes with the Network tab and find out where your pipeline actually stalls. Fix the slowest stage first, re-measure, repeat. It's less exciting than a plugin that promises a 100/100 score, but it's the difference between doing performance work and doing performance theater.

Photo: Surdu Horia on Pexels