How to Reduce HTTP Requests in WordPress: 2026 Guide

You can reduce HTTP requests in WordPress in under an hour by optimizing images, combining files and turning off features you don’t use. Start by checking your current request count. Without that number you cannot tell whether your changes worked.

We checked every step against the HTTP Archive Web Almanac, the Cloudflare docs and the Chrome DevTools docs in October 2026. Cloudflare removed its Auto Minify switch in 2024. The CDN step now matches the current dashboard. Each step lists the clicks inside your WordPress dashboard and needs no code.

The guide walks through nine changes in the order that gives the biggest speed win first. It ends with request benchmarks from HTTP Archive data and what to check when a site is still slow.

What Are HTTP Requests?

Every time someone opens a page on your site, their browser sends out a small request for each file it needs to build that page. An image is one request. A stylesheet is another. A script, a font, even your favicon each count separately.

The median page made 71 requests on desktop and 66 on mobile in 2024, according to HTTP Archive’s Web Almanac. A page stacked with plugins, sliders and tracking scripts can climb well past that.

Each request adds a small delay before the browser can move on. Seventy of those delays add up fast, especially on a slow mobile connection.

Why Reducing HTTP Requests Matters

Fewer HTTP requests mean less waiting for your visitors and for Google’s crawlers. Pages show up sooner on slow mobile connections, and faster pages do better on Core Web Vitals. Here is what changes when you cut the request count down:

• Faster page loads: Fewer files to fetch means your pages appear sooner. That matters most on mobile, where every round trip to the server costs more time. A visitor on an unstable 4G connection feels the gap between 30 requests and 90 far more than someone on fiber.
• Better SEO: Google’s Core Web Vitals documentation says its ranking systems use these loading and responsiveness metrics.
• More conversions: Visitors who leave before a slow page finishes loading never see your offer, your form or your product.

HTTP requests aren’t the only cause of a slow page. If your server itself responds slowly before it even starts sending files, that’s a separate problem covered in our guide to reducing TTFB in WordPress.

Check Your Current HTTP Request Count

Check your current HTTP request count before you change anything. GTmetrix shows it as Requests on the Summary tab, and Chrome DevTools shows it in the Network panel. Without that starting number you cannot tell whether a change made a real difference.

1. Open GTmetrix in a new browser tab. Paste in your site’s URL and click Analyze.
   
2. Look at the Summary tab. The Requests number near the top is your starting point. Write it down somewhere.
   
3. Click over to the Waterfall tab to see every single request listed out, one row per file.
   
4. Type “plugins” into the search box on that tab. This filters the list down to requests coming from your installed plugins. That is usually where the bloat hides.
   

Screenshot this page now. You’ll want it later to compare against your results once you finish the steps below.

No GTmetrix account? Open the page in Chrome, press F12 and select the Network tab. Tick Disable cache and reload the page. The status bar at the bottom lists the total number of requests, as the Chrome DevTools Network reference explains.

How to Reduce HTTP Requests in WordPress: 9 Easy Steps

To reduce HTTP requests in WordPress, start with images and lazy loading. Next combine CSS and JavaScript files and cut third-party scripts and unused plugins. Browser caching, a CDN, a light theme and fewer core scripts finish the job on most sites.

Work through the steps in order. Steps 1 and 6 usually produce the biggest visible change. Start there if you’re short on time.

1. Optimize and Compress Your Images

Images are usually the single biggest source of both requests and file weight on a WordPress page.

1. Install a compression plugin such as Smush or ShortPixel from your Plugins > Add Plugin screen.
   
2. Activate it and open its settings page from your dashboard’s left sidebar.
   
3. Run the plugin’s bulk tool (Bulk Smush in Smush) to compress every image already in your media library.
   
4. Set the plugin to automatically compress every new image you upload from here on.
   

Note: Before uploading new images, resize them to the actual width they’ll display at. A 4,000px photo shown at 800px wide is wasted file size that still counts as one full request.

