What Happens When You Enter google.com in a Browser?

(Medium-Depth Explanation with Bullet-Point Summary)

1 Overview
When a user types https://google.com (or just google.com) into a browser, a sequence of steps
spans from URL parsing and cache checks on the client side, through DNS resolution, network
transport (TCP/TLS), the HTTP request/response exchange, server-side processing in Google’s
global infrastructure, and finally browser rendering. Below is a concise yet comprehensive description
of these phases, followed by a crisp bullet-point summary.

2 Browser Initialization & Caching

2.1 URL Parsing
• The browser normalizes the input: missing scheme implies https://; HSTS forces HTTPS for
google.com.

• The URL is split into: scheme (https), host (google.com), port (default 443), and path (/).

2.2 Client-Side Caches

• DNS Cache: The browser checks its in-memory DNS cache (and then the OS resolver cache)
for a recent A/AAAA record of google.com.

• HTTP Cache: If a previous visit exists, the browser checks whether it can reuse a cached HTML
resource or must revalidate via If-None-Match (ETag) or If-Modified-Since.

If caches miss, the browser triggers a fresh DNS lookup.

3 DNS Resolution
3.1 Local and Recursive Resolver
• The browser calls the OS stub resolver (e.g., getaddrinfo), which checks the local hosts file and
then the OS DNS cache.

• If not found locally, the stub forwards the query to a recursive DNS server (e.g., ISP or public
DNS).

3.2 Iterative Lookup (Root → TLD → Authoritative)

1. Root Servers respond with referrals to .com TLD servers.

2. .com TLD Servers provide referrals to Google’s authoritative name servers (ns1.google.com,
etc.).

3. Google Authoritative Servers return one or more A/AAAA records (e.g., 142.250.x.x),
along with a TTL (e.g., 300 s).

1
 Each resolver along the chain caches intermediate responses according to the TTL. Once the
browser has an IP, it proceeds to establish a TCP connection.

4 TCP Connection Establishment

4.1 ARP & Ethernet
• The browser’s OS checks its ARP cache for the MAC address of the local gateway (router). If
not found, it broadcasts an ARP request.

• Once the MAC address is known, the client can send IP packets toward the gateway (and ulti-
mately to Google’s server) over Ethernet or Wi-Fi.

4.2 TCP Three-Way Handshake

1. Client → Server (SYN): The client sends a TCP segment with the SYN flag and an initial
sequence number.

2. Server → Client (SYN-ACK): Google’s server responds with SYN+ACK, acknowledging the
client’s SYN.

3. Client → Server (ACK): The client sends an ACK, completing the handshake.

During this exchange, TCP options such as MSS, Window Scale, SACK, and Timestamps are
negotiated. The connection then enters the established state.

5 TLS Handshake (HTTPS)

5.1 Purpose of TLS
• Provides encryption (confidentiality), integrity, and server authentication.

• Uses X.509 certificates, where google.com presents a certificate chain signed by a trusted CA.

• HSTS (HTTP Strict Transport Security) ensures the browser does not downgrade to HTTP.

5.2 TLS 1.3 Handshake Steps

1. ClientHello: The client proposes TLS 1.3, lists supported cipher suites, and includes a random
nonce and SNI extension (google.com).

2. ServerHello: The server selects a cipher suite, returns its random nonce and ephemeral public
key (KeyShare).

3. Certificate & CertificateVerify: The server sends its certificate chain (e.g., *.google.com)
and a signature over earlier handshake messages.

4. Client Finished: The client verifies the server certificate (chain of trust, domain match, validity
date) and sends a Finished message.

5. Server Finished: The server responds with its Finished message.

2
At this point, both sides derive symmetric keys for encrypting application data. If session resumption
is possible, the client may use a pre-shared session ticket (0-RTT) to send early data (e.g., HTTP
GET) on the first flight.

6 HTTP Request & Server Processing

6.1 HTTP/2 over TLS
• Most modern browsers and Google’s servers use HTTP/2 (binary framing, multiplexing).

