System Design: Web Page Load - Q&A

Web Page Load - Interview Q&A

You can read the main article here:

https://shiluqi.blogspot.com/2026/03/system-design-web-page-load-main.html

“What if the user types amazon.com without https://—how does the browser decide?”

There are really two decisions the browser makes.

First, the address bar decides whether amazon.com is a navigation target or a search query. Modern browsers use a unified address bar for both. Firefox’s docs explicitly note that some inputs are treated as a web address rather than searched, and Chrome’s own example for typed navigation is exactly the bare-domain case like example.com without a scheme. So amazon.com is normally interpreted as “go to this site,” not “search for these words.”

Second, once it decides “this is a site,” it has to choose the scheme. In Chrome, typed navigations without a protocol default to https:// starting with Chrome 90, and Chrome says it falls back to HTTP if the HTTPS attempt fails. Chrome also has an HTTPS-First mode that tries to upgrade page loads to HTTPS and shows a warning before loading HTTP.

Firefox has similar behavior now, but the details depend on mode and version. Mozilla says HTTPS-First is enabled by default in Firefox 136+, where Firefox will try HTTPS first and load HTTP only if a secure version is not available; it also says that typing an explicit http:// avoids the upgrade attempt. Mozilla had earlier introduced HTTPS-by-default in Private Browsing as well.

One important override is HSTS. If the browser already knows that a host must use HTTPS—because the site previously sent Strict-Transport-Security, or the domain is preloaded—the browser upgrades HTTP attempts to HTTPS automatically before loading, and for HSTS hosts it won’t let the user click through certificate errors.

So the interview version is:

amazon.com looks like a hostname, so the browser usually treats it as a URL-like navigation. Then a modern browser typically tries https://amazon.com first; whether it silently falls back to HTTP, warns, or refuses depends on the browser, settings like HTTPS-First/Only, and whether HSTS already forces HTTPS.

A nice one-line answer in an interview is:

“The browser first classifies amazon.com as a navigation, not a search, then applies its default scheme policy—now usually HTTPS-first—with HSTS able to force HTTPS regardless.”

Pro-Tip for the Interview

Mention "Happy Eyeballs" (RFC 8305). While usually discussed regarding IPv4 vs. IPv6, the same concept of "racing" connections applies to modern web performance—browsers may speculatively try multiple ways to connect to ensure the user sees a rendered page as fast as possible.

Server-Side Redirection (The Final Safeguard)

If the browser does send an initial http:// request and the server receives it, the server (or a Load Balancer/CDN at the edge) will typically issue a 301 Moved Permanently or 302 Found redirect pointing to the HTTPS version.

The Header: The server will also likely include a Strict-Transport-Security header in the HTTPS response. This tells the browser: "For the next $N$ seconds, never even try to contact me via HTTP again."

“What’s the difference between the URL standard and what browsers actually do?” 

(Good answer: browsers aim to follow the URL standard; there are historical quirks and heuristics; correctness and compatibility drive behavior.)

Say it like this:

“The URL standard is the normative parsing and serialization model—it defines what a URL is, how it’s parsed, normalized, and exposed through APIs like URL. Browsers try to follow that model, and the standard itself explicitly aims to align older RFCs with contemporary browser implementations so behavior becomes interoperable. But what browsers actually do is broader than the pure parser: they also have address-bar heuristics, legacy compatibility behavior, and security/UX policies. So the parser is standardized, while the full user-visible behavior is partly spec-driven and partly browser product behavior.”

A slightly more interview-polished version:

“The spec is the ideal contract for URL parsing and serialization. Real browsers aim to conform to it, and cross-browser test suites help keep them aligned. But browsers also have to preserve web compatibility and user experience, so around that core parser they add heuristics—like deciding whether text in the address bar is a URL or a search, or applying compatibility quirks for inputs the web already depends on.”

The key distinction to emphasize is:

URL standard: defines the parsing rules, structure, encoding, host/IP handling, and the URL API.

Browser behavior: includes omnibox/search heuristics, historical quirks, and compatibility decisions outside the narrow parser itself. Chrome’s own docs, for example, describe the address bar as something that handles both typed URLs and search terms, which is a browser feature layer, not just the URL parser.

A good closer in an interview is:

“So I’d treat the standard as the common parsing contract, and browser behavior as that contract plus compatibility and product heuristics.”

One thing to avoid saying is “browsers ignore the spec.” A better framing is: the spec was written partly to capture and unify browser reality, and browsers still have extra behavior around it. The URL standard says exactly that one of its goals is to align older RFCs with contemporary implementations because areas like illegal code points, query encoding, equality, and canonicalization were not fully shared before.

In a senior-level technical interview, this question is designed to see if you understand that software standards are often a "best-effort" target, while real-world browser behavior is dictated by the "Don't Break the Web" philosophy.

Here is how you can structure a sophisticated answer:

1. The Core Tension: Specification vs. Reality

Start by acknowledging that the URL Standard (maintained by WHATWG) is the theoretical "source of truth," but browsers are legacy-bound.

The Standard: Aims for a strict, mathematically sound way to parse and resolve URLs to ensure interoperability across all software.

The Browser: Must prioritize web compatibility. If a browser implements a strict new standard that causes 1% of the world's existing websites to stop loading, the browser (not the website) is seen as "broken" by the user.

2. Key Differences and "Quirks"

You can highlight these specific areas where browsers often deviate or add their own logic:

Heuristics and Normalization: Browsers do a lot of "cleaning" that the standard doesn't strictly require. For example, fixing backslashes (\) to forward slashes (/) in certain contexts or handling "lazy" typing (automatically prepending https:// to amazon.com).

Encoding Conflicts: The standard mandates UTF-8, but browsers often have to deal with legacy encodings (like Windows-1252) found in old HTML meta tags, which changes how query parameters are parsed.

The "User Interface" Layer: Browsers often treat the URL in the address bar differently than a URL in a fetch() call. They might hide the https:// prefix or "prettify" Punycode (IDN) to prevent phishing, even if the underlying standard treats the string literally.

