yoklainterview sim
ProgressHistory

Frontend Performance Interview Questions

75 verified Frontend Performance interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

PerformanceDifficulty 1
A product photo is served as a 2 MB PNG and loads slowly. Which change most reliably shrinks the download with little visible quality loss?
  • aRename the file's extension from .png to .jpg so the format changes
  • bRe-encode the photo to a lossy format such as JPEG or WebP✓
  • cAdd explicit width and height attributes to the <img> element
  • dReduce the image's opacity with CSS so it renders lighter
Explanation:Photographs compress far better in a lossy format like JPEG or WebP than in lossless PNG, which is meant for sharp-edged graphics. Renaming the extension (a) does not re-encode the bytes — the file stays a 2 MB PNG. Width/height attributes (c) reserve layout space and prevent shift, but do not change how many bytes are downloaded.
PerformanceDifficulty 2
<img src="gallery-12.jpg" loading="lazy" alt="...">

What does the loading="lazy" attribute do here?
  • aIt compresses the image on the fly before sending it to the browser
  • bIt lowers the image's priority so it always downloads after the page's scripts
  • cIt defers loading the image until it is about to scroll into view✓
  • dIt loads a small placeholder first and swaps in the full image on hover
Explanation:loading="lazy" tells the browser to postpone fetching an off-screen image until the user scrolls near it, saving bandwidth for images that may never be seen. It performs no compression (a) and is unrelated to script ordering (b); the placeholder-swap pattern (d) is something you build yourself, not what this attribute does.
PerformanceDifficulty 1
Why is shipping one very large JavaScript bundle generally bad for page performance?
  • aThe browser must download, parse, and run all of it before the page can be interactive✓
  • bLarge files can never be cached by the browser, so they re-download on every single visit
  • cBrowsers reject any JavaScript file that is larger than one megabyte in size
  • dA single large file inevitably contains more bugs than several smaller ones
Explanation:A big bundle delays interactivity: the user waits while the browser fetches, parses, and runs code they may not even need yet. Large files are cacheable just like small ones (b), there is no size limit that rejects them (c), and bug count is unrelated to bundling (d).
PerformanceDifficulty 2
A single-page app loads one bundle containing every screen, including a rarely used admin dashboard. Users on the login page wait for all of it. Which technique best addresses this?
  • aMove the whole bundle onto a CDN so it downloads from a server closer to the user
  • bMinify the bundle so the unused admin code occupies fewer bytes overall
  • cAdd the loading="lazy" attribute to the script tag that pulls in the bundle
  • dSplit the bundle so each screen's code is fetched only when that screen opens✓
Explanation:Code splitting lets the login page download just what it needs and load the admin dashboard's code on demand later. A CDN (a) and minification (b) both help a little but still ship the admin code to every visitor up front, and loading="lazy" is an image/iframe attribute, not a way to defer application modules (c).
PerformanceDifficulty 1
What does minifying a CSS or JavaScript file do?
  • aIt encrypts the source code so competitors cannot read it
  • bIt removes whitespace, comments, and shortens names to reduce file size✓
  • cIt splits the file into smaller chunks that load in parallel
  • dIt compiles the code into a faster machine-level binary the CPU runs directly
Explanation:Minification strips characters that machines do not need — whitespace, comments, long variable names — producing a smaller but functionally identical file. It is not encryption (a); the code is still readable after re-formatting. It does not split files (c) or compile to a binary (d).
PerformanceDifficulty 2
A page includes a large stylesheet with <link rel="stylesheet" href="app.css"> in the <head>. Users see a blank screen until it downloads. Why does the browser wait?
  • aThe <head> section must fully download before any HTML in <body> is parsed
  • bStylesheets are always downloaded before the HTML document itself
  • cCSS is render-blocking: the browser delays painting until it has the styles✓
  • dThe browser runs every stylesheet as a script before showing the page
Explanation:By default CSS blocks rendering — the browser avoids painting unstyled content, so a big stylesheet in the head delays first paint until it arrives. The head does not block body parsing wholesale (a); HTML parsing continues, but painting waits. CSS is not a script (d) and is requested after the HTML starts parsing, not before (b).

By specialization

Angular 450JavaScript 450React 450TypeScript 450Vue 450

By seniority

Frontend JuniorFrontend MidFrontend Senior

Other fields

BackendFullstackDevOps / CloudAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 2925-question Frontend bank.

Start interview