Full-Stack Performance: From Database to Browser

"The page is slow" is not a bug report. A request goes through the browser, the network, your server, your database and back. Time can be lost in any of them, and a fix in the wrong place changes nothing. Interviewers ask this topic to see if you work by evidence or by guessing.

This lesson does not repeat the basics. For the Core Web Vitals numbers (LCP, INP, CLS) see Browser, Lesson 09. For the question "the API is fast but the UI is slow" see Debugging, Lesson 01, and for the opposite case see Debugging, Lesson 02. For Redis, cache patterns and stampedes see Full-Stack Q&A, Lesson 18. For indexes, MVCC, locks and PgBouncer in more depth see Lesson 27. For HTTP cache headers see Browser, Lesson 05. Here we connect them into one path from the database to the browser, and we measure each step.

Words used in this lesson

• Latency is how long one request takes, from sending to getting the full answer. Throughput is how many requests finish per second. They are linked, but they are not the same number.
• A percentile is a position in a sorted list of timings. p50 (the median) is the time that half of the requests beat. p95 is the time that 95 out of 100 requests beat, so 5 are slower. p99 is the same for 99 out of 100. The slowest few are called the tail.
• A bottleneck is the one step that limits the whole system. Making any other step faster does not help.
• A query plan is the list of steps that the database chose to answer a query. EXPLAIN ANALYZE shows that plan and also runs the query to show real times.
• A sequential scan (seq scan) reads the whole table. An index scan uses an index to jump to the matching rows.
• N+1 is a pattern where you run 1 query to get a list, then N more queries, one for each item in the list.
• A connection pool is a small set of open database connections that your code borrows and returns, so each request does not open a new one.
• A cache is a stored copy of an answer, so you do not compute it again. A cache hit is when the copy is found. A TTL (time to live) is how long a copy may be used.
• TTFB (time to first byte) is the time until the first byte of the response arrives.
• Streaming means sending a response in parts while the server is still working on the rest. Suspense is the React tool that marks which part of the page may arrive later, and what to show in the meantime (the fallback).
• A load test sends many requests on purpose, to see how the system behaves under pressure. A closed model test keeps a fixed number of connections busy: a new request starts when the last one ends. An open model test sends requests at a fixed rate, whatever the server does.
• Coordinated omission is a measuring mistake in closed tests: when the server stalls, the test stops sending, so the slow period is under-counted and the percentiles look better than the truth.

Part 1. Find the bottleneck first

The method is the same one from Debugging, Lesson 00: measure, isolate, change one thing, measure again. For a full-stack path, "isolate" means: which layer owns most of the time?

Two habits make this work:

1. Decide what "fast enough" means before you start. For example "p95 under 300 ms at 200 requests per second". Without a target you never know when to stop.
2. Measure the same thing before and after. Same data, same machine, same load, several runs. One run is a story. Three runs are a result.

A useful quick check is the Server-Timing response header. It lets your server report its own parts of the time, and the browser DevTools shows them in the Network panel. For example Server-Timing: db;dur=3.1, render;dur=7.4. It costs almost nothing and ends many arguments.

Part 2. The database

Reading EXPLAIN ANALYZE

I made a table orders with 1,000,000 rows (50 MB of table data) and 10,000 users, so each user has 100 orders. The query is the typical "latest 20 orders of one user":

EXPLAIN (ANALYZE, BUFFERS)SELECT * FROM orders WHERE user_id = 42 ORDER BY created_at DESC LIMIT 20;

Without a useful index, Postgres 16 chose this (I removed some lines):

 Limit  (actual time=38.383..46.810 rows=20 loops=1)   Buffers: shared hit=6484   ->  Gather Merge  (actual time=38.380..46.805 rows=20 loops=1)         Workers Planned: 2   Workers Launched: 2         ->  Sort  (actual time=34.286..34.289 rows=17 loops=3)               Sort Key: created_at DESC               Sort Method: top-N heapsort  Memory: 26kB               ->  Parallel Seq Scan on orders  (actual time=0.228..34.161 rows=33 loops=3)                     Filter: (user_id = 42)                     Rows Removed by Filter: 333300                     Buffers: shared hit=6370 Execution Time: 46.952 ms

Then I added a composite index and ran the same query again:

CREATE INDEX orders_user_created_idx ON orders (user_id, created_at DESC);

 Limit  (actual time=0.043..0.180 rows=20 loops=1)   Buffers: shared hit=20 read=3   ->  Index Scan using orders_user_created_idx on orders  (actual time=0.042..0.177 rows=20 loops=1)         Index Cond: (user_id = 42) Execution Time: 0.229 ms