Historical Baggage: Certain schemes (like file://) have wildly different implementations across Windows, macOS, and Linux. Browsers often follow OS-specific historical quirks rather than the unified WHATWG spec for these.

3. The "Correctness vs. Compatibility" Trade-off

Explain the "Why":

Correctness: Browsers want to be correct to prevent security vulnerabilities (like URL Spoofing or Open Redirects).

Compatibility: They must be compatible to maintain market share.

Pro-Tip: Mention that modern browsers now share the same underlying engine components (like Chromium’s URL parser). This has actually made browsers more compliant over time because they are converging on a single "de facto" standard, even where it slightly differs from the written spec.

Summary for the Interviewer

"While the WHATWG URL standard provides the blueprint, browsers act more like archaeologists. They have to support decades of 'broken' URLs that exist in the wild. A good browser parser is a hybrid of the formal spec and a massive set of heuristics designed to ensure that the user gets to the right page, even if the URL they clicked was technically malformed."

“Which cache is checked first: browser cache or DNS cache?” 

(Good: there are multiple caches; DNS is needed to connect unless a connection is reused; HTTP cache can satisfy requests after a connection exists; service worker can short-circuit network fetches.)

I’d answer it like this:
        “There isn’t one universal ‘first cache’ because different caches apply at different stages. If the browser can reuse an existing connection, it may not need DNS at all. If a service worker controls the page, it can intercept the request before a network fetch. And if the browser already has a fresh HTTP cache entry, it can satisfy the resource without going to the network. DNS caching matters when the browser actually needs to establish a connection.”

Then, if they want more detail:
        “For a navigation, the browser first decides how to handle the request. A service worker might intercept it. An HTTP cache entry might satisfy it or be revalidated. But if the browser needs a new network connection, then name resolution becomes relevant, and that’s where browser/OS/resolver DNS caches come in. So the right answer is not ‘browser cache before DNS cache’ or vice versa—it depends on whether the request can be satisfied locally and whether a connection already exists.”

A stronger senior version:
        “These caches are layered, not a single queue. Service worker and HTTP cache can short-circuit the fetch path. DNS cache is only needed if we actually need to resolve the hostname for a new connection. And connection reuse can skip DNS and connect entirely for some requests.”

What interviewers want to hear:
        multiple caches exist
        they apply at different layers
        DNS is for connection setup
        HTTP cache/service worker can avoid network work
        connection reuse changes the sequence

A nice closing line:
        “So I’d avoid answering with a fixed order and instead explain the decision tree.”

----

Answering this question effectively requires moving away from a "linear" mindset and demonstrating that you understand the different layers of the web stack.

In a senior-level interview, the "correct" answer is that there isn't one single cache; rather, there is a hierarchy of caches that are consulted depending on what the browser is trying to achieve at that micro-moment.

The Layered Answer

A strong response should categorize the caches by their function: Network/Content vs. Addressing.

1. The "Short-Circuit" (Service Workers)

Before the browser even looks at a traditional cache or starts a DNS lookup, it checks if a Service Worker is registered for that origin.

        Why it matters: A Service Worker can intercept the fetch request and serve a response directly from its own CacheStorage. If this happens, the browser may never even need to perform a DNS lookup or check the standard HTTP cache.

2. The Addressing Layer (DNS Cache)

If the browser determines it needs to talk to the network, it first needs to know where to go.

        The Flow: The browser checks its internal DNS Cache first. If not found, it asks the Operating System cache, then the Recursive Resolver (ISP/Cloudflare/Google).

        The Logic: You cannot "check" the HTTP cache for a network resource if you don't even have a connection, and you can't have a connection without an IP address.

3. The Content Layer (HTTP Cache)

Once the browser has a destination (or is checking if it even needs to go to one), it consults the HTTP Cache (Memory Cache or Disk Cache).

        Freshness Check: It looks for Cache-Control or Expires headers. If the resource is "fresh," it loads it from the local disk/memory immediately.

        Revalidation: If it’s "stale," the browser uses the IP address found in the DNS step to send a "conditional request" (using ETag or Last-Modified) to see if the content has changed (304 Not Modified).

How to Phrase It in an Interview

If you want to sound like a Pro, use this narrative:

        "It’s actually a multi-layered process rather than a simple 'A before B' sequence.

        First, if a Service Worker is active, it can short-circuit the entire process by serving the resource immediately.

        If the request hits the network, we have to look at two different things: Finding the server and Finding the content. The browser will check its DNS cache to resolve the hostname to an IP address. Simultaneously, or immediately after, it checks the HTTP Cache.

        If the HTTP cache has a valid, 'fresh' version of the resource, the browser can use it without ever finishing a network connection. However, if the resource is stale, the browser uses the IP address it just resolved to perform a conditional GET request to the server."

Key "Senior" Nuances to Mention

        Connection Coalescing: Mention that if the browser already has an open HTTP/2 or HTTP/3 connection to that server, it skips the DNS and TCP/TLS handshake phases entirely.

        HSTS Cache: Mention the HSTS (HTTP Strict Transport Security) cache, which is checked very early to decide if the browser should automatically upgrade an http:// request to https://.

        Memory vs. Disk: Briefly note that the Memory Cache is checked before the Disk Cache because it's significantly faster, though it's cleared when the browser tab or process is closed.

“What does a 304 Not Modified mean exactly?”

A 304 Not Modified means:

“You asked whether your cached copy is still valid, and it is—use it.”

More exactly, the client already has a cached response and sends a conditional request, usually with headers like:

• If-None-Match with an ETag

• If-Modified-Since with a timestamp

If the server determines the resource has not changed relative to that validator, it returns 304 instead of sending the full body again.

Important details:

• 304 is not a normal “fresh cache hit.” It happens during revalidation.

• The response typically has no message body.

• The browser reuses its cached body.

• The server can still send updated metadata headers, like cache-control-related headers.

Good interview phrasing:

“A 304 means the browser had a cached copy but needed to revalidate it. The server confirmed that cached copy is still current, so it tells the browser to use what it already has instead of retransmitting the resource.”

A nice contrast:

• 200 OK: here’s the resource body

• 304 Not Modified: your cached body is still good; reuse it

Common misconception to avoid:

“304 means it came from cache.”

Not exactly. It means the browser asked the server about its cached copy, and the server said keep using it.

----

An HTTP 304 Not Modified status code is a redirection message that tells the browser (or a proxy) that the resource it is requesting hasn't changed since the last time it was fetched.

Instead of re-sending the entire file (like a large image or a heavy JavaScript library), the server sends this tiny header-only response, effectively saying: "You already have the latest version in your cache; just use that."

How the "Handshake" Works

This process is known as conditional validation. It relies on the browser sending specific "clues" about the version it currently holds:

1. The First Request: You visit a site. The server sends the file along with a "validator" header, such as an ETag (a unique hash of the file) or a Last-Modified timestamp.

2. The Subsequent Request: When you return to the site, the browser sends those validators back to the server using headers like If-None-Match (for ETags) or If-Modified-Since (for timestamps).

3. The Server’s Decision: * If the file matches the browser's version, the server sends a 304. If the file has been updated, the server sends a 200 OK along with the new file.

Why It Matters

• Performance: The page feels faster because the browser doesn't have to download the same data twice.

• Bandwidth Efficiency: It saves significant data for both the user and the host.

• Reduced Server Load: The server spends less time processing and transmitting large payloads.

Common Misconception

A 304 is not an error. It is a sign of a healthy, optimized caching system. If you see many 304s in your browser's Network tab, it means your local cache is working exactly as intended.

“Explain recursive vs authoritative DNS.”

To understand the difference between Recursive and Authoritative DNS, it helps to think of them as the "middleman" and the "source of truth." In a standard web request, like the one you're drafting in your post, these two roles work together to resolve a hostname into an IP address.

---

1. Recursive DNS (The "Researcher")

The recursive resolver is the first stop for your browser. Its job is to find the information you need by asking other servers.

• Role: Acts on behalf of the client (your computer).

• Behavior: If it doesn't have the IP address cached, it begins a multi-step journey, querying the Root, TLD, and finally Authoritative servers.

• Analogy: Think of it like a librarian. You ask the librarian for a book; they don't know everything by heart, but they know exactly which aisles and shelves to check to find it for you.

• Common Providers: Usually provided by your ISP, or public services like Google (8.8.8.8) or Cloudflare (1.1.1.1).

2. Authoritative DNS (The "Source of Truth")

The authoritative server is the final destination in the DNS lookup chain. It actually holds the "record" for the domain you are looking for.

• Role: Holds the actual DNS resource records (A, AAAA, CNAME, etc.) for a specific domain.

• Behavior: It does not "ask" anyone else. When it receives a query from a recursive resolver, it provides the definitive answer (the IP address) or an error (like NXDOMAIN) if the record doesn't exist.

• Analogy: Think of it like the specific book on the shelf. It contains the actual information you were searching for.

• Common Providers: Services like Route 53, Cloudflare, or GoDaddy, where a website owner manages their domain settings.

----

When your browser needs the IP for amazon.com, it usually asks a recursive resolver first, often run by your ISP, your company, or a public DNS provider. If that resolver already has a cached answer, it returns it immediately.

If not, the recursive resolver goes out and asks the DNS hierarchy:

• a root server: “Who handles .com?”

• a .com TLD server: “Who handles amazon.com?”

• an authoritative server for amazon.com: “What is the A or AAAA record for amazon.com?”

That last server is authoritative because it owns the zone data and gives the official answer.

A few important differences:

Recursive resolver

• Serves end users or client devices
  Follows the chain of DNS referrals
  Caches answers using TTLs
  Returns either a cached result or a freshly resolved one

Authoritative server

• Stores the domain’s DNS records
  Does not usually go look elsewhere for the answer
  Responds for the zones it is authoritative for
  Is the source of truth for names in that zone

A good interview line is:

“The recursive resolver is the middleman that performs the search; the authoritative server is the endpoint that owns the actual DNS records.”

One subtle point: the recursive resolver may contact multiple authoritative servers during one lookup, not just the final domain’s server. Root and TLD servers are also authoritative for their own zones.

“What’s TTL and what does caching actually cache?”

TTL means time to live. It’s the amount of time a cached DNS record is allowed to be reused before the client or resolver should treat it as expired and look it up again.

For DNS, what gets cached is usually the answer to a DNS query, not just “the IP” in a vague sense. Examples:

• A record: hostname → IPv4 address

• AAAA record: hostname → IPv6 address

• CNAME: alias → canonical hostname

• NS Records (Name Server): Caches which servers are authoritative for a zone, allowing the resolver to skip the "Root" and "TLD" steps for subsequent sub-domain lookups.

• Negative answers too, like NXDOMAIN (“that name does not exist”)

So if amazon.com has a DNS TTL of 60 seconds, a resolver that looked it up can usually reuse that answer for up to 60 seconds without asking upstream DNS servers again.

There are multiple caching layers:

Browser Cache: The fastest; stored in the browser's memory.

OS Cache: If the browser doesn't have it, it makes a system call to the Operating System (e.g., systemd-resolved on Linux or the DNS Client service on Windows).

Router Cache: Your home Wi-Fi router often maintains its own small cache.

ISP/Recursive Resolver Cache: The massive caches maintained by companies like Google (8.8.8.8) or your local internet provider.

That means even after a TTL expires in one layer, another layer may still need to refresh independently.

A subtle but important point: caching stores the DNS response data plus its expiration, not an open-ended truth about the hostname forever.

Example:

1. Browser needs amazon.com

2. OS or resolver already has A = 54.x.x.x, TTL remaining 25s

3. It reuses that cached answer

4. After those 25 seconds run out, the next lookup triggers a fresh DNS query

Why TTL matters:

• Lower TTL: changes propagate faster, but causes more DNS traffic

• Higher TTL: fewer lookups and better performance, but slower failover or migration

In interview language, a good answer is:

TTL is the lifetime of a cached DNS record. DNS caches store query results like A, AAAA, CNAME, and even negative responses, and they reuse them until the TTL expires, after which they re-resolve.

Also, “what does caching actually cache?” depends on the layer:

• DNS cache caches DNS records

• HTTP cache caches HTTP responses, based on headers like Cache-Control, ETag, and Last-Modified

So don’t mix DNS TTL with browser HTTP caching—they’re separate system

“What happens if DNS returns both IPv4 and IPv6?” (Good: clients often use Happy Eyeballs to reduce user-visible delay by racing connection attempts).

When a DNS query returns both IPv4 (A records) and IPv6 (AAAA records), modern browsers and operating systems don't just pick one at random or wait for one to fail. Instead, they use an algorithm called Happy Eyeballs (standardized as RFC 8305).

Here is how the process works to ensure the fastest possible connection for the user:

1. Dual-Stack Resolution

The browser's resolver requests both record types. If the DNS server returns both, the browser now has two potential paths to reach the destination (e.g., amazon.com).

2. The "Happy Eyeballs" Race

Rather than strictly preferring IPv6 (which is technically the successor but can sometimes be routed poorly or tunnelled slowly), the browser "races" the connections:

• Initial Attempt: The browser typically attempts to connect via IPv6 first.

• The Resolution Delay: It waits a very short amount of time—usually around 100ms to 250ms.

• The IPv4 Backup: If the IPv6 connection hasn't been established within that tiny window, the browser immediately starts a second connection attempt via IPv4.

• Winner Takes All: Whichever connection completes the TCP handshake first is used for the HTTP request. The "loser" of the race is silently discarded.

3. Why This Matters

• User Experience: It prevents "hanging" if a user's IPv6 configuration is broken or slower than their IPv4 path.

• IPv6 Adoption: It allows networks to deploy IPv6 without fearing that a misconfiguration will break the internet for their users.

• Performance: It accounts for real-world network conditions where the "theoretical" best path might be congested or high-latency.

4. Caching the Winner

        To avoid racing every single time, many implementations will cache the success. If IPv4 won the race for a specific destination, the browser may prioritize IPv4 for a short duration for subsequent requests to that same host to save resources.

----

Usually the client uses Happy Eyeballs.

That means if DNS returns both an AAAA record (IPv6) and an A record (IPv4), the browser or OS will generally:

1. Prefer trying IPv6 first, or give it a slight head start.

2. Very quickly start an IPv4 connection too if IPv6 doesn’t connect fast enough.

3. Use whichever connection succeeds first.

Why this exists: some networks technically have IPv6, but it’s broken or slow. If the client waited too long on IPv6 before falling back, page loads would feel sluggish.

In interview terms, the good answer is:

• DNS can return both IPv6 and IPv4 addresses.

• The client doesn’t blindly pick one and wait forever.

• It uses a fallback/racing strategy like Happy Eyeballs to reduce user-visible delay.

• The winner becomes the transport used for TCP or QUIC connection setup.

A nice extra detail:

• This choice happens at the connection stage, after DNS resolution.

• Policy can vary by OS/browser, but the goal is always low latency and robustness.

A polished interview line:

“If both A and AAAA records come back, the client usually uses Happy Eyeballs—IPv6 often gets a small preference, but IPv4 is raced shortly after so the user isn’t penalized by broken or slow IPv6.”

“How does HTTP/3 discovery happen—Alt-Svc vs HTTPS records?”

Since a browser can’t know for sure if a server supports HTTP/3 (QUIC) just by looking at a standard URL, it needs a "discovery" mechanism. Historically, this was done via an HTTP header, but modern systems are moving toward a more efficient DNS-based approach.
Here is the breakdown of how Alt-Svc and HTTPS Records differ in the discovery process:

---

1. Alt-Svc (The "Learn on the Fly" Method)
The Alt-Svc (Alternative Services) header is the "old school" way (though still very common) to discover HTTP/3. It works by having the server tell the browser about its QUIC support after the first connection is already made.
The Process: 
    1. The browser connects to a site using HTTP/1.1 or HTTP/2 over TCP.  
    2. The server includes an Alt-Svc header in its response: Alt-Svc: h3=":443"; ma=86400. 
    3. The browser caches this information.
    4. On the next visit to that site, the browser sees the cached entry and attempts to connect via HTTP/3 immediately.
    The Downside: It requires at least one full round-trip over a "slower" TCP connection before the browser even knows HTTP/3 is an option.

2. HTTPS/SVCB Records (The "Zero-Delay" Method)
Modern DNS introduced the HTTPS resource record (and its cousin, the SVCB record) to solve the "first-visit" problem. This moves the discovery from the application layer (HTTP) to the infrastructure layer (DNS).
The Process:
        1. While the browser is resolving the IP address (looking up A or AAAA records), it also asks for the HTTPS record for that domain.
        2. The DNS response contains metadata about the service, including supported protocols (ALPNs) like h3.
        3. The browser now knows the server supports HTTP/3 before it ever attempts to open a connection.
        The Upside: This enables "Happy Eyeballs" for transport—the browser can race a QUIC (UDP) connection and a TCP connection simultaneously, or go straight to QUIC, saving significant handshake time on the very first visit.

---

Comparison at a Glance

Feature	Alt-Svc Header	HTTPS DNS Record
Layer	Application Layer (HTTP)	Network Layer (DNS)
First Visit	Must use TCP first; discovery is for future visits.	Discovery happens during DNS lookup; works on the first visit.
Caching	Managed by the browser's Alt-Svc cache.	Managed by DNS TTL (Time to Live).
Primary Benefit	Simple to implement on the server.	Eliminates the "penalty" of the first TCP connection.

Why use both?
In a production environment like amazon.com, you will often see both. HTTPS records provide the fastest path for modern browsers and DNS resolvers, while Alt-Svc acts as a reliable fallback for environments where DNS records might be stripped or for older clients that don't yet support the new DNS record types.

The practical difference is:

• Alt-Svc is discovered from HTTP responses. Great for gradual rollout and per-client tailoring, but it usually cannot help the very first connection unless the client already cached a previous Alt-Svc advertisement.

• HTTPS records are discovered from DNS. They can influence the initial connection, including protocol choice and endpoint selection, because the client sees them before sending HTTP.

There are also some important behavioral differences:

• Trust model: Alt-Svc comes over HTTP, often an authenticated HTTPS response; HTTPS records come from DNS, which RFC 9460 treats as an untrusted channel unless protected by DNSSEC, so only “safe” parameters are allowed there.

• Caching: Alt-Svc uses its own freshness mechanism like ma=max-age; HTTPS records use DNS TTLs.

• Granularity: Alt-Svc can be tailored to a specific client/connection; HTTPS records are shared DNS data, so they are not suitable for single-client customization.

• HTTP→HTTPS upgrade: HTTPS records can also tell clients to prefer secure transport in a way similar to HSTS-style upgrade behavior.

When both are used, RFC 9460 says a client that has cached Alt-Svc and also supports HTTPS records should fetch HTTPS records for the alt-authority and make sure its connection attempts are consistent with both.

A good interview one-liner is:

Alt-Svc says “after you reached me over HTTP, here’s an HTTP/3 endpoint you can use next,” while HTTPS records say “before you connect at all, DNS can tell you that HTTP/3 is available and where.”

“Walk me through TLS 1.3 at a high level.” (Good: handshake establishes shared secrets; cert validation; forward secrecy; resumption/PSK and optional 0‑RTT.)

At a high level, TLS 1.3 is the modern standard for securing internet communications, designed to be faster and more secure than its predecessors by stripping away legacy algorithms and optimizing the connection process.

Here is the breakdown of how a TLS 1.3 session is established and maintained:

1. The 1-RTT Handshake

Unlike TLS 1.2, which required two round-trips to secure a connection, TLS 1.3 achieves this in just one round-trip (1-RTT).

• Client Hello: The client sends a list of supported cipher suites and—crucially—speculatively sends its key share (using Diffie-Hellman) based on a guessed algorithm.

• Server Hello: The server picks the cipher, provides its own key share, and sends its encrypted certificate.

• Secret Derivation: Because both sides now have each other's key shares, they can immediately derive the shared "session keys" to encrypt all subsequent data.

2. Certificate Validation & Identity

Once the encrypted handshake is underway, the browser must verify it is talking to the right person (e.g., amazon.com):

• Chain of Trust: The browser checks the server's certificate against a list of trusted Certificate Authorities (CAs).

• Hostname Match: It ensures the domain name in the certificate matches the URL entered.

• Certificate Transparency (CT): Modern browsers often require proof that the certificate has been logged in public, append-only logs to prevent fraudulent issuance.

3. Key Security Properties

• Forward Secrecy: TLS 1.3 mandates ephemeral key exchanges. This means that even if a server's private key is stolen a year from now, the attacker cannot decrypt past recorded traffic because each session used a unique, temporary key.

• Encrypted Handshake: Almost the entire handshake—including the server's certificate—is encrypted, which limits the information "leaked" to observers on the network (like ISPs).

4. Resumption and 0-RTT

If a user has visited a site recently, TLS 1.3 can skip the handshake entirely:

• PSK (Pre-Shared Key): The client and server remember a "resumption secret" from the previous session.

• 0-RTT (Zero Round-Trip Time): The client can send encrypted application data (like an HTTP GET request) in its very first message to the server.

  • Note: While 0-RTT is incredibly fast, it is susceptible to replay attacks, so it is typically used only for "safe" requests that don't change data on the server.

Common mistakes to avoid in an interview:

        Don’t mix up the TCP handshake with the TLS handshake.

        Don’t say HTTPS encrypts the hostname completely; with classic SNI, the hostname is still exposed.

        Don’t describe RSA key exchange as the normal TLS 1.3 flow; TLS 1.3 uses ephemeral key exchange for forward secrecy.

“How does the browser know to use HTTP/2?” (Good: ALPN advertises h2; server picks; requires TLS in practice for browsers.)

The transition from a URL to a specific protocol like HTTP/2 happens during the secure connection phase. Since almost all browsers only support HTTP/2 over an encrypted connection (TLS), the negotiation is baked into the "handshake" process.

Here is the breakdown of how the browser and server agree on which version to use:

1. ALPN (Application-Layer Protocol Negotiation)

The primary mechanism is an extension of TLS called ALPN.

• The ClientHello: When your browser initiates the TLS handshake, it sends a ClientHello message. This message includes a list of all protocols the browser supports (e.g., h2 for HTTP/2, http/1.1).

• The Server's Choice: The server looks at this list, compares it to its own supported protocols, and picks the most efficient one.

• The Confirmation: The server sends back a ServerHello message containing the selected protocol. This allows both parties to start talking HTTP/2 immediately after the encryption is established, without an extra round-trip.

2. Prior Knowledge (Rare)

In some specific (mostly non-browser) cases, a client can be configured with "prior knowledge." The client simply assumes the server supports HTTP/2 and starts the connection using the HTTP/2 connection preface. However, because this can break if the server or an intermediate proxy doesn't understand the protocol, standard web browsers do not use this for initial connections.

3. The Upgrade Header (HTTP/1.1)

Technically, a browser could start with a standard HTTP/1.1 request and include an Upgrade: h2c header (HTTP/2 Cleartext).

• If the server supports it, it responds with a 101 Switching Protocols.

• In practice: Major browsers (Chrome, Firefox, Safari) have largely abandoned support for HTTP/2 over unencrypted "cleartext" links, so you will rarely see this mechanism used for the public web.

4. Alt-Svc (Alternative Services)

If a browser is already communicating with a server via HTTP/1.1 or HTTP/2, the server can send an Alt-Svc header in its response. This tells the browser: "Hey, I have a faster version of this service available at this other port or using this other protocol (like HTTP/3)." The browser can then use that information for subsequent requests.

---

Summary Table: Protocol Negotiation

Feature	Method	Context
Primary Method	ALPN	During the TLS handshake (Most common)
Legacy Method	Upgrade Header	Transitioning from HTTP/1.1 (Rarely used by browsers)
Discovery	Alt-Svc	Post-connection hint for future requests

A few useful edge cases:
        If the server does not support HTTP/2, they fall back to HTTP/1.1.
        For browsers, HTTP/2 is almost always used only over HTTPS.
        HTTP/3 is different: it usually gets discovered through things like Alt-Svc headers or HTTPS DNS records, then the browser can try QUIC/HTTP/3. If that fails, it falls back to HTTP/2 or HTTP/1.1.
In interview form, the best answer is:
        “The browser learns to use HTTP/2 via ALPN during the TLS handshake. It offers h2 as a supported protocol, and if the server selects it, that connection speaks HTTP/2.”

“Why is HTTP/3 faster sometimes? Isn’t UDP unreliable?” (Good: QUIC implements reliability/flow control at user space; avoids some TCP head-of-line blocking; faster handshakes; better loss recovery at stream level.)

It is a common paradox in networking: UDP is "unreliable" because it doesn't guarantee delivery, yet HTTP/3 uses it to become more reliable and faster than its predecessor, HTTP/2.

The secret is that HTTP/3 doesn't just use "raw" UDP. It uses a protocol called QUIC (Quick UDP Internet Connections) that sits on top of UDP. QUIC re-implements the reliability features of TCP (like retransmissions and congestion control) but does so in a way that avoids the "clogging" issues of the past.

1. Eliminating "Head-of-Line Blocking"

In HTTP/2 (which uses TCP), all your data—images, scripts, and CSS—travels in a single "pipe." If one single packet of an image is lost in transit, TCP stops everything to wait for that packet to be re-sent. Your browser can't process the CSS or JS that already arrived because TCP insists on keeping every byte in the exact original order.

HTTP/3 solves this by making every resource its own independent stream:

• The Scenario: You're downloading an image and a script.

• The Glitch: A packet for the image gets lost.

• The HTTP/3 Result: The script keeps loading and executing without a pause. Only the specific image waits for its missing piece.

2. Blazing Fast Connection Setup

TCP and TLS (security) used to require multiple "handshakes" (back-and-forth messages) before any data could be sent.

• HTTP/2: Requires a TCP handshake + a TLS handshake (2–3 round trips).

• HTTP/3: Combines them into one. It can start sending data in just 1 round trip.

• 0-RTT: For sites you've visited before, HTTP/3 can often send data in 0 round trips—the very first packet you send to the server can include your request.

3. Connection Migration (Perfect for Mobile)

TCP connections are tied to your IP address. If you walk out of your house and your phone switches from Wi-Fi to 5G, your IP changes, your TCP connection "breaks," and your download or video stream has to restart.

        QUIC/HTTP/3 uses a unique Connection ID instead of an IP address. Your phone can switch networks seamlessly, and the server will recognize you by your ID, keeping your session alive without a hitch.

Comparison at a Glance

Feature	HTTP/2 (TCP)	HTTP/3 (QUIC over UDP)
Foundation	TCP (Reliable, but rigid)	UDP + QUIC (Reliable and flexible)
Packet Loss	Stops all streams (Blocking)	Only stops the affected stream
Handshake	2–3 round trips	0–1 round trips
IP Swapping	Connection breaks	Connection stays alive

Is it always faster?

Not necessarily. Because HTTP/3 handles reliability in the "user space" (the browser/app level) rather than the "kernel" (the operating system level), it can actually use more CPU than HTTP/2. On extremely stable, high-speed fiber connections, HTTP/2 might still be slightly more efficient. HTTP/3's real "superpowers" shine on unstable networks, mobile devices, and long-distance (high-latency) connections.

“What breaks HTTP/3?” (Good: UDP blocked; middleboxes; fallback to TCP/TLS and HTTP/2 or HTTP/1.1.)

While HTTP/3 is designed to be more robust than its predecessors, its reliance on the QUIC protocol (which runs over UDP) makes it susceptible to specific network behaviors that don't affect standard TCP-based traffic.

primary factors that "break" or prevent the use of HTTP/3:

1. UDP Blocking

Many enterprise firewalls and public Wi-Fi gateways are configured to block all UDP traffic except for specific services like DNS (Port 53). Since HTTP/3 requires UDP, these "middleboxes" effectively kill the connection, forcing the browser to fall back to HTTP/2 or HTTP/1.1 over TCP.

2. Aggressive Middleboxes

Some network appliances (like Load Balancers or Intrusion Prevention Systems) do not yet recognize the QUIC protocol. If they see a high volume of encrypted UDP traffic that doesn't match a known pattern, they may drop the packets as a security precaution, assuming it is a DDoS attack or a data exfiltration attempt.

3. MTU Issues and Packet Fragmentation

QUIC packets are often larger than standard UDP packets. If a network path has a smaller Maximum Transmission Unit (MTU) than expected, the packets may be fragmented or dropped. While QUIC has built-in path MTU discovery, extreme constraints can lead to connection failure.

4. Lack of "Alt-Svc" or HTTPS Records

A browser doesn't automatically know a server supports HTTP/3. It usually discovers it via:

• Alt-Svc Headers: The server tells the browser on an initial HTTP/2 connection that HTTP/3 is available.

• HTTPS DNS Records: The DNS response contains metadata about supported protocols.

  If these advertisements are missing or stripped by a proxy, the browser will never attempt the HTTP/3 upgrade.

---

Fallback Mechanism

It is important to note that when HTTP/3 "breaks," it rarely results in a failed page load for the user. Modern browsers use a Happy Eyeballs-style approach or a "race" where they attempt a QUIC connection while maintaining a TCP fallback. If the UDP path fails, the browser seamlessly switches to TLS/TCP.

“What if the certificate is valid but for the wrong hostname?” (Good: hostname match fails; user agents should error out or warn; automated clients should log and typically terminate.) 

If the certificate is valid but the hostname doesn't match, the browser will treat the connection as untrusted and block the request. This is because the primary goal of a certificate is not just to provide encryption, but to provide identity verification.

Here is what happens at different levels of the stack:

1. The Browser's Reaction

The browser compares the hostname you typed in the address bar (e.g., amazon.com) against the identities listed in the certificate’s Subject Alternative Name (SAN) field. If amazon.com is not in that list:

• Security Warning: You will see a "Your connection is not private" or "Potential Security Risk Ahead" warning (often error code ERR_CERT_COMMON_NAME_INVALID).

• Navigation Blocked: For most modern sites, the browser will prevent you from continuing to the page to protect you from a potential Man-in-the-Middle (MitM) attack.

• HSTS Enforcement: If the site is on the HSTS preload list, the browser will not even allow you to "click through" the warning and proceed.

2. The Identity Failure

Even if the certificate is cryptographically perfect (signed by a trusted CA, not expired, not revoked), the Identity Match fails. This usually happens in three common scenarios:

• Misconfiguration: A server admin forgot to include the www version of a domain or is using a certificate meant for a staging environment (e.g., dev.amazon.com) on the production site.

• Cloud Hosting/CDN Issues: If a CDN or Load Balancer isn't configured with the correct certificate for your specific domain, it might serve a "default" certificate for a different customer.

• Malicious Interception: An attacker is trying to redirect your traffic to their server. They might have a valid certificate for their domain, but since they can't get one for yours, the mismatch alerts you to the fraud.

3. Impact on Automated Clients

While humans might try to ignore a warning, automated clients (like APIs or curl) are stricter:

• They will typically terminate the connection immediately with an error.

• In production environments, this results in failed background jobs and broken integrations because these clients log the error and stop the process for safety.

“What is Certificate Transparency and why does it exist?” 

没有看懂

Certificate Transparency (CT) is a security framework that requires Certificate Authorities (CAs) to log every digital certificate they issue in a public, "append-only" ledger.

Before CT, the process of issuing SSL/TLS certificates was opaque; if a CA mistakenly or maliciously issued a certificate for your domain (like google.com or yourbank.com) to a hacker, you might never know until a major attack occurred.

Why Does It Exist?

CT was created to fix a fundamental "blind spot" in the web's trust model. Historically, any of the hundreds of trusted CAs worldwide could issue a certificate for any domain. This led to several high-profile security failures:

• CA Compromises: In 2011, the Dutch CA DigiNotar was hacked, and fraudulent certificates for Google, Yahoo, and Tor were issued, allowing attackers to spy on users.

• Lack of Accountability: There was no central record to verify if a CA was following proper validation rules. A "rogue" or "sloppy" CA could issue a certificate in secret, and it would be trusted by browsers indefinitely.

• Slow Detection: Without CT, it often took months or years to discover a mis-issued certificate.

How It Works

The system relies on three main components to ensure no certificate can be issued in secret:

1. Public Logs: CAs must submit new certificates to multiple independent logs. These logs use a Merkle Tree (a cryptographic data structure) that makes it impossible to delete or retroactively change an entry without being caught.

2. Signed Certificate Timestamps (SCT): When a log receives a certificate, it sends back an SCT. This is a "promise" that the certificate will be published. Browsers (like Chrome and Safari) now refuse to trust a certificate unless it carries valid SCTs.

3. Monitors and Auditors: Domain owners and security researchers use "Monitors" to watch these logs in real-time. If a certificate is issued for your domain that you didn't authorize, you get an alert immediately.

---

Benefits vs. Risks

Feature	Benefit
Early Detection	Unauthorized certificates can be spotted in minutes/hours instead of months.
CA Accountability	Sloppy CAs are publicly exposed, forcing them to improve or be distrusted by browsers.
Public Oversight	Anyone can search logs (using tools like crt.sh) to see every certificate ever issued for a brand.

Note on Privacy: Because logs are public, attackers also use them for "subdomain enumeration." They watch logs to find new, unannounced subdomains (e.g., dev-testing.company.com) to look for vulnerabilities.

“Where does SNI fit, and what privacy leak exists?” (Good: classic SNI is in cleartext; ECH aims to encrypt ClientHello metadata; status of deployment varies.) 

SNI stands for Server Name Indication and is part of the TLS handshake that happens when your browser connects to a website using HTTPS.

Where SNI fits in the connection

Typical HTTPS connection flow:

1. DNS lookup - Your device asks DNS: “What IP address is example.com?”

2. TCP connection - Your browser connects to that IP (usually port 443).

3. TLS handshake begins - The browser sends a ClientHello message.

4. SNI is inside the ClientHello - It includes the hostname you want (e.g., example.com).

5. Server selects the correct certificate
   Many domains can share one IP address.
   The server uses the SNI hostname to choose the right TLS certificate.

6. TLS encryption starts - After the handshake, the connection becomes encrypted.

So SNI happens before encryption is fully established, inside the ClientHello.

DNS -> TCP connect -> TLS ClientHello (contains SNI) -> ServerHello -> Encrypted traffic

---

The privacy leak

The key issue:

SNI is sent in plaintext in traditional TLS (≤ TLS 1.2 and most TLS 1.3 deployments).

This means that any observer on the network can see the hostname you are connecting to, even though the content of the connection is encrypted.

People who can see this include:
        Your ISP
        Wi-Fi network operators
        Corporate networks
        Nation-state surveillance
        Censors/firewalls

Example

If you visit:

https://example.com/private/page

Observers cannot see:
        page path (/private/page)
        cookies
        form data
        page contents

But they can see:

SNI: example.com

So they know which site you are visiting, just not the page.

---

Why SNI exists

Before SNI, each HTTPS site needed its own IP address because the certificate had to be chosen before the hostname was known.

SNI allows:

• multiple HTTPS sites on one IP

• virtual hosting for HTTPS

• modern CDN hosting

---

The modern fix: Encrypted ClientHello (ECH)

    To address the privacy leak, a newer mechanism was developed:

    ECH (Encrypted ClientHello)

        ECH encrypts: SNI and most of the TLS ClientHello

        So observers only see: connect to IP -> 203.0.113.10

        They cannot see the hostname.

        However:
                ECH deployment is still partial
                supported in modern browsers + some CDNs (e.g., Cloudflare)

Summary

Feature	Visibility
DNS query	usually visible
SNI (traditional TLS)	visible
TLS encrypted data	hidden
ECH SNI	hidden

So the privacy leak is that SNI exposes the hostname you visit even when using HTTPS.

“What’s the difference between HTTP/1.1 and HTTP/2 from the browser’s perspective?” 

From the browser’s perspective, the transition from HTTP/1.1 to HTTP/2 was a fundamental shift in how data is "packaged" and "shipped" across the network, even though the core concepts (like GET/POST, headers, and status codes) remained the same.

According to the provided System Design: Web Page Load documentation, here are the primary differences:

1. Multiplexing vs. Queuing

• HTTP/1.1: Browsers are limited to one request at a time per TCP connection. To speed things up, browsers typically open 6–8 parallel connections to a single domain, but they still face Head-of-Line (HOL) blocking at the application layer. If one large image is slow to download, it blocks all other requests behind it on that specific connection.

• HTTP/2: Introduces multiplexing, allowing the browser to send multiple requests and receive multiple responses simultaneously over a single TCP connection. This eliminates the need for multiple connections and prevents one slow resource from stalling the rest of the page.

2. Binary vs. Textual Framing

• HTTP/1.1: Uses plain text. The browser sends and receives human-readable text commands, which are simple but inefficient to parse.

• HTTP/2: Uses a binary framing layer. The browser breaks down messages into small, binary-encoded "frames." This makes communication much more efficient for the browser to parse and less prone to errors compared to text-based protocols.

3. Header Compression (HPACK)

• HTTP/1.1: Every request includes a set of headers (User-Agent, Cookies, etc.) in plain text. For modern sites with many small resources, these redundant headers often add significant overhead.

• HTTP/2: Uses HPACK compression. The browser and server maintain a shared "table" of headers. Instead of sending the full text every time, the browser only sends the differences (deltas) or small indices, drastically reducing the data sent over the wire.

4. Resource Prioritization

• HTTP/2 allows the browser to assign "weights" or priorities to different streams. For example, the browser can tell the server to prioritize the CSS and JavaScript needed to render the top of the page over a low-priority tracking pixel or an image at the bottom of the page.

5. Server Push

• HTTP/2 introduced the ability for a server to "push" resources to the browser's cache before the browser even asks for them. If the server knows the browser will need style.css after receiving index.html, it can start sending it immediately, saving a full round-trip.

---

Summary Table

Feature	HTTP/1.1	HTTP/2
Format	Text-based	Binary framing
Connections	Multiple (usually 6 per origin)	Single connection
Concurrency	One request at a time per connection	Multiplexing (many at once)
Headers	Redundant, plain text	Compressed via HPACK
Priority	First-come, first-served	Weighted prioritization

From the browser’s perspective, the biggest difference is how many requests it can keep in flight over one connection.

With HTTP/1.1:

• The browser usually opens several TCP connections to the same origin.

• Each connection can only handle requests in a much more limited way, so browsers often juggle many sockets to load a page faster.

• This creates tricks like domain sharding and more pressure to combine files.

With HTTP/2:

• The browser can send many requests and responses at once over a single connection using multiplexing.

• That usually makes page loading smoother and reduces the need for opening lots of parallel connections.

• It also compresses headers, so repeated request metadata costs less.

What this means in practice:

Loading behavior

• HTTP/1.1: More likely to see multiple parallel connections and resource queues.

• HTTP/2: More likely to see one connection carrying HTML, CSS, JS, images, and API calls together.

Performance

• HTTP/2 often improves real-world page load speed, especially on pages with many small assets.

• But it is not always automatically faster. If one TCP connection has packet loss, that single connection can still become a bottleneck.

Browser optimization strategies

• Under HTTP/1.1, browsers and sites often relied on:

  • bundling files

  • sprite sheets

  • domain sharding

• Under HTTP/2, some of those tricks become less useful or even counterproductive.

What developers notice

• In DevTools, HTTP/2 usually looks “cleaner”: fewer connections, more simultaneous transfers.

• Waterfalls often show less waiting caused by connection limits.

Protocol feel

• HTTP/1.1 is text-based and older in design.

• HTTP/2 is binary-framed, which browsers handle more efficiently internally.

A good one-line summary:

HTTP/1.1 makes the browser scale by opening more connections; HTTP/2 makes the browser scale by doing more over fewer connections.

One important note: HTTP/2 server push existed, but browsers and CDNs largely moved away from it, so it is not a major practical browser-side advantage today.

“What headers matter most for security and caching?” (Good: Cache-Control; Set-Cookie/Cookie; CSP; CORS headers; HSTS.) 

http headers (related to next question)

The biggest split is this:

• Security: the most important headers are usually response headers the server sets.

• Caching: the most important header is Cache-Control, then validators like ETag and Last-Modified, plus request headers like If-None-Match and If-Modified-Since. (for next question)

For security, these matter most:

• Strict-Transport-Security: tells browsers to use HTTPS only for that host in future requests.

• Content-Security-Policy: the highest-value browser defense against injected script/resource loading issues; it also includes frame-ancestors for clickjacking defense.

• Set-Cookie with Secure, HttpOnly, and explicit SameSite: these are critical for session cookies. Secure keeps cookies on HTTPS, HttpOnly blocks JS access, and SameSite helps reduce CSRF risk.

• X-Content-Type-Options: nosniff plus a correct Content-Type: this prevents MIME sniffing surprises.

• Referrer-Policy: controls how much referrer information gets sent on outgoing requests.

• Permissions-Policy: limits browser features like camera, mic, geolocation, and more.

For caching, these matter most:

• Cache-Control is the main one. The important directives are:

  • no-store = do not store the response anywhere.

  • no-cache = storage is allowed, but reuse requires revalidation.

  • private = browser cache only; important for personalized responses.

  • public / s-maxage = allow shared caches/CDNs to store.

  • immutable = best for versioned static assets.

• ETag is the strongest common validator for cache revalidation; clients send it back in If-None-Match.

• Last-Modified is a useful fallback validator; clients use If-Modified-Since. It is less accurate than ETag.

• Vary is easy to overlook but very important. It tells caches which request headers affect the response, so different variants do not get mixed together.

The request headers I’d watch most are:

• Authorization and Cookie: they usually mean the response may be user-specific, so caching rules need extra care. MDN notes that responses to requests with Authorization are not shared-cacheable by default unless response directives such as public, s-maxage, or must-revalidate change that behavior.

• If-None-Match and If-Modified-Since: these drive conditional requests and 304 responses.

• Cache-Control on requests can ask caches not to store or to prefer cached content, but the server’s response headers still define cacheability of the response.

A good practical default set is:

• HTML pages: Content-Security-Policy, Strict-Transport-Security, Referrer-Policy, X-Content-Type-Options, hardened Set-Cookie, and usually Cache-Control: no-cache with ETag so the HTML stays fresh without redownloading unnecessarily.

• Sensitive authenticated pages or secret-bearing responses: use private or no-store depending on how sensitive the content is.

• Versioned JS/CSS/images: Cache-Control: public, max-age=31536000, immutable plus ETag/Last-Modified.

The most common mistake is mixing up no-cache and no-store. no-cache does not mean “do not cache”; it means “store it, but revalidate before reuse.” no-store is the one that means “do not store.”

“How do conditional requests work?” 

Conditional requests let a client say, “Only send me the response if some condition is true.”

They are mainly used for two things:

1. Caching — avoid re-downloading unchanged data

2. Concurrency control — avoid overwriting someone else’s update

The basic idea

A server first gives the client a validator for a resource, usually:

• ETag: a version-like identifier for the representation

• Last-Modified: the timestamp of the last change

Later, the client sends that validator back in a conditional header.

The server checks the condition and decides whether to send the full body, no body, or reject the request.

---

Most common caching flow

First request

GET /notes/123 HTTP/1.1

Host: example.com

Server response

HTTP/1.1 200 OK

ETag: "abc123"

Last-Modified: Tue, 04 Mar 2026 18:00:00 GMT

Content-Type: application/json 

{"title":"Hello","body":"World"} 

Now the client stores the response plus the validator.

Later request

GET /notes/123 HTTP/1.1

Host: example.com

If-None-Match: "abc123"

If resource did not change

HTTP/1.1 304 Not Modified

ETag: "abc123"

No response body is sent. The client uses its cached copy.

If resource did change

HTTP/1.1 200 OK

ETag: "def456"

Content-Type: application/json 

{"title":"Hello","body":"Updated"}

---

Main conditional headers

If-None-Match

Usually used with GET or HEAD.

Meaning: “Send the resource only if its ETag does not match this value.”

* Match found → 304 Not Modified for GET/HEAD


* No match → normal 200 OK with body

This is the most reliable cache validator.

If-Modified-Since

Meaning: “Send the resource only if it has changed since this date.”

GET /file.txt HTTP/1.1

If-Modified-Since: Tue, 04 Mar 2026 18:00:00 GMT

* Not changed since then → 304 Not Modified
* Changed after then → 200 OK

Less precise than ETag because timestamps can be coarse.

---

Concurrency control

Conditional requests also protect updates.

If-Match -- Meaning: “Perform this write only if the current ETag matches.”

PUT /notes/123 HTTP/1.1

If-Match: "abc123"

Content-Type: application/json 

{"title":"Hello","body":"New text"}

• If current version is still "abc123" → update succeeds

• If someone already changed it → server returns:

HTTP/1.1 412 Precondition Failed

This prevents the “lost update” problem.

If-Unmodified-Since -- Meaning: “Only do this if the resource has not changed since this time.”

Same purpose as If-Match, but based on time instead of ETag.

---

Partial content case

If-Range

Used with range requests.

Meaning: “Give me the byte range only if the resource is still the same; otherwise give me the full new version.”

Useful for resuming downloads.

---

Common status codes

• 200 OK — condition passed, full response returned

• 304 Not Modified — cached version is still valid

• 412 Precondition Failed — condition for unsafe action failed

• 206 Partial Content — range request succeeded

---

Easy mental model

Think of it like this:

• If-None-Match → “Only send if different”

• If-Modified-Since → “Only send if newer”

• If-Match → “Only update if same version”

• If-Unmodified-Since → “Only update if unchanged since then”

---

Why this matters

Conditional requests help by:

• saving bandwidth

• speeding up page loads

• reducing server work

• preventing accidental overwrites

One-line summary

A conditional request is a normal HTTP request plus a rule like “send this only if changed” or “update this only if nobody else changed it first.”

========

Conditional requests are a mechanism in HTTP that allows a client to ask the server if a resource has changed since the last time it was fetched. If the resource hasn't changed, the server tells the client to keep using its cached copy, saving bandwidth and reducing load times.

This process relies on validators (metadata about the resource) and conditional headers.

1. The Validators (The "Fingerprints")

When a server sends a resource for the first time, it includes one or both of these headers to identify the specific version of that file:

• ETag (Entity Tag): A unique identifier (often a hash or version number) for a specific version of a resource. If the content changes, the ETag changes.
• Last-Modified: A timestamp indicating exactly when the resource was last updated on the server.

2. The Conditional Request

When the client needs that resource again and its cached copy is "stale," it sends a request to the server with "if" headers containing those stored validators:

• If-None-Match: The client sends the stored ETag. It's essentially saying, "Give me the full file only if its current ETag doesn't match this one."

• If-Modified-Since: The client sends the stored Last-Modified timestamp. It's saying, "Give me the file only if it has been updated since this time."

3. The Server’s Response

The server compares the client's validator with the current state of the resource:

Scenario	Server Action	Status Code
Resource Unchanged	The server sends a short response with no body, telling the client its cache is still valid.	304 Not Modified
Resource Changed	The server sends the entire new version of the resource along with new validators.	200 OK

---

Why It Matters

For high-traffic sites like amazon.com, conditional requests are vital for performance. They allow the browser to skip downloading large images, scripts, or CSS files if they haven't changed, while still ensuring the user always sees the most up-to-date version of the page.

“Where does TLS terminate?” (Good: could be at CDN/edge, at a load balancer, or at the service itself; depends on architecture and compliance.) 

TLS terminates at the point that decrypts the TLS session.

Usually that means one of these:

• On the origin server: the app server or web server handles TLS directly.

• At a reverse proxy / load balancer: Nginx, Envoy, HAProxy, AWS ALB, Cloudflare, etc. decrypts traffic there, then forwards plain HTTP or re-encrypted HTTPS upstream.

• At an API gateway / ingress: common in Kubernetes and microservices.

• At a CDN / edge: the edge terminates client TLS, then connects back to the origin with either HTTP or HTTPS.

So the practical answer is: TLS terminates wherever the certificate is presented and the encrypted connection is decrypted.

A quick rule of thumb:

• Client → termination point = encrypted with TLS

• Termination point → backend = either unencrypted or a new separate TLS connection

That’s why people distinguish:

• TLS termination: decrypt at proxy/load balancer

• TLS passthrough: proxy does not decrypt; backend terminates TLS

• Re-encryption / end-to-end-ish: decrypt at edge, then start a new TLS session to the backend

In a modern, high-traffic system like the one described for amazon.com, TLS (Transport Layer Security) termination can happen at several different layers depending on the specific infrastructure and security requirements.

Primary Termination Points

• At the Edge (CDN / Reverse Proxy): Most global services terminate TLS at the Edge POP (Point of Presence). By terminating the secure connection geographically close to the user, the system reduces the latency of the multi-step TLS handshake. The CDN then communicates with the origin server over a separate, often persistent and pre-warmed connection.

• At the Load Balancer: Within a data center or cloud region, TLS is frequently terminated at an Application Load Balancer (ALB) or a dedicated SSL/TLS Offloader. This "offloading" relieves the backend application servers from the CPU-intensive tasks of encryption and decryption, allowing them to focus on processing business logic.

• At the Service / Origin: In "Zero Trust" architectures or highly regulated environments (like banking or healthcare), TLS may be passed through the load balancer (using Layer 4 routing) and terminated directly on the individual application server or container. This ensures data remains encrypted even as it moves through the internal network.

---

Interview Deep Dive: Why It Matters

When answering this in an interview, you should emphasize the trade-offs involved in choosing a termination point:

Feature	Termination at Edge/LB	Termination at Origin
Performance	Higher. Reduces latency via early handshakes and offloads CPU work from app servers.	Lower. App servers must spend cycles on encryption/decryption.
Security	Moderate. Traffic is "clear" (or re-encrypted) within the internal network.	Highest. End-to-end encryption ensures no internal component sees raw data.
Complexity	Lower. Centralized certificate management at the LB or CDN level.	Higher. Requires managing certificates across many individual servers/nodes.

Key Keywords for Follow-ups

• SSL Offloading: The process of moving TLS processing to a specialized device or layer.

• Re-encryption: Terminating TLS at the edge but establishing a new secure connection from the edge to the origin to maintain security.

• Layer 4 vs. Layer 7: L4 load balancers (TCP level) just pass through the encrypted packets; L7 load balancers (HTTP level) must terminate TLS to "see" headers and make routing decisions.

“How does a CDN decide what to cache?” (Good: cache key; headers; TTL; vary; private vs shared caches; invalidation/purge.) 

Based on the system design context you are reviewing, a Content Delivery Network (CDN) uses a combination of explicit instructions from the origin server and internal optimization logic to decide what to cache.

The decision-making process generally breaks down into these key factors:

1. HTTP Cache-Control Headers

The most direct way a CDN decides is by looking at the headers sent by your origin server.

• Cache-Control: public: Signals that the response can be cached by any intermediate cache, including the CDN.

• max-age: Tells the CDN exactly how many seconds to keep the file before it is considered "stale."

• s-maxage: A specific directive for shared caches (like CDNs) that overrides the standard max-age.

• no-cache / no-store: Tells the CDN to either revalidate with the origin every time or not store the data at all.

2. The Cache Key

A CDN doesn't just store a file; it stores a "key-value" pair. The Cache Key is the unique identifier the CDN uses to determine if it has a specific resource in stock.

• By default, the key is usually the URL (e.g., amazon.com/logo.png).

• Advanced configurations can include headers (like Accept-Encoding for Gzip vs. Brotli) or query strings in the cache key. If two users request the same URL but the CDN sees them as different keys, it may cache two separate versions.

3. Static vs. Dynamic Content

CDNs are traditionally optimized for static assets—files that don't change based on who is looking at them (images, CSS, JS, videos).

• Extension-based caching: Many CDNs are configured to automatically cache common file extensions (.jpg, .pdf) for a default period if no headers are present.

• Dynamic content: For HTML pages or API responses that change per user, the CDN usually defaults to "pass-through" mode unless specifically told otherwise (e.g., using a "Stale-While-Revalidate" strategy).

4. Edge Logic and "Vary" Headers

The CDN uses the Vary header to decide if it should cache different versions of a resource based on request metadata.

• For example, Vary: User-Agent tells the CDN that the content might be different for mobile vs. desktop, so it should cache both versions separately.

---

Comparison of Caching States

State	Meaning	Action Taken
Cache Hit	The file is in the edge's memory and is still fresh.	Served instantly to the user.
Cache Miss	The file is not at the edge.	CDN fetches from origin, serves to user, and caches for next time.
Cache Stale	The file is at the edge but has expired (TTL is up).	CDN revalidates with origin (often using ETag or Last-Modified).

Interviewer Tip: If asked about this in a senior-level interview, mention Anycast (how the request gets to the right edge) and Purging/Invalidation (how you manually tell the CDN to delete a file when you've updated it at the origin).

In practice, the rough decision flow is:

1. Request arrives.

2. CDN builds a cache key.

3. It checks whether a fresh matching object already exists.

4. If yes, it serves from cache.

5. If not, it asks the origin.

6. Then it decides whether to store the response, based on headers and rules.

A simple rule of thumb:

• Static, public, versioned files → almost always cached

• User-specific or cookie-based pages → often bypassed or cached very carefully

One subtle point: a CDN does not always cache something just because it can. It may decline if the response is marked private, contains sensitive cookies, has a very short lifetime, or conflicts with platform rules.

“What is Anycast and why does it matter for CDNs?” 

In the context of networking and Content Delivery Networks (CDNs), Anycast is a routing methodology where a single IP address is assigned to multiple physical server locations.

When a request is sent to an Anycast IP, the network (via BGP or Border Gateway Protocol) routes that request to the "closest" node, typically defined by the fewest number of network hops.

Why Anycast Matters for CDNs

Anycast is a foundational technology for modern CDNs like Cloudflare or Akamai because it solves several distributed system challenges simultaneously:

• Latency Reduction: By routing users to the geographically or topologically nearest Edge POP (Point of Presence), Anycast minimizes the distance data must travel, significantly speeding up the initial TCP/TLS handshake.

• High Availability and Failover: If a specific data center goes offline, the network automatically reroutes traffic to the next closest available node. This happens at the routing layer, often without the need for complex DNS changes.

• DDoS Mitigation: Anycast naturally "scatters" the load of a distributed denial-of-service attack. Instead of a single server being overwhelmed by global botnet traffic, the attack volume is distributed across the entire edge network, allowing local nodes to absorb and filter the traffic.

• Simplified Configuration: Instead of managing thousands of unique IP addresses for different regions, a CDN can provide a single set of IP addresses that work globally.

---

Anycast vs. Unicast

While Unicast (the traditional method) maps one IP to one specific machine, Anycast maps one IP to many.

Feature	Unicast	Anycast
Mapping	1 IP : 1 Node	1 IP : Many Nodes
Routing	Direct to a specific location	To the "closest" healthy location
Resilience	Fails if the node goes down	Automatically reroutes to a peer
Primary Use	Standard web hosting	CDNs, DNS providers (e.g., 8.8.8.8)

The "DNS Load Balancing" Catch

As noted in the system design documentation, a common misconception is that DNS-based load balancing is "instant." Because of DNS TTLs (Time to Live) and resolver caching, it can take time for a DNS change to propagate. Anycast bypasses this by handling the rerouting at the network routing level, which is much faster than waiting for DNS records to expire globally.

========

Anycast is a routing method where the same IP address is announced from multiple servers in different locations. When a user sends traffic to that IP, the internet’s routing system usually sends it to the nearest or best reachable location.

Think of it like many stores sharing one phone number. When you call, the network connects you to the closest open store.

For CDNs, that matters a lot because CDNs want users to fetch content from a nearby edge server instead of a faraway origin.

Why it helps CDNs:

• Lower latency: requests go to a nearby edge location, so pages, images, video chunks, and APIs load faster.

• Better resilience: if one site goes down, routes can shift users to another site advertising the same IP.

• DDoS absorption: attack traffic gets spread across many locations instead of piling onto one server.

• Simple global entry point: users hit one IP, while the CDN decides where traffic is served from.

Example:
A CDN advertises 203.0.113.10 from New York, London, and Tokyo. A user in Paris will likely be routed to London; a user in California to New York. Both used the same destination IP, but reached different physical places.

Why “likely” and not “always”:
Anycast depends on BGP routing, and BGP chooses paths based on network policy, not pure geography. So the selected site is often the closest in routing terms, but not always the physically nearest.

One important nuance:
Anycast is great for getting users to the right edge, but for long-lived TCP connections or stateful sessions, routing changes can be tricky if traffic suddenly shifts to a different site. CDNs handle this with careful design, caching, load balancing, and session strategies.

So in one line: Anycast gives CDNs a fast, resilient, global front door.

“What is a reverse proxy vs load balancer?” (Good: overlapping; reverse proxy is a server-side proxy at L7; load balancer can be L4 or L7; both can terminate TLS and route.) 

While the terms are often used interchangeably because their functions frequently overlap, a reverse proxy and a load balancer serve distinct roles in a network architecture.

Essentially, a load balancer is about distribution (managing traffic across multiple servers), whereas a reverse proxy is about representation (acting as a single point of contact for one or more servers).

---

Comparison at a Glance

Feature	Reverse Proxy	Load Balancer
Primary Goal	Protects, optimizes, and simplifies access to a server.	Distributes incoming traffic to prevent server overload.
Scale	Can sit in front of a single server.	Requires a "pool" of multiple servers.
Security	Hides server IP; handles SSL/TLS termination and WAF.	Primarily prevents DoS by spreading load.
Performance	Uses caching and compression to speed up delivery.	Uses algorithms (Round Robin, etc.) to optimize resource use.

---

1. The Reverse Proxy

A reverse proxy acts as an intermediary for a web server. When a client sends a request, it hits the proxy first, which then fetches the data from the backend server and returns it to the client.

• Security: The client never talks to the actual backend server, keeping the server's internal IP address hidden.

• SSL Termination: It can handle the "handshake" and decryption of HTTPS traffic, taking that heavy computational load off the backend server.

• Caching: It can store copies of popular content (like images) to serve them faster without bothering the origin server.

2. The Load Balancer

A load balancer sits in front of a group of servers (a server farm) and acts as a traffic cop. It ensures that no single server becomes a bottleneck.

• Availability: If one server crashes, the load balancer detects the failure and reroutes traffic to the healthy ones.

• Efficiency: It uses specific algorithms to decide where to send the next request—such as Round Robin (sequential) or Least Connections (sending traffic to the quietest server).

• Scalability: It allows you to add or remove servers from the pool seamlessly without the user noticing.

---

How They Work Together

In a modern production environment, you rarely choose one or the other. Instead, they are often combined:

1. A Load Balancer receives the initial massive wave of traffic.

2. It distributes that traffic to several Reverse Proxies.

3. Each Reverse Proxy then handles the specific application logic, security, and caching for its respective backend service.

========

The easiest way to think about it:

• Reverse proxy = front door

• Load balancer = traffic distributor

Reverse proxy

A reverse proxy accepts client requests and forwards them to backend servers. It can also do extra jobs like:

• hiding backend servers from the public

• SSL/TLS termination

• caching

• compression

• authentication

• rate limiting

• URL routing

Example: a user visits example.com, and the reverse proxy decides whether to send the request to the app server, API server, or a cached response.

Load balancer

A load balancer focuses on availability and scale by distributing requests across multiple servers. It can:

• use round-robin, least-connections, or other balancing methods

• detect unhealthy servers

• stop sending traffic to failed instances

• improve performance and fault tolerance

Example: 10 app servers are running, and the load balancer spreads incoming traffic among them.

Key difference

The main difference is purpose:

• A reverse proxy is about mediating and managing requests

• A load balancer is about distributing requests across multiple servers

Important nuance

A load balancer is usually a specialized reverse proxy.
Not every reverse proxy does load balancing, but many can.

Simple example

If you have:

• 1 backend server

• Nginx in front doing SSL termination and caching

that is a reverse proxy, but not really a load balancer.

If you have:

• 5 backend servers

• a front-end system distributing requests among them

that is a load balancer.
If it also terminates SSL and rewrites headers, it is acting as both.

Real-world tools

Products like Nginx, HAProxy, Envoy, Traefik, and cloud LBs can often serve as both reverse proxies and load balancers.

Rule of thumb

Ask: Is the main job to manage/protect requests, or to spread traffic?

• manage/protect/request-routing → reverse proxy

• spread traffic across servers → load balancer

• both → often both

Why “the browser” is not one monolith,

Modern browsers, particularly those based on Chromium, have transitioned from monolithic entities to a multi-process architecture. This shift was designed to address the inherent stability and security risks of running all tasks within a single process.

In a multi-process model, the application is divided into several specialized components:

Key Processes in Modern Browsers

• Browser Process: The "privilege" process that coordinates the UI (address bar, bookmarks, back/forward buttons) and manages other processes. It handles network requests and file access.

• Renderer Process: Responsible for everything that happens inside a tab. It transforms HTML, CSS, and JavaScript into a web page the user can interact with. To enhance security, browsers often use site isolation, where each website runs in its own dedicated renderer process.

• GPU Process: Handles graphics tasks across different tabs and the browser UI. Isolating the GPU allows the browser to handle hardware-accelerated tasks without crashing the entire application if a graphics driver fails.

• Plugin/Utility Processes: These handle specific tasks like extensions, network services, or audio decoding.

---

Why the Browser is Not a Monolith

The decision to move away from a monolithic structure is driven by three primary factors:

1. Stability (Fault Tolerance)

In a monolithic browser, a single heavy JavaScript execution or a rendering error on one tab could cause the entire application to "hang" or crash.

• Multi-process benefit: If one renderer process crashes (e.g., a "He's Dead, Jim!" error in Chrome), it only affects that specific tab or site. The rest of the browser and other tabs remains functional.

2. Security (Sandboxing)

A monolith runs with the full privileges of the user. If a website manages to exploit a vulnerability in the rendering engine, it could potentially gain access to the user's entire system.

• Multi-process benefit: Renderer processes are sandboxed. They are stripped of privileges and cannot access the disk or network directly. They must communicate with the Browser Process via Inter-Process Communication (IPC) to perform restricted actions, significantly reducing the "blast radius" of a potential attack.

3. Performance and Responsiveness

A monolith often struggles with resource contention.

• Multi-process benefit: By separating the main thread (handling UI and logic) from the compositor thread (handling the actual drawing of the page), the browser can keep the interface responsive even if a webpage is performing heavy calculations. It also allows the OS to schedule different processes across multiple CPU cores more effectively.

---

Trade-offs: The "Memory Cost"

The primary downside of this architecture is increased memory (RAM) usage. Because each process has its own memory space, common infrastructure (like the V8 JavaScript engine) must be duplicated across multiple processes. Browsers manage this today by "pruning" or sleeping background processes when system memory is low.

Trade-offs of the multi-process model

It is not free.

Costs

• more memory overhead

• more process management complexity

• IPC overhead

• harder debugging across process boundaries

Benefits

• much better security

• much better crash isolation

• better responsiveness

• clearer privilege boundaries

• better scalability for modern web apps

Modern browsers accept the extra complexity because the benefits are worth it.

How sandboxing and site isolation reduce the blast radius of compromised renderers, and

1) The basic process model

Modern browsers are multi-process systems, not one big program. A simplified view looks like this:

• Browser process: the privileged coordinator. It manages tabs, navigation, permissions, storage access, and important security checks.

• Renderer processes: run web content such as HTML, CSS, and JavaScript.

• Other helper processes: often include GPU, network, audio, extension, or utility processes, depending on the browser. Chromium’s design goal is to divide web content into separate OS processes to improve stability, performance, and security. (Chromium Git Repositories)

The key security idea is that web pages are untrusted code. So the browser tries to make sure that if one page’s renderer is exploited, the attacker does not automatically gain control over the whole browser or all other sites. (Chromium Git Repositories)

2) What a compromised renderer means

