Refund Policy

Confused by what the cache-control HTTP header is and how it works with your WordPress site?

In a nutshell, cache-control is an HTTP header that specifies browser caching policies for certain static resources on your website, such as your images. That sounds a little complicated – we know! So if you bear with us, we’ll dig into the topic of cache-control in much greater detail.

In this article, we’ll explain what cache-control is and how it affects behavior on your website. But before we get into the cache-control header, we first need to explain the concept of browser caching.

Here’s what we’ll cover:

• What browser caching is
• What cache-control is and how it works (HTTP headers)
• The different cache-control directives
• How cache-control applies to WordPress/WP Rocket users

Let’s dig in…

What Is Browser Caching?

When someone visits your website for the first time, their web browser needs to request and download every single file to render your page.

However, on subsequent visits, it doesn’t make sense to force them to request and download every single resource on each visit.

For example, your logo probably loads on every single page, but it doesn’t change that often. Forcing a visitor’s browser to re-download your logo for every single page load is just a waste of resources that will slow down your site.

Browser caching lets you avoid that scenario by saving certain types of resources on a visitor’s local computer. Then, a visitor’s browser can load that resource locally rather than re-downloading it, which will speed up your site’s load times and create a better experience for your visitors. This is why you typically see “Leverage browser caching” as a common recommendation in tools like GTmetrix and Pingdom.

In order to enable browser caching, you need to configure your web server so that it tells visitors’ browsers which types of files to store and how long to store them for before re-downloading them.

For example, you can configure your server to say:

“Hey, store JPEG files for one year, but only store PNG files for one month”.

Basically, you set up expiration dates for how long visitors’ browsers should store certain content.

Why add expiration dates at all? Because you want to make sure your visitors still get the most recent version of your page. By setting an expiration date, you’re ensuring that visitors will periodically re-download the relevant resources to ensure an updated experience.

For more, check out our full explanation post on browser caching.

Note – browser caching is a separate strategy from page caching, which is what most people are talking about when they reference “caching” for WordPress. If you’re using WP Rocket, WP Rocket will automatically implement both page caching and browser caching for you – more on this later.

What Is Cache-Control, Then?

Cache-control is one of the main methods to control this browser caching behavior, with the other being expires headers.

Basically, cache-control lets you set these “expiration” dates to control whether a visitor’s browser will load a resource from its local cache or send a request to your site’s web server to download the resource. 

It gives you lots of control over how each individual resource behaves and it also lets you control who can cache your content. For example, you can say that a visitor’s browser can cache a certain image, but a CDN (such as Cloudflare) cannot cache it.

More specifically, cache-control is an HTTP header, which brings us to another term that we need to define.

What Are HTTP Headers?

HTTP, short for Hypertext Transfer Protocol, governs how clients and servers communicate. For our purposes, a client is a visitor’s web browser and a server is your WordPress site’s server.

When a client needs a file, it sends a request to the server and the server sends a response to the client.

For example, if your website has an image, a visitor’s browser would first request that image from the server and then the server would respond with the image file. The browser would then repeat the same process for every resource on your site, including CSS stylesheets, JavaScript, etc.

HTTP headers let clients or servers send additional information with those client requests and server responses. There are different types of HTTP headers, with cache-control being one of them.

Most modern web browsers include developer tools that let you see the HTTP headers associated with every request/response involved in loading a web page.

In Chrome, you can:

• Open developer tools (CTRL + Shift + I)
• Go to the Network tab
• Reload the page
• Select the resource that you want to analyze
• Look at the Headers tab

For example, here are all of the HTTP response headers for loading the featured image for one of WP Rocket’s blog posts:

You can see that cache-control is one of those headers, but there are lots of other headers that communicate additional information. We even added a nice little easter egg in the x-curious header.

HTTP headers can go in both directions. That is, your web browser can attach HTTP headers to the request that it makes to the server, and the server can attach HTTP headers to the response that it sends to the browser.

HTTP headers consist of key-value pairs. The “key” is the part to the left of the colon, while the “value” is the part to the right. More specifically, the value is called the directive for cache-control.

