JPJobPrepfull-stack interview
RoadmapsJS CompilerStar on GitHub
Career Roadmaps · Web Performance

Career roadmap

Web Performance Engineer

Turn slow into fast, and prove it with numbers that connect to revenue.

Time
4-6 months part-time
Entry bar
Solid frontend experience and comfort reading a waterfall chart.
Stages
5 · 25 topics
0/25 studied0%
All roadmaps

Before you start Web Performance

  • JavaScript, HTML and CSS at working level
  • Browser DevTools familiarity
  • Basic understanding of HTTP

Measurement first

3-4 weeks · 0/5 topics

You cannot optimise what you have not measured. Everything else depends on this stage.

  1. The metrics Google ranks on and executives quote. Know exactly what each one measures.

    • LCP: element, phases and typical causes
    • INP: what replaced FID and why
    • CLS: layout instability sources
    • Thresholds and the 75th percentile rule

  2. The most common mistake is optimising a lab score while field users stay slow.

    • Lighthouse and its limitations
    • CrUX and real user monitoring
    • Synthetic monitoring and alerting
    • Sampling and percentile reasoning

  3. Reading a performance trace quickly is the core practical skill of the role.

    • Performance panel and flame charts
    • Network waterfall and priorities
    • Coverage and unused code
    • Throttling that matches real conditions

  4. The reason this role is funded. Learn to make the argument with data.

    • Conversion and bounce correlation
    • A/B testing a performance change
    • Performance budgets as a contract
    • Reporting to non-engineers

  5. Latency, TLS and protocol behaviour set the floor on what is achievable.

    • DNS, TCP, TLS handshake costs
    • HTTP/2 and HTTP/3 multiplexing
    • Compression: gzip vs brotli
    • CDN behaviour and cache hit ratio

BuildInstrument a real site with RUM, and publish a dashboard showing field vitals at the 75th percentile.

Loading performance

4-5 weeks · 0/5 topics

Getting the first meaningful pixels on screen as early as physically possible.

  1. What blocks the first paint, and how to unblock it in the right order.

    • Render-blocking CSS and JavaScript
    • Critical CSS extraction and inlining
    • Resource hints: preload, preconnect, prefetch
    • Fetch priority and lazy loading

  2. The single largest lever on most sites: ship less script.

    • Bundle analysis and dependency weight
    • Code splitting and route-level chunks
    • Tree shaking and side effects
    • Polyfill strategy and differential serving

  3. Usually the largest bytes on the page, and usually the easiest win.

    • AVIF and WebP with fallbacks
    • Responsive images: srcset and sizes
    • Lazy loading and the LCP exception
    • Video posters and streaming formats

  4. A classic source of both CLS and invisible text.

    • font-display strategies
    • Subsetting and unicode-range
    • Self-hosting vs third-party
    • Metric-compatible fallbacks

  5. The fastest request is the one that never leaves the device.

    • Cache-Control and immutable assets
    • Stale-while-revalidate
    • Service workers and offline caching
    • Edge rendering and CDN cache keys

BuildTake a real page from a 4s LCP to under 2.5s on a throttled mobile connection, documenting each change.

Runtime performance

4-5 weeks · 0/5 topics

After it loads, keep it responsive. INP made this a first-class ranking concern.

  1. INP is the newest and least understood vital, which makes it interview-relevant.

    • Long tasks and input delay
    • Yielding to the main thread
    • scheduler.yield and isInputPending
    • Event handler cost

  2. Style, layout, paint, composite — and which properties skip which steps.

    • Layout thrashing and forced synchronous layout
    • Compositor-only animation properties
    • will-change and content-visibility
    • Paint areas and layer explosion

  3. Long-lived single-page apps get slower over a session. Nobody tests for it.

    • Heap snapshots and retained size
    • Detached DOM nodes
    • Listener and timer leaks
    • Memory on low-end devices

  4. Where the abstraction costs you, and what the framework gives you to fix it.

    • React render profiling and memoisation
    • Virtualisation for long lists
    • Hydration cost and partial hydration
    • Islands and server components

  5. Web workers and WASM for the genuinely expensive cases.

    • Web workers and transferable objects
    • Comlink and worker ergonomics
    • WebAssembly for compute-heavy paths
    • OffscreenCanvas

BuildFind and fix the three worst long tasks on a real application, with trace evidence before and after.

Keeping it fast

3-4 weeks · 0/5 topics

Performance regresses by default. The real job is building the ratchet.

  1. A number in CI is worth more than a wiki page nobody reads.

    • Choosing budgets that bite
    • Bundle size limits per route
    • Lighthouse CI in the pipeline
    • Handling justified budget breaks

  2. Catching a regression the day it ships, not the quarter it ships.

    • RUM alerting on percentile shifts
    • Per-release performance comparison
    • Attribution: which change caused it
    • Third-party script monitoring

  3. Usually the worst offender and the hardest political fight.

    • Auditing tag manager payloads
    • Facades for embeds and chat widgets
    • Partytown and worker offloading
    • Negotiating removal with marketing

  4. Performance work that depends on one person disappears when that person leaves.

    • Dashboards teams actually look at
    • Performance review in design and PR
    • Teaching profiling to product teams
    • Documenting the known slow paths

  5. TTFB is often the real problem, and it is not a frontend fix.

    • Time to first byte and server rendering cost
    • Database query time in the request path
    • Edge caching and regional latency
    • Streaming HTML responses

BuildAdd performance budgets and a CI gate that fails a pull request which regresses LCP or bundle size.

Interview and evidence

2-3 weeks · 0/5 topics

This role hires almost entirely on demonstrated, measured results.

  1. Given a slow page and DevTools, find the problems out loud. The core interview.

    • Systematic trace reading
    • Prioritising by impact, not ease
    • Explaining findings to a mixed audience
    • Proposing a remediation order

  2. Design the delivery architecture for a large site under a latency budget.

    • CDN and edge strategy
    • Rendering mode selection per route
    • Caching layers and invalidation
    • Global latency and regional deployment

  3. A small, stable set of questions covers most performance interviews.

    • What exactly is LCP measuring here
    • How would you cut INP on this page
    • Preload vs prefetch vs preconnect
    • Why did CLS get worse after the fix

  4. Numbers with a methodology attached. Vague claims are worse than none.

    • Before and after field data
    • Methodology and confounders declared
    • Business impact where you can measure it
    • Open-source contributions to tooling

  5. Most performance work is convincing other teams to change their code.

    • Getting a third-party script removed
    • Prioritising against feature deadlines
    • Explaining a regression to leadership
    • Teaching a team to profile

BuildA public case study: the site, the trace, the changes, and the field data movement afterwards.

Web Performance tools on your CV

  • Chrome DevTools
  • Lighthouse CI
  • WebPageTest
  • CrUX / RUM
  • Perfetto
  • Bundle analysers
  • Partytown
  • k6

What Web Performance employers ask to see

  • A public case study with before/after field data
  • A CI performance gate adopted by a real project
  • A trace-backed write-up of a long-task fix
  • A measured third-party script removal with impact numbers

A specialism that pays because it is measurable. E-commerce, media and any business with a conversion funnel funds it directly, and Core Web Vitals made it a board-level metric.

Content last reviewed 2026-08-31. Guidance only — no institute or paid placement is endorsed anywhere in this book.