How to read these, from the bottom of the tree up:

The machine-independent conclusion here is not "47 ms became 0.2 ms" (that depends on my CPU and cache). It is: the work changed from reading about 6,400 pages to reading about 23 pages. Pages read is a count, and it is the same on any machine. The index in the second plan is 30 MB, so it costs disk space and slows writes; I have not measured the write cost.

Indexes themselves, partial and covering indexes, and the order of columns are in Lesson 27. Two rules are worth repeating here. In a composite index, put the equality column first (user_id), then the sort column (created_at): the database can then read the rows already in order and stop after 20. And a function on the column (WHERE created_at::date = ...) hides the index.

N+1: many small queries

A database query is fast, but each one is also a round trip: send the query, wait, receive. Twenty-one round trips cost much more than one, even if each query is tiny.

// N+1: 1 query for the list, then 1 query per row (21 queries)const { rows } = await pool.query('SELECT id, user_id, total FROM orders WHERE id >= $1 ORDER BY id LIMIT 20', [start]);for (const o of rows) {  const u = await pool.query('SELECT name FROM users WHERE id = $1', [o.user_id]);  o.name = u.rows[0].name;}// One query with a joinconst { rows } = await pool.query(  `SELECT o.id, o.user_id, o.total, u.name FROM orders o JOIN users u ON u.id = o.user_id   WHERE o.id >= $1 ORDER BY o.id LIMIT 20`, [start]);

Inside Postgres, the join took 0.485 ms (EXPLAIN ANALYZE; it looked up the 20 users with an index, loops=20). In the HTTP test (Part 8) it was about 6 times faster in requests per second than the N+1 version. The point: the time is lost between your server and the database, not inside the database.