A compromised renderer is a renderer process where an attacker has found a bug and can execute unintended code inside that process.

Without strong isolation, that can be dangerous because the renderer handles page memory and web logic. If multiple unrelated sites share the same renderer, an attacker may be able to:

• inspect or influence data belonging to another site in the same process,

• abuse the renderer’s existing permissions,

• turn one renderer bug into a much larger browser compromise. (Google Research)

That is the “blast radius” problem: how much damage one compromised renderer can do.

3) How sandboxing reduces the blast radius

Sandboxing limits what a renderer process is allowed to do at the operating-system level.

In Chromium’s sandbox design, sandboxing works at process granularity: a privileged broker/controller process defines policy, and sandboxed target processes run with restrictions. Renderer processes are target processes. When restricted code needs certain actions, requests can be mediated by the broker and checked against policy. (Chromium Git Repositories)

What this means in practice:

• A compromised renderer usually has far fewer OS privileges than the browser process.

• It should not be able to freely read arbitrary local files, install software, or directly perform privileged actions.

• Sensitive actions are pushed through a more trusted component that can say yes or no. (Chromium Git Repositories)

So sandboxing mainly answers this question:

“If the attacker owns the renderer, how much of the machine do they own?”

Ideally, the answer is: very little.

4) How site isolation reduces the blast radius even further

