When you click a link or enter a URL, the browser first translates the human-readable domain name into an IP address through DNS resolution. The browser (or OS) checks local DNS caches (in the browser, OS, or router) to see if it already knows the IP for that domain (What Happens When You Type a URL Into a Browser?). If not found, it queries a DNS resolver (often your ISP’s), which will perform a recursive lookup. The resolver contacts the root DNS servers, then the appropriate TLD (top-level domain) servers, and finally the domain’s authoritative DNS server to get the correct IP address (DNS Resolution and TCP Handshake: A Comprehensive Guide - DEV Community). Once the IP is obtained, it’s returned to the browser and usually cached for a while (per DNS record TTL) to speed up future requests (DNS Resolution and TCP Handshake: A Comprehensive Guide - DEV Community; What Happens When You Type a URL Into a Browser?). With the IP address in hand, the browser knows where to send the request.
With the IP address resolved, the browser opens a TCP connection to the server (using the resolved IP and the port, e.g., port 80 for HTTP or 443 for HTTPS). Establishing a TCP connection involves a three-way handshake: the browser (client) sends a SYN packet to initiate the connection, the server responds with a SYN-ACK, and the client replies with an ACK to confirm (DNS Resolution and TCP Handshake: A Comprehensive Guide - DEV Community). After this “SYN, SYN-ACK, ACK” exchange, the TCP connection is established and ready for data transfer (DNS Resolution and TCP Handshake: A Comprehensive Guide - DEV Community). If the connection is secure (HTTPS), an additional TLS/SSL handshake occurs on top of TCP. In this TLS handshake, the browser and server exchange cryptographic information: the server presents its SSL/TLS certificate for the browser to verify, both sides agree on an encryption protocol (cipher suite), and they perform a key exchange to generate a shared secret key (What Happens When You Type a URL Into a Browser?). This process ensures authenticity and privacy – once the TLS handshake completes, all HTTP data will be encrypted in transit (What Happens When You Type a URL Into a Browser?). Only after the TCP (and TLS, if applicable) handshakes are done can the browser begin sending the actual HTTP request.
After the connection is ready, the browser sends an HTTP request to the web server for the desired resource (for example, a GET request for the page’s URL). This request includes details like the URL path, HTTP method (GET/POST), and headers (such as cookies, accepted formats, etc.) (What is HTTP, Structure of HTTP Request and Response?). The server receives this request and processes it – for a typical page, the server might load files or run backend code to prepare the content. It then sends back an HTTP response. The response starts with a status code (e.g. “200 OK” if successful), response headers (content type, caching info, etc.), and the body of the content (e.g. the HTML of the webpage) (What is HTTP, Structure of HTTP Request and Response?) (An overview of HTTP - HTTP | MDN). The browser immediately begins to parse the HTML as it arrives. Importantly, as the HTML is parsed, whenever the browser encounters references to other resources (like external images, stylesheets, or script files), it will issue additional HTTP requests for each of those resources (An overview of HTTP - HTTP | MDN). Modern browsers can fetch many resources in parallel (often using multiple connections or HTTP/2 multiplexing) to speed up page loading (An overview of HTTP | MDN). Each requested resource (CSS, JS, images, etc.) results in its own HTTP response from the server. In this way, the initial HTML and all dependent assets are retrieved through the request/response cycle. The server may also send caching directives (in headers) so that the browser can reuse responses on future loads. Once the browser has the HTML and other assets, it can proceed to render the page.
To improve performance, several caching mechanisms may come into play during the loading process, potentially eliminating some network steps on repeat visits. The browser cache stores previously fetched resources (HTML pages, CSS, JS, images) on the user’s device. Before making a new request, the browser checks if a resource is in its cache and is still valid (not expired) (What Happens When You Type a URL Into a Browser?). If so, it can load the resource directly from the local cache instead of contacting the server, significantly speeding up load time (What Happens When You Type a URL Into a Browser?). In addition, many sites employ Content Delivery Networks (CDNs), which are geographically distributed servers that cache content closer to users. If a site uses a CDN, your request for a resource may be routed to a nearby CDN edge server; if that server has a cached copy of the content, it will serve it directly, avoiding a trip to the origin server (How To Leverage Browser Caching to Improve Site Speed | DebugBear). This reduces latency because the data doesn’t have to travel as far. Another layer is the service worker cache: service workers are scripts that run in the background of the browser and can intercept network requests. A service worker can implement custom caching strategies (via the Cache Storage API), serving content from its cache even when offline or before the network responds (Service Worker Caching and HTTP Caching - DEV Community). The typical order is that a service worker, if installed, gets first crack at handling a request (returning a cached response if available), then the browser’s HTTP cache, and finally the network (CDN/origin) if needed (Service Worker Caching and HTTP Caching - DEV Community). All these caching mechanisms aim to reduce the data that must be fetched over the network, thereby improving load times and reducing server load.
How the page content is generated and delivered (the rendering method) affects the loading and rendering process:
Each of these rendering methods affects what the browser receives and how much work it must do: SSR/SSG/ISR deliver ready-to-render HTML (speeding up initial paint), whereas CSR shifts the rendering work to the client (slower initial load, but potentially snappier subsequent interactions within the app).
Once the browser starts receiving HTML and CSS, it enters the critical rendering path – the sequence of steps to turn HTML/CSS/JS into pixels on the screen. The process is as follows:
<div> or <p>) becomes a node in this tree. The DOM represents the page structure and content. Parsing HTML is incremental, so the browser can begin constructing the DOM before the entire HTML document is downloaded.<style> blocks, the browser fetches those and parses the CSS rules to build the CSS Object Model (CSSOM) (CRITICAL RENDERING PATH - DEV Community). The CSSOM is a tree of style rules that correspond to the DOM nodes (it represents all the styles that apply to elements). Render-blocking CSS: Note that the browser usually waits to finish downloading and parsing CSS before painting anything because it needs to know all the styles to correctly render the page. This is why CSS is considered render-blocking – the critical rendering path is paused until CSSOM is ready (Lazy loading - Web performance | MDN) (Critical rendering path - Web performance | MDN).<script> without defer/async), the HTML parser will pause, fetch and execute that script, because it might modify the DOM or CSSOM (Critical rendering path - Web performance | MDN) (Critical rendering path - Web performance | MDN). Properly, the DOM construction might be halted until the script is run (this is parser-blocking behavior). Scripts with defer (or modules) will execute after HTML parsing, and async scripts run as soon as they're ready, but in general, heavy JS can delay rendering. During this phase, any DOM-altering scripts will execute, potentially changing the DOM or injecting more HTML/CSS to parse.