We can load a web page faster if we cache the images and scripts used on the website into the user's browser cache. It will only help in optimizing the website if it has been already visited and the cache is not empty, else it has no effect. The following screenshot shows which static files are required to have far future expiry dates that are cacheable:

By using the Expires headers, these components become cacheable, that is, these avoid unnecessary HTTP requests on subsequent page views. The Expires headers are most often associated with images, but they can and should be used on all page components including scripts, stylesheets, and Flash. We can do this in two ways. The first way is by using the Never Expires setting for all static components and setting the value to a far future date. If you are using a 32-bit system, better set the "expires date" till January 18, 2038, else it won't work on a 32-bit system without tweaking the code.

Add the Expires header by using the meta tag for static contents. Consider a site that requests the header with the following meta tag:

<META HTTP-EQUIV="Expires" CONTENT="Sat, 04 Dec 2021 21:29:02 GMT">

The response header would contain the Expires term like this:

Expires: Sat, 04 Dec 2021 21:29:02 GMT

Another way is by using Cache-Control metadata to assist the browser with the requests. For dynamic contents we use Cache-Control header definition like the following:

<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="PUBLIC">

Content can be any of the four values: public, private, no-cache, or no-store. Here is some information regarding these four values:

If you have Firebug enabled in your Firefox browser, you can see the Cache-Control header's value at the request and response header as defined in RFC 2616 (http://www.ietf.org/rfc/rfc2616.txt).

The following are the two cache-related header parts that you should know:

cache-request-directive = "no-cache"  | "no-store"  | "max-age" "=" delta-seconds  | "max-stale" [ "=" delta-seconds  ] | "min-fresh" "=" delta-seconds   | "no-transform"  | "only-if-cached" | cache-extension                     
cache-response-directive ="public"  | "private" [ "=" <"> 1#field-name <"> ] | "no-cache" [ "=" <"> 1#field-name <"> ] | "no-store"   | "no-transform"  | "must-revalidate"  | "proxy-revalidate" | "max-age" "=" delta-seconds  | "s-maxage" "=" delta-seconds     

So, when you open any website for the first time it would return status 200 and will take some time to load the page because it will download each bit of the page. It all depends on your browser settings and cookies handler options.

When you would visit the same site next time, the latency period would be much lesser and it would return the 304 status code for the scripts or files, as shown in the following screenshot:

When the status is 200, the response header would show how much data is downloaded for a particular request. In the following screenshot, it shows 21501 bytes under the Content-Length attribute:

If the status code is 304, you will observe no data has been downloaded, as shown in the following screenshot:

Moreover, check the Expires section in the previous screenshot to get an idea of caching here.

This Cache-Control header technique and the meta tag bearing Expires were introduced from HTTP/1.1 onward.

HTTP 1.1 (RFC 2068), available at http://www.w3.org/Protocols/rfc2068/rfc2068, specifies that all HTTP date/time stamps must be generated in Greenwich Mean Time (GMT) and the format should follow the rules defined in RFC 1123, that is, weekday "," date time "GMT".

So, an example of this would be, CONTENT="Sat, 04 Dec 2021 21:29:02 GMT".