Sandboxing alone is not enough, because a compromised renderer may still access data that already exists inside that renderer’s memory.

That is where site isolation comes in. In Chromium, site isolation aims to keep content from different websites in different renderer processes, and the browser process can enforce rules so a renderer is only allowed to access data for its assigned site. Chromium describes this as using locked renderer processes plus browser-enforced restrictions on what a renderer may request over IPC. (Chromium Git Repositories)

The practical effect:

• If attacker.com is in one renderer and bank.com is in another, compromising the attacker’s renderer should not expose the bank’s page memory.

• Cross-site iframes can also be isolated, so embedding another site does not automatically place both sites in the same renderer.

• The browser process acts as a guardrail and can reject cross-site data access attempts from the wrong renderer. (Chromium Git Repositories)

So site isolation mainly answers this question:

“If the attacker owns one renderer, how much of the web data do they own?”

Ideally, the answer is: only that site’s renderer, not everyone else’s.

5) Sandboxing vs. site isolation

They solve different layers of the problem:

• Sandboxing protects the operating system and browser privileges from the renderer.

• Site isolation protects other sites’ data and memory from that renderer. (Chromium Git Repositories)

A good mental model:

• Sandbox = “You are trapped in a small room.”

• Site isolation = “You are trapped in your own small room, not a room shared with other sites.”

