Web Fundamentals: Deep Notes

The "do you actually understand how the browser works" round. Five buckets: rendering pipeline, critical rendering path, the event loop, CSS, and HTTP. The rendering pipeline overlaps heavily with the performance round, so getting it right here pays off twice.

---

1. Browser Rendering Pipeline — URL to Pixels

When you type a URL and hit enter, here's the full journey. Interviewers love asking you to narrate this end-to-end, so have the sequence memorized and be able to expand on any single step.

The Network Phase

1. DNS resolution — The domain name gets resolved to an IP address. The browser checks its own cache, then the OS cache, then asks a DNS resolver, which walks the root → TLD → authoritative name servers if needed.
2. TCP handshake — A connection is established via the three-way handshake (SYN → SYN-ACK → ACK).
3. TLS handshake — For HTTPS, certificates are exchanged and a session key is negotiated so traffic is encrypted.
4. HTTP request — The browser sends a GET request for the HTML document. The server responds with HTML.

The Rendering Phase

Once the HTML bytes start arriving, the browser begins building the page:

HTML bytes → tokens → nodes → DOM tree
CSS bytes  → tokens → nodes → CSSOM tree
DOM + CSSOM → Render Tree → Layout → Paint → Composite

• DOM construction — The HTML parser converts bytes into tokens, tokens into nodes, and nodes into the DOM (Document Object Model) tree. This is the structural representation of the page.
• CSSOM construction — CSS is parsed into the CSSOM (CSS Object Model), which holds all computed style information and cascades down the tree.
• Render tree — The browser combines the DOM and CSSOM into the render tree. This contains only the nodes that will be visible. Nodes with display: none are excluded. Note: visibility: hidden nodes are included — they just are not painted. A common gotcha.
• Layout (reflow) — The browser calculates the exact size and position of every node — its geometry. Output is the box model coordinates for each element.
• Paint — The browser fills in the pixels: text, colors, borders, shadows, images. This produces paint records and layers.
• Composite — Layers are drawn to the screen in the correct order. The compositor thread handles this on the GPU, which is why transform and opacity animations are cheap.

Reflow vs Repaint — The High-Yield Distinction

This is the question that connects directly to the performance round. Know exactly what triggers each.

Reflow (Layout) recalculates geometry (size, position). It is expensive and can cascade to children and ancestors. Triggered by: changing width, height, margin, padding, top, left, font size, adding or removing DOM nodes, or reading layout properties like offsetHeight. A reflow always implies a repaint follows it.

Repaint redraws pixels without changing layout. Cheaper than reflow, but still not free. Triggered by: changing color, background-color, visibility, box-shadow. Does NOT trigger reflow.

The cheapest changes of all — transform and opacity — skip both layout and paint and happen purely on the compositor. That is the answer to "how do you make a smooth 60fps animation."

Layout thrashing is the classic anti-pattern: interleaving DOM reads and writes in a loop, forcing the browser to reflow repeatedly.

JSfile.js
1// BAD — forces a reflow on every iteration
2for (let i = 0; i < boxes.length; i++) {
3  boxes[i].style.width = boxes[i].offsetWidth + 10 + 'px'; // read forces sync layout
4}
5
6// GOOD — batch reads, then batch writes
7const widths = boxes.map(b => b.offsetWidth); // all reads first
8boxes.forEach((b, i) => {
9  b.style.width = widths[i] + 10 + 'px';     // all writes after
10});

---

2. Critical Rendering Path & Render-Blocking Resources

The critical rendering path is the sequence of steps the browser must complete to render the initial view. Optimizing it means getting meaningful content on screen as fast as possible.

Why CSS Is Render-Blocking

The browser will not paint anything until the CSSOM is built. If it painted before the CSSOM was ready, you would get a flash of unstyled content followed by a re-layout. So CSS blocks rendering by design. The takeaway: ship critical CSS small and fast, and defer non-critical CSS.

Why Scripts Are Parser-Blocking

When the parser hits a plain <script>, it stops DOM construction, fetches the script (if external), executes it, and only then resumes parsing. This is because scripts can call document.write or manipulate the DOM. Worse, a script will wait for any in-progress CSSOM build to finish before executing, since scripts can read computed styles.

