Minimizing HTTP requests

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:

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

#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

#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

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.

#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.