My website displays traffic cams amongst other resources. They change every minute. I have to use the &nonce= to override the caching in order to get an update every minute. However, ALL of those get cached and the storage profile (specifically image caching) gets into gigabytes quickly.
As the traffic cam resources are out of my control (and they don't specify no-cache, but they DO prevent CORS), I see these options to prevent caching of images (but keep for other resources).
Specify (what?) in the request so that it's not cached.
Using xhr to specify no-cache and createObjectURL would fail b/c of CORS. And, can't bypass CORS b/c it's a PWA, not meant to have a local proxy server.
Override the response (headers!) with some middleware? (which?)
Clear only images in the cache every minute. (how?).
A better option I'm missing?
(Using straight js, no jquery).
Related
CORS node on CDN. We already allow CORS on the CDN, so the issue has nothing to do with the server.
It is blocked from the browser cache before being pushed to the remote server. When we open a page, the first time the images are stored in the browser cache. Then we open the image in preview mode and click download, now the browser is too "smart" to detect this image is already in the cache and get it straight from the cache.
Can someone explain why the cache is blocked even though the server has CORS enabled.?
Caching a complex topic, I suggest looking at proper documentation.
Documentation
HTTP caching
The performance of web sites and applications can be significantly improved by reusing previously fetched resources. Web caches reduce latency and network traffic and thus lessen the time needed to display resource representations. HTTP caching makes Web sites more responsive.
Types of caches
Caching is a technique that stores a copy of a given resource and serves it back when requested. When a web cache has a requested resource in its store, it intercepts the request and returns a copy of the stored resource instead of redownloading the resource from the originating server. This achieves several goals: it eases the load of the server because it doesn’t need to serve all clients itself, and it improves performance by being closer to the client. In other words, it takes less time to transmit the resource back. For a web site, web caching is a major component in achieving high performance. However, the cache functionality must be configured properly, as not all resources stay identical forever: it's important to cache a resource only until it changes, not longer.
I am trying to improve performance of few web pages and wanted to understand if the javascript files are cached by I.E or not for my internal application. So, I had fiddler to watch the requests going to server.
I can see, every single time a create customer page is loaded, the same number of requests in the fiddler, for the same files with Result '200' (and not 304 - not modified ) to fetch javascript files. These include jquery, knockout and a few custom ones.
I studied the request and response header (below) but I see cache-control to be ok and nothing that conveys it is not cached. But don't understand why these same http requests show up in fiddler (which conveys a request is actually made to server) if it is cached.
I can see the same requests every time going to server, which makes me wonder :
Is the browser caching these or not ?
If not, are these atleast cached in IIS ?
How can I avoid these unnecessary http requests, since these javascript files dont change at all ?
Many Thanks.
Your request for the file has a Pragma: no-cache header (up at the top of your image, two lines under "Request Headers"), which tells the browser and the server that you don't want to use the cached copy.
You'll want to look at how you're making that request to find out why that header is there, and get rid of it.
Possibilities:
You're loading it via some kind of AMD or other dynamic loading mechanism that is configured to not use cache
You're running with development tools with the "disable cache" option most of them have turned on
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.
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.
Read more about HTTP caching:
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en#validating-cached-responses-with-etags
http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/
Meanwhile, note that the use of the Application Cache is mainly applicable if you wish to provide your users with offline content.
In my opinion you would reinvent the wheel. Instead of trying to create a second cache on top of a browser's built-in cache, you should take advantage of a proxy like CloudFlare to handle caching of static assets for you.
As for the issue of cached files not updating, a common technique to force resources to be re-requested is to add a query string parameter containing the file's last modification time (e.g. /js/script.js?1441538979), which normally forces the browser to re-download the file.
Is there any way to browser caching for some css and javascript files only through htaccess file?
I have three css files
http://www.example.com/css/main.css
http://www.example.com/css/star_rating.css
http://www.example.com/js/jquery.autocomplete.css
"main.css" may be chaged day by day. I want caching for star_rating.css and jquery.autocomplete.css only, not for main.css. How can I achieve this?
Also is there any way to caching google adsense javascript file.
https://www.gstatic.com/swiffy/v7.1/runtime.js
http://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js
https://pagead2.googlesyndication.com/pagead/osd.js
Set a cache-control header in your HTTP Response, in .htaccess, already answered here: How can i add cache control code to htaccess?
You will need a subsequent rule to reduce the cache interval of main.css, to whatever you need. However, before you go ahead with that...
Personally, I wouldn't bother with such sophisticated granularity, just set your cache time so the resources are only requested once for a typical browsing session (24 hours?). Although some browser caches can be rather large, there's no guarantee a busy user is going to still have your resources cached the next time they visit your site, if they fill their cache, the less frequent/stale items will be removed.
For long-term caching strategies I would just check that ETag support is working on your servers. If a browser already has one of your items cached, it will request with an "If Not Modified" header and provide the ETag it holds for your resource.
If the resource has not been modified (if the ETag values match), your server will respond with a 304 (Not Modified) instead of a 200, a good saving for large resources.
You cannot influence the response headers if hot-linking to the Google AdSense JavaScript files and not hosting them yourself, but they should have sensible cache-control headers (set by Google) anyway I would expect.
We're developing an app with AngularJS and RESTful services. The data returned by services is changed infrequently and I very much would like to cache responses for a period of time. I'm setting Cache-Control: no-transform, max-age=604800 in the response.
Is there a way to have AngularJS JSON requests ($http/$resource) respect browser cache instead of using completely parallel built-in AngularJS cache (http://www.metaltoad.com/blog/angularjs-vs-browser-http-cache) or angular-cache library (http://angular-data.pseudobry.com/documentation/api/angular-cache)? From what I can see watching the network, by default $http requests are ignoring Cache-Control headers.
The browser will respect the cache time set by the response for that particular asset. Any subsequent GET should look to the cache until the timeout is reached.
Its possible you have devtools ignoring this.
Where I was stumbling was page reloads and the way they behave differently.
Let's divide use cases into two:
1. Page hit: simply going to a previously visited page.
Here I see what you see: most of the content is retrieved from cache. Chrome shows it better than Firefox/Firebug. Firebug simply does not show cache hits in the Network panel.
2. Regular page reloads.
Pretty much all browsers have two shortcuts to refresh a page: regular reloads (Ctrl+R in Chrome/Windows) and
reloads ignoring cache (Shift+F5 in Chrome/Windows). I'm talking about regular reloads since if cache is ignored, there is nothing to discuss.
What seems to be happening is that browser issues If-Modified-Since requests for all resources on the page. The server then responds with 304 Not Modified for static resources and browser gets them from cache.
The issue is that we were not handling If-Modified-Since in our services. We simply were setting Cache-Control with the expiration age.
The server code update that started to handle If-Modified-Since resolved the issue.
BTW, here is a background article on browser caching that I found quite useful: https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers