How to Fix the “Specify a Cache Validator” Warning - Gregg Hosting

The affects of Web Hosts on Your Business Website

Here're ways your choice of web hosting service provider impacts the performance of your business:


Website loading speed


Uptime and availability


Customer support




Server location

How to Fix the “Specify a Cache Validator” Warning

How to Fix the “Specify a Cache Validator” Warning

Specify a Cache Validator


On your WordPress site, are you getting the “Specify a cache validator” warning from Pingdom, GTmetrix, or Google PageSpeed Insights? This is due to the absence of HTTP caching headers, which should be provided in every origin server response because they validate and set the cache length. If the headers aren’t found, it’ll make a new request for the resource each time, putting more strain on your server. Using caching headers eliminates the need for subsequent requests to be loaded from the server, conserving bandwidth and enhancing user speed.

specify a validator warning for the cache
A cache validator warning can be specified.
Pingdom has issued a warning:

A cache validator is missing from the following sites. Cache validators aren’t specified in resources, therefore they can’t be renewed efficiently. To enable cache validation for the following resources, use a Last-Modified or ETag header.

To fix the “Specify a cache validator” warning, follow the instructions below.

Fix the “Specify a cache validator” Warning
The first thing to remember about this warning is that it can only be fixed for requests that originate from your server. If you’re seeing this on 3rd-party requests, there’s nothing you can do because you don’t have control over their web servers. However, please feel free to forward this material to them. Remember that using Pingdom, you may need to repeat the test several times. It’s possible that the warning will appear the first time and then vanish the second time. The utility is priming the cache of assets from the server when you first launch it.

There are four different sorts of headers that can be used to fix this warning in different ways. This is where things can get a little difficult, but we’ll try to make it as simple as possible to understand.

Validating Cache Headers
Last-modified and ETag are the first two headers. These headers assist the browser in determining whether the file has changed since it was last accessed. Or, to put it another way, they validate the cache.

1. When was it last modified?
The server often sends the last-modified header automatically. You won’t have to add this header manually very often. It’s sent to see if the file in the browser’s cache has changed since it was last accessed. To examine the value of the last-modified header, look at the header request in Pingdom or use Chrome DevTools.

header with the most recent changes
Header with the most recent modification 2. ETag
The ETag header resembles the last-modified header in appearance. It’s also used to check if a file’s cache is valid. The ETag header is already added using the FileETag directive if you’re running Apache 2.4 or higher. In terms of NGINX, the ETag header has been enabled by default since 2016.

header etag
Header for ETag
Using the following code, you may manually enable the ETag header in NGINX.

etag on Cache Length Determining Headers
Cache-Control and Expires are the following two headers. These headers govern how long a file should be cached before a new copy is requested from the server. Remember that in order to fix the warnings in Pingdom or GTmetrix, you must have a header that validates the cache as well as one that defines the cache length.

3. Cache Management
Cache-Control is a header made up of various directives that allow you to specify the cache length. The following are a handful of the most common directives:

Do you want to discover how we grew our traffic by over 1000%?
Join the 20,000+ people who receive our weekly email with WordPress insider secrets!

Now is the time to subscribe.
max-age: This specifies how long a file should be cached.
public: Allows any cache to store the response publicly.
private: Only the browser that is accessing the file can cache it.

Header for Cache-Control
The max-age directive is used by the asset in our example above. A seven-day cache would be 604800 seconds. Simply add the following code to your.htaccess file to configure this in Apache.

“.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$” filesMatch
/filesMatch> header set Cache-Control “max-age=604800, public”
Simply add the following code to your NGINX config file to configure this. The /etc/nginx/ directory contains all NGINX configuration files. /etc/nginx/nginx.conf is the main configuration file.

location *. (js|css|png|jpg|jpg|jpeg|gif|ico) $ add header Cache-Control “public”; $ add header Cache-Control “public”; $ add header Cache-Control “public”; $ add
Check out this in-depth essay on Cache-Control to learn more about the different directives.

Do you have issues with downtime with WordPress? Kinsta is a web hosting service that saves you time! Take a look at our highlights.
4. Has passed its expiration date
Finally, there’s the expires header. The HTTP Caching: Cache-Control header was developed as part of the HTTP/1.1 protocol and supersedes prior headers (in this case, the Expires header) used to define response caching policies, according to this Google Developers page. Cache-Control is supported by all modern browsers, so that’s all you’ll need. It won’t harm if you have both, but keep in mind that only one of them will be used. The Expires header utilizes the current date, whereas the Cache-Control header allows you to specify a time limit before the cache expires.

header expires
Simply add the following code to your.htaccess file to enable the Expires header in Apache.

## EXPIRES HEADER CACHING ## IfModule mod expires.c> IfModule mod expires.c> IfModule mod expires.c> IfModule mod expires.c
Active On ExpiresOn ExpiresOn ExpiresOn Expires
image/jpg “access 1 year” ExpiresByType image/jpg “access 1 year”
ExpiresByType image/jpeg “access 1 year” ExpiresByType image/gif “access 1 year” ExpiresByType image/png “access 1 year”
image/png “access 1 year” ExpiresByType image/png “access 1 year”
Text/css “access 1 month” ExpiresByType
application/pdf “access 1 month” ExpiresByType
ExpiresByType application/javascript “access 1 month” ExpiresByType application/javascript “access 1 month”
ExpiresByType application/x-javascript “access 1 month” ExpiresByType application/x-javascript “access 1 month”
application/x-shockwave-flash “access 1 month” ExpiresByType application/x-shockwave-flash “access 1 month”
image/x-icon ExpiresByType “access 1 year”
ExpiresDefault “access 7 days” /IfModule> ExpiresDefault “access 7 days” /IfModule>
Make sure your Expires headers block is below stuff like mod rewrite, GZIP, and so on. The safest location is at the bottom of the file.

htaccess expire headers
.htaccess headers with expires
Simply add the following code to your NGINX config file to enable Expires headers.

.(js|css|png|jpg|jpeg|gif|ico) location*

$ expires in 7 days;
On NGINX, the Cache-Control and Expires headers are frequently combined, despite the fact that this is not technically required:

.(js|css|png|jpg|jpeg|gif|ico) location*

$ expires in 7 days; add header Cache-Control “public”; $ expires in 7 days;
All of the headers listed above are automatically added to all Kinsta servers, so if you’re a Kinsta customer, you’ll never see this warning and won’t have to worry about it. When delivering your assets, most 3rd party CDN providers, such as KeyCDN and Cloudflare, include these headers automatically. If you’re seeing the warnings, it’s possible that your host is using out-of-date software or that the server has been misconfigured. This is most common on shared hosts. If you’re setting up your own server, some of the headers listed above may not yet be present.

And if all goes well, and you don’t have any 3rd-party requests that aren’t using the header appropriately, you should see an increase in your score using website performance test tools like Pingdom (as seen below).

Specify a cache validator warning has been fixed.
Save time, money, and improve site performance by using:

Expert WordPress hosting assistance is available 24 hours a day, 7 days a week.
Integration with Cloudflare Enterprise.
With 29 data centers across the world, we can reach a global audience.
With our built-in Application Performance Monitoring, you can improve your performance.
All of this and more is included in a single plan that includes no long-term obligations, aided migrations, and a 30-day money-back guarantee. Check out our plans or speak with a sales representative to find the ideal plan for you.