How to Easily Fix Leverage Browser Caching Warning in WordPress

Are you staring at that stubborn “Leverage Browser Caching” warning in your Google PageSpeed Insights report? You’re not alone. It’s one of the most common performance recommendations, and it often sounds far more complicated than it is.

In this guide, we will explain browser caching from a server-level perspective and show you how to fix the leverage browser caching warning in WordPress by setting the correct Cache-Control and Expires headers.

By the end of this article, in addition to fixing the “Leverage Browser Caching” warning in WordPress, you will see noticeable speed improvements in your website.

Let’s get started!

What is the “Leverage Browser Caching” Warning in WordPress?

When someone visits your site for the first time, their browser has to download all the website’s assets, such as your logo, stylesheets (CSS), and scripts (JavaScript). Browser caching is a set of instructions that your server can send along with these files that says, “These files can be stored on your computer for a while. You don’t need to download them again on your next visit.”                

When these instructions are missing, the browser has to re-download all those files on every page load, making the site feel much slower for returning visitors.

📖 Suggested read: LiteSpeed Cache WordPress Plugin Configuration Tutorial

Why Does Google PageSpeed Insights Show The “Leverage Browser Caching” Warning?

Google PageSpeed Insights shows the “Leverage Browser Caching” warning because adding proper caching controls speeds up the website for repeat users. When Google recommends a website to its users in search results, Google’s goal is to provide the best experience for its users, and that includes sending them to sites that load quickly.

The warning is triggered for two main reasons:

1. Slows Down Repeat Visits: Without caching, returning visitors have the same slow, “first-time” loading experience every time they visit. Fixing this makes the site feel almost instantaneous for them, which greatly boosts user experience.
2. Wastes Resources: Forcing the browser to re-download the duplicate files repeatedly uses unnecessary bandwidth (both for the user and your server) and increases your server’s workload.

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

How to Fix the “Leverage Browser Caching” Warning in WordPress

You can easily fix the “Leverage Browser Caching” warning by adding specific rules, known as caching headers, to your server’s configuration. In this section, we’ll explore the primary methods to implement this on your server.

⚠️ But before we go any further, here is a note of warning!

We understand that editing server configuration files or even .htaccess can feel intimidating. What if you make a mistake?

This is where RunCloud provides a layer of confidence with automated backups. Before implementing any of the caching rules discussed in this guide, you can take a one-click, on-demand backup of your entire web application’s files. If anything goes wrong, you’ll be able to quickly and easily restore your entire website to its previous state in seconds.

#1 – Setting Cache-Control Headers

The Cache-Control header is the most powerful way to manage browser caching. It gives the browser precise instructions on how to handle a file. The max-age directive in this header tells the browser how many seconds it takes to keep a file cached before asking for it again.

For example, a max-age of 31536000 tells the browser to store the file for one year. You can also specify directives such as public, meaning the file can be cached by any cache (like a browser or a CDN), or private for user-specific data.

On a RunCloud server using an nginx + Apache2 hybrid or OpenLiteSpeed stack, you can add these rules to your .htaccess file. For a pure nginx stack, you would use the “nginx Config” editor in your RunCloud dashboard. A typical rule looks like this for your .htaccess file, targeting different file types with appropriate expiration times:

<IfModule mod_headers.c>
  <filesMatch "\.(ico|jpeg|jpg|png|gif|svg|webp)$">
    Header set Cache-Control "max-age=31536000, public"
  </filesMatch>
  <filesMatch "\.(css)$">
    Header set Cache-Control "max-age=2592000, public"
  </filesMatch>
  <filesMatch "\.(js)$">
    Header set Cache-Control "max-age=2592000, public"
  </filesMatch>
</IfModule>

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

#2 – Using Expires Headers to Set Expiration Dates for Static Assets

The Expires header is an older, simpler method for enabling browser caching. Instead of specifying a duration in the same way Cache-Control does, the Expires header sets a specific future date and time when the cached file should be considered “stale”.

While Cache-Control is the modern standard, and it will override the Expires header if both are present, including Expires headers is still good practice for compatibility with older proxy servers and browsers.

Adding expiration headers is very straightforward, especially in the .htaccess file found on RunCloud’s Apache2 or OpenLiteSpeed stacks. The mod_expires module allows you to set human-readable expiration times, making configuration easy.

For example, you can specify “access plus 1 year” for images and “access plus 1 month” for CSS and JavaScript files. This tells the browser to calculate the expiration date based on when the user first accessed the file.

Here is a simple and effective ruleset to add to your .htaccess file:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/gif "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

📖 Suggested read: Everything You Need to Know About WordPress Object Caching

