Suggest an edit

Improve this article

Refine the answer for “Minimizing HTTP requests”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

**Minimizing HTTP requests matters because every request costs a separate connection, network latency and server load, not just the bytes it transfers.** The fewer requests a page makes, the sooner the browser reaches rendering, and the better LCP, FCP and TTFB turn out.

## Theory

### TL;DR
- Every request means DNS resolution, a TCP connection, a TLS handshake, and only then the data transfer.
- Even a tiny 5 KB file costs tens or hundreds of milliseconds of latency, and those delays add up.
- CSS and JS block rendering, so extra requests postpone the moment the user sees content.
- Techniques: bundling and minification, sprites, `srcset` and `image-set()`, HTTP/2 and HTTP/3, caching and a CDN, lazy loading, inlining critical CSS.
- The payoff: a faster First Paint, a lower TTI, better Core Web Vitals and better SEO.

### Quick example

Bad, 7 HTTP requests just for CSS and JS:

```html
<link rel="stylesheet" href="reset.css">
<link rel="stylesheet" href="grid.css">
<link rel="stylesheet" href="header.css">
<link rel="stylesheet" href="footer.css">
<script src="jquery.js"></script>
<script src="slider.js"></script>
<script src="form.js"></script>
```

Better, 2 requests instead of 7, files merged and minified:

```html
<link rel="stylesheet" href="bundle.min.css">
<script src="bundle.min.js" defer></script>
```

### What happens on every request

When the browser goes after a new resource (CSS, JS or an image), it walks the full cycle each time:

1. **DNS resolution**: find the IP address of the domain.
2. **TCP connection**: the handshake between client and server.
3. **TLS encryption** (over HTTPS): one more handshake.
4. **Request and response**: only now does the data start to arrive.

Even if the resource is tiny, these stages take tens or hundreds of milliseconds. And when there are hundreds of such files, the delay accumulates.

### Why this slows the site down

| Problem | What happens |
| --- | --- |
| **Long network delays** | Rendering is postponed while all the files load |
| **Render-blocking resources** | CSS and JS block the display of content |
| **CPU and memory load** | The browser has to process many files |
| **More connections, more power** | Especially critical on mobile |
| **Core Web Vitals drop** | LCP, FID, TBT, CLS all get worse |

### How to reduce the number of HTTP requests

**1. Bundling and minification.** Merge CSS and JS (Webpack, Vite, Rollup, esbuild; Next.js does it for you). Minification strips whitespace and shortens variable names.

**2. Sprites for icons.** One SVG sprite or a single PNG sprite instead of dozens of small images. In CSS you cut out the piece you need with `background-position`.

**3. `image-set()` and `srcset`.** Instead of downloading every size of an image, the browser takes only the one that fits the current screen.

**4. HTTP/2 and HTTP/3.** These protocols multiplex several files over one connection. But even with them, fewer requests means fewer headers and less overhead.

**5. Caching and a CDN.** The `Cache-Control`, `ETag` and `Last-Modified` headers let the browser skip a new request while the resource has not changed.

**6. Lazy loading.** Load images, video and JS only when they are genuinely needed.

**7. Inlining.** Critical CSS or a small SVG can go straight into the HTML (`<style>` or `<svg>`). That matters most for above-the-fold content.

### Ballpark numbers

| Resource type | Typical weight | Effect on loading |
| --- | --- | --- |
| CSS/JS | 30-500 KB | Block rendering |
| Images | 100-1000 KB | Long download |
| Fonts | 30-150 KB | Can cause a Flash of Invisible Text |
| API requests | 100-500 ms latency | Content is delayed |

> Even 10-20 small 5 KB files can slow a page by hundreds of milliseconds, purely because of network round trips.

### What optimization buys you

After minimizing requests:

- a faster first render (First Paint);
- a lower Time to Interactive (TTI);
- fewer render-blocking resources;
- better SEO and Core Web Vitals;
- the site simply feels fast to the user.

| Reason | Why minimize |
| --- | --- |
| Fewer network delays | The page loads faster |
| Less overhead | Less CPU and memory |
| Better on mobile | Less battery and data usage |
| Better SEO | Google ranks fast sites higher |
| Better UX | The user sees content sooner |

### Common mistakes

- **Assuming HTTP/2 cancelled the problem.** Multiplexing removes the connection queue, but not the headers, the prioritization, or the browser's per-resource work.
- **Gluing everything into one giant bundle.** A single 3 MB file blocks rendering worse than a few sensibly split chunks with code splitting.
- **Inlining everything.** A resource embedded in HTML is not cached separately, so inline only the critical minimum.
- **Forgetting cache headers.** Without `Cache-Control` the browser goes back to the server every time, even when the file has not changed.
- **Optimizing only static assets.** A dozen small API requests on page start cost just as much as a dozen images.

Markdown · drag & drop images · ⌘B / ⌘I shortcuts832 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.