Compression won’t lower the number of image requests. Each image is still its own request. But smaller files finish downloading faster, and that is most of what visitors notice. For sizing and format details, see our full guide on image optimization in WordPress.

2. Enable Lazy Loading

WordPress has lazy loaded images by default since version 5.5 and iframes since version 5.7. Some themes and plugins turn it off. Confirm it works on your site with the check below.

1. Open any post or page in your browser and right-click an image below the first screen’s worth of content.
   
2. Select Inspect to open your browser’s developer tools.
   
3. Check the image tag for loading="lazy" in the HTML. If it’s there, built-in lazy loading is active.
   
4. If it’s missing, install the a3 Lazy Load plugin and enable it in settings.
   
5. For extra control, turn on lazy loading for embedded videos and iframes too. These are often heavier than a single image.
   

Lazy loading doesn’t remove the request. It delays it until the visitor scrolls close enough to need it. That keeps the first page load light.

You may also wonder whether to remove wp-polyfill from WordPress, and our test shows when that is safe.

3. Combine and Minify CSS and JavaScript Files

Every plugin and theme on your site tends to ship its own stylesheet and script file, and each one is a separate request before your page can finish rendering.

1. Install and activate the Autoptimize plugin from the WordPress plugin directory.
   
2. After installation, go to Settings > Autoptimize and turn on Aggregate CSS files and Aggregate JS files.
   

Save the settings and click through your site’s main pages to confirm nothing broke. Pay special attention to any with a menu, slider or contact form.

If something stops working, add that one file to the plugin’s exclusion list and leave it out of the combination. Combine the rest as normal.

Note: HTTP/2 lets browsers load several small files over one connection quickly. This step matters less than it did a few years ago on modern hosting. It’s still worth doing. Just don’t expect a dramatic before-and-after on its own.

Combining files doesn’t shrink what’s inside them. It cuts the number of separate requests your browser has to make. That is the exact problem this guide solves.

4. Cut Unnecessary Third-Party Scripts, Fonts and Embeds

Every social share button, tracking pixel, embedded map and custom web font pulls in its own request. Most of them come from servers outside your control.

1. Open your GTmetrix Waterfall tab again and look for rows pointing to domains other than your own.
   
2. If you’re using Google Fonts, install OMGF to host those font files on your own server instead of fetching them from Google each time.
   
3. Review your tracking scripts and remove any tool nobody checks. A site running five analytics tools rarely needs all five on every page. Load the ones you keep through one tag manager such as Google Tag Manager. Its triggers let you fire each tag only on the pages that need it.

Note: Some of these requests are added by your host or an ad network rather than your dashboard. You may need to contact them directly to remove certain ones.

Third-party requests also tend to be the slowest, since your browser has to open a brand new connection to each outside domain before the file can even start downloading.

5. Check and Remove Unnecessary Plugins

Every active plugin is a potential source of extra CSS and JavaScript files, whether or not you’re using its features on that page.

1. Go to Plugins → Installed Plugins in your dashboard.
   
2. Deactivate the unused plugins one by one.
   
3. Delete deactivated plugins once you’re confident you don’t need them. They don’t add requests while inactive, but leftover files are still a security risk if never updated.
   

A slider plugin installed for one old campaign is a typical example. It can keep loading its scripts on every page long after the campaign ends.

6. Set Up Browser Caching

Caching lets a visitor’s browser store your files locally. That way it doesn’t have to request them again on a return visit.

1. Install and activate a caching plugin like W3 Total Cache.
   
2. Enable Page Cache and Browser Cache from the main settings tab.
   

For a full side-by-side comparison, our breakdown of WordPress caching plugins covers pricing and features in detail.

7. Add a Content Delivery Network (CDN)

A CDN doesn’t lower your total request count. It serves your files from a server closer to the visitor, and that cuts the wait on each request. Cloudflare’s free plan is a common place to start.