This is why script placement and the async/defer attributes matter:

HTMLindex.html
1<!-- Blocks parsing while fetching AND executing. -->
2<script src="app.js"></script>
3
4<!-- async: fetched in parallel, executes as soon as ready (may interrupt parsing).
5     Order NOT guaranteed. Good for independent scripts like analytics. -->
6<script async src="analytics.js"></script>
7
8<!-- defer: fetched in parallel, executes only after HTML parsing completes,
9     in document order. Best default for app scripts that need the DOM. -->
10<script defer src="app.js"></script>

defer for scripts that touch the DOM and depend on order. async for fire-and-forget third-party scripts. Put any remaining blocking scripts at the end of <body>.

Optimizing the Critical Path — Three Levers

1. Reduce the number of critical resources — inline critical CSS, defer the rest, lazy-load below-the-fold scripts.
2. Reduce critical bytes — minify, compress (gzip/Brotli), tree-shake.
3. Reduce round trips — use a CDN, preconnect to required origins, use HTTP/2.

---

3. The Event Loop

JavaScript is single-threaded, yet it handles async work without blocking. The event loop is the mechanism. This is one of the most-asked topics — expect an output-prediction question.

The Moving Parts

• Call stack — Where synchronous code runs, LIFO. One frame at a time.
• Web APIs — Browser-provided (timers, fetch, DOM events). These run off the main thread. When done, they hand a callback to a queue.
• Macrotask queue — Holds callbacks from setTimeout, setInterval, I/O, UI events.
• Microtask queue — Holds callbacks from resolved Promises (.then/.catch/.finally), queueMicrotask, and MutationObserver.

The Golden Rule

After each macrotask, and after the current synchronous code finishes, the event loop drains the entire microtask queue before picking up the next macrotask. Microtasks always jump the line ahead of the next timer callback.

The Classic Question

JSfile.js
1console.log('1: sync start');
2
3setTimeout(() => console.log('2: setTimeout'), 0);
4
5Promise.resolve()
6  .then(() => console.log('3: promise then'))
7  .then(() => console.log('4: promise then 2'));
8
9console.log('5: sync end');

Output:

1: sync start
5: sync end
3: promise then
4: promise then 2
2: setTimeout

Synchronous logs (1, 5) run first and empty the call stack. Then the microtask queue drains — both .then callbacks (3, 4) run before control returns to the event loop. Only then does the macrotask (2: setTimeout) get picked up, even though its delay was 0.

A harder variant mixes async/await — code after an await becomes a microtask:

JSfile.js
1async function foo() {
2  console.log('A');
3  await null;
4  console.log('B'); // runs as a microtask
5}
6console.log('start');
7foo();
8console.log('end');
9// Output: start, A, end, B

---

4. CSS Fundamentals

Frequently underprepared because people assume it is "easy" — which is exactly why it gets asked. Have crisp answers for these.

The Box Model

Every element is a box: content → padding → border → margin.

The default box-sizing: content-box means width only sets the content width; padding and border add on top. Almost every codebase resets to border-box so width includes padding and border:

CSSstyles.css
1*, *::before, *::after {
2  box-sizing: border-box;
3}

Specificity

When multiple rules target the same element, specificity decides the winner. Score it as (inline, IDs, classes/attributes/pseudo-classes, elements/pseudo-elements):

• div — 0,0,0,1
• .btn — 0,0,1,0
• #header — 0,1,0,0
• style="..." (inline) — 1,0,0,0
• !important — overrides everything (avoid)

Higher tuple wins. Ties go to whichever comes last in source order.

Flexbox vs Grid

• Flexbox — one-dimensional (a row or a column). Best for distributing items along a single axis: navbars, button groups, centering.
• Grid — two-dimensional (rows and columns together). Best for page layouts and any explicit grid.

CSSstyles.css
1/* Center anything — the interview favorite */
2.center {
3  display: flex;
4  justify-content: center; /* main axis */
5  align-items: center;     /* cross axis */
6}

Positioning

• static — default, in normal flow.
• relative — offset from its normal position; still occupies original space; establishes a positioning context.
• absolute — removed from flow; positioned relative to the nearest positioned ancestor.
• fixed — positioned relative to the viewport; stays on scroll.
• sticky — hybrid: acts relative until a scroll threshold, then sticks.