• The client sends an initial SETTINGS frame, and then a HEADERS frame on Stream 1 containing
pseudo-headers:

:method = GET
:scheme = https
:authority = google.com
:path = /
user-agent = Mozilla/5.0 ...
accept = text/html,...
accept-encoding = gzip, br

• No request body is sent (END_STREAM flag set).

6.2 Google’s Edge Infrastructure

• Anycast IP: The IP for google.com is announced from multiple Google edge locations worldwide.
BGP routes the client’s packets to the nearest PoP (point of presence).

• Edge Load Balancer: Terminates TLS (often via specialized hardware), then proxies the de-
crypted HTTP/2 request to a local front-end server cluster.

• Cache Check: If the homepage HTML is cached in the edge, it can send a cached response;
otherwise, it forwards to a search-frontend service.

• Front-End Server: Composes the HTML (e.g., localized template, search box), sets appropriate
response headers (e.g., Cache-Control: private, max-age=0), compresses with Brotli, and
sends back the HTTP/2 HEADERS+DATA frames.

7 HTTP Response & Transport Details

7.1 Response Headers
• :status = 200

• content-type: text/html; charset=UTF-8

• content-encoding: br (Brotli-compressed)

• cache-control: private, max-age=0, no-cache (forces revalidation)

• set-cookie: NID=...; Secure; HttpOnly; SameSite=Lax

3
7.2 TCP/TLS Flow Control
• The server’s TLS layer splits the compressed HTML into TLS records, which are sent in TCP
segments.

• The client’s TCP stack acknowledges received segments; congestion control (Slow Start → Con-
gestion Avoidance) adjusts the send window.

• Once all HTML bytes are received and acknowledged, the TCP connection remains open (Keep-
Alive) for 90 seconds, allowing subresource requests to reuse it.

8 Browser Rendering Pipeline

8.1 HTML Parsing & DOM Construction
• The browser’s HTML parser incrementally parses the received HTML and builds a DOM tree.

• Encountering a <link rel="stylesheet"> triggers a fetch (over the same HTTP/2 connection)
for CSS; the parser may wait (render-blocking) until critical CSS arrives if needed.

• <script> without async/defer blocks parsing until the script is fetched and executed; async/defer
scripts allow parsing to continue.

8.2 CSS Parsing & CSSOM

• The browser fetches and parses CSS (e.g., main.css), building the CSSOM.

• Style recalculation happens once CSS is available: each DOM element is matched against CSS
selectors to compute its styles.

8.3 Render Tree, Layout, Paint & Compositing

• Render Tree: Merges DOM and CSSOM, creating a tree of renderable nodes (excluding display:none
elements).

• Layout (Reflow): Computes geometry (width, height, position) for each render node based on
the CSS box model, flex, grid, etc.

• Paint: Each render node is drawn into GPU layers (bitmaps), including text, backgrounds,
borders, and images.

• Compositing: The GPU compositor merges layers into final screen pixels.

8.4 JavaScript Execution & Events

• DOMContentLoaded fires after the HTML is fully parsed (but before images/fonts finish loading).

• window.onload fires after all subresources (images, fonts, CSS) are fully loaded.

• The event loop processes microtasks (Promise callbacks) between rendering frames; forced reflows
(e.g., reading offsetWidth) can stall rendering.

4
9 Subresource Fetching & Caching
9.1 Additional Resources
• Images (Logo): Fetched via HTTP/2 on the same connection; served with long TTL (e.g.,
Cache-Control: public, max-age=86400, immutable).

• JavaScript Bundles: May load additional JS modules dynamically; each uses the existing
connection or opens new ones if cross-origin (e.g., fonts.gstatic.com).

• Web Fonts: Trigger DNS → TCP → TLS → HTTP to fonts.gstatic.com, then download a
WOFF2 (Brotli-compressed) font file; fonts may cause FOIT/FOUT.

9.2 Browser Connection Management

• HTTP/1.1: Historically limited to 6 parallel TCP connections per origin (not relevant for
Google since it uses HTTP/2).

