Javascript force file caching

Question

My website has 200k Active users daily

I read an article not to long ago about forcing javascript and PHP to cache files. I have never needed to have my files cached before, but now that i am dealing with a massive amount of data being transferred to and from the server i would like to store some of this data locally on the client side.

I don't know if there are any better ways on doing this but essentially, i am considering writing a library using

HTML5 local storage if its available / manifest
with a fallback of java if its available
with a fallback of silverlight if its available.

I am very interested in pursuing this, preferably in JavaScript.

I would like to know how to cache files using JavaScript

Before anyone thinks i am re-inventing the wheel

(example) I have several Javascript files which if updated, the browser will not reload the script because it is cached. With version control, i can manage when a user needs to reload cached data.

Sometimes. but i would like to cache more than just JavaScript. — THE AMAZING, Aug 21 '15 at 18:20
Caching has to be done on the server. You should cache requests from JavaScript not file. — code_wrangler, Aug 21 '15 at 18:25
It can be both actually. The client can cache files, the server can cache responses to requests — Maria Ines Parnisari, Aug 21 '15 at 18:28
@l19 true, but i am only looking to cache files, i havent considered caching responses which i might look into that later now that you have enlightened me — THE AMAZING, Aug 21 '15 at 18:29
Have a look at the AppCache API: http://www.html5rocks.com/en/tutorials/appcache/beginner/ — Maria Ines Parnisari, Aug 21 '15 at 18:30
Another thing to consider if your site is getting heavy traffic and serving a lot of the same resources multiple times is using a CDN. I am familiar with AWS Cloudfront but there are a lot of options out there. A CDN is really helpful for taking load off of your servers while improving user load times at the same time. — jaredkwright, Sep 04 '15 at 20:16
@jaredkwright my content data network is powered by AWS. The issue here is not about content routing; more or less, its about preventing repetitive & sometimes consecutive request for data to the server(s). — THE AMAZING, Sep 05 '15 at 01:15

score 4 · Accepted Answer · answered Sep 06 '15 at 12:46

See caching in HTTP. Basically, for every request you should specify the cache-control header field in the response, indicating when a fresh content will be available. The formal definition of the cache-control header field is as follows:

The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain. The directives specify behavior intended to prevent caches from adversely interfering with the request or response. These directives typically override the default caching algorithms. Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.

The field is usually specified along the lines of

cache-control: private|public, max-age=[, no-cache].

public

Indicates that the response MAY be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non- shared cache. (See also Authorization, section 14.8, for additional details.)

private

Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache MAY cache the response. Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content.

no-cache

If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests. If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.

For example, cache-control: private, max-age=86400, no-cache directs the client to cache a response and reuse it until 86400 seconds (24 hours) have elapsed. However, things may change before that time elapses. no-cache directive causes a revalidation each time. It is like the browser asking each time may I really present your user with the cached content? Together with the ETag header, you will be able to push important changes to your user before previously cached content expires.

During revalidation, an Etag present in a response is compared with the one provided previously in a request for same resource. If they are same, it reassures that the resource has not changed, thus, cache is really valid. Else if they differ, then the resource content has changed, and the new content will be given as response to the user.

Javascript force file caching

2 Answers2