N+1 hides in ORMs and in GraphQL resolvers, because the loop is not visible in the code. How to find it: count the queries per request (turn on the query log in development), and look for the same query shape repeated. Fixes: a join, WHERE id = ANY($1) with a list of ids, or a batching tool (a DataLoader, or Prisma's include). See Backend, Lesson 08 and Lesson 08.

Connection pooling

Opening a Postgres connection is expensive: a new TCP (or Unix) connection, authentication, and on the server a new operating system process. So a server keeps a pool. With node-postgres, new Pool() uses a maximum of 10 connections by default (I read it in the pg-pool source: this.options.max = ... || 10). A request borrows a connection and gives it back. If all 10 are busy, the next query waits in a queue.

Three things to know:

• Too small a pool makes requests wait in your app. Too large a pool makes the database do too much at once. My local server had max_connections = 100 (the default of my install), and each connection is a process, so thousands of connections are not an option.
• Every app instance has its own pool. 20 instances with a pool of 10 means up to 200 connections.
• For many instances or serverless functions, put a pooler in front (PgBouncer). The modes, and what breaks with SET and prepared statements, are in Lesson 27.

In Part 8 I compare the same query with a pool and with a new connection per request.

Part 3. Caching layers and what to cache

A request can be answered at many places. The closer to the user, the cheaper the answer, and the harder it is to change.

What is worth caching

A good cache candidate has all of these:

1. It is expensive to compute (a slow query, a call to another service), or it is asked very often.
2. It is read much more than it is written.
3. It can be a little stale without harm (a product list, yes; an account balance before a payment, no).
4. It is the same for many users, or it has a key that separates users safely.

Do not cache what is cheap. Caching adds code, memory and a new way to be wrong. My own test below shows this clearly: caching a join that already takes about 0.5 ms in the database gave only a small gain. Fix the query first, cache second.

Rules that avoid the usual bugs (details in Lesson 18):

• Put a TTL on everything, so a mistake heals itself.
• Make the cache key include everything the answer depends on: user id, language, query parameters. A missing part of the key shows one user's data to another.
• Never put private data in a shared cache (CDN) without private or a key per user.
• Plan invalidation: on a write, delete or update the key, or accept staleness until the TTL ends.
• Protect against a stampede: when a popular key expires, many requests recompute it at once. Use a lock, a short random extra TTL, or serve the stale value while one request refreshes it.
• Watch the hit ratio (hits divided by hits plus misses). A cache with a low hit ratio is only extra work.

Part 4. HTTP compression and caching headers

Compression

Text compresses well. I took 1,000 rows of JSON (order id, user id, price, name, timestamp), which is 100,354 bytes, and compressed it with Node's built-in zlib:

The conclusions that do not depend on my machine: compression cut this JSON to about one seventh or less; going from gzip level 6 to level 9 gains almost nothing but costs three times the time; and the highest brotli level is far too slow to run on every response. Use it for static files that you compress once at build time, and use a low or middle level for dynamic responses. My data is repeated and regular, so it compresses better than most real data. Already-compressed files (JPEG, PNG, WebP, video) should not be compressed again.

The client says what it accepts with Accept-Encoding: gzip, br, and the server answers with Content-Encoding: gzip and Vary: Accept-Encoding (so a cache stores one copy per encoding). In Next.js, next start compresses with gzip by default (compress: true). I checked: with Accept-Encoding: gzip the response had Content-Encoding: gzip. If you use nginx or a CDN that does brotli, the Next.js docs say to set compress: false so you do not compress twice.

Caching headers

The browser side is in Browser, Lesson 05. The short table you need for performance:

ETag and Last-Modified let the browser ask "has it changed?" and get a tiny 304 Not Modified instead of the whole body. This saves bandwidth, not the server's work, unless your server can answer the question without doing the full render.

Part 5. Streaming and Suspense in Next.js

Without streaming, the server must finish all the data work before it sends the first byte. One slow query then delays the whole page, including the parts that were ready at once. With streaming, the server sends the page shell (layout and fallbacks) at once, and sends each slow part when it is ready (this is how the Next.js "Streaming" guide describes it; it uses chunked transfer encoding and React's <Suspense> boundaries).

I built two pages. Both have a slow part that takes 1000 ms. The first has no Suspense. The second wraps the slow part in <Suspense>:

// app/blocking/page.jsx  (no Suspense)export default async function Page() {  await connection();                          // make the route dynamic  return (<main><h1>Shell</h1><Slow /></main>);   // Slow awaits 1000 ms}// app/stream/page.jsx  (with Suspense)export default function Page() {  return (<main><h1>Shell</h1>    <Suspense fallback={<p>loading...</p>}><Slow /></Suspense></main>);}

I requested each page three times with curl -w "ttfb=%{time_starttransfer} total=%{time_total}":

The response had Transfer-Encoding: chunked, and the first chunk already contained <h1>Shell</h1> and <p>loading...</p>. With Accept-Encoding: gzip the page was still streamed (TTFB 0.012 s). The conclusion that holds on any machine: streaming does not make the slow work faster. The total stayed at about 1 second. It moves the first byte, and the visible shell, from about 1 s to about 10 to 20 ms. The browser can start loading CSS and JavaScript, and the user sees something.

Rules for using it well:

• Put a <Suspense> boundary around the slow part, not around the whole page. Sibling boundaries load independently and do not block each other. loading.js is a shortcut that wraps a whole page segment.
• Start slow requests in parallel. Two awaits in a row add up. Start both promises first, or give each its own Suspense boundary.
• A page that streams has already sent status 200 when the shell goes out, so a later notFound() cannot change the status code (see Lesson 27).
• Proxies can ruin it. The Next.js self-hosting guide says that nginx and similar proxies need buffering turned off (X-Accel-Buffering: no), and that some load balancers buffer by default. If TTFB is still slow in production but fast on your machine, check for buffering.
• Streaming helps TTFB and often LCP (see Browser, Lesson 09), but a big fallback or a layout that jumps when the real content arrives can hurt CLS. Give the fallback the same size as the content.

Part 6. Images, fonts and bundle size

The browser has to download, parse and run what you send. This is the usual cause when "the API is fast but the UI is slow" (Debugging, Lesson 06 covers it).

Images

Images are often the biggest files and the LCP element. What to do with next/image (from the Next.js docs):

• Always give width and height (or use fill). The browser then reserves the space and the page does not jump (CLS).
• Use the preload prop (Next.js 16; the old priority prop is deprecated) only for the main image above the fold. The docs say that in most cases loading="eager" or fetchPriority="high" is enough. Everything else is lazy by default (loading="lazy").
• Use the sizes prop so a phone does not download a desktop-sized file.
• The default output format is WebP. You can add AVIF (formats: ['image/avif', 'image/webp']), but the docs warn that each format is cached separately, so the cache grows.
• Static imports get a content hash and are cached "forever" with immutable.

Fonts

next/font downloads the font at build time and serves it from your own domain, so the browser makes no request to Google. It also helps avoid layout shift. Use a variable font (one file for all weights) when you can, limit subsets, and load only the weights you really use. Every extra font file is a request and a chance of a flash of wrong text.

Bundle size

JavaScript costs more than its download size, because the browser must also parse and run it. Steps:

1. Look first. In Next.js 16.1 and later there is an experimental analyzer: npx next experimental-analyze (Turbopack). For webpack there is the @next/bundle-analyzer plugin. Both are described in the Next.js "Package bundling" guide.
2. Keep the client small. Server Components send no component JavaScript to the browser. Mark only the interactive part with 'use client', not the whole tree.
3. Lazy load what is not needed at first: a modal, a chart, an editor. Use next/dynamic or React.lazy with Suspense.
4. Import less. Import one function, not the whole library. Replace a heavy library with the platform (Intl, fetch, structuredClone) when you can.
5. Set a budget (for example "main JavaScript under 170 kB gzipped") and fail the build if it is exceeded. Choose your own number, based on your users' devices.

Part 7. Load testing and how to read p50, p95 and p99

Two tools

autocannon is a small Node tool. You give it a number of connections and a duration:

npx autocannon -c 20 -d 10 http://127.0.0.1:3099/join

-c is the number of connections, -d is the duration in seconds. It is a closed model tool: each connection sends the next request when the last one finishes. Its latency table shows the 2.5th, 50th, 97.5th and 99th percentiles (from its README), so it has no p95; I use p97.5 as the "slow outlier" number. With -R (overall rate) it sends at a fixed rate and corrects for coordinated omission.

k6 (Grafana) uses JavaScript test scripts and has thresholds that fail the run. Its constant-arrival-rate executor is an open model: it starts a fixed number of requests per second whatever the server does.

// k6 script (I ran this)import http from 'k6/http';import { check } from 'k6';export const options = {  scenarios: { open: { executor: 'constant-arrival-rate', rate: 1500, timeUnit: '1s',                       duration: '8s', preAllocatedVUs: 100, maxVUs: 400 } },  thresholds: { http_req_duration: ['p(95)<100', 'p(99)<200'], http_req_failed: ['rate<0.01'] },};export default function () { check(http.get('http://127.0.0.1:3099/join'), { ok: (r) => r.status === 200 }); }

In k6, http_req_duration is the time of sending, waiting and receiving, without the DNS and connection time (k6 metrics reference). dropped_iterations counts requests that k6 could not start because it ran out of virtual users.

Closed or open: why it matters

A real website is an open system: users arrive when they want, not when your last request ended. If the server slows down, users still arrive, and a queue grows. A closed test hides this, because the test "waits politely". I ran the same N+1 endpoint in an open test:

At 400 per second the endpoint was healthy. At 1500 per second it could only do about 660, and latency went up by a factor of about 100 and the queue grew. The lesson that holds everywhere: a system has a knee. Below it, latency is flat. Above it, latency explodes. The right question is not "what is the average?" but "at what rate does p99 leave our target?"

Reading the percentiles

• p50 shows the typical request. p95 and p99 show what unlucky users feel. Averages hide the tail. Report percentiles, never only the mean.
• The tail adds up across calls. If one page view makes 20 calls and each call is slower than its p99 only 1% of the time, then the share of page views with no slow call is 0.99 to the power of 20, which is about 82%. So about 18% of page views get at least one slow call (this assumes the calls are independent, which is only roughly true).
• Watch the max and the shape. A p99 far above p95 usually means rare events: garbage collection, a lock, a cold cache, a connection being opened.
• In a closed test, latency and throughput are one number seen twice. With 20 connections, the average latency is about 20 divided by the requests per second. This is Little's law: the number of requests in the system equals the throughput times the average time each one spends there. My results agree: 20 / 4,940 per second is about 4 ms, close to the median of 3 ms; and 20 / 46 per second is about 435 ms, close to the 412 ms median of the no-index test. So you cannot improve throughput "and" latency separately in a closed test. They move together.
• Warm up. The first run in my test had worse tails than the next two (the N+1 endpoint had p99 of 129 ms in run 1, and 50 and 46 ms in runs 2 and 3). Throw away the first run, or run longer.
• Do not run the load tool on the machine you test, if you can avoid it. I did, so my top numbers are limited by shared CPU.

Part 8. The experiment: seven ways to answer the same request

All variants return 20 rows as JSON from the same Node server. The server picks a random key from 9,000 values for each request, so there is no one hot row. I ran each variant with autocannon -c 20 -d 6 (20 connections, 6 seconds), three times each in rotation (all variants, then all again, then again), and I report the median of the three runs.

The variants:

The cache part of the code, for example:

const cache = new Map();                       // key -> { at, rows }async function cached(start) {  const hit = cache.get(start);  if (hit && Date.now() - hit.at < 60_000) { hits++; return hit.rows; }  misses++;  const rows = await join(start);              // the one-query version  cache.set(start, { at: Date.now(), rows });  return rows;}

Results (median of three runs, 20 connections):

There were no errors and no non-2xx answers in any run. During the cached runs the hit ratio over the whole session was about 91% (177,383 hits and 18,002 misses).

What I conclude, and how sure I am:

1. The index is worth about two orders of magnitude in this setup (46 to 5,943 requests per second, p50 from 412 ms to 2 ms). The size of the gap depends on the table size, and the shape does not: a seq scan costs more as the table grows, an index lookup barely does. This is the biggest and most certain win.
2. N+1 cost about 6 times the throughput and gave a p99 about 5 times worse than the join (50 ms against 9 ms). The cause is 21 round trips. The ratio depends on how far the database is from the server: on my machine it is a Unix socket on the same host, which is the best case for N+1. With a network between them, N+1 would be worse. That last sentence is an expectation from how round trips work, not something I measured.
3. A new connection per request cost about 12 times the throughput against a pool. Again this is the best case for "no pool": a local socket and no TLS. With a network and TLS it would be worse.
4. The cache gave only about 2 times the throughput over the join, and the p99 went from 9 ms to 7 ms. The join was already about 0.5 ms in the database, so there was little to save. The cache helps most when the original work is slow, and here the Node server itself (JSON, HTTP) became the limit. So: fix the query first, then decide if you still need a cache.
5. The order of the wins (index, then N+1, then pool, then cache) matches the advice "do the cheap, structural fixes first". The exact numbers will be different on your machine. If you reproduce the test, expect the same order and similar ratios, not the same milliseconds.

To run it yourself you need a Postgres, the setup SQL (two tables, 1,000,000 orders, an ANALYZE, and an index for the indexed route), a small Node server with the seven routes and pg, and npx autocannon. The pieces are all shown above; the rest is plain http.createServer and pool.query.

Part 9. Measuring before and after with numbers

A short checklist for any performance change you want to defend:

1. Write the target (for example "p95 under 100 ms at 500 requests per second").
2. Record the baseline: the number, the date, the commit, the machine, the data size and the tool settings.
3. Change one thing. If you change an index and add a cache together, you do not know which one helped.
4. Repeat at least three runs, drop the warm-up run, and report the median and the spread.
5. Compare ratios and counts (pages read, queries per request, bytes sent), not only milliseconds. Counts are stable across machines.
6. Check in production. Use real-user data for the browser (see Core Web Vitals in Browser, Lesson 09) and percentiles from your server metrics. A test shows a possibility; production shows the truth.
7. Write down what you did not fix, and what you saw get worse (write speed, memory, complexity).

Common mistakes

• Optimising before measuring, and fixing the layer that was not slow.
• Reporting only the average. The tail is what users remember.
• Testing with one hot row or one URL, so the database cache makes everything look fast.
• Running one test run, or comparing a cold run with a warm one.
• Adding a cache before fixing the slow query, then fighting stale data forever.
• A cache key that misses the user or the language, so users see each other's data.
• A pool of 100 per instance on 30 instances, so the database runs out of connections.
• Loading a big library for one function, or marking a whole page 'use client'.
• Using a closed test to claim "we handle 5,000 requests per second", when real users arrive at a fixed rate.
• Forgetting that a proxy buffers the response, so streaming works locally and not in production.

Interview questions

Key takeaways

• Find the layer that owns the time before you change anything. Set a target. Change one thing. Measure again.
• Read plans for Seq Scan, Rows Removed by Filter, row estimate gaps and Buffers. Counts of pages are stable across machines; milliseconds are not.
• N+1 and connection setup cost round trips. Use a join or a batch, and a pool. On my machine the index, the join and the pool each changed throughput by a large factor, and the cache by a small one.
• Cache work that is expensive, read often and tolerates staleness. Always use a TTL and a full key. Fix the query before you cache it.
• Compress text, not images. Use a middle gzip or low brotli level for dynamic responses and the highest level only at build time. Hashed files get immutable.
• Streaming moves the first byte earlier; it does not make slow work faster. Put <Suspense> around the slow part, and check for proxy buffering.
• Size images, load fonts with next/font, and look at the bundle with an analyzer before you cut.
• Use percentiles, repeat runs, and prefer an open model for capacity questions. Say what the numbers do not show.

What's next

Go to Lesson 33 for Node.js internals: the event loop phases, the threadpool, streams and backpressure, which are the parts under many of the numbers in this lesson. For the Postgres side in more depth, return to Lesson 27, and for Redis patterns to Lesson 18.