Skip any old advice to turn on Auto Minify. Cloudflare deprecated Auto Minify on August 5, 2024 and removed it from the dashboard. Minify your files with Autoptimize from Step 3 instead.

Compression needs no switch either. As of October 2026 the Cloudflare compression docs say every plan compresses content by default. The Brotli toggle older guides mention no longer exists. Our test of what each compression format saves uses real WordPress files.

Our guide on how to speed up a WooCommerce website covers the CDN step together with caching and image work.

8. Choose a Lightweight Theme

Some themes ship with more CSS, JavaScript and demo assets than any single site needs.

1. Go to Appearance > Themes to see your active theme. Then type its folder name into the GTmetrix Waterfall search box to count the files it loads.
   
2. Compare it against a known lightweight option like GeneratePress or Astra using GTmetrix on a staging copy of your site.
   

If theme performance is a recurring headache on your store, take a look at our review of the fastest WooCommerce themes. It’s worth checking before you commit to a new one.

9. Turn Off WordPress Core Features You Don’t Use

WordPress quietly loads a handful of small files on every single page by default, whether or not you actually use the features behind them.

1. Install and activate the Asset CleanUp plugin from the WordPress plugin directory.
   
2. After installation, go to Asset CleanUp > Settings > Common Site-Wide Unloads.
   
3. Disable the emoji script wp-emoji-release.min.js. It loads on every page even if you never use an emoji shortcode.
   
4. Disable the embed script. It’s only needed if you actually embed WordPress posts from other sites into your own content.
   
5. Disable Dashicons for logged-out visitors. That icon font only needs to load for people signed into your dashboard. Regular readers do not need it.
   
6. Open the HTML Source CleanUp tab. Remove the REST API discovery link and the RSD (Really Simple Discovery) link from your page header. These are tags in the header and not separate requests, but they trim the page source.
   
7. Re-run your test from GTmetrix one final time and compare the new request count against where you started.
   

Note: Most speed guides skip this step entirely because each item only removes one request. Stack four or five of them across your whole site, though, and the savings add up the same way plugin cleanup does in Step 5.

Plugin bloat gets most of the attention in speed guides. WordPress’s own default scripts rarely do. This step takes about five minutes.

Still Slow After All Nine Steps?

If you’ve worked through each step and your site still feels slow, the main slowdown might not be HTTP requests at all. Server response time, unoptimized database queries and hosting limits can all produce the exact same symptom.

That kind of diagnosis is hard to do alone, especially on a deadline. Our WordPress speed optimization service handles the full check, from request count down to server configuration.

How Many HTTP Requests Is Too Many?

There is no official limit for HTTP requests, but HTTP Archive’s 2024 data gives a useful scale. The median page made 71 requests on desktop and 66 on mobile. A quarter of mobile pages stayed at 39 requests or fewer, and a tenth stayed at 22 or fewer.

• Under 40 on mobile: Lighter than about three quarters of the pages HTTP Archive measured in 2024.
• Around 66 on mobile or 71 on desktop: The median page in the same 2024 data.
• Over 110 on mobile: Heavier than about three quarters of measured pages. Most of these have room to cut.

Treat the count as a signal. It is not a strict rule. A page with 60 small cached requests can load faster than a page with 30 large uncached ones.

A low request count does not guarantee a fast site. A page still loads slowly when the few files it keeps are large, uncompressed or served from a slow host. Pair the request work with the image and caching steps above.

Conclusion

Reducing HTTP requests in WordPress comes down to three habits: remove what you don’t need, combine what you do and cache everything you can. You don’t need to tackle all nine steps in one sitting. Start with image compression and a caching plugin, since those two alone usually produce the biggest visible change.

Re-run your GTmetrix test after each change and watch that request count come down. A faster site pays for itself in fewer lost visitors, better rankings and less time spent staring at a loading spinner.

Frequently Asked Questions (FAQs)