What Happens When You Press Enter
The full lifecycle of a page load — DNS, TCP, TLS, request, response, parse, render — and where the time actually goes.
Between pressing enter and seeing a page, the browser performs a fixed sequence of steps. None of it is mysterious, most of it is standard, and once you know the order you can tell instantly where a slow page is spending its time. It is also the most useful mental model in web performance work, because every optimisation targets a specific step.
The sequence
-
Parse the URL and check the caches
Browser history, HSTS preload list, and the connection pool. If a connection already exists it is reused, which is the single biggest reason a second page load is so much faster than the first.
-
Resolve DNS, unless cached
Hostname to IP address, via DNS. Cached for a TTL, so this step often costs nothing.
-
Establish the connection
A TCP handshake, three packets, unless a connection is already open or the previous one is still usable.
-
Negotiate TLS, unless cached
A handshake, possibly shortened to a single round trip with session resumption.
-
Send the request and receive the response
One request for the document, with headers, then a response with a status code, headers and a body. Status codes worth recognising: 200, 301/308, 304, 404, 500.
-
Parse the HTML and discover subresources
This is the critical discovery step. The parser finds the stylesheet, script, font and image references, but many of them cannot be requested until the parser reaches the tag, because it does not know they exist until then.
-
Fetch subresources, in parallel
Stylesheets block rendering. Scripts may block parsing. Images usually do not block anything but do compete for bandwidth.
-
Build the DOM, then the CSSOM, then the render tree
The DOM is the document structure. The CSSOM is the styles. The render tree combines them and skips anything with display none. Both must be complete before anything can be painted.
-
Layout, then paint, then composite
Layout calculates the position and size of every box. Paint fills in pixels. Composite puts the layers together on screen. This is where the first contentful paint happens.
The three things that block the first paint
| Blocker | Why it blocks | What unblocks it |
|---|---|---|
| CSS in the head, or discovered late in the body | Rendering cannot start without a complete CSSOM, or text gets painted and then reflowed | Inline the above-the-fold styles, or load the stylesheet early and preload it |
| Render-blocking scripts in the head | A classic script pauses the parser until it has downloaded and executed | Move it, make it async or defer, or make it a module |
| A web font needed for above-the-fold text | Text cannot be painted in a fallback metric-compatible face | Use font-display: swap, or preload the one file you need |
The discovery problem
The parser only knows about a stylesheet or script once it has read the tag. So a stylesheet linked near the end of the body is not discovered until the browser has already read the whole document — and because CSS blocks rendering, the page waits anyway. A script at the end of the body has the opposite problem: it delays the end of parsing.
Two tools exist for this. Preload tells the browser to start fetching something the parser has not found yet. Preconnect tells it to open a connection to another origin ahead of time so the handshake is not on the critical path. Neither of them is free — preloading something unnecessary wastes bandwidth — so they are for resources you know will be needed.
Where the time actually goes
On a modern connection, a simple page is dominated by three things: the round trips before the first byte, the size of the critical CSS, and the time for the server to produce the document. On a slow mobile connection, total transferred bytes become dominant, and on a slow server it is server response time. The fix is completely different in each case, which is why measuring before optimising is not optional.
- Server slow to respond? The document request is the problem. Caching, a CDN, or a static build.
- Fast server, slow first paint? Round trips and render-blocking resources. Preconnect, preload, inline critical CSS, defer scripts.
- Slow first paint, slow everything else? Too many bytes. Images, fonts and JavaScript bundles.
- Fast to first paint, then it jumps around? Late CSS, web fonts, or images without reserved space. See the font and layout stability discussion.
The three tools that matter
-
The network panel, with throttling on
Shows the waterfall: which requests started when, what blocked them, and what each one cost. Disable the cache first, because a warm cache is a lie about your real users.
-
The performance panel, recording a load
Shows the main thread, the long tasks, and the browser's own reasoning about why the page was not interactive. Look for anything over 50 milliseconds.
-
A Lighthouse run, mobile emulation, several times
A single run is noisy. Take the median of five, and look at the specific audit that failed rather than the overall score.
Common questions
Frequently asked questions
Why is a second page load so much faster?
Because almost nothing is repeated. DNS is cached, the TLS session is resumed rather than renegotiated, the connection is already open, the document may come from a cache, and the subresources certainly do. This is why measuring with the cache enabled produces results that do not resemble what a real visitor sees.
Should scripts be async, defer, or neither?
A normal script in the head blocks the parser. defer downloads in parallel and executes in order after parsing. async downloads in parallel and executes the moment it arrives, so order is not guaranteed. Use defer by default for anything that touches the DOM. Use async only for genuinely independent scripts, such as analytics.
What is the critical rendering path?
The sequence of steps the browser must complete before it can show the first pixel: get the document, find and fetch the blocking CSS, fetch and run any blocking scripts, build the DOM and CSSOM, then lay out and paint. Shortening it is the single highest-leverage performance work on any page.
Does server-side rendering help?
It helps when the client has to do an unreasonable amount of work before it can show anything, which was the standard problem with heavy single-page applications. It also means more JavaScript is shipped, and it reintroduces a server to maintain. For content, generating plain HTML at build time is the better answer than either, which is the approach this site itself takes.