6) Why this mattered even more after Spectre/Meltdown

Process separation became more important after transient-execution attacks such as Spectre and Meltdown, because those attacks showed that code might infer data from other memory in the same process. Google’s site-isolation paper and Mozilla’s Fission write-up both frame process separation as an important defense against that class of threat. (Google Research)

That is a big reason modern browser security architecture moved toward stronger per-site process boundaries.

7) Final takeaway

The shortest checkpoint summary is:

• Browsers assume renderers are likely attack targets.

• Sandboxing makes a compromised renderer low-privilege.

• Site isolation prevents that renderer from sharing a process with unrelated sites.

• Together, they shrink the blast radius from “one renderer bug compromises a lot” to something closer to “one renderer bug compromises one sandboxed site process.” (Chromium Git Repositories)

Where network requests are scheduled and coordinated relative to rendering. 

Browser process model: the short checkpoint

Using Chromium as the concrete reference, the cleanest answer is:

• Network requests are not scheduled “inside rendering.” A renderer can initiate a navigation or a subresource fetch, but the actual network work is mediated by the browser-side networking layer / Network Service, which owns trusted network contexts and can delay request start through its ResourceScheduler.

• Rendering is a separate pipeline. Blink runs document work on the renderer main thread, then commits results to the compositor thread, and finally Viz/GPU aggregates compositor frames and draws them to the screen.

