Category: WordPress

You publish an update, refresh the page, and nothing changes for your visitors.

If your WordPress changes are not showing after an update, then you are in the right place. In this cache troubleshooting guide, we will move past the basic advice of “have you tried turning it off and on again?” We will dive deep into why your logged-out view differs from what you see as an admin, and how to verify whether you are hitting the page cache or the Redis object cache.

This guide explains why those failures happen and shows you how to fix them in the correct order, without guessing.

How to Identify Which Cache Is Causing the Problem

Before clearing anything, use the quick checks below to identify which cache layer is actually blocking your update.

• Changes are visible when logged in, but not logged out
  • Server-level page cache or CDN cache is serving stale HTML
  • Skip to Step 3 and Step 5
    
• Content updates show, but CSS or layout does not
  • Browser, CDN, or server is caching static assets
  • Skip to “How to Handle Real-Time Updates with Stale Cached Assets”
    
• Dynamic elements are wrong – cart counts, menus, widgets
  • Object cache or transients are stale
  • Skip to Step 4
    
• Code changes to the theme or plugin are not reflected
  • PHP opcode cache or object cache issue
  • See “Clear PHP OPcache” and “Clear Object Cache”
    
• Nothing updates anywhere
  • Multiple cache layers active
  • Follow all steps in order

Why WordPress Changes Are Not Showing After an Update

If your WordPress website is not showing changes after an update, caching is the most common cause.

Caching is the process of storing commonly accessed information on the server. To make your site load faster, browsers, plugins, servers, and CDNs show visitors a “snapshot” instead of rebuilding the page from scratch every time. This works well in most scenarios, but the problem arises when you update the site, and the cache keeps showing the old snapshot.

Most WordPress setups rely on disjointed tools, one plugin for page cache, another for object cache, and a separate dashboard for your CDN. This makes it hard to know which layer is holding onto the old data. With RunCache, server-level NGINX configuration and full-page caching are managed from a single dashboard, which reduces overlap between cache layers.

How to Fix WordPress Changes That Are Not Showing 

When troubleshooting a website, we should start with the easiest fix (your browser) and work our way back to the server. 

Step 1: Hard Refresh the Page and Verify 

Before changing any settings, force your browser to reload the page. On Windows, press Ctrl + F5, or Cmd + Shift + R on Mac. Alternatively, you can open the URL in an Incognito/Private window.

If the Incognito window still shows the old version, the issue is not your browser and must be upstream.

Suggested read: How To Use NGINX FastCGI Cache (RunCache) To Speed Up Your WordPress Performance

Step 2: Purge the WordPress Cache Plugin

If you are using a third-party caching plugin, clear its cache once before moving on. If this does not resolve the issue, do not keep purging here.

If you find yourself constantly modifying plugin settings, consider RunCache. It combines page, object, and edge caching into a single dashboard, which eliminates the need for complex plugins that don’t effectively communicate with your server.

Suggested read: How To Use Redis Full-Page Caching To Speed Up WordPress

Clear Theme and Page Builder Caches

This step is often skipped, which is why many cache purges appear to do nothing.

Many modern WordPress themes and page builders generate compiled CSS and layout files that sit outside standard page caching.

Common examples include Elementor, Divi, Oxygen, and block-based themes using theme.json.

If you are using a page builder or a performance-focused theme, you must clear its internal cache before touching the server.

Typical actions include:

• Elementor – Tools → Regenerate Files and Data
• Divi – Theme Options → Builder → Advanced → Clear Cache
• Oxygen – Settings → Library → Clear Cache
• Block themes – re-save global styles or theme settings

If these files are stale, server purging will have no effect because WordPress is still outputting old asset references.

Only proceed to server-level cache clearing after completing this step.

Step 3: Purge Server Page Cache (FastCGI / NGINX cache)

Even if you disable the caching plugin on your WordPress website, your server (NGINX/FastCGI) might still be holding a cached version of your HTML to speed up load times.

If you need to clear the NGINX FastCGI cache manually, delete the temporary files NGINX has created, then reload the service. Here is how to do it safely.

1. Locate the Cache Path

First, you need to find out where NGINX stores the cache. This is defined in your NGINX.conf or sites-available files under the directive fastcgi_cache_path.

Run this command to find the path:

sudo grep -r "fastcgi_cache_path" /etc/nginx/

• Standard Install: Usually /var/cache/nginx or /var/run/nginx-cache.
• RunCloud Server: located at /var/cache/nginx-rc/ 

In the above example, the cache is stored in a folder located at /var/cache/nginx-rc

Suggested read: How To Use Redis Object Cache To Speed Up Dynamic WordPress Site

2. Delete the Cache Files

Once you have the path, you can remove the cache files. Be extremely careful with the rm -rf command. A single mistake can delete critical system files.

Option A: Clear Everything (Root/Sudo)

Run the following command to clear all the cache created by NGINX:

