Every performance conversation eventually reaches the rendering pipeline: what blocked the first paint, why the layout shifted, why a click took 400 ms to respond. Interviewers ask "what happens when the HTML arrives" to see whether you know the order of operations well enough to reason about a waterfall or a profile.

Know

• Parsing: the HTML tokenizer builds the DOM incrementally; a preload scanner looks ahead and starts fetching scripts, stylesheets, images and fonts before the parser reaches them (which is why hiding a critical image behind CSS or JavaScript delays it). Invalid nesting is repaired by the parser, which is a source of hydration mismatches.
• CSS is render-blocking: the browser will not paint until the CSSOM for blocking stylesheets is built (it would otherwise flash unstyled content). media attributes make stylesheets non-blocking when they do not match; inlining critical CSS is the trade-off for very large stylesheets.
• Scripts: a classic <script> blocks parsing while it downloads and executes; defer downloads in parallel and executes in order after parsing; async executes as soon as it arrives, out of order; type="module" is deferred by default and strict. Nuxt emits module scripts with modulepreload hints.
• The pipeline per frame: input handlers → requestAnimationFrame callbacks → style (compute styles) → layout (geometry; "reflow") → paint (rasterise into layers) → composite (GPU assembles layers). transform and opacity changes can skip layout and paint (compositor-only); width, top, font-size force layout; color, background force paint. The frame budget at 60 Hz is about 16 ms, less on 120 Hz displays.
• Forced synchronous layout and layout thrashing: reading geometry (offsetHeight, getBoundingClientRect(), getComputedStyle()) after a write forces layout immediately; alternating reads and writes in a loop forces it repeatedly. Batch reads, then writes; use requestAnimationFrame for visual updates; ResizeObserver instead of polling sizes.
• Long tasks and INP: a task over 50 ms delays input processing; INP measures the worst interaction's delay (input delay + processing + presentation). Fixes: break work with scheduler.yield(), defer non-urgent work (requestIdleCallback, setTimeout), avoid layout thrashing in handlers, reduce DOM size, move CPU work to Web Workers (postMessage, structuredClone, transferables; OffscreenCanvas for drawing off-thread).
• Observers replace polling: IntersectionObserver (lazy loading, infinite scroll, visibility-based hydration, analytics), ResizeObserver (element size changes, container-like logic in JS), MutationObserver (DOM changes; runs as a microtask), PerformanceObserver (long tasks, LCP candidates, layout shifts, event timing for INP, resource timing).
• Layout stability: dimensions on media, reserved space for late content, font fallbacks with matching metrics, no content inserted above the viewport; content-visibility: auto and contain limit layout scope for long pages.
• Metrics vocabulary: TTFB (server), FCP (first paint of content), LCP (largest element; good under 2.5 s), INP (responsiveness; good under 200 ms), CLS (stability; good under 0.1), TBT (lab proxy for INP). Field data (CrUX, RUM via web-vitals) at the 75th percentile is what counts; Lighthouse is a lab.
• Rendering in Nuxt terms: SSR gives early FCP/LCP because HTML arrives styled; hydration is JavaScript work that can create long tasks, which is why lazy hydration and server components matter; experimental.ssrStreaming flushes the shell earlier; NuxtLink prefetch and Speculation Rules move navigation cost ahead of the click.

How it works

Loading attributes and hints that decide the critical path:

<head>
  <link rel="preconnect" href="https://cdn.example.com">
  <link rel="preload" as="image" href="/hero.avif" fetchpriority="high">     <!-- LCP image found early -->
  <link rel="stylesheet" href="/_nuxt/entry.css">                              <!-- render-blocking, small -->
  <link rel="stylesheet" href="/_nuxt/print.css" media="print">                <!-- non-blocking -->
  <link rel="modulepreload" href="/_nuxt/entry.js">
  <script type="module" src="/_nuxt/entry.js"></script>                        <!-- deferred by default -->
  <script async src="https://analytics.example.com/tag.js"></script>           <!-- independent, out of order -->
</head>

Layout thrashing and its fix, the way it appears in a real component:

export function useEqualHeights(items: Ref<HTMLElement[]>) {
  // ✗ read, write, read, write: each write invalidates layout and the next read forces it again
  // for (const el of items.value) { el.style.height = ''; el.style.height = `${Math.max(...items.value.map(i => i.offsetHeight))}px` }

  // ✓ batch: all reads, then all writes, inside a frame
  function equalise() {
    requestAnimationFrame(() => {
      for (const el of items.value) el.style.height = ''      // writes (reset)
      const max = Math.max(...items.value.map(el => el.offsetHeight)) // reads, one forced layout
      for (const el of items.value) el.style.height = `${max}px`      // writes
    })
  }

  // ResizeObserver instead of a resize listener + polling
  useResizeObserver(items, equalise)
  onMounted(equalise)
}

Measuring what the user experiences, in the browser, and moving CPU work off the main thread:

import { onCLS, onINP, onLCP } from 'web-vitals/attribution'

export default defineNuxtPlugin(() => {
  const send = (m: { name: string, value: number, attribution: Record<string, unknown> }) =>
    navigator.sendBeacon('/api/telemetry/vitals', JSON.stringify({ name: m.name, value: m.value, target: m.attribution.interactionTarget ?? m.attribution.element, path: location.pathname }))
  onLCP(send)
  onINP(send) // attribution tells you *which* interaction and element was slow
  onCLS(send)
})

// A dedicated module worker: heavy filtering off the main thread
self.onmessage = (e: MessageEvent<{ rows: Row[], query: string }>) => {
  const q = e.data.query.toLowerCase()
  const hits = e.data.rows.filter(r => r.name.toLowerCase().includes(q))
  postMessage(hits)
}

export function useWorkerSearch(rows: Ref<Row[]>) {
  const results = shallowRef<Row[]>([])
  let worker: Worker | undefined
  onMounted(() => { worker = new Worker(new URL('~/workers/search.worker.ts', import.meta.url), { type: 'module' }); worker.onmessage = e => { results.value = e.data } })
  onScopeDispose(() => worker?.terminate())
  const search = (query: string) => worker?.postMessage({ rows: toRaw(rows.value), query }) // structured clone; toRaw avoids cloning the Proxy
  return { results, search }
}

Exercise

Be able to say