Web Performance Interview Questions
Reviewed by Mark Dickie · Last updated
Web performance is the practice of measuring and improving how fast a web page loads, renders, and responds to user input. For an interview on this topic, you should know the Core Web Vitals metrics (LCP, INP, CLS), how the browser's critical rendering path works, and the common causes of layout shift and main-thread blocking. Expect questions on resource loading strategies, caching headers, image optimization, and how to read a performance trace in Chrome DevTools or Lighthouse. You should also be comfortable explaining the difference between perceived performance and actual load time, since interviewers often probe whether you understand the user-facing impact of each optimization you propose.
| Core area | What an interview covers | Key metrics or tools |
|---|---|---|
| Loading speed | How quickly content appears on screen | LCP, FCP, Lighthouse |
| Interactivity | How fast the page responds to input | INP, TBT, long tasks API |
| Visual stability | How much the layout shifts during load | CLS, Layout Shift API |
| Resource delivery | How assets are fetched, cached, and prioritized | preload, prefetch, Cache-Control, CDN |
| Rendering pipeline | How the browser turns HTML/CSS/JS into pixels | DOM, CSSOM, render tree, paint |
What does a web performance interview test?
It tests whether you can identify a performance problem from a trace or report, explain the underlying browser behavior, and propose a fix with the right trade-off in mind. Interviewers want to see that you reason about the critical path rather than blindly applying tips. A strong answer names the metric affected, the cause, and the specific change you would ship.
Which optimization steps should I follow?
- Measure first — capture a Lighthouse report or a DevTools performance trace on a real (not throttled-only) device profile.
- Identify the largest contentful element and any long tasks blocking the main thread for over 50 ms.
- Reduce initial JavaScript: code-split, defer non-critical scripts, and remove unused dependencies.
- Optimize images with proper formats (AVIF or WebP),
loading=lazybelow the fold, andfetchpriorityhints for the hero image. - Set long-lived caching headers for static assets and use a CDN with HTTP/2 or HTTP/3 push multiplexing.
- Re-measure the same metrics to confirm the improvement and guard against regressions with a CI budget.
Key facts
- Tarmac has 41 Web Platform interview questions on this topic, 10 of them on this page, at difficulty 1–4 of 5.
- Tarmac tracked 507 job postings asking for Web Platform in August 2026.
- Roles asking for Web Platform advertise a median base salary of US$167,500, across 145 job postings as of August 2026.
- Tarmac last reviewed these Web Platform interview questions on 31 August 2026.
At a glance
| Questions | 10 shown · 41 in the bank |
|---|---|
| Difficulty | 1–4 of 5 |
| Formats | True / false, Multiple choice, Fill in the blank, Multiple answer, Code output, Find the bug, Short answer, Ordering, Flashcard |
What you'll review
- core web vitals
- debounce throttle
- speculation rules
Practice questions
Try one before you open the answer. Pick an option and press Check; it's marked on the spot.
Largest Contentful Paint (LCP) measures the time from when the user first navigates to a page to when the largest image or text block in the viewport is fully rendered. A 'Good' LCP score is 2.5 seconds or less.#
Options
Show answer
True. Largest Contentful Paint (LCP) measures how long it takes for the largest visible image or text block to render in the viewport from the start of page navigation. Google classifies an LCP of 2.5 seconds or less as 'Good', making this the target threshold for a positive user experience.
LCP does measure the render time of the largest content element visible in the viewport from the moment the user begins navigation. Google's thresholds classify LCP ≤ 2.5 s as 'Good', 2.5–4.0 s as 'Needs Improvement', and > 4.0 s as 'Poor'. Both parts of the statement are correct.
Which of the following metrics is not one of Google's three Core Web Vitals (as of 2024)?#
Options
Show answer
First Contentful Paint (FCP) is not a Core Web Vital. The three Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). FCP is a useful diagnostic metric in Lighthouse and PageSpeed Insights, but it does not count as an official Core Web Vital and does not directly influence Google Search ranking signals.
The three Core Web Vitals are LCP (loading), INP (interactivity — which replaced FID in March 2024), and CLS (visual stability). First Contentful Paint (FCP) is a diagnostic metric reported in Lighthouse and PageSpeed Insights, but it is NOT one of the three Core Web Vitals. LCP, INP, and CLS are the metrics that feed directly into Google Search ranking signals.
Complete the following Core Web Vitals thresholds:#
Show answer
Complete the following Core Web Vitals thresholds:
- LCP should occur within 2.5 seconds for a "Good" score.
- CLS should be less than 0.1 for a "Good" score.
- INP should be less than 200 milliseconds for a "Good" score.
Google defines "Good" thresholds for the three Core Web Vitals as: LCP ≤ 2.5 s (measures when the largest above-the-fold content element becomes visible); CLS < 0.1 (a unitless score measuring unexpected layout shifts); and INP < 200 ms (measures end-to-end latency of user interactions). Values between the Good and Poor thresholds are rated "Needs Improvement".
Which of the following practices improve Largest Contentful Paint (LCP)? Select all that apply.#
Options
Pick every one that applies.
Show answer
Three practices improve Largest Contentful Paint: adding fetchpriority="high" to the hero <img> element, preloading the LCP image with <link rel="preload" as="image">, and serving images via a CDN to reduce Time to First Byte. fetchpriority="high" tells the browser to download the hero image early, preload kicks off that request before the parser reaches the <img> tag, and a lower TTFB means the page's bytes, including the LCP resource, start arriving sooner.
LCP measures when the largest content element (commonly a hero image) becomes visible. fetchpriority="high" on the hero <img> tells the browser to prioritise downloading that resource early, directly shortening its fetch time. <link rel="preload" as="image"> kicks off the LCP resource request before the parser even reaches the <img> tag, reducing discovery latency. Serving via a CDN reduces TTFB, which shortens the time before any byte of the page—including the LCP resource—can begin downloading. loading="lazy" is actively harmful for the LCP element because it intentionally delays its fetch. Deferring an analytics script that is already at the end of <body> and is therefore neither render-blocking nor related to the LCP element; moving a non-blocking end-of-body script to defer has no meaningful effect on LCP.
A trailing-edge debounce delays the call until 100ms after the last invocation. f is called three times in quick succession (well under 100ms apart). How many times does g run, and with what argument?#
function debounce(fn, wait) {
let t;
return (...args) => {
clearTimeout(t);
t = setTimeout(() => fn(...args), wait);
};
}
const g = debounce((x) => console.log(x), 100);
g('a');
g('b');
g('c');Show answer
c
Each call clears the previous pending timer and schedules a new one, so the first two never fire. Only the timer from the last call (g('c')) survives the 100ms of quiet, so fn runs exactly once with the most recent argument, logging c.
This search-as-you-type input fires a network request on nearly every keystroke instead of waiting for the user to pause. What's the bug?#
const search = throttle((query) => fetchResults(query), 300);
input.addEventListener('input', (e) => search(e.target.value));Options
Show answer
throttle runs the handler at most once per 300ms throughout the burst of keystrokes, so it keeps firing while the user is still typing; a search-as-you-type field wants debounce, which waits for a pause and fires once with the final value
Throttle's whole point is a steady drip of calls during continuous activity — good for scroll/resize, wrong for search input, where firing on every partial, in-progress query wastes requests and can flash stale results before the final one resolves. Debounce is the fit here: it resets its timer on every keystroke and only calls the handler once activity has stopped for the wait period, so it fires once with the completed query. The listener does correctly receive each keystroke's value (the claim that wrapping search has no effect and the claim that e.target.value is undefined are wrong), and swapping the wait time doesn't fix the fundamental mismatch in the claim that throttle and debounce are interchangeable here — throttle keeps firing mid-burst at any wait value.
A product team is trying to improve their page's Interaction to Next Paint (INP) score. Which of the following interventions reduce INP by shortening one of its three sub-parts (input delay, processing time, or presentation delay) for the measured interaction? Select all that apply.#
Options
Pick every one that applies.
Show answer
Two interventions reduce INP by shortening one of its sub-parts: (1) breaking up long JavaScript tasks with scheduler.yield() or setTimeout so the main thread is free when the user interacts (shrinks input delay), and (2) minimizing DOM size and expensive style recalculations triggered by handlers so layout and paint complete faster (shrinks presentation delay). Image format changes, HTTP/2 stream limits, and blanket requestAnimationFrame wrapping do not.
INP measures the latency of discrete interactions from input until the next frame is painted, and is decomposed into input delay, processing time, and presentation delay. Yielding long tasks with scheduler.yield() or setTimeout keeps the main thread from being blocked when the user interacts, which reduces the input delay portion of INP for subsequent interactions — a well-established optimization in Google's INP guidance. Reducing DOM size and expensive style recalculations triggered by handlers shortens the layout/paint work the browser must do after the event callback, directly reducing presentation delay. Switching image formats to WebP reduces page weight and affects LCP/transfer cost, but does not change how quickly the main thread responds to an interaction. HTTP/2 concurrent-stream limits are a network-multiplexing concern unrelated to main-thread interaction latency. Unconditionally wrapping interaction-driven DOM updates in requestAnimationFrame defers the visual update to a later frame, which generally increases presentation delay for the measured interaction; Google's INP guidance specifically warns against using rAF as a blanket wrapper for interaction visual updates for this reason.
Explain what Cumulative Layout Shift (CLS) measures and describe two specific, distinct root causes that commonly produce a high CLS score on a production web page. For each cause, state the recommended fix.#
Show answer
CLS measures the sum of all unexpected layout shift scores that occur during the page's lifecycle. Each layout shift score is calculated as the product of the impact fraction (the fraction of the viewport affected) and the distance fraction (how far elements moved). A high CLS is commonly caused by: (1) Images or media without explicit width/height attributes — the browser does not reserve space for them, so when they load they push content down. Fix: always set width and height attributes or use aspect-ratio in CSS so the browser reserves the correct space before the resource loads. (2) Dynamically injected content (e.g., ad banners, cookie consent banners, or lazy-loaded components) inserted above existing content — this shifts everything below it downward. Fix: pre-reserve the space with a placeholder of the same dimensions (e.g., a min-height container), or insert the content below the fold / outside the current viewport.
CLS is the only Core Web Vital that is not a time-based metric; it quantifies visual instability. Its score is the sum of (impact fraction × distance fraction) for each unexpected shift. The two most prevalent causes are unsized media (no reserved space) and late-injected content above the fold. The fixes directly address the reservation of layout space before resources load or content appears.
A browser navigates to a page whose LCP element is an <img>. Consider the following five milestones, where each milestone is defined as the first moment the described condition becomes true. Arrange them in the order in which they must occur.#
Put these in order
Show answer
The correct order is: TTFB → image request dispatched → first image byte received → first paint of the image → LCP entry recorded. Each milestone is a strict data-dependency of the next: the browser needs HTML bytes to discover the <img>, needs to send the request before bytes come back, needs some image bytes to paint any pixels, and per the Web Vitals spec the largest-contentful-paint renderTime corresponds to that first paint.
Each milestone is a strict data-dependency prerequisite of the next, giving a single uncontested total order. (s1) TTFB precedes everything — no HTML bytes means no parsing and no discovered <img>. (s2) The request for the image can only be dispatched after enough HTML has arrived to expose the tag or its preload hint, so s2 follows s1. (s3) The first image byte cannot arrive before the request has been sent, so s3 follows s2. (s4) The first paint of the image requires at least some image bytes to have been received and decoded (even progressive/streaming codecs need some bytes on hand), so s4 follows s3. (s5) The Web Vitals spec ties the LCP renderTime to the moment the element was first painted, so the entry cannot be recorded before that paint occurred; s5 follows s4. Note this version deliberately uses first-occurrence milestones (first byte, first paint) rather than completion gates, which sidesteps progressive-decode and tiled-rendering concerns — decode may overlap download and paint may overlap decode, but the first occurrence of each still respects this ordering.
What does the eagerness setting control in a Speculation Rules document rule, and what are the levels?#
Show answer
eagerness tells the browser how aggressively to act on speculation candidates, trading hit-rate against wasted work. Roughly: immediate (act as soon as the rule is seen), eager (very soon, on the slightest signal), moderate (on a reasonable signal of intent, e.g. hovering/focusing a link in view for a moment), and conservative (only on strong intent, e.g. pointer-down/tap-start). Prefetch is cheap so you can be eager; prerender is expensive, so moderate/conservative are the safer defaults.
Eagerness lets one rule say 'prerender, but only when the user clearly intends to navigate.' The browser also applies its own heuristics and limits (memory, concurrent speculations) on top of your setting, so it may decline or evict speculations regardless of the level you request.
Sources
The official documentation these questions are checked against:
Related interview questions
Job market
See web-platform salaries and hiring demand from live job postings.
The other 31 questions
This page shows 10 and marks what you pick. That's as far as a page can go. A free account opens the other 31 and keeps every answer. What you miss comes back until it's right: after a day, then at longer gaps.
Free · the whole bank · 100 marked answers per 30 days · written feedback on the paid plan