Senior Web Performance Developer Interview Questions: Advanced Topics and Answers

Senior web performance developer interview questions assume you already know what Largest Contentful Paint is and how to open Lighthouse. What they actually probe is whether you can own performance for a real product: deciding what to measure, diagnosing a regression you cannot reproduce on your own machine, holding a budget when a deadline pushes against it, and knowing when the right call is not to optimise at all. This guide covers 8 of those questions with worked answers, each grounded in the current specifications rather than folklore.

If the fundamentals are not solid yet, start with GreatFrontEnd's web performance interview questions, which covers the metrics, the critical rendering path, and the debugging basics this guide assumes.

What separates senior from mid-level web performance candidates

A mid-level candidate can read a Lighthouse report and act on its recommendations. A senior candidate can explain why Lighthouse and real users disagree, decide which signal to trust, and defend a performance decision to a product manager who wants one more third-party tag. The questions below are about measurement strategy, diagnosis under uncertainty, and ownership, not about definitions.

Question 1: INP replaced FID. What actually changed, and how does that change your diagnosis?

How to approach it

Naming the swap is the mid-level answer. Interaction to Next Paint became a stable Core Web Vital on 12 March 2024, and First Input Delay is retired and no longer a Core Web Vital.

The senior answer explains why the replacement was necessary, and it comes down to what FID could not see. FID measured only the first interaction on the page, and only the delay before a handler started running. It could report a healthy score on a page where every subsequent interaction was slow, and it was blind to the time the handler itself spent working.

What makes INP diagnostically useful is that it breaks an interaction into three phases, and each one points at a different bug. Per web.dev's INP documentation, those phases are input delay, "the time before any callback for an interaction is handled"; processing duration, "the time for all the callbacks to execute"; and presentation delay, "the time after the callbacks have been executed until the frame is presented on the user's screen."

A long input delay usually points to work already occupying the main thread when the interaction occurred, such as script execution, timers, another interaction, or hydration. A long processing duration points to expensive event callbacks, whether first-party or third-party. A long presentation delay points toward expensive rendering work such as style calculation, layout, paint, or compositing. Each phase suggests a different area to investigate, and a candidate who identifies the phase before proposing a fix is reasoning rather than guessing.

Two details from the same documentation are worth having ready, since they are easy to get wrong: INP observes qualifying interactions throughout the page's lifetime and usually reports the slowest one. On pages with many interactions, it ignores one worst interaction for every 50 interactions to reduce the effect of occasional outliers, and only three interaction types count, clicking with a mouse, tapping on a touchscreen, and pressing a key. Hovering, scrolling, and zooming are not measured at all.

Question 2: Your lab tests pass but field data says the site is failing. Which do you trust?

How to approach it

The trap in this question is treating one of them as wrong. They measure different things, and a senior answer says so before picking.

Lab data is a synthetic run on a machine you control, with a fixed network profile and no real users. It is reproducible, which makes it good for catching a regression between two builds. Field data is what actual users experienced on their actual devices and connections. Core Web Vitals are assessed at the 75th percentile of page loads, segmented by device type, which matters more than it sounds: you are being judged on the experience of the slower quarter of your traffic, and mobile and desktop are scored separately.

The percentile is part of the explanation, but the larger difference is population versus controlled conditions. Field data includes the actual distribution of devices, networks, locations, cache states, content, and user behaviour, while a lab test represents one deliberately chosen environment. If field data fails while the lab passes, first ask which real-user conditions your lab setup is failing to represent.

The senior move is to use each for what it is good at: field data to decide whether you have a problem and for whom, lab data to reproduce and fix it, then field data again to confirm the fix reached real users. A candidate who proposes to fix the lab number is optimising the instrument rather than the experience.

Question 3: How do you diagnose a slow INP you cannot reproduce locally?

How to approach it

This is the realistic version of the job, and it starts by admitting the constraint: if it does not reproduce under your current local conditions, repeatedly profiling the same setup is unlikely to find it. Start with field data to narrow down the affected users and interactions, then try to recreate those conditions locally.

Start by narrowing with the field data you do have. Device and page segmentation tells you who is affected and where. If your RUM instrumentation captures INP attribution, the three phases from Question 1 narrow it further by showing whether the time is going to input delay, processing, or presentation before you open a profiler.

