When you type a URL and press Enter, the browser does not go straight to drawing the page. It parses the address, checks whether it already has a usable response, resolves the domain name, opens a secure connection, sends an HTTP request, receives HTML, and begins rendering while more resources download.
The exact sequence changes with cache state, redirects, service workers, and protocol support. The core path stays the same: address, destination, connection, request, response, render.
The address bar decides what you meant
The address bar accepts searches, domains, full URLs, browser shortcuts, and local history matches. Before any network request, the browser decides whether your input is a search query or a URL.
If you type vayce.app/tools/word-counter, the browser can infer a site. If you type ideal sentence length, it treats the input as a search unless a local shortcut says otherwise.
For a URL, the browser normalizes the address into a structured URL object. It fills in missing pieces such as the scheme when possible, encodes unsafe characters, and resolves path segments.
new URL("/tools/word-counter", "https://vayce.app").href
// "https://vayce.app/tools/word-counter"At this point, the browser has a target address. It still may not need the network.
Cache and service worker checks
Before opening a connection, the browser checks whether it can reuse something.
The HTTP cache may already hold the document or its resources. Cache headers such as Cache-Control, ETag, and Last-Modified tell the browser whether cached files can be used directly or need validation.
A service worker can also intercept the request. If the site installed one, that script can return cached content, ask the network, or combine both. This is how some web apps load even when the network is unavailable.
If cache and service worker do not satisfy the navigation, the browser has to find the server.
DNS turns the name into an address
A domain such as vayce.app is not the network address the browser connects to. The browser needs an IP address.
DNS resolution may check several places:
- Browser DNS cache.
- Operating system cache.
- Router or local network cache.
- A configured DNS resolver.
If no cached answer exists, a resolver looks up the record and returns an IP address. The answer may point to a content delivery network, which routes the request to a nearby or available server.
DNS tells the browser where to connect. It does not request the page itself.
The browser opens a secure connection
For HTTPS pages, the browser opens a connection and negotiates encryption with TLS. The TLS handshake verifies the server certificate and creates keys for encrypted traffic.
With HTTP/1.1 or HTTP/2, the connection can run over TCP. With HTTP/3, it runs over QUIC, which combines transport and encryption differently. The browser and server choose what both sides support.
The important point: before the browser asks for the HTML, it has to establish a connection that can carry the request safely.
The HTTP request asks for the resource
Once connected, the browser sends an HTTP request. A simplified navigation request looks like this:
GET /tools/word-counter/ HTTP/2
Host: vayce.app
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, br, zstdThe method GET asks for a resource. The path names which resource. Headers tell the server what the browser can accept, which encodings it supports, and whether cookies or credentials apply.
The server may return the page, redirect to another URL, reject the request, or send an error. Redirects can restart part of the process with a new address.
The response starts the page
A successful response begins with a status and headers:
HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: public, max-age=3600The body can start streaming before the full document has arrived. Browsers can parse HTML as bytes come in, so rendering does not always wait for the whole file.
The parser builds the DOM. A preload scanner looks ahead for CSS, JavaScript, fonts, and images. CSS builds the CSSOM. Together, those structures feed layout, paint, and compositing.
More requests follow the HTML
The first HTML file is rarely the only request. It can reference more resources:
- CSS files.
- JavaScript modules.
- Fonts.
- Images.
- API data.
- Icons and manifests.
Some resources block rendering. CSS can block first paint because the browser needs styles to lay out the page correctly. JavaScript can block parsing when it is not deferred or loaded as a module.
Performance work starts here: reduce blocking resources, cache stable assets, compress text, and ship images at the size the layout needs.
Repeat visits reuse work
The second visit can be faster because the browser has more information:
- DNS answers may still be cached.
- Connections may be reused.
- TLS sessions may resume.
- Static assets may come from HTTP cache.
- A service worker may respond before the network.
This is why cache headers matter. They tell the browser which files are stable and which ones need to be checked again.
Watch the sequence in DevTools
Open DevTools, switch to the Network tab, and reload a page. Select the main document request and inspect the Timing panel. Depending on the browser and cache state, you can see DNS lookup, connection setup, TLS, request, waiting, and content download.
Then switch to the Performance panel and record a reload. That view shows what happens after bytes arrive: parsing, style calculation, layout, paint, scripting, and compositing.
The address bar hides the sequence. DevTools shows each phase as measurable browser work.