Main processes and what they do

• Browser process: the central coordinator. It manages renderer processes, handles browser UI, and in navigation decides which renderer process should own the new document based on origin, headers, and isolation policy.

• Renderer process: runs the web page logic and most pre-compositing rendering work such as DOM/CSS processing and document lifecycle work up to commit.

• Viz / GPU side: aggregates compositor frames from renderers and the browser UI, then rasters and draws them to the screen.

• Network Service: launched by the browser process; on most platforms it prefers to run out-of-process in a dedicated utility process, though Chromium can also run it in-process in some configurations.

Where network requests are scheduled

• A request may start from navigation, fetch(), an image/script/style discovery, and so on, but the renderer does not directly own the real network stack. Chromium’s network APIs are exposed through Mojo interfaces, with browser/network-side implementations behind them.

• In the modern stack, a consumer talks to a URLLoaderFactory; inside the Network Service this becomes a URLLoader, which then creates a URLRequest from a URLRequestContext.

• This is the key scheduling point: after the URLLoader is created, it calls into network::ResourceScheduler, which may delay starting the request based on priority and other activity before the request actually proceeds.

• The browser-side networking layer also centralizes cookies, cache, connection limits, and session state, which is one reason Chromium keeps network control outside renderers.

Where rendering is scheduled

• Rendering has its own scheduler path, separate from request start scheduling. In Chromium’s compositor architecture, work requests a BeginMainFrame; the scheduler then signals the main thread, Blink runs the document lifecycle, and the result is later committed back to the compositor thread.

• In RenderingNG terms, the renderer main thread handles the document lifecycle up to commit; commit copies display data to the compositor thread; then the compositor and Viz continue the pipeline toward raster and draw.

Relative ordering: network vs rendering

1) Top-level navigation

• After beforeunload, Chromium starts the network request for the new document. Not every navigation hits the network, because Service Workers, cache, WebUI, data: and similar paths can satisfy it differently.

• Response headers are processed first; redirects and some MIME-type decisions are handled before commit.

• Then the response is handed from the network stack to the browser process, which chooses the target renderer and asks it to create the new document. That renderer acknowledgment is the commit point.

• Only after commit does Chromium move into the loading/rendering phase for the page: reading remaining data, parsing, rendering, running scripts, and loading subresources.

2) Subresources after the document exists

• Once a document is loading, Blink may discover scripts, stylesheets, images, fonts, and other resources. Those requests still go through the browser-mediated networking path rather than directly from the renderer to the OS network stack.

• As bytes arrive, the renderer may parse more, update style/layout/paint state, and produce new commits for the compositor. So network and rendering overlap, but they remain distinct subsystems with a handoff boundary between them.

The simplest mental model

• Browser process = policy, orchestration, process selection.

• Network Service = request execution and request-start throttling/scheduling.

• Renderer main thread = parse / DOM / style / layout / paint preparation.

• Renderer compositor thread = compositing, fast scroll/animation coordination.

• Viz / GPU = final aggregation, raster, draw to screen.

One-line conclusion

• Network requests are scheduled on the browser/network side, while rendering is scheduled on renderer/compositor/Viz paths; they are coordinated through IPC and document-commit/loading boundaries, not merged into one single rendering loop.

“What does the renderer do vs the browser process?” 

Browser Process vs. Renderer Process

In a modern browser, these two processes have different jobs:

Browser Process

The browser process is the manager of the whole browser.

It usually handles:

• the UI of the browser

  • tabs

  • address bar

  • back/forward buttons

  • menus

• creating and managing renderer processes

• network requests

• disk access

  • cache

  • cookies

  • downloads

• permissions and security decisions

• communication between different processes

Think of it as the control center.