For the deeper layer, the Long Animation Frames API is one particularly useful tool for this. It improves on the older Long Tasks API by describing slow UI frames in more detail and, where attribution is available, identifying the main-thread scripts that contributed to them. That makes it useful for diagnosing responsiveness problems in real-user traffic rather than only in a lab. It shipped in Chrome 123, following an origin trial that ran from Chrome 116 to 122.

State the limitation, because an interviewer may be checking whether you do: LoAF is currently limited to Chromium-based browsers and is not available in Safari or Firefox. So it is a strong diagnostic for the share of your traffic on Chromium and gives you nothing for the rest. If a performance problem is concentrated on iOS Safari, this tool will not see it, and a candidate who recommends it as a universal answer has not deployed it.

Question 4: How do you set a performance budget, and how do you actually enforce it?

How to approach it

A budget is easy to state and harder to hold, and the gap between the two is what this question is really asking about. A senior answer treats the enforcement mechanism as the substance, because a budget nothing checks is a preference, not a budget.

Enforcement means the budget runs in CI on every change, and a breach does something visible: fails the build, blocks the merge, or at minimum posts the regression on the pull request where the person who caused it will see it. The value comes from attaching the feedback to the change that caused it, while the author still has context, rather than discovering a slow cumulative drift a quarter later with no idea which commit did it.

On what to budget, the senior distinction is between what is easy to measure and what actually predicts user experience. Bundle size is easy to enforce and only loosely correlated with what users feel. Budgeting on the metrics that map to experience, and on the main-thread work that drives INP, is harder to wire up but measures the thing you care about. A reasonable strategy uses both. Asset-size and main-thread-work budgets are cheap pre-merge warnings, while reproducible lab metrics and scripted user flows can act as CI gates. Field Core Web Vitals serve a different role: they are production signals that tell you whether those safeguards are translating into a good experience for real users.

The part that gets skipped is what happens on a breach. A budget that everyone learns to override is worse than none, because it costs CI time and teaches the team the signal is ignorable. Have an explicit path: who can approve an exception, and what is recorded when they do.

Question 5: In a server-rendered app, where does hydration cost actually land?

How to approach it

This separates people who have shipped server-side rendering from people who have read about it. The common assumption is that SSR is a performance win across the board. It is a win for the paint, and it can be a cost for interactivity.

The mechanism is worth tracing rather than asserting. Server rendering can improve early content rendering because the browser receives useful markup before all of the application's JavaScript is ready. But framework-managed interactions may still depend on client-side JavaScript and hydration, and that work consumes main-thread time. If a user interacts with a part of the page while hydration or other startup JavaScript is occupying the main thread, that work can increase the interaction's input delay.

That produces the failure mode this question is really about: a page that scores well on paint metrics and feels broken to a real user, because it looked ready before it was. A senior answer names the specific mitigations rather than gesturing at "optimise hydration": ship less JavaScript to hydrate in the first place, defer or skip hydration for parts of the page that are not interactive, and prioritise hydrating what the user is most likely to touch first. Frameworks differ in what they offer here, so the concrete answer depends on the stack, and saying so is better than pretending one approach is universal.

Question 6: How do you govern third-party scripts you do not control?

How to approach it

The honest framing is that you cannot fix code you do not own, so the leverage is entirely in the decisions around it: whether it loads, when it loads, and whether it stays.

On loading, the questions are whether it needs to run before interactivity at all, whether it can be deferred until after the page is usable, and whether it can be loaded only on the routes that need it rather than globally. Many tags are added site-wide for convenience when they are only used on one page.

The part senior candidates raise and others miss is the ongoing governance. Third-party scripts accumulate. Each one was added for a reason that made sense at the time, by someone who may have left, and nobody owns removing them. A tag that no team can name an owner for is a strong candidate for deletion. Auditing periodically, and attributing main-thread cost to specific third parties so the conversation is about a measured number rather than a hunch, is what makes the removal argument winnable.

This is also where the political part of a senior performance role shows up, and it is fair to say so. The decision to drop a marketing tag is not usually an engineering decision. Bringing a measured cost to that conversation is more effective than bringing an objection.

Question 7: When would you not optimise?

How to approach it

An interviewer asking this is checking whether you treat performance as a goal in itself or as a means to something. Answering "you should always optimise" is the failure.

