Web Performance Interview Questions for Frontend Development
25 Web Performance questions with answers for frontend development roles — 7 easy, 11 medium, 7 hard.
About Web Performance
Performance directly affects conversions and search ranking. This topic covers Core Web Vitals LCP, INP and CLS, lab versus field data, code splitting, resource hints, long tasks, HTTP caching, images, fonts and hydration cost, with practical work on measuring real users, yielding to the main thread and enforcing performance budgets.
Sheet progressStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
What are Core Web Vitals and their good thresholds?
Core Web Vitals are Google's user experience metrics measured from real users. Largest Contentful Paint measures loading and should be 2.5 seconds or less. Interaction to Next Paint measures responsiveness and should be 200 milliseconds or less. Cumulative Layout Shift measures visual stability and should be 0.1 or less. A page passes when at least 75 percent of visits meet each threshold, and they influence search ranking.
Code splitting breaks a large JavaScript bundle into smaller chunks so the browser downloads only what the current page needs. Lazy loading defers loading code or assets until they are required, using dynamic import() for components like a chart or a rich text editor. Route-based splitting is the most common starting point. It reduces initial download and parse time, which improves LCP and INP on slower devices.
03
How do you choose the right image format and size?
Use AVIF or WebP for photos because they are much smaller than JPEG at similar quality, with JPEG as fallback. Use SVG for icons and logos, and PNG only when lossless transparency is essential. Serve sizes that match the display width with srcset and sizes, compress with tools like Squoosh or an image CDN, and always specify width and height to avoid layout shift.
04
How can web fonts slow a page down and how do you optimise them?
Fonts are often discovered late, after CSS is parsed, and text may stay invisible until they load. To optimise, self-host fonts in WOFF2 format, subset them to the characters you need, preload the main weight, and use font-display: swap so fallback text appears immediately. Limiting the number of weights and using variable fonts reduces downloads. Matching fallback metrics with size-adjust prevents layout shift.
Use a dynamic import inside the event handler:
const exportBtn = document.querySelector('#export-pdf');
exportBtn.addEventListener('click', async () => {
exportBtn.disabled = true;
const { generatePdf } = await import('./pdf-export.js');
await generatePdf(reportData);
exportBtn.disabled = false;
});
The bundler creates a separate chunk for pdf-export.js, so users who never export do not download it. Prefetching on hover can hide the delay.
06
Add resource hints for a third-party font and the hero image.
Place these early in the head:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>
<link rel='preload' href='/img/hero-1200.avif' as='image' fetchpriority='high'>
<link rel='dns-prefetch' href='https://analytics.example.com'>
Fonts must be preloaded with crossorigin, even from the same origin, or the browser downloads them twice. Preload only a few critical resources.
07
Product images on a listing page load slowly. What quick fixes would you apply?
I would convert images to WebP or AVIF, resize them to the actual thumbnail size instead of loading full product photos, and serve them through srcset. Images below the fold get loading='lazy', while the first few visible ones load eagerly. Adding width and height prevents layout shift, and serving images from a CDN with long cache headers makes repeat visits much faster.
08
What is Interaction to Next Paint and what usually makes it poor?
INP replaced First Input Delay in 2024. It measures the delay from a click, tap or key press until the next frame is painted, across all interactions on the page, reporting roughly the worst one. Poor INP usually comes from long JavaScript tasks blocking the main thread, heavy event handlers, large re-renders and expensive layout work after interaction. Breaking up tasks and showing immediate visual feedback improves it.
09
What is the difference between lab data and field data in performance?
Lab data comes from controlled tests like Lighthouse or WebPageTest on a fixed device and network, which is great for debugging and comparing changes. Field data, or real user monitoring, comes from actual visitors through the Chrome UX Report or your own analytics, capturing real devices, networks and behaviour. Google ranks on field data. A page can score well in the lab but fail in the field on low-end phones.
preconnect opens an early connection, including DNS, TCP and TLS, to an important third-party origin like a font or API server. preload fetches a resource needed for the current page at high priority, such as the hero image or main font. prefetch downloads resources likely needed for the next navigation at low priority during idle time. Overusing preload wastes bandwidth and can delay more critical resources.
11
What are long tasks and why do they hurt user experience?
A long task is any main-thread work lasting more than 50 milliseconds. While it runs, the browser cannot respond to taps or paint updates, so the page feels frozen. Common sources are large script evaluation, heavy JSON processing, big framework re-renders and third-party scripts. The Performance panel highlights them with red corners, and splitting work into smaller chunks or moving it to a worker keeps the page responsive.
12
How do HTTP caching headers work for frontend assets?
Cache-Control controls caching. Files with content hashes in their names, like app.3f9a2c.js, can use max-age=31536000, immutable because a new build produces a new filename. HTML should use no-cache, which forces revalidation so users get new asset references after a deploy. ETag and Last-Modified allow cheap revalidation with 304 Not Modified responses. Wrong headers cause either stale apps or needless re-downloads.
13
Collect Core Web Vitals from real users with the web-vitals library.
Report metrics to your analytics endpoint:
import { onLCP, onINP, onCLS } from 'web-vitals';
function send(metric) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
rating: metric.rating,
page: location.pathname
});
navigator.sendBeacon('/analytics/vitals', body);
}
onLCP(send);
onINP(send);
onCLS(send);
sendBeacon delivers data reliably even when the page is closing. Aggregate at the 75th percentile per page.
14
Configure cache headers for hashed assets and HTML in Nginx.
Long cache for fingerprinted files, revalidation for HTML:
location ~* \.(js|css|woff2|avif|webp|svg)$ {
add_header Cache-Control 'public, max-age=31536000, immutable';
}
location / {
try_files $uri /index.html;
add_header Cache-Control 'no-cache';
}
This works only when build tools add content hashes to filenames. Returning users then load assets from cache instantly, while every deploy still reaches them through fresh HTML.
15
The main JavaScript bundle is 2 MB. How do you reduce it?
I would run a bundle analyser to see what is inside. Usual wins are route-based code splitting, lazy loading heavy widgets, replacing large libraries such as full date or utility packages with smaller alternatives or native APIs, and importing only needed functions so tree shaking works. I would also remove polyfills for browsers we no longer support, and make sure production mode and minification are enabled.
16
Marketing has added many third-party scripts and the site has become slow. What do you do?
I would measure each script's cost using the Performance panel and request blocking in DevTools. Then I would remove unused tags, load the rest with async or defer, delay non-essential ones like chat widgets until user interaction or idle time, and use facades, such as a static image for embedded videos. Moving tag management to a server-side setup and agreeing on a script budget with marketing prevents repeat problems.
17
Most of your users are on low-end Android phones with slow networks. How does that change your approach?
I would test with real budget devices and network throttling rather than a fast laptop. The priorities become sending less JavaScript, rendering important content on the server, compressing images aggressively, and keeping the initial page under a strict size budget. Caching with a service worker helps repeat visits. Features like large animations and heavy carousels should be reduced or loaded only when the device can handle them.
18
An audit finds twenty performance issues. How do you decide what to fix first?
Situation: a Lighthouse and field data audit of our app listed many issues. Task: I had one sprint to show improvement. Action: I ranked issues by user impact and effort, focusing first on the LCP image, render-blocking CSS and one oversized library on the most visited pages. Result: these three fixes delivered most of the gain, and I scheduled the remaining smaller items into later sprints.
19
How do HTTP/2 and HTTP/3 change frontend bundling strategy?
HTTP/1.1 allowed few parallel requests per domain, so developers concatenated everything into one big bundle and used domain sharding. HTTP/2 multiplexes many requests over one connection, and HTTP/3 runs over QUIC to avoid head-of-line blocking on lossy mobile networks. This makes moderate chunk splitting efficient and improves caching, because changing one module invalidates only its chunk. Still, too many tiny files add overhead.
20
What is hydration and why can it hurt performance?
With server-side rendering, the server sends ready HTML so content appears quickly, but the page is not interactive until the framework downloads JavaScript and hydrates, attaching event listeners and rebuilding state. On slow phones, this causes a gap where buttons look ready but do nothing, hurting INP. Techniques like streaming, partial or progressive hydration, islands architecture and server components reduce how much JavaScript must hydrate.
21
Break a long-running loop into smaller tasks to keep the page responsive.
Yield to the main thread between chunks:
function yieldToMain() {
if (globalThis.scheduler?.yield) return scheduler.yield();
return new Promise(resolve => setTimeout(resolve, 0));
}
async function processRows(rows) {
let last = performance.now();
for (const row of rows) {
processRow(row);
if (performance.now() - last > 40) {
await yieldToMain();
last = performance.now();
}
}
}
The browser can handle clicks between chunks, which improves INP. scheduler.yield keeps the task's priority after resuming.
22
Enforce a performance budget in CI with Lighthouse CI.
I would reproduce with CPU throttling in the Performance panel and record the click to see what runs. Typical findings are a heavy handler, analytics calls running synchronously, or a large re-render of the whole page. Fixes include updating the button state immediately, deferring non-urgent work like tracking with scheduler.yield or requestIdleCallback, and narrowing which components re-render. Attribution data from web-vitals helps find the exact element and script.
24
Lighthouse shows a score of 95, but Search Console reports failing Core Web Vitals. Why?
Lighthouse is a single lab run on a simulated device, while Search Console uses field data from real Chrome users at the 75th percentile over 28 days. Real users may have slower phones, interact with the page, which affects INP and CLS later in the session, or see different content like ads and personalised blocks. I would add real user monitoring with attribution to find which pages and elements fail.
25
How did you convince stakeholders to prioritise performance work over new features?
Situation: our product team kept postponing performance fixes for new features. Task: I needed to show the business value. Action: I correlated our real user data with conversion and found that sessions with LCP above 4 seconds converted at about half the rate. I proposed a two-sprint plan with clear targets. Result: leadership approved it, LCP improved by 40 percent and checkout conversion rose measurably.
Frequently asked questions
How important is Web Performance in Frontend Development interviews?
Performance directly affects conversions and search ranking. This topic covers Core Web Vitals LCP, INP and CLS, lab versus field data, code splitting, resource hints, long tasks, HTTP caching, images, fonts and hydration cost, with practical work on measuring real users, yielding to the main thread and enforcing performance budgets.
How should I use the Web Performance sheet?
Go top to bottom — easy to hard. Answer before opening each answer, tick what you solved and save misses to Last-Minute Revision.