Suggest an editImprove this articleRefine the answer for “Minimizing HTTP requests”. Your changes go to moderation before they’re published.Approval requiredContentWhat you’re changing🇺🇸EN🇺🇦UAPreviewTitle (EN)Short answer (EN)**Every HTTP request** is a separate connection to the server (TCP, TLS handshake), latency while the request-response cycle runs, and load on the server and network. **Key point:** the more requests there are, the slower the page renders and the worse metrics like LCP, FCP, and TTFB become.Shown above the full answer for quick recall.Answer (EN)Image## In short: why it matters Every HTTP request is: - a **separate connection** to the server (TCP, TLS handshake), - **latency** while the request-response cycle runs, - **load on the server and network**. The more requests, the **slower the page renders**, the longer it takes to show content to the user, and metrics like LCP, FCP, and TTFB drop. --- ## What happens on every request When the browser makes a new HTTP request (for example, for a CSS, JS, or image file): 1. **DNS resolution** - finding the domain's IP. 2. **TCP connection** - a "handshake" between client and server. 3. **TLS encryption** (if HTTPS) - another handshake. 4. **Request -> response** - the data starts loading. Even if the resource is small, these stages take **tens to hundreds of milliseconds**. And if there are hundreds of such files, the delay adds up. --- ## Why this slows down a site | Problem | What happens | |---|---| | **Long network delays** | While all files load, rendering is delayed | | **Render-blocking resources** | CSS and JS block content from displaying | | **CPU and memory load** | The browser needs to process many files | | **More connections -> more energy** | Especially critical on mobile | | **Core Web Vitals drop** | LCP, FID, TBT, CLS worsen | --- ## Code examples ### Bad: ```javascript <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> ``` - 7 HTTP requests just for CSS and JS. ### Better: ```javascript <link rel="stylesheet" href="bundle.min.css"> <script src="bundle.min.js" defer></script> ``` - 2 requests instead of 7. CSS and JS are minified and bundled. --- ## How to reduce the number of HTTP requests ### 1. Bundling and minification - Combine CSS and JS (Webpack, Vite, Rollup, esbuild, Next.js does this by itself). - Minify (remove whitespace, shorten variable names). ### 2. Icon sprites - SVG sprites or a single PNG sprite instead of dozens of small images. - In CSS you can use `background-position` to crop them out. ### 3. Use `image-set()` and `srcset` - Instead of loading every size of an image, load only the one that fits the screen. ### 4. HTTP/2 and HTTP/3 - These protocols allow **multiplexing** several files over a single connection. - But even then, fewer requests mean fewer headers, less overhead. ### 5. Caching and a CDN - Use the `Cache-Control`, `ETag`, `Last-Modified` headers. - Then the browser makes no new requests if the resources haven't changed. ### 6. Lazy Loading - Load images, video, and JS only when they're actually needed. ### 7. Inlining - Critical CSS or SVG can be inserted directly into HTML (`<style>` or `<svg>`). - Especially important for above-the-fold content. --- ## Numbers for reference | Resource type | Average weight | Effect on loading | |---|---|---| | CSS/JS | 30-500 KB | Blocks rendering | | Images | 100-1000 KB | Long load time | | Fonts | 30-150 KB | Can cause a Flash of Invisible Text | | API requests | 100-500 ms latency | Delays content | > Even **10-20 small 5 KB files** can slow a page down **by hundreds of milliseconds** - purely from network delays. --- ## The result of optimization After minimizing requests: - faster first render (First Paint); - lower Time to Interactive (TTI); - fewer render-blocking resources; - better SEO and Core Web Vitals; - the site feels like it "flies" to the user. --- ## Short conclusion | Reason | Why minimize | |---|---| | Fewer network delays | Faster page loading | | Less overhead | Less CPU and memory | | Better on mobile | Less battery and data usage | | Better SEO | Google ranks fast sites higher | | Improves UX | The user sees content faster |For the reviewerNote to the moderator (optional)Visible only to the moderator. Helps review go faster.