> > Using cache-control for browser caching

Updated: March 17th 2016

What is cache-control?

  • Cache-Control is a HTTP header that defines the amount of time and manner a file is to be cached.
a css file and caching instructions

This article will discuss how to use cache-control, what the values mean, and how to get it to actually work on your website.

Most modern and fast websites use cache-control to leverage browser caching.

Using Cache-control

Contents of this guide:

Cache-Control header basics

The basic Cache-Control header defines amount of time that a file should be cached and the manner in which that caching should take place.

Cache-Control: max-age=2592000, public

When a file is accessed by a browser the HTTP headers are also retrieved. When the Cache-Control header is included the browser will respect the values found there.

If a browser sees that a file should be cached for five minutes, it will stay in the browser cache for five minutes and that file will not have to be retrieved if it is called again.

a cached file being used

An example might be your logo image. If a visitor comes to one of your web pages, it will download the logo image. If the user then goes to another webpage on your site, the logo image will not be downloaded again. Instead the cached version will be used.

What is max-age?

  • "max-age" defines the amount of time a file should be cached for.
  • The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds. 1

max-age usage

The max-age portion of the header looks like this:


The max-age is expressed in seconds.

Common max-age values are:

  • One minute: max-age=60
  • One hour: max-age=3600
  • One day: max-age=86400
  • One week: max-age=604800
  • One month: max-age=2628000
  • One year: max-age=31536000

When using max-age to define your cache times one should consider the file type and how it is used. We will discuss this in more detail later in this article.

Caching Directives

The cacheable directive portion of the above header looks like this:


The Cache-Control header above states "public". This means that this file may be publicly cached (in contrast to being a private file).

By default, most things are considered to be publicly cacheable (able to be cached) but there do exist times when this behavior would not be advisable for sensitive documents, security, user specific content, etc.

We will cover three main directives offered by Cache-Control:

  • public
  • private
  • no-store


The "public" directive basically is saying that anyone can cache this at any level.

The official specification defines it as...

The "public" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache.

In essence, if you want something cached for page speed reasons, and it is not private or time sensitive then you should use the public directive.


The private directive means it is specific to one person. An example would be a Twitter page. When you go to Twitter you see one thing and another person going to the same url sees something else. Even though the information on that page is public and not sensitive, it is specific to one person. (Note: Twitter is just a conceptual example, I have no idea what they use or how they use it)

The official specification defines it as...

The "private" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared cache. A private cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable.

So if I go to, and then hit refresh some things will be cached for me but not you. If you go to and hit refresh some things will be cached for you but not me.


The no-store directive is the strongest indication that something should never ever be stored in any caching mechanism whatsoever.

The official specification defines it as...

The "no-store" response directive indicates that a cache MUST NOT store any part of either the immediate request or response. This directive applies to both private and shared caches.

Once again I must note that this does not actually secure anything.

File types

Two questions a webmaster should ask are:

  • What file types should I cache?
  • How long should I cache them for?

What file types should be cached?

As a very broad and general guide, I would point out the following things about certain file types...

  • Images - (png, jpg, gif, etc.) Images don't really change so they can have a long cache time period (a year)
  • CSS - CSS files tend to change more often than other files, a shorter time period may be needed (week or month)
  • ico (favicon) - rarely changed (a year)
  • JS - Javascripts for the most part are not changing very often so a longer cache time is normally possible (a month)

Things to consider

Only you can determine what is best for your site and your site resources. One thing I would mention is that if you do change something (like a CSS file) and that file is cached, you should consider changing the name of the file so that your updated CSS file is seen by all users.

This is called URL fingerprinting.

Getting a fresh (not cached) file resource is possible by having a unique name. An example would be if our css file was named "main.css" we could name it "main_1.css" instead. The next time we change it we can call it "main_2.css". This is useful for files that change occasionally.

How to add Cache-Control to your site

The way to add Catch-Control to your files is the same way you add any headers to your server.

Everything we have talked about on this page is about the Cache-Control header.

So how is it added?

That depends on your web server. We will go through the most common scenarios below.

.htaccess file

Most people reading this will likely use the .htaccess file for adding headers.

Example code for .htaccess file:

The most basic code for setting the Cache-Control header via the .htaccess file is...

Header set Cache-Control "max-age=2628000, public"

The above code however does not give you any ability to provide different caching instructions for different file types.

To apply different Cache-Control headers to different file types we would use...

# One month for most static assets
<filesMatch ".(css|jpg|jpeg|png|gif|js|ico)$">
Header set Cache-Control "max-age=2628000, public"

The above code is basically saying...

"If the file type is css, jpeg, jpg, png, gif, js, or ico then apply the following header to it."

Now let's say we want to make images be cached for a year, but keep css and js files cached for a month.

We would then put the following in our .htaccess file:

# One year for image files
<filesMatch ".(jpg|jpeg|png|gif|ico)$">
Header set Cache-Control "max-age=31536000, public"

# One month for css and js
<filesMatch ".(css|js)$">
Header set Cache-Control "max-age=2628000, public"

Above we have two blocks of code, one for images and one for css and js files. This is just to illustrate that you can have multiple blocks in your .htaccess file.

Apache config http.conf

If you have access and know what you are doing, setting your headers via the config file is faster and recommended.

The code examples above from .htaccess will work as is.

Use filesMatch and Header set to create your file type specific instructions (again, the .htaccess code examples above should work fine).


Using the expires directive you can add cache instructions to a server or location block.

location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;

The above code is for each of the file types listed in the first line. These filetypes can be added to or removed. There can also be multiple blocks for fine tuning diferent file types.


If you have a multi cpu license, you will have access to advanced cache directive via the online configuration.

If you do not have a multi cpu license then you will need to use the .htaccess file for Cache-Control. The instructions above for .htaccess work for Litespeed servers.

Patrick Sexton by