sudo rm -rf /var/run/nginx-cache/*

Option B: Clear for a Specific Site (If separated by folder)

If your configuration separates caches by folder, then you can delete only a part of the cache without changing anything else. To do this, first run the following command to see a list of all the available folders in the Nginx cache:

sudo ls -lah /path/to/cache

In the above example, remember to replace /path/to/cache with the path identified in the previous step.

In the above example, we can see there are two different folders present on the server. You can delete the folder you want to clear the cache from. For example, if you want to clear the cache for runcloud-hub-fastcgi-app-auer, run the following command:

sudo rm -rf /var/cache/nginx-rc/runcloud-hub-fastcgi-app-auer/*

3. Reload NGINX

After deleting the files, you must reload the NGINX configuration to ensure it stops serving any lingering pointers to deleted files.

sudo systemctl reload nginx
# OR
sudo service nginx reload

Note: If you are using RunCloud, then you don’t need to touch the command line for this. Simply log in to your RunCloud Dashboard and navigate to the RunCloud Hub settings page for your web application. On this page, click the Purge button. This clears the cached HTML immediately, even without SSH access.

Suggested read: How to Easily Fix Leverage Browser Caching Warning in WordPress

Step 4: Clear Object Cache 

When parts of your site that update automatically (like a “Recent Posts” widget, shopping cart count, or user login status) remain stuck, the issue is likely within your Object Cache (typically Redis).

This caching layer stores the results of database queries in memory to speed up PHP execution, but it can sometimes hold onto stale data even after the content has changed. If you only clear your page cache (HTML), these database-driven elements will persist because the server continues to retrieve the old query results from memory instead of the database.

To resolve this via the command line, you will need to SSH into your server and interact with the Redis instance directly. You can run redis-cli flushall to remove all keys from the Redis database, forcing all applications using that instance to rebuild their cache from scratch.

However, if you only want to flush the cache for a particular WordPress site, navigate to your WordPress root directory and run the wp cache flush command. This will clear the object cache for that site specifically, without risking data loss for other applications sharing the same Redis instance.

RunCloud offers a much simpler solution that eliminates the need for SSH access or complex commands. You can manage Redis directly from the WordPress Dashboard by navigating to your RunCache settings and clicking the Clear Redis Object Cache button.

Suggested read: How to Create Custom NGINX Configuration Easily Using RunCloud

Object cache issues can also originate from WordPress transients stored in the database. Themes and plugins commonly use these for time-based data such as menus, pricing, or scheduled updates.

If clearing Redis does not resolve the issue, temporarily disable the object cache and reload the page to confirm whether a transient is responsible.

If the issue disappears, the problem is application logic, not caching.

Clear PHP OPcache After Code Changes

If theme or plugin code changes do not appear, PHP’s opcode cache may still be serving an older compiled version.

This is common after:

• Theme file edits
• Plugin updates
• Custom PHP changes

On most servers, OPcache persists until PHP-FPM is reloaded.

On RunCloud servers, PHP-FPM reloads are handled automatically through the dashboard and do not require manual intervention.

If you are not using RunCloud, reload PHP-FPM to force OPcache to rebuild.

This step is not required for content edits but is critical for code-level changes.

Step 5: Purge CDN Cache 

Since every Content Delivery Network (CDN) operates differently, the exact steps here will vary depending on whether you use Cloudflare, BunnyCDN, or Fastly.

However, the process is generally the same: log in to your CDN provider’s dashboard, navigate to the Cache or Purge section, and look for the option to clear the cache. You should always select Purge by URL (or “Custom Purge”) and enter the specific link that is stuck, rather than clearing the entire cache.

RunCache supports smart purging. It handles edge caching logic for you, ensuring that when you update content, the specific URL is automatically cleared from the CDN. This keeps your site fast and your server happy, without you ever needing to log in to a separate CDN dashboard.

Suggested read: Server Cache vs. Browser Cache vs. Site Cache: What’s the Difference?

How to Confirm Which Cache Layer Is Responding

Guessing wastes time. Confirm the cache status before making any changes.

Open your browser’s developer tools and reload the page with the Network tab visible. Click the main HTML request and inspect the response headers. Look for indicators such as:

• X-Cache or X-RunCache – server page cache
• cf-cache-status – Cloudflare edge cache
• Status 304 – browser or intermediary cache revalidation

A cached response confirms that the issue is not WordPress itself but an upstream cache layer.

If the response is a fresh 200 but the content is still wrong, the issue lies inside WordPress logic or asset generation.

How to Handle Real-Time Updates with Stale Cached Assets

Sometimes, even after clearing every cache, the old design still appears. This usually happens not because the server is broken, but because the browser thinks it already has the correct file and refuses to ask for a new one. This is common with CSS (styles) and JS (functionality) files. 

Step 1: Fix CSS/JS Cache Busting With File Versioning

The most reliable mechanism to force a browser to discard stale data and retrieve a fresh asset is not by manually renaming the file on the server, but by implementing versioning query strings (such as requesting style.css?ver=2.1), which instantly tells the browser that the underlying content has been modified. By appending this unique identifier to the resource URL, you can bypass local browser caches and CDN edges.

RunCloud allows you to control exactly how the server handles these dynamic parameters through its advanced NGINX caching rules:

• Include cache based on matching query string: This setting lets you specify parameters that trigger the creation of a unique cache file, ensuring that visitors viewing ?currency=USD see a different cached version than those viewing ?currency=EUR without slowing the page.
• Exclude cache based on matching query string: Conversely, this option lets you define specific query strings that will force the server to bypass the page cache entirely whenever they are present, ensuring that dynamic or sensitive URLs are always served live from the backend.

Step 2: Confirm the Browser is Requesting the New CSS/JS URL (Not a Cached URL)

Before you assume the server is broken, you need to determine if WordPress is actually telling the browser to fetch the new file. This diagnostic step determines whether the failure occurs within the WordPress application logic or at the server/network level.

Here is how you can do this:

• Open a Fresh Session: Open your website in an Incognito (Chrome) or Private (Firefox/Safari) window to ensure your local browser history isn’t interfering with the test.
• Access the Source Code: Right-click anywhere on the page background and select “View Page Source” (or press Ctrl + U on Windows / Cmd + Option + U on Mac). Do not use “Inspect Element” for this, as the DOM can sometimes differ from the raw source delivered by the server.
• Locate the Specific File: Press Ctrl + F (or Cmd + F) to open the search bar. Type in the name of the file you modified, such as style.css, main.js, or the specific plugin stylesheet handle.
• Analyze the Query String: Focus on the filename’s ending. You are looking for a version parameter, which typically looks like ?ver=1.2.3 or ?ver=time_stamp. Compare this number to the version you expect (e.g., if you just updated a plugin from version 2.0 to 2.1, the tag should read plugin.css?ver=2.1).

How to interpret the results and fix the issue:

• Scenario A: The Version Number Has Not Changed

If the source code still shows the old version, the issue is not the server cache. The issue lies within WordPress itself. Your caching plugin might be serving a stale HTML page that contains the old link tags, or your theme might be “hardcoding” the version number instead of using the dynamic wp_enqueue_style function.

To fix this, you need to clear the cache of your WordPress page cache plugin first. If that fails, check your functions.php file to ensure you are updating the version number on your enqueued scripts.

• Scenario B: The URL Has Changed, But the Style is Old

If the source code shows the new version, but the site still looks wrong, you are facing a “Hard Cache” issue on the server or CDN. The browser is requesting the new file, but an intermediate layer (such as NGINX or Cloudflare) has aggressively cached that path and is ignoring the query string. To fix this, you need to update the caching rules of your server and CDN.

Step 3: Stop Caching HTML Too Long (Cache-Control Header)

Incorrectly configuring the Cache-Control headers can create persistent caching issues. This HTTP header instructs the user’s browser: “Save this file locally and do not check the server for updates for X days.”

It is recommended to set a 1-year expiration for static assets (such as images and fonts) for optimal performance.

However, applying those same rules to your dynamic HTML pages is disastrous. If you accidentally instruct browsers to cache your homepage HTML for 30 days, no amount of server-side purging will resolve the issue. The visitor’s browser will simply stop requesting the page from your server entirely, relying on its local copy until the timer expires.

RunCloud’s NGINX templates come preconfigured with safe, industry-standard Cache-Control policies. Our stack is tuned to aggressively cache static assets for maximum speed while ensuring dynamic HTML remains fresh and revalidates frequently. This built-in logic prevents “configuration drift” and safeguards you from accidentally locking your users onto an obsolete version of your site.

Special Considerations for WordPress Multisite

WordPress Multisite environments often share Redis instances, PHP workers, and cache directories across multiple sites. Flushing object cache or Redis globally may affect other sites on the network.

If you are running Multisite, prefer site-specific cache purging through WordPress or RunCloud tools rather than command-line flushes.

Always confirm whether Redis databases or FastCGI cache folders are isolated per site before manually clearing them.

Wrapping Up

Debugging a WordPress site that refuses to update is one of the most tedious parts of development, but it doesn’t have to be a mystery. As we’ve discussed, the “invisible wall” preventing your changes from showing up is usually a result of multiple caching layers (browser, server, object, and CDN) working a little too well.

By following the workflow we outlined, you can stop guessing and start resolving issues systematically. 

However, the best way to handle caching is to use a platform that simplifies it.

Managing NGINX rules, Redis instances, and CDN purges separately is a recipe for frustration. RunCloud RunCache solves this by integrating server-side page caching, object caching, and edge caching into a single, intuitive dashboard. You get the raw speed of a custom-tuned server with the ease of use of a simple plugin.

If you want consistent performance and a “Clear Cache” button that actually works,create a new test site today to experience RunCache. 

FAQs on WordPress Changes Not Showing After Update

There is a pervasive myth in the web development community: “WordPress is for novices. Real developers build custom apps.”

If you’re a developer who loves the clean workflow of Git, the component architecture of React, or the speed of static sites, you might look at WordPress with disdain. You might picture bloated plugins, spaghetti PHP code, and ongoing security concerns.

But if you ignore WordPress, you are ignoring a tool that powers over 60% of all websites using a CMS.

That market dominance isn’t an accident, and it isn’t just because it’s “easy” for beginners. It’s because WordPress solved the hardest problem in web development: Content Management.

As technical experts, we need to stop looking at WordPress as a “website builder” and start seeing it for what it truly is: a highly accessible, open-source, API-driven Content Database.

Whether you are using a sophisticated Roots.io stack with Git integration or going fully Headless, WordPress gives you complete freedom to manipulate the frontend while empowering your non-technical team.

However, the allure of “simplifying” the stack often leads developers to swing the pendulum too far in the opposite direction. In an effort to escape database management and PHP, many technical teams migrate to pure Static Site Generators (SSGs), relying solely on Markdown files.

While this initially feels like a developer’s utopia, offering total control and zero maintenance, it often turns into an operational nightmare for the rest of the organization.

Who This Architecture Is For

This approach is not aimed at hobby sites or solo blogs. It is designed for teams where developers and content editors have different needs.

If you are working with:

• A marketing or content team that needs editorial autonomy
• Developers who prefer modern JavaScript frameworks
• A product or SaaS site where performance and security matter

Headless WordPress becomes a practical architectural choice rather than an experiment.

Why You Shouldn’t Use Static Site Generators

Many teams migrate to Static Site Generators (SSGs) for faster page load times and simpler hosting requirements, as Markdown files power them. On the surface, the idea sounds utopian as it is “Just a bunch of HTML files! No database! Easy deployment!“

Using a static file-based solution would mean you now need a PR for every update to a blog post. Let’s look at the reality of that workflow in a mid-sized company:

• A marketing manager spots a typo in a blog post.
• They can’t fix it. They have to ask a developer. The developer must create a branch, fix the typo, commit, push, open a Pull Request (PR), wait for the CI/CD, and then merge.
• Your highly paid engineers are spending time fixing typos instead of shipping product.

We cannot expect marketing teams to learn Git or write perfectly formatted Markdown. We need to empower them with a CMS while retaining our own developer freedom.

Classic vs. Headless WordPress

For advanced development teams, the biggest friction point with WordPress isn’t the dashboard; it’s the templating engine.

You might already have a sophisticated corporate identity, a component library built in React, or a legacy styling setup that your team loves. Trying to shoehorn that existing frontend architecture into the standard WordPress PHP template hierarchy (single.php, header.php, the Loop) can feel like forcing a square peg into a round hole.

You often end up fighting the CMS rather than leveraging it, translating modern frontend patterns into WordPress-specific PHP themes. This adds complexity, slows iteration, and ties your frontend decisions to the WordPress render cycle.

This is where the distinction between Classic and Headless WordPress changes the game.

The Classic WordPress

In the Classic WordPress model, the backend (admin interface/database) and the frontend (what the user sees) are tightly coupled. They live on the same server and share the same codebase. When a user visits your site, WordPress dynamically generates the HTML based on your active theme.

For many projects, this is fine (even preferred). But for a technical team that wants to iterate on the frontend independently of the content engine, this monolithic structure can be a bottleneck.

Developers often try to add their modern components within a custom PHP theme or build complex custom plugins to manage data, aiming to make the WordPress editor feel more like a modern frontend experience.

While this can offer temporary relief, it often leads to a more complex, heavier application. You are still ultimately constrained by the limitations of the WordPress render cycle and the PHP environment, and you’re forced to maintain a custom codebase that may be difficult for new developers to onboard to. 

The Headless Revolution

Headless WordPress decouples this relationship entirely. Think of it as performing surgery: you keep the “Body” (the robust content management, user roles, and database) because WordPress does that better than almost anyone else. However, you sever the “Head” (the frontend display layer).

In this architecture, WordPress becomes a data source. It sits quietly in the background, waiting for instructions. You then use the WordPress REST API or WPGraphQL to fetch that content and inject it into a completely separate frontend application.

This shift from “Website Builder” to “Content API” unlocks three massive advantages for technical teams:

• You are no longer bound by PHP. You can build your frontend in React, Vue, Svelte, Angular, Next.js, Gatsby, or even plain HTML/JS. If your team is already proficient in React, they can build the site using the tools they know and love, simply treating WordPress as a JSON endpoint. You stop hacking themes and start building applications.
• In a classic setup, your content is trapped in the website’s HTML. In a headless setup, your content is portable data. You can publish a case study once in WordPress and have it instantly available via API to your marketing website, your native iOS/Android app, an internal intranet dashboard, and even a smartwatch interface simultaneously.
• Because your frontend is physically separated from your backend (often hosted on entirely different servers or CDNs), your database is not directly exposed to user traffic. Even if your frontend site experiences a large traffic spike or an attack, your WordPress installation is far less exposed, since it is not directly serving public traffic and can be further protected behind the API layer.

If you want to combine the SEO benefits of static sites with the dynamic power of a CMS, pairing WordPress with a framework like Gatsby is a good choice.

Gatsby pulls your data from WordPress via GraphQL, generates static HTML at build time, and deploys it to the edge. This results in extremely fast page loads that are difficult for traditional PHP-rendered sites to match at scale. If you want to learn more about this architecture, then we recommend reading why Gatsby chose headless WordPress for its blog.

How To Set Up Headless WordPress with Gatsby

For this guide, we will use RunCloud to manage our infrastructure. RunCloud offers an excellent balance of server control and ease of use. While a production workflow usually involves local development pushed to a Git repository with CI/CD pipelines (Atomic Deployment), we will perform this setup directly on the server to demonstrate the architecture clearly.

Here is how you connect the dots between your WordPress backend and your Gatsby frontend.

Step 1: Set Up the WordPress Backend (The “Body”)

First, we need the source of truth for your content.

1. Create the App: Log in to your RunCloud dashboard and create a new Web Application. This will host your WordPress installation.
2. Install WordPress: Use the RunCloud “One-Click Install” feature (or your preferred installation method) to get WordPress running.

3. Configure Permalinks: This is a crucial step! Go to Settings > Permalinks in your WordPress dashboard. Set it to “Post name” or a custom structure. The default “Plain” setting (?p=123) can sometimes cause issues with GraphQL routing.
4. Install Essential Plugins: Go to Plugins > Add New and install the following two plugins:
   • WPGraphQL: This exposes your WordPress data via a GraphQL API.
   • WPGatsby: This optimizes communication between WordPress and Gatsby, handling tasks such as cache invalidation and delta updates.

Your marketing team will log in here to publish content. To them, it appears to be a standard WordPress site.

Step 2: Prepare the Frontend Environment

Now, we need a place for the Gatsby application to live.

1. Create a New Web App: Back in RunCloud, create a second Web Application.
2. Select Stack: Choose an Empty Web App stack (since Gatsby is a React-based framework running on Node).
3. Domain: Assign your public-facing domain to this application (e.g., www.example.com).

In a production environment, you would develop locally, push to Git, and use RunCloud’s Git deployment feature. For this tutorial, we will initialize the app directly on the server to give you an immediate overview of the file structure.

Step 3: Install Gatsby via SSH

Connect to your server via SSH using the system user attached to your Frontend Web Application. Before moving ahead, ensure the Gatsby CLI is installed globally on the server by running the following command:

npm install -g gatsby-cli

Navigate to the root directory of your new application (/home/username/webapps/appname). In this folder, you will need to delete the default index.html file by running the following command.

rm index.html

Once the directory is empty, run the following command to generate the site skeleton using a WordPress-specific starter:

gatsby new . https://github.com/gatsbyjs/gatsby-starter-wordpress-blog 

This command pulls down a pre-configured Gatsby site optimized for fetching data from WordPress.

You have now initialized the core files for your Gatsby frontend in this folder. You can update the React components, styling, and general structure as you like.

Step 4: Connect Frontend to Backend

You need to tell Gatsby where your WordPress API lives. Open the configuration file using your preferred editor (nano or vim):

nano gatsby-config.js

Locate the configuration options for gatsby-source-wordpress and update the url setting to point to your backend’s GraphQL endpoint. After editing, it will look like this:

Save and exit the file by pressing Ctrl + O, Enter, and Ctrl + X. 

For a deep dive into advanced configuration, schema customization, and troubleshooting, we highly recommend reading the official documentation: Gatsby Source WordPress Documentation

Step 5: Build and Deploy

Now, we will need to generate the static files that will be displayed on the internet.

Handle SSL (Optional): If your backend is on a staging server using a self-signed certificate, Gatsby might refuse to connect. You can bypass this temporarily by running:

export NODE_TLS_REJECT_UNAUTHORIZED=0

Build the Site: Run the build commands to fetch the data from WordPress and generate the HTML/CSS/JS files in your Gatsby environment:

gatsby clean
gatsby build

Update Public Path: By default, RunCloud points the web server to the root of your application. However, Gatsby compiles your static site into a folder named “public”. Therefore, we will update the public path of the Gatsby web application in the RunCloud dashboard. Please note that we don’t need to modify this setting for the WordPress backend.

1. Go to your RunCloud Dashboard > Web Application > Settings.
2. Change the Public Path to /public.
3. Save settings by clicking the Update Stack button.

After updating the public path, your website will be immediately accessible on the internet. 

Suggested Read: What is WordPress Object Caching

Next Steps and Considerations

With your Headless WordPress architecture now fully deployed, here are a few things to consider for ongoing maintenance and optimization:

Continuous Deployment for Content Changes

Currently, every time your marketing team publishes a new post or makes an edit in the WordPress dashboard (Step 1), you still need to manually run gatsby build on your server (Step 5) to see the changes on the live site. To automate this process, you need to implement Webhooks and CI/CD.

• Configure Webhooks: The WPGatsby plugin you installed in Step 1 can be configured to automatically send a signal (a webhook) to an external service every time content is saved or published.
• Trigger a Build: Set up your deployment pipeline (e.g., using RunCloud’s Git deployment feature or a dedicated service like Netlify/Vercel) to listen for this webhook. When the signal is received, the pipeline automatically triggers a new Gatsby build, fetching only the updated content (delta changes) and deploying the new static files.
• Benefit: This creates a zero-touch content workflow, where the content team publishes content, and the live site updates automatically in minutes, without requiring developer intervention.

Scaling and Optimization

Since your frontend is static, hosting it on a global Content Delivery Network (CDN) will drastically reduce load times for international users. Services like Cloudflare or AWS CloudFront can be easily configured to sit in front of your Gatsby application.

Maintaining Security

The separation of your backend and frontend inherently improves security, but proactive measures are still essential for the WordPress installation:

• Regular Updates: Ensure your WordPress core, themes (even those unused for templating), and all plugins (especially WPGraphQL and WPGatsby) are kept up to date. We strongly recommend using Patchstack for this step, as it secures your website from vulnerabilities by using RapidMitigate technology, which protects your website even if the plugin developers haven’t released an update.
• Firewall Rules: Use the firewall features to restrict access to the WordPress dashboard (e.g., only allow specific IP addresses or VPN ranges) since it’s an internal-only application.

This decentralized approach gives you the ultimate control to tune and scale each component independently, ensuring both performance and editorial freedom.

WordPress is a Power-Up, Not a Compromise

For too long, developers have viewed WordPress as a “necessary evil”, something you tolerate because the client demanded it. It’s time to retire that mindset.

When you pair WordPress with a modern architecture, such as a Headless setup, it stops being a compromise and becomes a massive workflow accelerator. It solves the content problem instantly, allowing your team to focus on what actually moves the needle: building high-performance user interfaces, optimizing conversion funnels, and shipping code.

You get the stability of a CMS that powers over 60% of the web, combined with the bleeding-edge speed of a React frontend. 

You Don’t Need to Be a Linux Expert

Perhaps the biggest hesitation remaining is the infrastructure. “If I go Headless, don’t I need to manage multiple servers? Do I need to be a Linux sysadmin to keep this secure?”

This is where RunCloud bridges the gap.

Powerful architecture shouldn’t require you to spend your time managing low-level server configuration. RunCloud does all the heavy lifting for you. We automate the provisioning, security patching, and server management so you can deploy a WordPress backend and a Node.js frontend in minutes, not days.

But unlike “Managed Hosting” that locks you in a black box, RunCloud respects your expertise.

• We handle the tedious tasks: SSL installation, backups, and service monitoring occur automatically.
• You retain control: You maintain full root access to your server. Want to tweak a custom NGINX config? Go ahead. Need to install a specific server-side library? You have the keys.

You get the convenience of a managed dashboard with the raw power of a VPS.

Ready to Build Your Headless Stack?

Don’t let infrastructure headaches stop you from building the best version of your website. Join developers and agencies using RunCloud to deploy faster, secure their infrastructure, and scale with confidence.

Sign up for RunCloud today and start building your next project with the freedom you deserve.

Frequently Asked Questions

A slow WordPress site isn’t just frustrating – it drives visitors away and hurts your SEO.

In most cases, the cause is simple: too many HTTP requests.

Every script, image, and font file your browser fetches adds another delay, which hurts your WordPress website performance and Core Web Vitals

This guide shows you how to cut those requests at the source – and make your site load noticeably faster. You’ll learn how to configure your WordPress site to:

• Dequeue unnecessary assets properly
• Combine images using CSS sprites
• Disable WordPress emojis.

Let’s get started!

What are HTTP Requests on a WordPress Website?

Let’s try to understand this with the help of an example. You can think of your web browser as a personal shopper with a list of things it needs to build the webpage you want to see.

An HTTP request is a single trip your shopper (the browser) makes to a server to pick up one item on that list. For a WordPress site, this list is long and includes trips to different “stores” (servers):

• Your Server: It needs to get the logo, background images, the main text content, and theme files (CSS for styling, JavaScript for interactivity).
• Google’s Servers: It might need to fetch custom fonts (Google Fonts).
• Facebook’s Servers: It might need to grab a tracking pixel or a “Like” button script.
• Other Servers: It may need to get a video from YouTube or an icon from a font library.

Each one of these “trips” is an individual HTTP request. A modern website can easily make 50-100 of these requests just to load a single page, and a slow or disorganized shopping trip makes for a frustratingly slow website.

Benefits of Making Fewer HTTP Requests in WordPress

Reducing the number of “shopping trips” your browser has to make provides immediate and significant benefits.

1. Firstly, it dramatically improves page load speed and creates a much better experience for your visitors.
2. Secondly, this speed boost directly impacts your SEO and Core Web Vitals, as search engines like Google reward fast, responsive websites with better rankings.
3. Finally, fewer requests mean less work for your server. This allows it to handle more traffic without slowing down, which is important for growing your business.

Suggested read: How To Use NGINX FastCGI Cache (RunCache) To Speed Up Your WordPress Performance

Measuring HTTP Requests with Waterfall Analysis

The best way to see all these HTTP requests is with a waterfall analysis, which you can find in tools like GTmetrix or your browser’s developer tools (F12 > Network). A waterfall chart gives you a visual breakdown of every single file your browser requests to build the page. It looks like a cascading series of bars, showing:

• What was requested: Every image, script, and stylesheet.
• Where it came from: Your server, a CDN, or an external site.
• How long it took: Long bars are performance bottlenecks.

By analyzing this chart, you can pinpoint exactly what is slowing your site down: too many files, large images, or slow external services.

Suggested read: How To Use Redis Full-Page Caching To Speed Up WordPress

How Reducing HTTP Requests Works on a WordPress Site

As we already discussed, every element on a WordPress site, each image, stylesheet (CSS file), script (JavaScript file), and font, requires the browser to make a separate request to a server to download it. And if a web browser has to perform more tasks, it would take longer.

If we reduce the number of requests, we can speed up the entire loading process:

Remove or Replace Heavy Plugins and Themes That Load Excessive Assets

The single biggest source of unnecessary HTTP requests in WordPress comes from poorly coded or feature-heavy plugins and themes. A complex theme or a “do-it-all” plugin might load dozens of its own CSS and JavaScript files on every single page, even if the feature isn’t being used.

Auditing and replacing these heavy assets with lightweight, modular alternatives is a high-impact first step toward a leaner, faster website.

1. Use a tool like GTmetrix or open the “Network” tab in your browser’s DevTools to run a waterfall analysis. Look for clusters of .css and .js files being loaded from specific plugin or theme directories (/wp-content/plugins/plugin-name/).
2. For each heavy plugin, ask: “Is this functionality critical?” and “Can it be achieved more simply?” For example, a heavy social sharing plugin might be replaceable with simple HTML links or a lighter plugin.
3. Research plugins and themes that are specifically marketed as “lightweight,” “performant,” or “modular.” Look for options that allow you to disable features (and their associated assets) that you are not using.
4. Deactivate the heavy plugin on a staging site, install the lighter alternative, and run the waterfall analysis again to measure the reduction in requests.

Suggested read: The Complete WordPress Speed Optimization Guide

Load Assets Conditionally and Dequeue Unused CSS/JS Per Page

Many plugins load their assets globally. For example, the scripts for your contact form are also loading on your homepage and blog posts, where there is no form. Conditional loading is the practice of preventing assets from loading on pages where they are not needed.

This approach ensures that each page only loads the absolute minimum number of files required for it to function correctly. If you prefer a code-based approach, you can use WordPress functions wp_dequeue_style() and wp_dequeue_script() in your theme’s functions.php file. Wrap them in conditional tags to target specific pages.

Example: To disable a contact form script everywhere except the “Contact” page:

add_action( 'wp_enqueue_scripts', 'my_dequeue_scripts', 100 );
function my_dequeue_scripts() {
    if ( ! is_page( 'contact' ) ) {
        wp_dequeue_script( 'contact-form-7' ); // Use the script's handle
        wp_dequeue_style( 'contact-form-7' );  // Use the style's handle
    }
}

Suggested read: How to Reduce Cache Misses & Avoid Them: Proven Tips [FIXED]

Minify and Combine CSS/JS

Minification removes unnecessary characters (like whitespace and comments) from code to reduce file size. And after minification, you can bundle multiple CSS or JavaScript files into a single file to reduce the number of HTTP requests.

However, this strategy is most effective for older HTTP/1.1 servers. Modern servers using HTTP/2 and HTTP/3 can handle many small requests in parallel very efficiently, so combining files can sometimes be counterproductive.

1. For HTTP/1.1: Use a caching plugin like WP Rocket or W3 Total Cache to enable minification and file combination for both CSS and JS.
2. For HTTP/2 and HTTP/3: You can enable minification, but be cautious with the combination setting. It’s often faster to load multiple small, minified files that are deferred or loaded asynchronously than one large, combined file that could block rendering. You should test your load times with the combination enabled and disabled to see what works best for your specific site.

Optimize Fonts (Self-Host, Subset, Preload, Use font-display: swap)

Web fonts, especially those loaded from external services, can introduce multiple HTTP requests and DNS lookups that slow down rendering. By taking full control of your fonts, you can eliminate these external requests and ensure they are delivered as efficiently as possible from your own optimized server.

1. Host Fonts Locally: Use a plugin like OMGF (Optimize My Google Fonts) to automatically find the Google Fonts your site uses, download them, and serve them directly from your own server. This eliminates the external request to fonts.googleapis.com.
2. Subset Your Fonts: Subsetting removes all the characters and weights you don’t use from a font file, and this drastically reduces its size. Many local font generation tools offer this as an option.
3. Use font-display: swap;: Add this CSS property to your @font-face declaration. It tells the browser to display a fallback system font immediately while the custom font is loading. This prevents a blank text flash (Flash of Invisible Text).
4. Preload Critical Fonts: Identify the one or two font files needed to render the “above-the-fold” content. Preload them by adding a <link> tag to your site’s <head> to tell the browser to download them with high priority.
   • Example: <link rel="preload" href="/wp-content/fonts/my-font.woff2" as="font" type="font/woff2" crossorigin>

Suggested read: Server Cache vs. Browser Cache vs. Site Cache: What’s the Difference?

Reduce External Requests (Fonts, Analytics, Chat Widgets, Ads) or Host Locally

Every third-party service you add, analytics, heatmaps, live chat widgets, ad networks, and social media feeds, adds external HTTP requests. These requests can significantly slow down your site because your server has no control over the speed and reliability of the third-party server. Minimizing or locally hosting these scripts where possible is key to reclaiming performance.

1. Use your waterfall chart to identify all requests going to domains that are not your own.
2. For each external service, decide if its value outweighs its performance cost. Can you remove it?

3. For services like Google Analytics, plugins like Perfmatters allow you to host the analytics.js script locally on your server. This gives you full caching control and eliminates an external DNS lookup. A server managed by RunCloud will serve this local file with incredible speed.
4. For non-critical scripts like chat widgets or ad scripts, use a script manager to delay their loading until a user interacts with the page (e.g., scrolls or clicks).

Suggested read: How to Easily Optimize Your WordPress Website With RunCloud Hub

Optimize Images (Next-Gen Formats, Lazy Loading, SVG Sprites for Icons)

Images are often the heaviest assets on a page, and a site with many unoptimized images will generate a huge number of HTTP requests. Modern image optimization techniques focus on reducing file size, deferring loads, and combining multiple small image requests into one.

1. Convert your JPEGs and PNGs to modern formats like WebP or AVIF. These formats offer superior compression and smaller file sizes with no visible quality loss. We recommend reading this excellent article on Best WordPress Image Optimization Plugins by Patchstack to learn more about image compression.
2. Lazy loading prevents images and iframes that are “below the fold” from loading until the user scrolls them into view. This drastically reduces the number of initial HTTP requests. This is a native feature in WordPress 5.5+, but many WordPress plugins also offer more advanced control.
3. For simple graphics, logos, and icons, you should use Scalable Vector Graphics (SVGs). They are incredibly small in file size and scale perfectly without losing quality.

Suggested read: 8 Best GTmetrix Alternatives for Website Performance Testing (Includes Free)

Use Resource Hints (preload, preconnect, dns-prefetch, fetchpriority) for Critical Files

Resource hints are instructions that you can place in your site’s HTML <head> to give the browser a “heads-up” about resources it will need soon. This allows the browser to start fetching critical files or establishing connections early, which can shave valuable milliseconds off your load time by optimizing the request-and-response cycle.

1. dns-prefetch: You can use this for third-party domains your site needs to connect to, like Google Fonts or Google Analytics. It tells the browser to perform the DNS lookup in the background.
   • Example: <link rel="dns-prefetch" href="//fonts.googleapis.com">
2. preconnect: This goes a step further than dns-prefetch. It completes the DNS lookup, TCP handshake, and TLS negotiation. Use this for critical third-party domains from which you know the site will fetch resources.
   • Example: <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
3. preload: Use this for a specific, critical file on your own server (like a font file or CSS file) that is needed for the initial render but might be discovered late by the browser.
   • Example: <link rel="preload" as="style" href="/wp-content/themes/my-theme/critical.css">
4. fetchpriority=”high”: A newer hint you can add to critical <img> or <link> tags (like your LCP image) to signal its importance to the browser.
   • Example: <img src="lcp-image.webp" fetchpriority="high">

Suggested read: The Best WordPress Caching Plugins To Speed Up Your Site (2025)

Enable a CDN and HTTP/3 with QUIC to Reduce Latency on Many Small Requests

A Content Delivery Network (CDN) reduces latency by storing copies of your assets on servers around the world and serving them from the location physically closest to the user. Enabling CDN can dramatically speed up your website.

HTTP/3 is the latest web protocol, built on QUIC, and designed to be faster and more reliable, especially on mobile or unstable networks. It excels at handling many small, parallel requests without the “head-of-line blocking” that could slow down HTTP/2.

1. Integrate a CDN: Sign up for a CDN service like Cloudflare, BunnyCDN, or KeyCDN. For a service like BunnyCDN, you’ll get a unique URL to which to point your assets. Alternatively, you can also use RunCloud’s built-in feature to enable Cloudflare Proxy with the flip of a switch.

2. Enable HTTP/3: This is a server-level configuration and might require you to modify server settings via CLI. However, with RunCloud, enabling HTTP/3 is as simple as flipping a switch in your web application’s settings. This ensures your site is using the most advanced protocol for handling requests efficiently.

Disable WordPress Emojis, Embeds, and Other Non-Essential Features That Trigger Requests

By default, WordPress loads a small JavaScript file (wp-emoji-release.min.js) on every single page to convert text emoticons into emojis. It also loads scripts for oEmbeds, which allow you to embed content from sites like YouTube easily. If you don’t use these features, they are just extra, unnecessary HTTP requests.

1. The easiest way to get rid of them is to use a plugin like Perfmatters or Asset CleanUp, which have simple toggles to disable emojis, embeds, and other WordPress core features like XML-RPC and jQuery Migrate.
2. Use Code Snippets: If you prefer not to use a plugin, you can add the following code to your theme’s functions.php file to disable these features manually:

// Disable emojis
remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
remove_action( 'wp_print_styles', 'print_emoji_styles' );
// Disable oEmbeds
remove_action( 'wp_head', 'wp_oembed_add_discovery_links' );
remove_action( 'wp_head', 'wp_oembed_add_host_js' );

Create SVG Sprite Sheets or Icon Sets to Consolidate Multiple Small Assets

If your site uses multiple small icons (e.g., for social media links, user interface elements), each one is often a separate HTTP request. An SVG sprite sheet is a technique where you combine all of your SVG icons into a single, large SVG file. You can then display any individual icon from that single file using a simple CSS reference, consolidating dozens of potential requests into just one.

Instructions:

1. Gather Your SVGs: Collect all the individual SVG icons you use on your site.
2. Generate a Sprite Sheet: Use an online tool like SVGOMG or a build tool like Webpack to combine your SVGs into a single sprite file. The tool will give you one .svg file and the corresponding HTML/CSS markup.
3. Load the Sprite: You can either include the SVG sprite inline in your theme’s header.php or footer.php file (best for performance) or load it via JavaScript.
4. Display an Icon: Use an SVG use element to reference the ID of the icon you want to display from the sprite.
   • Example: <svg class="icon"><use xlink:href="#icon-twitter"></use></svg>

Implement Critical CSS and Defer/Async Non-Critical JavaScript

By default, CSS and JavaScript files are “render-blocking”, which means that the browser has to download and parse them completely before it can display the page. Critical CSS is a technique where you extract the absolute minimum CSS needed to style the “above-the-fold” content and place it inline in the HTML <head>.

You then load the rest of the stylesheet asynchronously. Similarly, you should defer or async non-critical JavaScript so it doesn’t block the initial page paint.

1. Use a tool like the Critical Path CSS Generator or a service like criticalcss.com to generate the critical CSS for your key pages (homepage, blog post, etc.).
2. Implement in WordPress:
   • Plugin Method: Caching plugins like WP Rocket have a feature that automatically generates and applies critical CSS for you with a single click. This is the recommended and easiest method.
   • Manual Method: If doing it manually, you would inline the generated CSS in a <style> tag in your site’s <head>.
3. Load Full CSS Asynchronously: Load the main stylesheet using a non-blocking method.
   • Example: <link rel="stylesheet" href="styles.css" media="print" onload="this.media='all'">
4. Defer/Async JavaScript: Go through your enqueued scripts and add the defer or async attribute. The defer tag executes the script after the document has been parsed, while async executes it as soon as it’s downloaded. For most scripts, defer is the safer option. You can do this with plugins or programmatically using the script_loader_tag filter in WordPress.

Wrapping Up: Why You Should Reduce HTTP Requests for Your WordPress Websites

In this post, we’ve covered a wide array of powerful techniques to reduce the number of web requests for your website. While any single change provides a small benefit, their combined effect can turn a slow, bloated website into a streamlined, fast, and efficient website.

But why is this so critical? Reducing HTTP requests isn’t just about numbers. Some people even go as far as to create a website which is less than 14KB in size to reduce the number of web requests.

Finally, a leaner site puts less strain on your server, making it more stable and capable of handling more traffic without slowing down.

These optimizations only go so far without a fast, reliable server.

RunCloud takes care of the heavy lifting – managing caching, HTTP/3, and CDN configuration – so your site can load faster and handle more visitors effortlessly.

Start your free RunCloud trial today and see how quickly your WordPress site can perform when every HTTP request is optimized by default.

FAQs on Reducing HTTP Requests in WordPress