#3 – Fixing “Leverage Browser Caching” Warning for Third-Party Scripts and Resources

One of the most common frustrations for site owners is seeing a caching warning for scripts that aren’t even hosted on their own server. This frequently happens with resources such as Google Analytics, Google Fonts, or Facebook Pixel. You can’t control their caching headers because these files are located on Google’s or Facebook’s servers. This is why PageSpeed Insights will still flag them, even if your server is perfectly configured.

While you technically can’t “fix” the headers on their servers, the only workaround is to host these scripts locally on your server. For example, you could download the Google Fonts files and serve them directly from your domain.

However, the biggest downside to this approach is maintenance. When Google updates its Analytics script or adds new font characters, your local copy will become outdated, and you are responsible for manually updating it.

For most users, the performance gain from caching these small third-party scripts locally is not worth the maintenance and potential security risks of running outdated code. Also, hosting third-party content on your own servers might break copyright laws in some jurisdictions. The best practice is often to correctly configure caching for all your assets and accept the warning for these third-party services.

📖 Suggested read: Which is Better: Redis Full-Page Cache or nginx FastCGI Caching?

Best WordPress Plugins to Fix the “Leverage Browser Caching” Warning

For many users, manually editing server configuration files can be daunting. Thankfully, the WordPress ecosystem has many powerful plugins that can automatically configure these settings with just a few clicks.

#1 – How Litespeed Cache Solves Browser Caching Issues

If your WordPress site runs on a RunCloud server with the OpenLiteSpeed (OLS) stack, you can quickly configure the LiteSpeed Cache for WordPress (LSCache).

Unlike other caching plugins, LSCache is not a third-party plugin that provides basic caching solutions. It is a server-level solution that integrates directly with the OpenLiteSpeed web server. This deep integration allows it to manage caching with incredible efficiency.

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

When you install and activate the LSCache plugin, you can navigate to the LiteSpeed Cache > Cache > Browser tab in your WordPress dashboard. You’ll find a simple toggle switch for “Browser Cache” here. Turning this on will automatically add the optimal Cache-Control and Expires rules to your .htaccess file.

This configuration also sets long cache lifetimes for your static assets, instantly solving the “Leverage Browser Caching” warning for all files hosted on your server. Additionally, this plugin is “talking” directly to the OLS server, and it can create highly optimized rules and work seamlessly with its other powerful features, like full-page caching and ESI.

If you want step-by-step instructions for this, we recommend reading our thorough article covering the LiteSpeed Cache WordPress plugin configuration.

#2 – Using RunCloud Hub to Manage Browser Caching Automatically

If your site is running on the nginx stack, then you can use RunCloud’s highly optimized page cache solution called RunCache. When you install the RunCloud Hub on your WordPress site, RunCloud automatically applies an advanced nginx configuration that serves your site with incredible speed. This default configuration already includes best-practice rules for browser caching.        

This means that for most users, RunCache automatically solves the browser caching warning without you needing to do anything extra. It’s configured to tell browsers to cache static assets like images, CSS, and JS for a long period.

We recommend reading the following documentation posts if you want to learn more about RunCloud Hub:

• Installing RunCloud Hub on multiple sites via API
• Understanding RunCache Purging Options in RunCloud Hub
• Best Practices for Caching WooCommerce with RunCloud Hub
• RunCloud Hub Integration with Cloudflare Caching
• How to Use MainWP Cache Control with RunCloud Hub

Wrapping Up

The “Leverage Browser Caching” warning is a direct signal that you’re sacrificing site speed and user experience. You should fix this warning as soon as you see it, as this improvement directly impacts user satisfaction, reduces bounce rates, and sends positive signals to search engines like Google, which heavily favor fast, responsive websites as part of their Core Web Vitals initiative.

And with a platform like RunCloud, you can move beyond basic plugin solutions to implement a far superior, server-level caching strategy.

A typical WordPress caching plugin operates within the WordPress environment. WordPress and its underlying PHP code must first be loaded into memory for a cache to be built or served. While this is better than nothing, it still consumes server resources including memory and PHP workers.

RunCloud Hub allows you to configure RunCache, its native nginx FastCGI cache. This server-level cache intercepts requests before they even reach WordPress. It serves a pre-made, static HTML version of your page directly from the web server’s memory. This method is dramatically faster and more efficient, bypassing the resource-intensive process of loading PHP and the WordPress application.

RunCloud provides a powerful, intuitive Hub with server-level performance tools like RunCache at your fingertips.

Deploy your first lightning-fast, securely managed WordPress site with RunCloud today.

FAQs on Fixing Browser Caching Warnings in WordPress