In the example above, the key is “cache-control” and the value/directive is “max-age=31536000” (more on what this means next). 

How Does Cache-Control Work?

Ok, at this point you know what browser caching is. You also know that cache-control is one way to control browser caching behavior and that cache-control is an HTTP header that’s passed when a visitor’s browser communicates with your web server.

Now, let’s get into how cache control actually works and the different directives that you can use to control browser caching behavior.

As you learned above, cache-control is a key-value pair that looks something like this:

cache-control: max-age=31536000

In this example, the directive is max-age=31536000, but there are other cache-control directives that you can use, and you can also combine multiple directives by using commas.

Let’s go through the most common cache-control directives.

cache-control: max-age=<seconds>

The max-age directive defines how long a browser can reuse the fetched resource before it should download a new resource. The max-age number is in seconds and starts as soon as the request is made.

Example:

cache-control: max-age=31536000

In this example, the directive is telling a visitor’s browser to use the cached resource for one year from the time of the original request. There are 31,536,000 seconds in one year.

Many cache-control responses will only contain the max-age directive, so you can kind of think of this as the “default” directive.

The max-age directive can be used by both the client and the server.

cache-control: public and cache-control: private

The public and private directives are two opposing directives that control which types of clients can cache resources.

The public directive means that the resource can be stored by any cache. For example, a visitor’s browser, a CDN, etc. 

The private directive, on the other hand, means that the resource can still be cached by the visitor’s browser, but it cannot be cached by other intermediate caches, such as a CDN. 

You would typically use the private directive for content with user information that you don’t want to be cached by a CDN but are fine with being cached by the visitor’s browser.

The public and private directives are only used by the server in its HTTP response.

cache-control: s-maxage

The s-maxage directive is similar to max-age, but specifically for shared caches (such as a CDN). It lets you control how long those shared resources can continue to serve a resource from the cache.

For example, if you’re using a CDN, this would be one way to control how long your CDN caches resources (as long as your CDN obeys the directive, which most popular CDNs do).

The s-maxage directive is only used by the server in its HTTP response.

cache-control: no-cache

The no-cache directive is somewhat confusing because of the name. It allows any cache to store the response, but the stored response must go through validation with the origin server before using it. That is, a visitor’s browser has to check to make sure that the resource hasn’t changed before using the cached resource.

If you want to completely avoid storing the response in any cache, you actually want to use no-store, which is the next directive that we’ll look at.

The no-cache directive can be used by both the client and the server.

cache-control: no-store

The no-store directive disallows both browsers and intermediate caches from storing the resource. The client will always need to request this asset from the server for every page load.

Typically, you would use this for very sensitive information that you never want to be cached, such as banking information.

The no-store directive can be used by both the client and the server.

cache-control: max-stale[=<seconds>]

Unlike the other directives which can all be used in the server’s HTTP response, the max-stale directive is only used in a client’s request to the server.

The max-stale directive tells a server that the client is willing to accept a response that has exceeded its freshness lifetime by the number in the max-stale directive (in seconds).

WP Rocket and Cache-Control: Do You Need to Do Anything?

If you’re using WP Rocket to speed up your WordPress site, you don’t really need to worry about the cache-control header concepts that we’ve discussed in this article.

WP Rocket automatically implements browser caching using another popular method – expires headers.  

WP Rocket enables browser caching (and expires headers) by default as soon as you activate the plugin. It sets up expiration times that are optimal for different types of data – you can view the exact configuration here.

So – if you’re using WP Rocket on your WordPress site, you don’t need to worry about cache-control or expires headers – we take care of it for you as soon as you activate WP Rocket.

You can also use cache-control and expires headers at the same time – they don’t have to be mutually exclusive concepts.

If you’re using WP Rocket, this might come into play if you’re using a CDN to deliver some of your static assets. Many CDNs let you define your own HTTP cache-control headers for resources that you deliver via the CDN. 

Conclusion

To finish things out, let’s recap what we’ve covered from the perspective of a WordPress user.

