Browser, HTTP & networking

Browser, HTTP & networking

The platform underneath every framework — how browsers turn bytes into pixels, how HTTP and caching work, what fetch, CORS and cookies actually do, what browser storage and service workers offer, and which web APIs a senior should know by name.

Frameworks abstract the platform; interviews check whether you can see through the abstraction. "Why is this page slow to first paint", "why does this request fail in the browser but work in curl", "why did the user see a stale page", "where does this data survive" are platform questions with platform answers. Nuxt's rendering, caching and cookie helpers all sit on the mechanisms described here.

Know

  • Rendering is a pipeline: parse HTML while a preload scanner fetches resources, build the CSSOM (render-blocking), compute style, layout, paint, composite; scripts block parsing unless deferred; long tasks block input; and the Core Web Vitals (LCP, INP, CLS) measure the user's experience of it (how browsers render).
  • HTTP moved to multiplexed connections (HTTP/2, HTTP/3 over QUIC) and caching is the biggest performance lever you control: Cache-Control directives, validators, Vary, CDN behaviour, immutable hashed assets, resource hints and early hints (HTTP and caching).
  • fetch, CORS and cookies are where "works locally, fails in production" lives: preflights, credentials, SameSite, HttpOnly, and the fact that CORS protects users, not servers (fetch, CORS and cookies).
  • Storage and offline capabilities range from localStorage to IndexedDB, the Cache API, OPFS and service workers, each with quotas, eviction rules and SSR implications (storage and offline).
  • Web APIs worth knowing by name include the observers, the Page Lifecycle and bfcache, the Performance APIs behind the vitals, crypto.subtle, the Navigation and View Transitions APIs, and the Speculation Rules that make navigations instant (web APIs).

How the pages fit

PageQuestion it answers
How browsers render"What happens between the HTML arriving and the first pixel, and why is INP bad?"
HTTP and caching"Design the caching for a Nuxt site" and "what does stale-while-revalidate mean?"
Fetch, CORS and cookies"Why is this request blocked?" and "which cookie flags do you set?"
Storage and offline"Where do you store this, and how does a service worker update?"
Web APIs worth knowing"Which platform API would you use for …?"

How it works

A request for a Nuxt page, end to end, with the platform mechanisms named:

1. DNS → TCP → TLS 1.3 (or QUIC for HTTP/3); `preconnect` hints can warm this for a second origin.
2. GET /products/42 with cookies (SameSite=Lax) and Accept-Encoding: br, zstd, gzip.
3. CDN checks its cache key (URL + Vary headers). MISS → Nitro renders; `swr` route rule → cached at the CDN for 5 minutes.
4. Response: 200, Content-Type text/html, Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=60, Link: preload hints (or 103 Early Hints).
5. Browser: tokenises HTML; the preload scanner fetches /_nuxt/*.js and .css (immutable, cached for a year by hash).
6. CSS blocks render; module scripts are deferred; CSSOM + DOM → style → layout → paint → composite: first paint, then LCP when the hero image lands (fetchpriority=high).
7. Hydration runs as tasks; if one exceeds 50 ms it delays the first click: INP.
8. Later navigation: NuxtLink prefetch (or Speculation Rules) fetched the next chunk; the payload comes from /_payload.json or the API; bfcache restores the page instantly on Back if nothing blocked it.
Gotcha· Answering with the framework

"Nuxt handles caching" is not an answer to "how does caching work". Interviewers want the headers, the cache key and the invalidation story, then how Nuxt exposes them (routeRules, defineCachedEventHandler, useCookie). Knowing the platform is what lets you debug the framework when it does not do what you expect.

Exercise

Exercise
  • Open DevTools on this app's deployed URL, record a Performance profile of a cold load, and annotate the timeline with the eight steps above.
  • Inspect the response headers of the HTML and of a /_nuxt/*.js file; explain each Cache-Control directive you see.

Be able to say

Be able to say· How deep is your knowledge of the web platform under the frameworks?

"Deep enough to debug the framework. I can walk a request from DNS to paint, name what blocks rendering and what causes a long task, and read a Performance profile against the Core Web Vitals. I know HTTP caching as headers and cache keys, not as a setting: max-age versus s-maxage, validators and 304s, Vary, immutable hashed assets, stale-while-revalidate, and how a CDN and Nuxt's route rules layer on top. I can explain a CORS preflight and a SameSite cookie rejection from the headers alone, choose between localStorage, IndexedDB and a service worker cache with their quotas and SSR constraints in mind, and I know the APIs behind the vitals, bfcache and instant navigations by name."

Pages in this section

  1. 01How browsers renderFrom bytes to pixels — parsing and the preload scanner, render-blocking CSS and script loading attributes, the style-layout-paint-composite pipeline, the frame budget, layout thrashing, the observer APIs, long tasks and INP, and where Web Workers fit.
  2. 02HTTP and cachingHTTP/1.1 to HTTP/3, methods and status codes worth knowing, and caching as the biggest lever you control — Cache-Control directives, validators and 304s, Vary, CDN behaviour, immutable hashed assets, stale-while-revalidate, resource hints, early hints and speculation rules.
  3. 03Fetch, CORS and cookiesWhat fetch does and does not do, credentials and modes, the same-origin policy and how CORS preflights work, why CORS protects users not servers, cross-origin isolation headers, and every cookie attribute — SameSite, Secure, HttpOnly, prefixes, partitioning — with how Nuxt reads and sets them on both sides.
  4. 04Storage and offlineThe browser storage options and their quotas, eviction and SSR constraints — Web Storage, IndexedDB, the Cache API, OPFS — plus service workers and their update lifecycle, PWA installability, Web Workers and cross-tab communication, and what "offline-first" actually commits you to.
  5. 05Web APIs worth knowing by nameThe platform APIs a senior frontend engineer should be able to reach for without searching — URL and encoding, Web Crypto, files and blobs, history and the Navigation API, View Transitions, Page Lifecycle and bfcache, the Performance and observer APIs, Speculation Rules, clipboard and share, Web Components and WebAssembly — with the questions each one answers.

Your notes

Open in Notes

Nothing yet. Notes filed here show up on every page of this section.