Stacking Context

z-index only works on positioned elements (and flex/grid children). A new stacking context is created by: a positioned element with a z-index other than auto, any element with opacity < 1, transform, filter, or will-change. Children are stacked within their parent's context — so a child with z-index: 9999 can still sit behind another element if its parent's context is lower. This trips up a lot of people debugging "why won't my modal come to the front."

---

5. HTTP Basics

Methods

• GET — read, safe, idempotent
• POST — create, not idempotent
• PUT — replace, idempotent
• PATCH — partial update
• DELETE — idempotent

"Safe" means no side effects. "Idempotent" means repeating it yields the same result.

Status Codes

• 2xx Success — 200 OK, 201 Created, 204 No Content
• 3xx Redirect — 301 Moved Permanently, 302 Found, 304 Not Modified
• 4xx Client error — 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests
• 5xx Server error — 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable

Know the 401 vs 403 distinction: 401 means not authenticated, 403 means authenticated but not allowed. Know what a 304 means: your cached copy is still valid.

Caching Headers

• Cache-Control — the primary control. max-age=3600 (cache for an hour), no-cache (must revalidate before using — not "do not cache"), no-store (never cache), public/private, immutable.
• ETag — a fingerprint of the resource. On the next request the browser sends If-None-Match: <etag>; if unchanged the server returns 304 Not Modified with no body.
• Last-Modified — a timestamp; paired with the If-Modified-Since request header. ETag is more precise and preferred when both exist.

HTTPfile.http
1# Server response
2Cache-Control: max-age=86400
3ETag: "abc123"
4
5# Browser revalidation on next visit
6GET /style.css
7If-None-Match: "abc123"
8
9# Server replies (file unchanged) — no body re-sent
10HTTP/1.1 304 Not Modified

CORS — How Preflight Works

The same-origin policy blocks a page from reading responses from a different origin (scheme + host + port). CORS is the controlled relaxation of this.

For "non-simple" requests (custom headers, methods like PUT/DELETE, or certain content types), the browser first sends an automatic preflight OPTIONS request asking the server what it permits:

HTTPfile.http
1# Preflight (sent automatically by the browser)
2OPTIONS /api/data
3Origin: https://app.example.com
4Access-Control-Request-Method: PUT
5Access-Control-Request-Headers: Authorization
6
7# Server's response granting permission
8Access-Control-Allow-Origin: https://app.example.com
9Access-Control-Allow-Methods: GET, PUT, POST
10Access-Control-Allow-Headers: Authorization

Only if the server's response approves does the browser send the actual request. Key framing: CORS is enforced by the browser, not the server — the server can respond, but the browser blocks the page from reading the response if the headers do not allow it. This is not a protection mechanism for your server — it is a protection mechanism for users' browsers.

HTTP/1.1 vs HTTP/2 vs HTTP/3

• HTTP/1.1 — one request at a time per connection (with head-of-line blocking). Browsers open ~6 parallel connections per origin to compensate. Plain text headers.
• HTTP/2 — multiplexing: many requests and responses share a single connection concurrently, interleaved as streams. Adds header compression (HPACK) and server push. Solves application-layer head-of-line blocking, but TCP-level HOL blocking remains.
• HTTP/3 — runs over QUIC (built on UDP) instead of TCP. Eliminates TCP head-of-line blocking entirely — a lost packet on one stream no longer stalls the others. Also has faster connection setup with the TLS handshake folded in.

---

Two Framings Worth Memorizing

"Walk me through what happens when I type a URL and press enter."

DNS → TCP → TLS → HTTP request → server responds with HTML → parse HTML into DOM, fetch and parse CSS into CSSOM → build render tree → layout → paint → composite. Scripts can pause parsing; CSS blocks rendering. Mention defer/async and the critical rendering path as optimizations.

"What is the difference between reflow and repaint?"

Reflow recalculates geometry, is expensive, and can cascade. Repaint just redraws pixels and is cheaper. transform/opacity skip both and run on the compositor — that is how you get smooth animations. Avoid layout thrashing by batching DOM reads before writes.