I have a carousel with about 20 images. When all images are loaded, they should be cached, and then loaded once again in an iframe. Browser shows that images are cached.
The issue is the same image URL in an iframe downloading them once again, not loading from the cache.
Is there any way to load these images from cache?
The browser's cache is not window-specific.
If your images are getting re-requested, it's because one of these things is true:
(Unlikely) The URL is different (even if your server ends up returning the same image), or
(Likely) The caching headers, etc., being sent back with the images are telling the browser not to cache them, or
The browser decided not to cache them even though it is allowed to for whatever reason (e.g., its caching heuristics said "don't cache these").
To fix it, ensure that your URLs to the images evaluate to the same full URL (they probably already do, but double-check), and that the server sends back sufficient caching information to allow the browser to cache the images.
Related
I have a component which lazy loads the images.For the first time when my page loads then at that time the images are displayed using lazy loading but if I refresh or reload or close and then open the tab then my images are pre loaded because it is now fetched from cache.Is there any way i can stop caching of my component in angular 7?
The cache is not being done by Angular but your browser. Once you load an image (and depending on the headers of the response) your browser will cache it to be able to load it faster the next time. This is usually a good approach.
Not sure why you don't want them to be cached but you have different options. Here you have a good read about HTTP caching: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching This cache configurations for static assets are usually done by your web server and they depend on which webserver you are using (nginx, Apache, IIS, node, ...).
Another option is to append a random query string to your image URL. This HTTP cache system works by using the image URL as a resource key to identify it. Because of this reason you can do something like:
<img src="./yourimagefolder/yourimage.jpg?r=putherearandomstring">
In this way your image resource 'Id' will be different in each request. (You will need to change the 'putherearandomstring' string in the example with a different random string each time the page is loaded.
If this is just for development purposes, you can disable the cache in developer tools. I don't see a reason you would want to do this for a live site though? As you would be forcing the user to grab the images everytime they load the component which will reduce performance.
The problem with cache in an environment where custom software is updated frequently and some users are less savvy is that they will not automatically get critical client-side changes unless they are told specifically to refresh their cache. With all of the decorations in the index.html I have not yet found a reliable solution.
Every time i refresh a site and view its page source, the javascript src i.e js.js?version=1364903356; the version number always changes.
My question is: What is the meaning of this number; and if i put js.js in every page, the site is not working.
The version is generally appended for caching purposes, or rather, for invalidating the cache (by changing the version number, and hence, the requested URL), so it's seen as a new resources and downloaded afresh.
The number is probably meaningless. It is almost certainly just being appended to the URL so that the URL changes so the JS won't be fetched from the cache.
it's just for to avoid Caching purposes and request new each time. whenever you visit a same content. if you set static content caching enabled in IIS, then Browser will issue HTTP 304 not modified status to the resource.
you can view in chrome. open developer tools (f12) then go for network tab. you will see in request header like this.
Request Method:GET
Status Code:304 Not Modified
IIS/Any web server wil determine whether the content is changed or the same content. if the content is the same as resides in the cache then it will not iniitate the new request.
by appendign the version number, filename/url/resource will be changed. so browser will issue a new GET request for the resources.
This is a common technique used to prevent or manage caching of javascript and other files that the browser would normally cache.
If the version number always changes, then it means that the page in question is preventing your browser from caching the file at all; every request will load a new copy of the file regardless of whether it's changed or not.
This is poor practice, and likely due to a misconfiguration of the site in question.
More commonly, the version number would remain static, but could be triggered to change by the site itself. This would mean that for most requests the browser's caching would be in play, but that the site owner has control over whether to refresh the cache, for example when he updates the script file.
Without this technique, a browser that has already cached the old version of the file might not know that the file has been updated, and may not fetch the updated version. This could result in version conflicts between script files on the page.
There are, in fact, more technically correct ways of doing this that don't involve adding random values to the end of your URLs. The HTTP standard specifies that the browser should query the URL, and tell the site what version it has cached. The site can then respond with a "Not changed" message, and the browser can use the cached version. This ought to mean that the technique used in the question isn't necessary.
However, the technique is necessary in some cases because some browsers and/or web server configurations may not work correctly with the standard method, and the browser may still end up using the cached version incorrectly.
This technique can therefore be seen as a work-around for that.
I'm writing an application that uses Dropbox as the source of image files which are loaded via javascript by assigning img.src = "[Dropbox download link]". This works fine, but I'm often fetching many files at a time, and when re-loading a set of images (say, on a page reload), the browser re-sends a request for each one (which returns 304 not modified). I'd like to have the browser cache the image on the initial load so I can simply avoid the re-requests altogether, but can't figure out how to enable browser caching of these images. Can I set cache headers in this situation? The response headers from Dropbox have "cache-control" set to "no-cache".
You might be able to use HTML5's application cache. But I'm pretty sure you wont be able to serve the manifest file from dropbox either.
Is there a way to tell the client-side user, through the browser, if certain images are loading from cache or if they are being loaded from the server?
You can through the browsers console. For Example inside chrome the network tab will tell you details about each resource, as for doing it in JavaScript I'm not sure you have that much control over images.
I have several different sites in different hosts and I use the same JS file in all of them which is loaded from one and only remote host. For instance,
One single JS filename my.js is stored at someotherhost.net.
This filename is loaded in several different pages (sites):
somedomain1.net/home.html
somedomain2.net/home.html
somedomain3.net/home.html
Browsing through these sites browser caches my.js. But will it use the same cache for all different sites?
Or maybe it doesn't matter whether the requested filename is named the same, stored in single remote host and loaded in different pages, browser will have different caches?
How browser caching works?
Yes. The browser will cache each unique url, provided there are no headers that tell it not to.
Your file should have one entry in the browser cache even if it is requested from a number of referring pages. Once cached from one site the browser will use the cached version for all the others so speeding up the page load.
This is the idea behind loading JavaScript libraries from a CDN (content delivery network). If you load jquery from http://ajax.googleapis.com/ajax/libs/jquery/1.5/jquery.min.js there's a good chance the user already has it in their browser cache so it will load instantly.