Core Web VitalsPerformance ProfilingCritical Rendering PathPerformance Budgetsmiddle level

A Measurement-First Web Performance Strategy

the question

How do you approach optimizing a website's performance? Which measurements and changes would you prioritize?

what they're testing: The interviewer is probing whether you can turn user-facing performance data into prioritized, measurable improvements instead of applying generic tricks.

a strong answer

Start by measuring the journeys users care about, not by applying a generic checklist. Field data shows LCP, INP, and CLS across real devices and networks. Lighthouse and the browser's Network and Performance panels help reproduce a slow path and locate the bottleneck. Check server response time, the request waterfall, render-blocking work, long main-thread tasks, and layout shifts.

Then fix the highest-impact path. Make the initial HTML and LCP resource arrive early. Keep critical CSS small, compress text assets, optimize images, and avoid shipping JavaScript the page does not need. Use a CDN when measurement shows that it reduces delivery time. Split code and lazy-load below-the-fold media, but do not lazy-load the LCP image. If TTFB is slow, trace the server and application work. If interaction is slow, reduce long tasks and forced synchronous layout.

Re-test on representative devices and connections, then compare before-and-after field data. A performance budget for key timings, JavaScript, and image weight helps prevent gradual regressions. Trade-offs matter: preloading every resource can create contention and delay the content users need first.

Where people slip

the tempting wrong answer, and what's actually true

A Lighthouse score of 100 proves the site is fast for users.
Lighthouse is a lab diagnostic under predefined conditions, while field data shows what real users experienced across their devices and networks.
Every image should use `loading="lazy"` to improve initial load time.
Offscreen images can be lazy-loaded, but lazy-loading the LCP image delays its request and harms LCP.
Setting `fetchpriority="high"` on every image makes them all load faster.
High priority should be limited to one or two critical images because applying it broadly makes prioritization less useful.
Minifying JavaScript is enough to solve poor interaction performance.
Minification reduces transfer size, but long main-thread tasks and expensive rendering work still need to be profiled and reduced.

If they push further

What is the difference between lab and field performance data?

Lab data is repeatable and useful for diagnosis under controlled conditions. Field data captures real devices, networks, and user behavior, so when it is available it is the better evidence of production experience.

How would you investigate a poor LCP score?

Find the LCP element, then break its timing into TTFB, resource load delay, resource load duration, and element render delay. The largest part points toward server delivery, discovery and priority, asset size, or render-blocking work.

How do you keep performance from regressing?

Set budgets for user-facing timings and asset sizes, check them in CI where practical, and monitor field metrics after deployment. Review exceptions as product trade-offs instead of silently moving the limits.

Sources

Now answer it yourself.

Reading a strong answer is easy. Producing one under pressure is the skill the interview tests. Gapmap grades your answer against the same bar an interviewer would.

was this useful?

beta

The interviewer part is in the works.

The diagnostic, personal maps, and AI mock interviews are being finished right now. The notes stay free either way. Leave an email and you'll get the first-cohort invite, plus a month of Pro when it opens.