Renderer Process

The renderer process is responsible for displaying and running a web page.

It usually handles:

• parsing HTML and CSS

• building the DOM and render tree

• layout and painting

• running JavaScript for the page

• handling page-level events

  • clicks

  • input

  • scrolling logic

• updating what the user sees inside the tab

Think of it as the page engine.

---

Simple Analogy

• Browser process = the hotel manager

• Renderer process = the staff inside one room

The manager controls the building and coordinates services.
The staff inside each room only takes care of what happens in that room.

---

Why split them?

This design improves:

• Stability

  • if one page crashes, the whole browser may not crash

• Security

  • web pages run in a more restricted environment

• Performance and isolation

  • pages can be separated from each other

---

Typical Example

When you open a new tab and go to a website:

1. The browser process receives the navigation request.

2. It may start or choose a renderer process for that page.

3. The renderer loads the page content and runs its JavaScript.

4. If the page needs something privileged, it asks the browser process.

For example:

• a page wants network data → often coordinated through browser-side components

• a page wants to access cookies or permissions → browser process decides

• a page updates the DOM → renderer does it

---

In one sentence

• The browser process manages the browser itself.

• The renderer process runs and displays the contents of a web page.

Quick rule of thumb

Ask:

• “Is this about the browser as an application?” → Browser process

• “Is this about one web page’s content and script execution?” → Renderer process

“Why does multiprocess architecture improve security?” 

duplicate

“What is the critical rendering path?” 

1. Browser Process Model

A modern browser is not just one process. It is usually split into multiple processes for stability, security, and performance.

Main process types

• Browser process

  • Controls the whole browser

  • Manages tabs, windows, navigation, address bar, bookmarks

  • Handles coordination between other processes

• Renderer process

  • Renders web pages

  • Parses HTML, CSS, and JavaScript

  • Builds the DOM and layout

  • Usually one or more tabs/sites get separate renderer processes

• GPU process

  • Handles graphics and compositing

  • Helps with accelerated rendering, animations, and video

• Network process

  • Handles network requests

  • Downloads resources such as HTML, CSS, JS, images

• Utility / plugin / extension processes

  • Isolate special tasks

  • Reduce risk if one part crashes

Why multiple processes matter

• Security: one site is isolated from another

• Stability: one crashed tab does not kill the whole browser

• Performance: work can be distributed across CPU cores

---

2. Internal Architecture of Page Rendering

Inside the renderer process, the browser turns web code into pixels on the screen.

Key internal pieces

• HTML parser

  • Reads HTML and builds the DOM tree

• CSS parser

  • Reads CSS and builds the CSSOM

• JavaScript engine

  • Executes scripts

  • Can modify DOM, CSSOM, and page behavior

• Style engine

  • Combines DOM + CSSOM

  • Computes the final styles for each element

• Layout engine

  • Calculates size and position of elements

• Paint

  • Converts visual parts into draw commands

• Compositor

  • Organizes layers and sends them to GPU

  • Produces the final frame shown on screen

---

3. What is the Critical Rendering Path?

The Critical Rendering Path (CRP) is the sequence of steps the browser follows to turn HTML, CSS, and JavaScript into visible pixels on the screen.

Its goal is to display content as quickly as possible.

Core steps

• Parse HTML

  • Browser receives HTML

  • Builds the DOM

• Parse CSS

  • Browser reads CSS files and inline styles

  • Builds the CSSOM

• Build Render Tree

  • Combines DOM and CSSOM

  • Includes only visible elements

• Layout

  • Computes geometry:

    • width

    • height

    • position

  • Also called reflow

• Paint

  • Fills in colors, text, borders, shadows, images

• Composite

  • Combines layers and displays them on screen

---

4. Why CRP is “Critical”

It is called critical because it directly affects:

• First paint

• First contentful paint

• Page load speed

• User-perceived performance

The shorter the path, the faster users see content.

---

5. Important Blocking Factors

Some resources can delay rendering.

CSS is render-blocking

• The browser usually must load and parse CSS before painting

• Because it needs final styles to render correctly

JavaScript can block parsing

• A normal <script> can pause HTML parsing

• The browser may stop building the DOM until the script is downloaded and executed

This happens because JavaScript might change the HTML or CSS before rendering continues.

---

6. Simple Example

Input

• HTML defines structure

• CSS defines appearance

• JS adds logic and may change the page

Browser flow

• Download HTML

• Parse HTML → DOM

• Download and parse CSS → CSSOM

• Execute JS if needed

• DOM + CSSOM → Render Tree

• Layout

• Paint

• Composite to screen

---

7. Easy Memory Version

You can remember CRP like this:

• HTML → DOM

• CSS → CSSOM

• DOM + CSSOM → Render Tree

• Render Tree → Layout

• Layout → Paint

• Paint → Composite

---

8. Interview-Style Answer

Critical Rendering Path is the process the browser uses to convert HTML, CSS, and JavaScript into pixels on the screen. It includes building the DOM, building the CSSOM, creating the render tree, performing layout, painting, and compositing. Its importance is that it determines how quickly content becomes visible to the user.

---

9. One-line Summary

The critical rendering path is the browser’s step-by-step pipeline for turning page code into visible content as fast as possible.

“What does it mean for a change to trigger layout vs paint vs composite only?” 

In the context of the browser’s rendering pipeline, these terms represent different stages of turning code into pixels. The more stages a change triggers, the more "expensive" it is in terms of CPU/GPU resources and potential frame drops (jank).

Here is a breakdown of what each trigger means for performance:

1. Layout (or Reflow)

The "Geometry" Stage

This is the most expensive trigger. When you change a property that affects an element's size, position, or relationship to other elements, the browser must recalculate the geometry for the entire page (or large portions of it).

• What triggers it: Changing properties like width, height, margin, padding, border, top, left, or font-size.

• Impact: The browser must run Layout → Paint → Composite. Because elements affect their neighbors (e.g., increasing a div height pushes everything else down), this can cause a massive chain reaction.

2. Paint

The "Visuals" Stage

If you change a property that doesn't change the element's footprint but does change its appearance, the browser skips layout but must "repaint" the pixels of that element and any elements it overlaps.

• What triggers it: Changing color, background-color, visibility, outline, or box-shadow.

• Impact: The browser runs Paint → Composite. While cheaper than layout, it is still done on the Main Thread in many browsers, which can block user interaction if the paint area is large or complex.

3. Composite Only

The "Layer" Stage

This is the "Golden Standard" for smooth animations (60fps). Some properties can be handled entirely by the GPU on a separate thread (the compositor thread) without needing to re-draw pixels or calculate geometry.

• What triggers it: Only two main properties are guaranteed to be composite-only in most modern browsers: transform (scale, rotate, translate) and opacity.

• Impact: The browser skips Layout and Paint, running only Composite. Since this happens off the main thread, your animations stay smooth even if the main thread is busy executing heavy JavaScript.

---

Comparison Table

Trigger	Cost	Browser Pipeline	Common CSS Properties
Layout	Highest	Layout → Paint → Composite	width, height, margin, flex
Paint	Medium	Paint → Composite	color, background-image, box-shadow
Composite	Lowest	Composite Only	transform, opacity

Pro-Tip for Performance

If you want to move an object across the screen, using left: 10px triggers Layout, while transform: translateX(10px) triggers Composite Only. Always prefer transform and opacity for high-performance animations.

Quick memory trick

Layout = recalculate size and position
Paint = redraw appearance
Composite-only = reuse existing layers and just move/blend them

Ask these in order:

1. Did the element’s size or position in layout change?

   • Yes -> layout

2. Did only its visual appearance change?

   • Yes -> paint

3. Can the browser reuse the painted result and only move/fade it?

   • Yes -> composite-only

“Why might a page look ‘rendered’ but still be loading?” (Good: async requests, lazy-loading, streaming/hydration, long tasks; define ‘rendered’ with metrics.) 

A page can look finished because the browser has already painted something useful to the screen, but many other parts of the page lifecycle may still be in progress.

In modern browsers, “rendered” and “fully loaded” are not the same thing.

---

1. Different browser work finishes at different times

A browser does not do one giant “load page” step. It does many smaller steps, often in parallel:

• Network: download HTML, CSS, JavaScript, images, fonts, API data

• Parsing: read HTML and CSS

• Execution: run JavaScript

• Rendering pipeline: build layout, paint pixels, composite layers

• Post-load work: fetch more resources, hydrate UI, open connections, run timers, analytics, ads, lazy-load content

So the browser may already have enough information to draw the first visible view, even though background work is still happening.

---

2. “Looks rendered” usually means the critical path finished

What you first see is often just the critical rendering path completing enough to show the viewport.

For example:

1. HTML arrives

2. Browser parses it

3. CSS needed for above-the-fold content arrives

4. Layout and paint happen

5. User sees the page

At that point, the browser may still be:

• downloading images below the fold

• fetching web fonts

• executing non-critical JavaScript

• requesting API data

• loading ads, trackers, or analytics

• waiting on deferred or async scripts

So visually, the page appears done, but internally the tab is still busy.

---

3. “Loaded” has multiple meanings

This is one of the biggest reasons for confusion.

DOM is ready

The browser has parsed the HTML into a DOM tree.
This does not mean all images, styles, or scripts are finished.

window.onload

This fires later, when the document and dependent resources are loaded.
But even this may not mean the page is truly “done,” because JavaScript can continue fetching data afterward.

Network quiet / app ready

In modern web apps, the page may only feel truly ready when:

• important API calls finish

• event handlers are attached

• client-side rendering/hydration completes

• main-thread work settles down

So there is no single universal “the page is done” moment.

---

4. Common reasons a page still loads after it looks complete

A. JavaScript is still running

The initial HTML and CSS may already be enough to draw the screen, but JavaScript may still be:

• attaching interactions

• rendering components

• fetching user data

• initializing frameworks

• reconciling virtual DOM

• hydrating server-rendered markup

A page can look correct but still not be fully interactive yet.

B. Resources are still downloading

Browsers prioritize what is needed first. Lower-priority resources may continue afterward:

• images

• fonts

• videos

• iframes

• third-party scripts

• source maps

• prefetch/preload resources

This is especially common on media-heavy pages.

C. Lazy loading

Many sites intentionally delay loading some content until needed.

Examples:

• images only load when near the viewport

• comments load after scroll

• recommendations load after main content

• route chunks load when navigating in an SPA

So the visible shell may be there, while more content is queued.

D. API calls are still in flight

Modern pages often render a skeleton or basic layout first, then fill in real data later.

That means you may see:

• page frame

• placeholders

• buttons

• headers

while actual data such as messages, products, or feed items is still being fetched.

E. Hydration in SSR/CSR hybrids

In frameworks like Next.js or similar architectures, the server may send HTML that the browser can paint immediately.
But then the client JavaScript has to hydrate that HTML so it becomes interactive.

This creates a state where the page looks finished, but part of the app is still booting.

F. Background work never really stops

Some tabs keep ongoing activity:

• analytics beacons

• polling

• WebSocket/SSE connections

• ads

• performance monitoring

• service worker updates

So the loading spinner or network activity may continue even though the main page is already usable.

---

5. From the browser process model perspective

In a browser like Chrome, several processes may be involved:

• Browser process: tab management, navigation, networking coordination, storage, UI

• Renderer process: parse HTML/CSS/JS, layout, paint, run most page scripts

• GPU process: compositing and raster/GPU-related work

• Utility/network-related processes: support services, decoding, etc.

A page may look rendered because the renderer process has already produced displayable frames and the GPU/compositor has shown them.
But other processes may still be working on:

• more network responses arriving

• JS tasks still executing

• image decode

• font decode

• compositing new layers

• iframe/subframe work

• service worker activity

So “pixels are on screen” only means one visible milestone has been reached, not that the entire multi-process system is idle.

---

6. Why this matters in practice

This is why users sometimes say:

• “The page is visible, but buttons don’t work yet”

• “It looks loaded, but scrolling is janky”

• “The spinner in the tab is still spinning”

• “Some text shifts after a second”

• “Images pop in later”

Each symptom points to different unfinished work:

• not interactive yet → JS/hydration/main-thread busy

• layout shifts → fonts/images/late DOM changes

• tab still spinning → network requests still active

• partial content → lazy loading or API fetches

• jank → long JS tasks blocking the main thread

---

7. A good mental model

Think of page load in layers:

1. Can the browser show something?

2. Can the user read it?

3. Can the user interact with it?

4. Has all important data arrived?

5. Has background activity settled?

A page may satisfy step 1 or 2 and therefore look “rendered,” while steps 3–5 are still ongoing.

---

8. One-sentence summary

A page can look rendered but still be loading because the browser can paint an initial visual result before all scripts, resources, data fetches, and background tasks across its processes have finished.

“If the user says ‘the page is slow,’ what metric do you care about?” (Good: distinguish TTFB vs LCP vs INP; use lab + field data.) 

1. “Fully Rendered” — What Does It Mean?

A page is considered fully rendered when the visible content is complete and stable for the user, even if some background resources are still loading.

