Stop 20 · Interview PreparationTechnical · 8/8

Performance across the stack

Part of the Full Stack Developer Roadmap

In short

"The dashboard takes six seconds to load. Fix it." The slow part could be a huge JavaScript bundle, a chatty API or one missing index. Strong answers measure before they touch anything.

Being able to discuss performance holistically — a slow page could be a rendering issue, a slow API, or an unindexed database query, and diagnosing which requires full-stack thinking.

The purple blob sits in an auto-rickshaw stuck in traffic, checking a stopwatch.

Think of it like this

Why is the auto ride so slow?

Is it traffic, the driver stopping for chai, or a long route? Shouting 'go faster' fixes nothing. You time each part of the trip first. Performance work is the same: time each layer, then fix the slowest one.

Watch it happen

Finding the slow six seconds

Measure

Frontend

Network

API

Database

Re-measure

1/6Run Lighthouse on a throttled mobile profile and note LCP, INP and the slowest requests.

The big ideas

What you need to know

Measure first, always

Use Lighthouse, the Network waterfall and server timings. Without numbers you're just guessing.

Ship less JavaScript

Code-split heavy components, lazy-load images, and check bundle size before adding a library.

Fewer, faster round trips

Combine chatty calls, cache safe responses, and serve static pages from a CDN.

The database is often the culprit

Missing indexes, N+1 queries and fetching unused columns slow down even a tiny app.

See it in code

Walk through the code

1app.get("/api/feed", async (req, res) => {2  const t0 = performance.now();3  const posts = await db.post.findMany({ take: 20, orderBy: { createdAt: "desc" } });4  const t1 = performance.now();5  const body = JSON.stringify(posts);6  const t2 = performance.now();7  res.set("Server-Timing", `db;dur=${(t1 - t0).toFixed(1)}, json;dur=${(t2 - t1).toFixed(1)}`);8  res.type("json").send(body);9});10// In DevTools: Network, click the request, open Timing. "db" and "json" appear there.

1/4Time the database query on its own.

The Server-Timing header shows the server's own breakdown right inside Chrome DevTools, next to the network timings.

Save yourself the pain

Common mistakes

Oops

Adding Redis or a CDN before knowing which layer is slow.

Do this instead

Measure each layer first, fix the biggest number, then measure again.

Oops

Testing speed only on your laptop on office Wi-Fi.

Do this instead

Throttle to a mid-range phone on a slow network. That's what many of your users have.

Your mission

Before and after

~45 min

Quick check

Server-Timing shows db;dur=2400 for a list endpoint. What's the best next step?

Go deeper

1Prepare a structured answer: measure first (frontend and backend), then optimize based on data.
2Have a real example ready where you found a performance issue was actually in a layer you didn't initially suspect.
3Practice explaining the full request path when discussing where time is spent.

More technical at this stop