Octet

Say this first

The browser checks HSTS and its caches, then resolves the name: its own cache, the OS stub resolver, then a recursive resolver that walks root, TLD and authoritative servers for A, AAAA and HTTPS records. It races IPv6 and IPv4 connections (Happy Eyeballs). The host sees the address is off-subnet, ARPs for its default gateway's MAC and sends the SYN there; NAT at the edge rewrites the source, and BGP-routed paths carry it to the nearest edge, often a CDN. TCP and TLS 1.3 handshakes (or one QUIC handshake) follow, with SNI, ALPN and certificate validation. Then the HTTP request goes through load balancers to the application, the response comes back under slow start, and the browser parses, fetches subresources and renders.

Go deeper

1. Before any packet

Parse the URL. HSTS or the preload list may force HTTPS for http:// links.
Check the HTTP cache and service worker; reuse an open connection to the same origin if one exists.

2. Name resolution

Browser DNS cache, then the OS (hosts file, then the stub resolver), then the configured recursive resolver over UDP 53 or encrypted DNS.
On a cache miss the resolver asks a root server for .com, a .com TLD server for example.com, and the authoritative server for the A, AAAA and HTTPS records. TTLs govern caching at each step.
An HTTPS record can announce alpn="h3,h2" and keys for Encrypted Client Hello.

3. Getting the first packet out

The destination is off-subnet, so the frame goes to the default gateway. ARP (IPv4) or neighbor discovery (IPv6) finds its MAC if not cached.
Happy Eyeballs (RFC 8305) starts IPv6 first and IPv4 after a short delay, about 250 ms, and keeps whichever connects first.
The edge firewall does PAT: a private source like 192.168.1.20:51544 becomes a public address and port.
Routers forward hop by hop on longest prefix match; across providers, BGP chose the path. The service is often anycast, so the nearest CDN site answers.

4. Transport and security

TCP: SYN with MSS, window scale, SACK and timestamps, then SYN-ACK and ACK: one RTT.
TLS 1.3: ClientHello with SNI shop.example.com, ALPN h2,http/1.1 and a key share; the server returns its certificate chain encrypted; the client validates the chain and the name: one more RTT.
Or, if HTTP/3 was advertised: one QUIC handshake on UDP 443 covers both.

5. The request and the server side

HTTP/2 GET / with :authority, cookies and Accept-Encoding, compressed with HPACK.
A CDN may answer from cache. Otherwise a layer 7 load balancer terminates TLS, picks a healthy backend, and the application talks to caches and databases.

6. The response and rendering

Status and headers (Cache-Control, Set-Cookie, Strict-Transport-Security, Alt-Svc), then a compressed body.
The first flight is limited by the initial congestion window of 10 segments, about 14.6 KB.
The browser parses HTML, finds CSS, JavaScript and images, fetches them over the same multiplexed connection, builds the DOM and CSSOM, lays out and paints.

7. Afterwards

The connection stays open for reuse. When it finally closes, whichever side sends the first FIN holds TIME_WAIT.

They will ask next

Where would you look if the page is slow but only for the first visit?
Cold caches on every layer: DNS lookups that walk the hierarchy, new TCP and TLS handshakes, slow start on a fresh connection, and an empty browser and CDN cache. curl -w with time_namelookup, time_connect, time_appconnect and time_starttransfer splits the delay.
Where does the MAC address of the web server come into this?
It does not. The client only learns its gateway's MAC. Each router hop rewrites the layer 2 header; the IP addresses stay the same end to end apart from NAT.
What changes if the browser already has an HTTP/2 connection to the site?
No DNS lookup, no TCP or TLS handshake, and a warm congestion window: the request goes out at once as a new stream on the existing connection.

Traps

Saying the client ARPs for the web server's IP. It ARPs for the default gateway.
Skipping certificate validation and congestion control. That is where a deep answer stands out.

How did you do?Book 9.3 Infrastructure Applications Book 9.1 Traditional Applications Book 5.2 Reliable Byte Stream (TCP)