The clearest case is when you have not measured. Optimising a page nobody visits, or a path that is already comfortably inside its budget, spends engineering time for no user-visible gain, and the cost is whatever else that time would have bought.

The second case is when the optimisation trades away something that matters more. Aggressive code splitting can turn one slow load into several slower interactions. Removing a feature is always faster and sometimes wrong. Caching more aggressively improves speed and increases the chance of showing someone stale data, which for some products is a correctness problem rather than a tradeoff.

The third case is diminishing returns against the threshold. Once a metric is comfortably inside its target at the 75th percentile, further improvements may have lower marginal value than fixing another failing metric or user journey. The threshold is a useful prioritisation signal, not evidence that performance beyond it has no value. The senior answer names where the remaining headroom actually is rather than continuing to push the metric that is already green.

Question 8: Core Web Vitals were designed around page loads. How do you measure a single-page app?

How to approach it

This has historically been a gap in Core Web Vitals, but the situation is changing. Single-page apps use soft navigations, where the URL and visible content change without creating a new document, so the original Web Vitals model could not treat each route transition like a separate page load.

In supporting Chromium browsers, that gap is now partly addressed by the Soft Navigations API introduced in Chrome 151. It lets performance entries be associated with individual soft navigations, and web-vitals v6 can report LCP, INP, and CLS separately for them. The important limitation is coverage: this is not yet supported across all browsers, and how soft-navigation data will ultimately appear in CrUX is still evolving.

A practical senior answer is therefore to use the standard metrics for full navigations, measure soft-navigation Web Vitals where the browser supports them, and supplement that with application-level route-transition measurements where broader coverage is needed. Keep those datasets clearly segmented rather than pretending they are equivalent.

Saying "the platform now has a standard direction here, but coverage is not universal yet" is more accurate than either pretending the problem is solved everywhere or ignoring SPA navigations entirely.

Common mistakes and red flags at the senior level

• Treating a lab score as the goal, rather than as a reproducible proxy for what field data says real users experience.
• Recommending a Chrome-only tool as a universal solution, without noting the coverage gap. The same applies to any browser-specific API.
• Describing a performance budget with no enforcement mechanism and no answer for what happens when it is breached.
• Assuming server-side rendering is a performance win everywhere, without separating the paint benefit from the interactivity cost.
• Optimising before measuring, or continuing to optimise a metric already comfortably inside its threshold while a different one is failing.

Frequently asked questions

Do I need to memorise the exact Core Web Vitals thresholds? Knowing the current targets is reasonable, LCP within 2.5 seconds, INP at or below 200 milliseconds, CLS at or below 0.1, all at the 75th percentile. What matters more in a senior round is knowing that the assessment is percentile-based and split by device, because that is what explains most lab-versus-field disagreements.

Is FID still worth knowing about? Only as context. It is retired and no longer a Core Web Vital, but being able to explain why it was replaced demonstrates you understand what INP measures, which is the point of the question.

How current does my knowledge of performance tooling need to be? Current enough to know what has shipped and where. Tooling in this area moves, so a specific claim about availability is worth re-checking before you make it in an interview; being wrong about whether something is available, or in which browsers, is a more damaging mistake than not mentioning it.

Should I mention specific framework features for hydration? Yes, if the role uses that framework and you have actually used them. Naming a mitigation you have shipped is strong. Listing framework features you have only read about invites a follow-up you will not enjoy.

How to prepare

Work through GreatFrontEnd's web performance interview questions first if the metric definitions and debugging basics are not already automatic, since a senior round assumes that level. From there, the highest-value preparation is having one real performance problem you personally diagnosed that you can walk through end to end: what the field data said, how you narrowed it, what you changed, and how you confirmed real users saw the improvement. Senior rounds tend to follow up on specifics, and a real story survives follow-ups that a rehearsed answer does not. The same judgment-first pattern runs through the rest of this series, including GreatFrontEnd's guides on senior CSS, senior HTML, and senior Node.js interview questions.

Conclusion

Senior web performance developer interview questions test whether you can own the measurement, not whether you can recite the metrics. Reading INP's three phases to locate a bug, explaining why lab and field data disagree, enforcing a budget rather than declaring one, separating the paint benefit of server rendering from its interactivity cost, and being honest about the parts of single-page-app measurement that are still unsolved are the actual differentiators. What separates a senior answer is having made these calls on a real product and being able to say what happened.