What Actually Happens When the Browser Loads a Page: From DNS to a 90 Lighthouse Score

When a user types a URL and hits enter, a lot happens in milliseconds. Understanding this process is not just academic. It helps you debug slow sites, prioritize fixes, and improve both user experience and SEO. Here is what actually happens, step by step, and how each stage affects performance.

DNS lookup and initial connection

The first step is resolving the domain name to an IP address. The browser checks its cache, the OS cache, the router, and finally DNS servers. Slow DNS adds unnecessary latency, especially on mobile networks.

Once the IP is known, the browser establishes a TCP connection. For HTTPS sites, this includes TLS handshake to negotiate encryption. TLS 1.3 has reduced handshake round trips significantly compared to older versions. Connection reuse, through keep-alive or HTTP/2 multiplexing, prevents paying this cost for every resource.

HTTP requests and connection protocols

Modern sites use HTTP/2 or HTTP/3. With HTTP/1.1, browsers limited concurrent requests per domain, leading to waterfall bottlenecks. HTTP/2 allows multiplexing multiple requests over one connection. HTTP/3 moves to QUIC over UDP, reducing head-of-line blocking and improving performance on unreliable networks.

The browser first requests the HTML document. This is usually a small text file, but it is the key that unlocks everything else. How the server delivers it, compression (like gzip or Brotli), and caching headers all affect first load time.

HTML parsing and building the DOM

As the browser receives HTML bytes, it parses them into tokens, then into the DOM tree. This is a streaming process; the browser can start parsing before the entire document is downloaded. However, parsing is blocked when it encounters synchronous scripts without defer or async.

While parsing HTML, the browser discovers references to external resources: stylesheets, scripts, images, fonts, and more. Each discovery triggers a new request, which can either be queued or started depending on the protocol and priority.

Critical CSS and render-blocking resources

CSS is render-blocking by default. The browser cannot render content until it has the CSSOM (CSS Object Model) constructed. Large, unoptimized stylesheets delay the first paint. A common optimization is to extract and inline critical CSS for above-the-fold content, then load the rest asynchronously.

JavaScript is even more impactful. Synchronous scripts block HTML parsing and can delay rendering. Using script type=module, defer, or async changes when execution happens. defer preserves execution order and runs after DOM parsing. async runs as soon as it is downloaded, without preserving order. Moving non-critical scripts to the end or deferring them is key to improving perceived performance.

Preloading, prefetching, and resource hints

Not all resources are discovered at the same time. The browser builds a preload scanner that looks ahead in the HTML to discover resources earlier. You can also give explicit hints: link rel=preload for critical resources like fonts or hero images, preconnect to establish connections early, and prefetch for resources likely needed on the next page.

These hints help the browser prioritize what matters most for the current view. Used correctly, they reduce load delays without overloading the network.

Images, fonts, and layout stability

Images often account for the largest bytes. Optimizations like modern formats (WebP, AVIF), responsive srcset, lazy loading offscreen images, and proper sizing reduce both bytes and layout shifts. Decoding large images can also block the main thread; using decoding=async or proper sizing helps.

Fonts can cause invisible text or layout shifts if not handled well. font-display: swap shows fallback text quickly while the web font loads, improving perceived performance. Preloading critical fonts reduces the chance of FOIT (Flash of Invisible Text).

Cumulative Layout Shift (CLS) comes from content shifting after initial render. Reserving space for images, ads, or dynamic content is one of the most effective ways to improve CLS.

The rendering pipeline and Core Web Vitals

Once CSSOM and DOM are ready, the browser constructs the render tree, computes layout, paints pixels, and composites layers. This happens frame by frame. Long tasks on the main thread block interactivity.

Core Web Vitals map directly to this pipeline. Largest Contentful Paint (LCP) measures when the largest visible element loads, often a hero image or heading. Interaction to Next Paint (INP) measures responsiveness to user input. Cumulative Layout Shift (CLS) measures visual stability. These metrics heavily influence Lighthouse scores and SEO rankings.

Getting to a 90 Lighthouse score

Reaching 90+ is achievable by focusing on high-impact fixes. Optimize images and serve them in modern formats. Defer or lazy-load non-critical JavaScript. Inline critical CSS and eliminate render-blocking resources. Use caching headers and a CDN to reduce Time to First Byte (TTFB). Preconnect to third-party domains and preload critical assets. Finally, minimize layout shifts by reserving space for dynamic elements.

The key is not doing everything. It is fixing what blocks the critical path for your specific page. Profile with Chrome DevTools and Lighthouse, measure, then iterate.

Key takeaways

• DNS, TCP, and TLS add connection latency; reuse connections and use HTTP/2 or HTTP/3.
• HTML parsing is streaming but blocked by synchronous scripts; use defer/async for non-critical JS.
• CSS blocks rendering; inline critical CSS and load the rest efficiently.
• Preload critical assets and preconnect to important origins to reduce wait time.
• Optimize images, fonts, and layout to improve LCP, INP, and CLS for better Lighthouse scores.

FAQ

Q: What is the single biggest factor for LCP? A: Usually the hero image or large visible element. Optimizing its size, format, and load priority has the most impact.

Q: Should I use async or defer for scripts? A: Use defer for scripts that depend on DOM order. Use async for independent scripts like analytics that do not interact with page structure immediately.

Q: How does HTTP/3 help performance? A: HTTP/3 uses QUIC over UDP, reducing head-of-line blocking and recovering faster from packet loss, especially on mobile or unreliable networks.