This does not necessarily mean that every network request has finished. For example:

• Analytics scripts may still load

• Ads may still load

• Background API calls may still happen

From the user's perspective, a page is “ready” when they can see and interact with it without layout shifts or delays.

So “fully rendered” is really about perceived completeness, not technical completion.

---

Key Performance Metrics

2. First Contentful Paint (FCP)

What it measures:
The time from navigation until the browser renders the first piece of DOM content (text, image, canvas, etc.).

Why it matters:

• It tells the user that something is happening

• Reduces the feeling of a blank screen

Example:
If FCP = 1.2 seconds, the user sees initial content after 1.2 seconds.

However, FCP does not mean the page is usable yet.

---

3. Largest Contentful Paint (LCP)

What it measures:
The time when the largest visible element in the viewport finishes rendering.

This is usually:

• a hero image

• a large heading

• a main content block

Why this metric matters most:

If a user says “the page is slow,” LCP is usually the primary metric we care about.

Because it reflects when the main content becomes visible.

Google’s guideline:

• Good: ≤ 2.5 seconds

• Needs improvement: 2.5 – 4 seconds

• Poor: > 4 seconds

---

4. Time to Interactive (TTI)

What it measures:
The time until the page becomes fully interactive.

That means:

• JavaScript is loaded

• Event handlers are ready

• The main thread is free enough to respond to input

Example problem:

• The page looks ready

• But clicking a button does nothing for 2 seconds

This means TTI is slow, even if rendering was fast.

---

5. Total Blocking Time (TBT)

What it measures:
How long the main thread is blocked by long JavaScript tasks between FCP and TTI.

Long tasks (>50ms) prevent the browser from responding to input.

High TBT usually means:

• heavy JavaScript bundles

• synchronous scripts

• expensive computation on the main thread

This metric is a strong indicator of JavaScript performance problems.

---

6. Cumulative Layout Shift (CLS)

What it measures:
Visual stability — how much the layout shifts while loading.

Common causes:

• images without dimensions

• ads loading late

• dynamic content pushing elements down

Example bad experience:

You try to click a button → an ad loads → the button moves.

Good CLS score:

• ≤ 0.1

---

If a User Says “The Page Is Slow”

The most important metric to check first is:

Largest Contentful Paint (LCP)

Because it reflects when the main content appears to the user.

But in practice, you should also check:

1. LCP → main content speed

2. FCP → initial feedback to user

3. TTI / TBT → interactivity delay

4. CLS → visual stability

Together these metrics form Core Web Vitals and related performance signals.

---

Summary

When evaluating whether a web page is slow:

• FCP tells us when users first see content

• LCP tells us when the main content appears (most important)

• TTI / TBT measure when the page becomes responsive

• CLS measures visual stability

A page is effectively “fully rendered” when the main content is visible, stable, and interactive, even if background resources are still loading.

The following metrics are the industry standards for diagnosing what a user actually means by "slow."

---

1. The Critical "Visual" Metric: Largest Contentful Paint (LCP)

If you only care about one metric for perceived speed, it is LCP. It measures when the largest image or text block in the viewport has finished rendering.

• Why it matters: Users perceive a page as "loaded" when the main content appears. A low LCP (under 2.5 seconds) suggests the user isn't staring at a blank screen or a half-finished layout.

• What to look for: If LCP is high, you likely have issues with large hero images, slow server response times (TTFB), or render-blocking CSS/JS.

2. The "Responsiveness" Metric: Interaction to Next Paint (INP)

A page might look ready, but if a user clicks a button and nothing happens for half a second, they will describe the site as "laggy" or "broken." INP replaced First Input Delay (FID) as the gold standard for measuring this.

• The Explanation: INP observes the latency of all interactions (clicks, taps, keyboard presses) a user has with the page and reports the longest duration.

• The Goal: You want an INP of 200ms or less. High INP usually points to a "heavy" main thread—often caused by massive JavaScript bundles executing or long-running tasks that block the browser from reacting to the user.

3. The "Stability" Metric: Cumulative Layout Shift (CLS)

"Slow" is sometimes a user's word for "annoying." If a user is about to click a link but an image loads late and pushes the link down, causing them to click an ad instead, the user experience is ruined.

• Definition: CLS measures the sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page.

• Visual Stability: This isn't about speed, but about predictability. A "stable" page feels faster and more reliable than one that jumps around.

4. The "Backend" Foundation: Time to First Byte (TTFB)

Before the browser can render anything, it has to receive the first byte of data from the server.

• The Bottleneck: If your TTFB is high (e.g., > 1s), no amount of front-end optimization will make the page feel fast. This metric helps you isolate whether the "slowness" is a Networking/Server problem (slow database, no CDN, heavy server-side rendering) or a Browser/Client problem (too much JS, unoptimized images).

If the user says...	You should check...	Because...
"It takes forever to start seeing anything."	TTFB & First Contentful Paint (FCP)	The server or network is likely the bottleneck.
"The headline appears, but the main image is missing."	Largest Contentful Paint (LCP)	Resource prioritization or file size is the issue.
"I click the menu and it takes a second to open."	Interaction to Next Paint (INP)	The JavaScript main thread is overloaded.
"The page is 'jittery' and items move around."	Cumulative Layout Shift (CLS)	Images/Ads don't have defined dimensions.

“How do you break down where time is spent?” (Good: DNS/connection/TLS/TTFB/download from network waterfall + navigation/resource timing). 

When discussing "fully rendered" in a senior technical context, the definition shifts from a single browser event to a spectrum of user-centric metrics. Breaking down where time is spent requires analyzing the Network Waterfall and the Browser Rendering Pipeline.

---

1. The Network and Server Breakdown

Before a single pixel can be drawn, the browser must navigate the "empty" time of network overhead and server processing.

• DNS Resolution: This is the time taken to translate the domain name into an IP address. High latency here often indicates a lack of local caching or a slow recursive resolver.

• Connection & TLS Handshake: For modern sites, this includes the TCP 3-way handshake and the TLS negotiation. In $TLS\ 1.3$, this is significantly faster, but on poor connections, multiple Round Trip Times (RTT) can create a noticeable "stall" before any data is sent.

• TTFB (Time to First Byte): This is a critical metric representing the "Server Think Time." It measures the gap between the browser's request and the arrival of the first byte of the HTML response. A high TTFB usually points to slow database queries, complex server-side rendering (SSR), or a distant origin server without a CDN.

---

2. Document Parsing and Subresource Loading

Once the HTML arrives, the browser begins the "Critical Rendering Path."

• DOM Construction: The browser reads HTML tokens and builds the Document Object Model.

• Render-Blocking Resources: This is where most "slowness" is perceived. By default, synchronous <script> tags and <link rel="stylesheet"> block the parser. The browser cannot render anything until the CSSOM (CSS Object Model) is ready, as it needs to know the styles to calculate the layout.

• Resource Prioritization: The browser's network stack assigns priorities (e.g., "Highest" for CSS, "Low" for images at the bottom of the page). Delays here occur if too many resources compete for the same connection bandwidth, a problem often mitigated by HTTP/2 or HTTP/3 multiplexing.

---

3. The Visual Rendering Pipeline

After the DOM and CSSOM are combined into a Render Tree, the browser begins the actual work of drawing.

• Layout (Reflow): The browser calculates the geometry (position and size) of every visible element. Large, complex DOM trees make this expensive.

• Paint: This is the process of filling in pixels. It involves drawing text, colors, images, and borders.

• Compositing: Modern browsers split the page into "layers." The compositor thread handles moving these layers (like scrolling or CSS transforms) without re-painting the entire screen. Compositor-only changes are the gold standard for 60fps performance because they bypass the expensive Layout and Paint steps.

---

4. Key Performance Metrics (The "User" Perspective)

Standard events like load are often misleading. Instead, we use Core Web Vitals to break down perceived time:

• LCP (Largest Contentful Paint): Measures when the main content (e.g., a hero image or heading) is likely visible. This is the best proxy for "When does the user think the page is loaded?"

• CLS (Cumulative Layout Shift): Measures visual stability. If elements jump around while loading, the "render" feels broken even if it is fast.

• INP (Interaction to Next Paint): Replaces First Input Delay (FID) to measure how long the browser takes to respond to a user's click or keypress after the initial render.

---

Summary Table: Where is the Bottleneck?

If the waterfall shows...	The bottleneck is likely...	Potential Fix
Long green/purple bars before HTML	Network / SSL	Use CDN, Upgrade to TLS 1.3
High "Waiting (TTFB)"	Server-side logic	Database indexing, caching
Long gap between HTML and LCP	Render-blocking assets	Inline critical CSS, defer JS
High CPU usage / Main thread lag	JavaScript execution	Code splitting, Web Workers

How to think about “fully rendered”

“Fully rendered” is not a single browser-defined moment. The W3C Paint Timing spec explicitly says load is not one instant and no single metric captures the whole experience. So the first step is to decide which finish line you care about.

A practical mapping is:

• DOM is ready → DOMContentLoaded / domContentLoadedEventEnd

• All page resources finished loading → loadEventEnd

• Something became visible → FCP

• Main content became visible → LCP

• App is actually ready for the user → often a custom mark plus main-thread analysis, not a built-in browser event.

A clean way to break down where time is spent

For most pages, I would split the time into five buckets.

1. Before the browser gets the first byte

This is the “nothing visible yet, waiting on the initial document” phase. It includes redirects, connection setup, and server response time. In browser timing terms, a key checkpoint is responseStart, which is when the browser has received the first byte of the response. Resource/Navigation Timing also expose lower-level timestamps such as DNS, connect, requestStart, responseStart, and responseEnd.

If this bucket is large, the problem is usually backend / CDN / redirect / connection / cache miss, not rendering. A useful mental model is:

time to first byte = waiting before responseStart.

2. HTML arrives, but the page is still being built

After the first byte arrives, the browser still has to download the HTML, parse it, build the DOM, discover subresources, and run any blocking work. domInteractive is the point where DOM construction has finished and interaction with the DOM is possible; domContentLoadedEventEnd is immediately after the DOMContentLoaded handlers complete.

If this phase is large, think about HTML size, parser-blocking scripts, blocking CSS, and heavy work tied to DOMContentLoaded.

3. Critical resources are not ready yet

Once the browser discovers CSS, fonts, scripts, and the main image/text resource, you want to see when those requests actually started and how long they took. Resource Timing is the right API for this, and DevTools’ Network waterfall is the easiest visual view. For individual resources, requestStart → responseStart shows request wait time, and fetchStart → responseEnd shows total fetch time for the final resource.

This bucket is where you separate two very different problems:

• Late request start → discovery / prioritization problem

• Long request duration → network / transfer size / caching problem

4. The resource is loaded, but the user still does not see it

This is the part many teams miss. web.dev breaks LCP into four subparts:

• TTFB

• resource load delay

• resource load duration

• render delay

That decomposition is extremely useful. If your LCP resource finished downloading but LCP is still late, then the lost time is usually render delay: JavaScript is busy, CSS/layout is blocking, the element is hidden, or the browser has not painted it yet.

A very practical formula is:

time to main content visible (roughly LCP)
= TTFB + resource load delay + resource load duration + render delay

5. The page looks visible, but the main thread is still busy

A page can be “painted” and still feel slow. Long Tasks are tasks that keep the UI thread busy for 50 ms or more, and they are a strong signal for poor responsiveness, delayed interactivity, jank, or expensive re-renders.

This is where the Chrome DevTools Performance panel matters most. Its Main track / flame chart shows the call stack over time, selected-event duration, self time, stack trace, and can separate first-party from third-party work. Long tasks are explicitly highlighted.

So if “rendered” looks late even after the network finished, inspect the main thread for:

• heavy JavaScript

• hydration/client boot

• style recalculation

• layout

• paint/compositing

• third-party scripts

The simplest decision tree

When you profile a page, ask these questions in order:

• Is the delay mostly before responseStart?
  Then it is mostly server / CDN / redirect / connection time.

• Did the critical image/CSS/script start late?
  Then it is a discovery or prioritization issue.

• Did it start on time but download slowly?
  Then it is transfer size, caching, or network.

• Did it download on time but paint late?
  Then it is render delay: main-thread work, CSS/layout, hidden element, or delayed reveal.

• Did it paint, but the page still feels sluggish?
  Then look for long tasks and runtime work in the Performance flame chart.

What I would use in practice

For a normal webpage, I would measure in this order:

1. Navigation Timing for the main document milestones.

2. Resource Timing for CSS, JS, fonts, hero image, API calls.

3. Paint Timing / FCP for first visible pixels.

4. LCP for “main content visible”.

5. Long Tasks + DevTools Performance for blocked main thread and render delay.

6. Custom performance.mark() / measure() for your own app-ready milestone if built-in browser milestones are not enough.

Bottom line

The best breakdown is not “network vs render” only. It is:

server / connection → HTML parse → critical resource discovery → resource download → render delay → main-thread/runtime work. That model maps cleanly to the browser’s timing APIs and to what you see in DevTools.