Cache-control is an HTTP header that lets you control how/how long visitors’ browsers (or CDNs) should cache different types of resources on your site.

By caching these resources locally, you can speed up your site’s page load times. However, you don’t want to permanently cache resources, as you also want to ensure that visitors are always seeing the most recent version of your website. Properly implementing browser caching lets you strike the right balance.

There are different directives that you can add to cache-control, but the most “common” directive is max-age, which specifies how long a visitor’s browser should store a resource before requesting it again, in seconds.

If you’re using WP Rocket, you don’t need to worry about cache-control headers because WP Rocket already implements browser caching for you using another popular method – expires headers.

However, you still might encounter cache-control headers if you’re using a CDN with your WordPress site, as most CDNs let you customize the cache-control headers for the resources that you deliver via your CDN.

You can speed up your WordPress site so it’s around three times faster or more with the OPcache PHP OPcode caching system.

OPcache is a type of caching system that saves precompiled script bytecode in a server’s memory called a cache, so each time a user visits a web page, it loads faster.

Here’s more detail on OPcache and how to install it for your WordPress site to speed it up.

What is Caching?

Caching is a system you can put in place to speed up your site. It works by saving content to your server’s memory the first time it’s loaded on a web page. Each subsequent page load has the stored content retrieved from memory and served on the page.

This process means cached content is displayed a lot faster than if it’s loaded directly from the server.

It’s like memorizing your multiplication tables. Once you have memorized it, it’s so much faster to recite the answer to a multiplication problem from memory rather than trying to calculate the answer all over again.

A cache works in a similar way. Content is stored in a server’s memory so it can be loaded from there quickly instead of going all the way to the server to load the content which takes more time.

The result is a faster-loading WordPress website.

There are also different types of caching such as browser, site, object, and OPcode caching. It’s recommended that you implement more than one kind to increase your site’s performance.

For details, you can also check out these resources:

• Caching for WordPress, Explained in Plain English
• Browser Cache vs Cookies: What’s the Difference?
• What is Object Caching and How to Use It With WordPress

What is OPcache or PHP Opcode Caching?

OPcache is a type of OPcode caching. This kind of caching compiles human-readable PHP code to code your server understands which is called opcode. This occurs when the PHP file loads on a web page for the first time. Then, it’s saved to the server’s memory for faster loading at each subsequent page visit.

Bytecode cache engines such as OPcache, APC, and Xcache all complete this process the first time the PHP file is executed without having to do it a second, or third time.

How PHP Opcode Caching Works

When a PHP script executes, your server’s cache memory is checked to see if the script has already been cached. If it hasn’t, it’s parsed, which means the code is analyzed.

Then, the script is compiled into opcode making the file readable by the server. Once that’s done, the opcode is saved to the server’s memory.

In other words, it’s stored in your server’s cache. The next time a visitor loads the page with the PHP script, the cached code is executed and loaded much faster.

On the other hand, if the script is loaded on the page and the cache is checked for opcode and finds it, then it’s loaded lickety-split.

The Differences Between OPcache and APC Caches

OPcache, APC as well as Xcache are all opcode caching systems. OPcache used to be owned by Zend and Alternative PHP Cache (APC) was a free, open-source extension for PHP. Xcache was also an alternative option.

APC was widely used, but it didn’t have the backing that OPcache had so it could be well maintained and stable with each new PHP release.

Fortunately, Zend made OPcache open source and available as an extension since PHP version 5.5. In earlier versions, you have the choice to use APC or OPcache, but if you would like to use the latter, you need to manually install it.

Xcache, on the other hand, is a good alternative to OPcache as a PHP accelerator.

Will OPcache Speed up My WordPress Site?

All three options are suitable for WordPress, but the recommended option for PHP version 5.5 and above is OPcache. On average, it speeds up WordPress threefold, at the very least for medium to large sites.

If you have a smaller site without many additional PHP scripts or plugins installed, you likely won’t notice much of a difference.

However, you can still install OPcache on even small WordPress sites with no negative effects other than a slight increase in memory usage. But, it won’t be enough to cause any issues. This is similar for medium, large, or enterprise sites.

