Guide Speed & Performance

How to reduce the number of requests a page makes

Why every extra file a page loads adds delay, and how to cut the number down without changing how the page looks.

iFastHosting Support Team Updated 26 August 2026 8 min read Intermediate

Every image, stylesheet, script and font on a page is a separate request, and each one carries its own overhead before the actual file content even starts arriving — a connection to negotiate, headers to exchange, a queue to wait in behind other requests competing for the same limited number of connections a browser will open at once. A page that makes a small number of requests for a modest amount of data will generally load more predictably than one that makes a great many requests, even if the total amount of data downloaded is not enormously different.

This is separate from file size, and it needs a different set of fixes. Compressing an image reduces how many bytes it contains; reducing requests is about how many separate round trips the browser has to make in the first place.

Where the requests usually come from

Look at the network panel in your browser's developer tools while a typical page loads, and group the requests by type. On most sites carrying more requests than they need, the excess falls into a small number of categories:

Plugins and widgets, each loading their own CSS and JavaScript. A page with a dozen active plugins can easily be loading a dozen separate stylesheets and scripts, most of them small individually and significant in total.
Icon sets loaded as individual image files rather than as a single sprite or an inline SVG.
Multiple font weights and styles, each a separate file, when the design only actually uses two or three of them.
Third-party embeds — social feeds, review widgets, chat tools — each pulling in their own scripts, stylesheets and fonts independently of the rest of the page.
Tracking and analytics scripts added over time and never audited as a group, sometimes duplicating what another tool already does.

Combine what genuinely belongs together

Where several small CSS or JavaScript files are always loaded together on every page, combining them into fewer files reduces the number of separate requests without changing what the browser ultimately receives. Many content management systems and build tools can do this automatically — WordPress optimisation plugins commonly offer to combine and minify assets from active plugins and the theme together, which is exactly this technique applied without manual editing.

Combining helps most on HTTP/1.1; less so, but still worthwhile, on HTTP/2 and HTTP/3

Older connections could only fetch a limited number of files from the same server in parallel, which made combining files into fewer, larger ones a significant win. Modern connections handle many simultaneous requests to the same server far more efficiently, which reduces but does not remove the benefit — fewer requests still means less total overhead, just less dramatically than it once did.

Remove what is not doing anything

The highest-value fix is often not combining requests but eliminating them entirely. A plugin installed for a feature nobody uses anymore, a tracking script for a service the business no longer runs, an icon font loaded in full when the page uses four icons from it — all of these are requests a page makes for no benefit to anyone viewing it.

Audit plugins periodically, not just when installing something new. Deactivating and, where safe, deleting anything not actively used removes its requests along with it.
Replace icon fonts with inline SVG where only a handful of icons are actually used — a handful of inline SVGs is usually both fewer requests and less total data than an entire icon font loaded for four symbols.
Limit font weights to what the design actually uses. Stopping web fonts slowing your page covers this in more depth.

Defer what is not needed immediately

Not every request has to happen during the initial page load. Anything a visitor will not see or use until they scroll or interact does not need to compete with the content above the fold for the browser's attention straight away.

loading="lazy" on images below the fold delays their request until a visitor is about to scroll to them. See lazy-loading images for exactly where the line between above and below the fold sits.
defer or async on non-essential scripts lets the browser carry on parsing and rendering the page instead of stopping to fetch and run a script the page does not need in order to display.
Load third-party widgets on interaction where possible — a chat widget that only loads once a visitor clicks to open it, rather than on every page view regardless of whether anyone uses it.

<script src="analytics.js" defer></script>

Test after deferring or removing anything

A script that appears unused can still be doing something load-bearing — tracking a conversion, initialising a form, feeding a report someone actually reads. Deactivate or defer one thing at a time and check the page still works correctly before moving to the next.

A practical order to work through

List every request the page makes
Use the network panel in developer tools on a representative page, not just the homepage.
Remove anything not actually in use
Unused plugins, abandoned tracking scripts, icon sets loaded in full for a handful of icons.
Combine what is always loaded together
Small CSS and JS files that appear on every page are the best candidates.
Defer anything not needed for the initial view
Lazy-load images below the fold, defer non-essential scripts.
Re-test and compare the request count
Confirm the number actually dropped, and that nothing on the page broke as a result.

Reducing requests works alongside minifying CSS and JavaScript and compressing images rather than replacing either — a page with fewer, smaller, well-compressed files consistently outperforms one that has only had one of those three things done to it.