You enter an address, press Enter, and see a page a moment later. In that time, the browser works out where to go, establishes a connection, receives several kinds of resources, builds and calculates the page, loads additional files, and reuses data from earlier visits. Finally, it turns the result into pixels on your screen.
How it works
In simplified form, the browser:
- parses the URL;
- checks caches and local rules;
- finds a network address through DNS;
- establishes a connection;
- creates a secure channel for HTTPS;
- sends an HTTP request;
- receives a response and starts parsing HTML;
- discovers and loads related resources;
- builds the DOM and CSSOM;
- forms a rendering tree;
- calculates geometry;
- paints and composites layers;
- runs JavaScript and updates the interface.
Let’s follow that path in more detail.
1. The browser parses the address
The URL https://example.com/catalog/?sort=new has several parts: https is the scheme, example.com is the domain name, /catalog/ is the path, and sort=new is a query parameter.
First, the browser decides whether the input is an address. If it is ordinary text, it may pass it to a search engine. For a recognized URL, the browser applies security rules, redirects, and saved information about the domain. Reusing that information can make loading faster.
2. The cache is checked
Some information may already be on the device: a DNS lookup result, previously downloaded HTML, styles, scripts, fonts, images, a web app’s service worker instructions, or information that helps resume a secure connection.
Using a cache does not necessarily mean showing an old copy. The server supplies freshness and validation rules. Depending on those rules, the browser may use a particular resource immediately, check whether it has changed, or download it again.
3. DNS finds the server’s address
People type domain names; network packets travel to IP addresses. DNS links a domain name to an IP address so the browser can connect to a server. This usually happens out of sight.
The answer may come from the browser, operating system, router, or DNS resolver’s cache. If there is no cached record, the resolver follows the DNS hierarchy to find an address for the name.
A domain can return multiple addresses. A service may direct you to a suitable server or CDN location to reduce distance and spread the load.
DNS tells the browser where to go, but it cannot guarantee that the web server is healthy or will return the right page. Think of it as a directory that translates human-readable names into network addresses.
4. A transport connection is established
The details depend on the HTTP version and the network. HTTP/1.1 and HTTP/2 usually use TCP, which provides a reliable, ordered stream of bytes between client and server.
HTTP/3 runs over QUIC. QUIC uses UDP as its underlying transport while handling delivery and encryption differently. The essential point is that the parties need a working communication channel before they can exchange the web request.
Latency depends on distance, network quality, and the number of round trips required. A server in another region may therefore take longer to start responding even if it processes the request instantly.
5. HTTPS protects the connection
With HTTPS, the browser and server negotiate TLS. The server presents a certificate; the browser checks the domain name, validity period, and chain of trust. The parties agree on security parameters and establish session keys.
After that, data travelling between them is encrypted and protected against undetected changes in transit.
HTTPS does not prove that a site’s claims are true or that its application has no vulnerabilities. It establishes a protected connection to the party that controls a valid certificate for that name.
6. An HTTP request is sent
In effect, the browser asks: “Get /catalog/?sort=new from example.com.” The request includes a method, path, headers, and sometimes a body. Headers can describe supported formats, language, caching, authorization, and where the visit came from.
The request may pass through a CDN, load balancer, reverse proxy, cache, or security filter before reaching the application.
7. The server prepares a response
A response contains a status code, headers, and a resource body. 200 means success; 301 or 308 indicates a permanent redirect; 404 means the resource was not found; 500 means the server encountered an error.
HTML may be a ready-made file or the result of an application. The server might query a database, check a session, assemble a template, or call other services. “Server response time” can conceal a whole chain of internal work.
8. HTML arrives as a stream
The browser need not wait for the whole document. It can start parsing the first chunks of HTML as they arrive. Text becomes tokens, then nodes in the Document Object Model (DOM). Nesting establishes relationships between elements. Headings, paragraphs, and links become objects used by styles, JavaScript, and accessibility technologies.
The HTML parser follows formal rules and can recover from many markup errors. That makes the web resilient, but it does not turn careless structure into good semantics.
9. Additional resources are discovered
HTML can refer to CSS files, JavaScript, images, fonts, video, audio, embedded documents, and preloaded data. The browser schedules these requests and assigns priorities. A preload scanner may discover some resources before the main parser reaches them.
The number of files does not equal the number of sequential waits: modern connections can transfer multiple resources efficiently. Still, every unnecessary byte must be downloaded, parsed, and sometimes executed.
10. CSS becomes the CSSOM
The browser parses style rules into the CSS Object Model. The cascade, inheritance, and selectors determine the computed values for each element. CSS affects both appearance and layout, so the browser needs style information to render the page correctly.
11. JavaScript can change the loading sequence
A normal synchronous <script> encountered during HTML parsing can pause the parser: the script may change the document, so it must run at the right point.
defer, async, module scripts, and on-demand loading help control this behavior. There is no universal rule to make every script asynchronous: order and dependencies matter.
Once running, JavaScript can add or remove elements, change classes and styles, request more data, register event handlers, update the interface, or start work on the main thread or in a worker. Long-running code can delay interactions even after every file has downloaded.
12. The render tree is built
The DOM describes the document; the CSSOM describes its styles. Together they let the browser determine which nodes to display and with which computed properties.
Elements inside <head> and nodes with display: none do not occupy space in the rendered layout. An element with visibility: hidden remains part of the layout although it is not visible.
The browser also builds an accessibility tree, which helps assistive technologies understand the roles, names, and relationships of elements.
13. Layout calculates geometry
During layout, the browser determines the sizes and positions of visible boxes. Percentages, flexible grids, viewport dimensions, fonts, and content turn into specific coordinates.
If an image loads late without reserved dimensions, nearby text may shift. Such movement harms visual stability. DOM or style changes can also require part of the page to be laid out again; repeatedly reading and changing geometry in a script can create noticeable delays.
14. Paint draws the elements
The browser turns calculated boxes into drawing commands for backgrounds, text, borders, shadows, and images. Some parts occupy separate layers. During compositing, the layers are combined into a final frame. A layer can sometimes move without repainting the whole page, although too many layers use memory.
The screen can display a useful frame while the page continues loading data and changing.
When is a page “loaded”?
The technical load event does not necessarily match a person’s sense that the page is ready. Conversely, a page may become useful before secondary analytics or a lazy-loaded image has finished loading.
Where time is most often lost
Delay can arise anywhere: slow DNS; a long network distance; a slow application or database response; missing caching; heavy images or fonts; blocking styles and scripts; too much JavaScript; long tasks on the main thread; repeated layout calculations; third-party resources; or data fetched only after a large application has started.
That is why “speed up the server” or “compress the images” is not a universal prescription. Measure the actual journey first.
What changes on a repeat visit?
The browser may already know some DNS answers, reuse a connection, and hold resources in its cache. A service worker can return a local copy or assemble a response according to the app’s rules.
This is one reason a page can open quickly for a developer but slowly for a first-time visitor. Test both first and repeat loads, including on mobile networks and less powerful devices.
The key point
After you press Enter, the browser does not “download a website” as one file. It finds an address, establishes network and secure connections, exchanges HTTP messages, receives HTML and related resources, builds the DOM and CSSOM, calculates layout, paints and composites layers, runs scripts, and responds to changes.
Page speed depends on the entire chain. To improve it, identify the step that prevents someone from seeing content or taking action—not merely a way to make every file a little smaller.