How to Install OPcache on Your Server

If you have PHP version 5.5 and above, OPcache PHP opcode caching is installed and enabled by default. You don’t have to do anything else. There are also no additional requirements or configurations needed to run it.

That’s also why you won’t find any options if you were to look for them.

For details, check out Why You Need to Upgrade to PHP 7+ ASAP. (and How to Do It Right Now)

According to the PHP manual:

“OPcache can only be compiled as a shared extension. If you have disabled the building of default extensions with –disable-all, you must compile PHP with the –enable-opcache option for OPcache to be available.
Once compiled, you can use the zend_extension configuration directive to load the OPcache PHP opcode caching  extension into PHP. This can be done with zend_extension=/full/path/to/opcache.so on non-Windows platforms, and zend_extension=C:\path\to\php_opcache.dll on Windows.”

When you have done that, restart PHP using SSH.

On Apache, enter the command below to restart PHP.

<script src="https://gist.github.com/jennimckinnon/a0a6d996d5d553aff58087cffc6c2f2b.js"></script>

For Nginx, enter the following:

<script src="https://gist.github.com/jennimckinnon/ee58de4f502c3540e3f5cb81f60db64d.js"></script>

How to Install OPcache on Earlier Versions

If your server is running on PHP versions 5.2, 5.3, or 5.4 you can manually install OPcache using the PECL command below:

<script src="https://gist.github.com/jennimckinnon/f80d2fe73c1c1e0be5712e9bb8fe3fd1.js"></script>

Next, go to you php.ini file:

<script src="https://gist.github.com/jennimckinnon/b4cbe5d0f924293fa29240c8ddf52517.js"></script>

You’ll need to update your php.ini file with the following recommended settings:

<script src="https://gist.github.com/jennimckinnon/a08541df21fa0a275b1306ec67b6f31c.js"></script>

You can often find your php.ini file in your site’s file folder system. If you’re not sure how to find it, contact your hosting provider.

Wrapping Up

For many WordPress site owners, their server may already have the latest version of PHP installed. This means they already have OPcache automatically enabled to drastically speed up page load times for their site.

For those who have PHP version 5.2 to 5.4, you can manually install OPcache with the steps outlined above.

Caching is one of the pillars of web performance optimization, the set of techniques to make your website load faster. No website can call itself optimized without a caching system in place.

At first sight, caching can look like a very complex topic: we’re not going to lie, most of the time it is! But the good news is that we’re here to help. ?

All caching systems work under the same principle:

Caching is the process of storing data in a temporary storage unit, called cache.

So far, so good. Complexity comes into the picture when we try to define the storage unit our caching process is working on. Caching can take many forms and leverage on diverse aspects of our website.

Here’s a quick list of the different types of caching we can identify:

• Page cache: it happens on the server and stores the entire HTML of a page (as WP Rocket does);
• Browser cache: it keeps storing the HTML but occurs on the browser;
• Object cache: it stores database queries;
• Bytecode cache: it’s a PHP extension and stores precompiled script bytecode in the memory;
• CDN cache: it occurs on the CDN-side and stores the HTML and all other static files (images, CSS and JS);
• Reverse proxy cache: it happens on the server’s side and stores all its responses to the client’s server.

In this article, we’re going to focus on this last type of caching and, in particular, to one of the most popular HTTP reverse proxies: Varnish cache.

Understanding HTTP Reverse Proxies

Generally speaking, a ”Proxy” is a server placed between the Internet and a user (or a network of users, like a LAN). The proxy server is there to filter the requests sent by the user to a specific web page, following a particular rule.

A classic example of a proxy server (also called forward proxy) is the one implemented by several companies wanting to block employees’ access to some content on the Internet (i.e., social media websites).

On the other hand, a reverse proxy is a server placed between the Internet and a company’s web server. A reverse proxy is the entry point of all requests directed to a company’s website: its scope is to filter those requests before they reach the site.

The most used reverse proxy on the market are:

• Varnish
• Apache httpd
• Nginx
• IIS
• Lighttpd
• Squid
• F5 BIG-IP
• HA Proxy