• HTTP/2 Multiplexing: All subresources for google.com share the same TCP/TLS connection,
with multiple concurrent streams (no head-of-line blocking at HTTP layer).

• HTTP/3 (QUIC): If supported, the browser may use QUIC over UDP, combining TLS 1.3 with
multiplexed streams and 0-RTT resumption, reducing handshake overhead.

10 Metrics & Monitoring

• Navigation Timing API: Captures timestamps for DNS lookup, TCP connect, TLS handshake,
request start/response start, DOMContentLoaded, and load events.

• Web Vitals: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), First Input Delay
(FID) are measured and reported via navigator.sendBeacon() or XHR.

• Error Reporting: JS runtime errors or network failures are logged to Google’s telemetry services
for real-user monitoring (RUM).

11 Bullet-Point Summary
1. URL Parsing & Caching

– Browser normalizes google.com to https://google.com/ (HSTS).

– Checks browser DNS cache, then OS resolver cache; checks HTTP cache for previous HTML
or resources.

2. DNS Resolution

– Stub resolver checks hosts file & OS cache; if missing, queries recursive DNS.
– Recursive lookup: root → .com TLD → Google’s authoritative servers → returns IP(s) (e.g.,
142.250.x.x).
– Caches intermediate results (TTL-based).

3. TCP Handshake

5
 – Client sends SYN; server replies SYN-ACK; client replies ACK.
– Negotiates TCP options (MSS, window scaling, SACK, timestamps).

4. TLS Handshake (HTTPS)

– ClientHello (TLS 1.3, SNI=google.com, supported ciphers).

– ServerHello (chooses cipher, sends certificate chain, key share).
– Client verifies certificate (chain of trust, domain, validity), sends Finished.
– Server sends Finished; symmetric keys established for encrypted data.
– Possible 0-RTT resumption with session ticket for faster reconnects.

5. HTTP Request (HTTP/2)

– Browser opens HTTP/2 session (SETTINGS exchange) on the TLS connection.

– Sends HEADERS frame: :method=GET, :scheme=https, :authority=google.com, :path=/,
plus standard headers (user-agent, accept, accept-encoding).
– Marks END_STREAM; no request body.

6. Server-Side Processing

– Anycast IP routes packet to nearest Google edge PoP.

– Edge load balancer terminates TLS, checks cache; if miss, forwards to front-end server cluster.
– Front-end server composes HTML (search box, localized template), compresses with Brotli, sets
response headers (e.g., Cache-Control: private, max-age=0), and responds via HTTP/2.

7. HTTP Response & Transport

– Server sends HEADERS (:status=200, content-type, content-encoding, cache-control,

set-cookie).
– Brotli-compressed HTML is sent in DATA frames over HTTP/2.
– TCP acknowledges segments; flow/congestion control adjusts the send window.
– Connection remains open (Keep-Alive) for 90 s to fetch subresources.

8. Browser Rendering

– Incremental HTML parsing builds the DOM.

– Encountering <link> triggers CSS fetch; CSS parsing builds CSSOM; style recalculation oc-
curs.
– <script> tags (unless async/defer) block parsing until JS executes.
– DOM + CSSOM → Render Tree → Layout → Paint → Compositing.
– DOMContentLoaded fires when DOM is ready; window.onload fires when all subresources finish
loading.

9. Subresource Fetching & Caching

– Images (logo), JS bundles, and fonts are fetched over HTTP/2 (same connection) or new
connections if cross-origin.

6
 – Static assets get long TTL (Cache-Control: public, max-age=86400, immutable); home-
page HTML gets revalidated each load.
– HTTP/2 multiplexes multiple streams on one TCP; HTTP/3 (QUIC) may be used if sup-
ported, combining TLS 1.3 with UDP.

10. Metrics & Monitoring

– Browser records timing (DNS, TCP, TLS, TTFB, DOMContentLoaded, load) via the Naviga-
tion Timing API.
– Web Vitals (LCP, CLS, FID) are measured and reported for performance analytics.
– Errors or performance issues are logged via beacons or XHR to Google’s telemetry endpoints.

End of Document