Some of them, like Apache httpd, NGINX, Lighttpd, and IIS are also web servers, but they can act as reverse proxies.

Why Should You Use a Reverse Proxy on Your Website?

The answer is simple: there are several advantages of using a reverse proxy. Let’s see them briefly:

• Anonymization: if someone scans a domain pointing to a reverse proxy, they will get information about the proxy, not about the actual web server behind it;
• Security: following the point above, a website protected by a reverse proxy can more easily avoid malicious attacks;
• SSL download, or SSL termination: the reverse proxy can absorb all the HTTPS requests and perform the SSL handshake with the user’s browser. These requests are then converted to HTTP and sent to the web server. In this way, you set your server free from the SSL handshake, and it can take care of other important actions (like downloading the rest of your webpage content);
• Centralized administration of multiple SSL certificates: with a reverse proxy you can place all the SSL certificates that you use in your web pages in a single server;
• GZIP compression: you can configure the GZIP mode on your web server, so it can compress your file sizes and transfer them quicker;
• Last but not least, caching! If you let the reverse proxy temporarily store the static content of your pages, this will be served whenever a new request asks for it: there won’t be any call to the origin server, and your pages will load faster.

We’re going to develop this last point in the following chapter.

What is Varnish Cache?

Now that you know what a reverse proxy is, you’re ready to dig into the magic of Varnish Cache!

Varnish acts as a cache HTTP reverse proxy and sometimes you can also see it defined as a front-end accelerator. It’s not a stand-alone solution, because it needs a dedicated web server to rely on, like NGINX or Apache.

You can use Varnish to cache both dynamic and static content: this is an efficient solution to increase not only your website speed but also your server performance. According to its developers:

“It can speed up delivery with a factor of 300 – 1000x, depending on your architecture.“

What Are the Benefits of Using Varnish Cache?

The first benefit Varnish provides, as already mentioned, is the speed boost for your website and server.

This happens thanks to a series of factors:

• The cache server is faster than the origin server when delivering objects because the workload on the first is less intensive and less varied.
• The cache server delivers all assets that don’t frequently change, like CSS and JavaScript files. This reduces the burden on the origin server, which can focus on rendering pages quicker since it doesn’t have to serve static content on every reload.
• Time To First Byte (TTFB) decreases because the processing time for the backend server database is lower.
• You can use Varnish as part of a highly available environment to serve cached content even when the web server is experiencing downtimes (more on this below).

How Does Varnish Cache Work?

Varnish handles all inbound requests before they land to your web server backend: its cache serves all web traffic and, by default, refreshes every two minutes (or a different lifespan, if you decide so).

If the request is not cached, Varnish will forward the request to the web server’s backend and cache the result, as we already saw in the general reverse proxy paragraph.

The cached requests are then stored in the memory: from this moment on, retrieving and delivering them to clients will be much faster.

To specify configuration, caching policies and other rules, Varnish uses a language called VCL (Varnish Configuration Language).

Through this language and its alterations, you can handle each request differently. For example, you can choose to forward specific requests to a particular backend, or you can ask Varnish to act differently depending on the properties of the inbound request or its output.

Another cool behavior of Varnish is that thanks to a built-in tool called backend polling, cached content can continue to be served even when the web server is not available.

The backend polling interrogates the server with a frequency that you can flexibly configure: if Varnish detects downtime, it will keep serving cached content for a period called grace time (which is also customizable).

More info on the configuration commands is available in Varnish documentation.

How to Use Varnish Cache on Your WordPress Site?

Millions of WordPress sites are using Varnish Cache.

Once Varnish is installed and configured on your web server, you’re ready to instruct WordPress to interact with it and purge Varnish Cache whenever the cached content changes.

To achieve this, you can use a WordPress plugin: one of the most installed (and better maintained) is Proxy Cache Purge.

But there are several other plugins with features interacting with Varnish and making cache purging easier.

WP Rocket, for example, includes a Varnish add-on that allows you to flush the Varnish cache at the same time as WP Rocket.

Try it by yourself, get WP Rocket now!