If I've loaded an image into an html page, when I load it a second time further down in that page will it be instantly available?
Depends on the headers sent with the image, but I believe most browsers will cache images automatically. That should work fine as long as the URL is the same. Check the network request to make sure the image is only being requested once from the server.
Related
Imagine an image with url https://example.com/image.jpg is accessed from page https://example.com/ . If another web page say, http://another.com/page shows https://example.com/image.jpg on the page, will the image cached by the browser be shown or new image will be requested from the server.
The image will be cached by the browser, unless you specify otherwise in your browser's settings or the page serving the image specifies otherwise in its response headers. In fact, this is the main point of caching: to improve load times by avoiding repetitive requests to the same URL.
Chrome keeps loading an image from cache, even when I have the dev tools open, and have disabled cache.
Why does Chrome do this?
How to make it stop?
The image you're loading is a base64 encoded inline image. That means it's no loaded via a separate HTTP request, but instead is embedded inside your HTML, CSS or JavaScript code.
The URL could look like this for example: data:image/png;base64,iVBORw0KG....
Chrome is treating it as a request to a data: url, but since no server roundtrip is required to look it up Chrome shows it as "(from cache)". (This isn't quite accurate but does make some sense.)
I'm having some problems with the resources I try to load on my web application, using img or video HTML tags.
I use angular for my app and dynamically set the src param of the img tags, using the ng-src="{{ src }}" directive.
There are not that many images and resources to load (on the model I'm currently testing, it loads about 30 images or videos), but it seems like the browsers (tested on Chrome and Firefox on Windows and OSX) don't handle correctly that many parallel requests, and the requests appear as "pending" on Chrome, and does not show any status on Firefox.
At the moment I took these screenshots, they were no other requests running. I have this problem all the time, but the number of correct requests and pending requests change almost every time I refresh the page.
The resources URIs are of course correct, and I can open pictures in another tab with no problem.
If it can be of any relevance, even though it doesn't seem like the request is even sent from the browser, the resources are loaded from an Azure blob storage, and CORS options are correctly set.
The problem happens both when I test my app locally (with localhost as hostname) and when it is hosted on a web server.
Have you any idea on why this problem is happening and how I can fix it?
Thanks !
I finally found what caused the problem!
I had several videos loading with a video tag with the preload="metadata" attribute. It caused many connections to start, and it seems that even when the preload finished, it prevented the requests for the other resources to be sent. I think it is a browser bug, it should not be the desired behavior.
With preload="none" on the video tags, I don't have any problem like that.
Various flavors of this have been asked already, but I've yet to see a real answer for this.
We have a separate image service that our web app uses to get some of its images. The image service is well tested and is functioning properly. To make it concrete, our app is served from domain.com. The src element of img elements is images.domain.com/{imageId}. The image service retrieves the URL for the image and sends back a HTTP 302 redirect for the image.
The application allows users to change images. So say a user 5 has image A as a profile image, and decides to change it by uploading image B. When the user uploads the image, the application cache is properly invalidated and the database is updated. The application does a standard redirect after POST and one of the elements in the page that the user is redirected to after changing her image is something like:
<img src="example.domain.com/5">
The problem is that Chrome never makes the call to example.domain.com/5 to retrieve the image upon the initial redirect or a regular reload of the page, it simply serves image A from the browser cache. A standalone call to example.domain.com/5 correctly returns image B, and a hard refresh or clearing Chrome's cache forces Chrome to request the image's src, which correctly returns image B. Note that I'm not talking about serving either image from the cache after getting a 304 Not Modified response, I'm talking about Chrome deciding not to visit the img src at all and just returning image A. Also, appending some unique query string to the img's src attribute fixes the problem, but that's a hack that we'd rather not have to do.
It's worth noting that Firefox was doing the same thing initially. There were no Cache Control headers in the response initially. We added a Cache Control: no-cache header (and tried no-store as well) to the response header and this fixed the behavior in Firefox, but Chrome and Safari still serve the outdated, cached image without making a call to the image's src.
It looks like this was a longstanding bug in Chromium (https://code.google.com/p/chromium/issues/detail?id=103458) that's allegedly fixed as of about 6 weeks ago, but we're using the most updated version of Chrome.
We've looked at the answers here and here but they don't actually answer the question.
Per section 14.9.1 of RFC 2616:
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.
Unless we're missing something or doing something wrong, it would seem that Chrome (and Safari) are not complying the RFC behavior for no-cache headers for 302 redirects? Anyone experience this before or have any insight?
cache-control: no-store
I had the same maddening problem that you described (slightly different in that it was a missing cookie redirect back to the login page) that worked everywhere but Safari.
In desperation, I came across this open WebKit bug and saw the fateful comment (and finally a glimmer of hope):
CachedRawResource now keeps the redirect chain, and has some trivial logic for checking correctness, but it's nowhere near complete (only checks cacheControlContainsNoStore()). And of course other resource types don't have anything.
Added no-store to my cache-control header and no more problem.
Please read this.. https://www.hochmanconsultants.com/articles/301-versus-302.shtml
Chrome has pretty aggressive caching.
When you use a temporary redirect, you are basically saying that the actual URL is temporarily unavailable so use this other URL instead. Chrome rightly caches the old URL because it is still valid. Try a 301 instead. Then Chrome should know that the original URL is no longer valid.
The files listed in the .mf file are the same files i am trying to load when the page first runs. Does having a manifest attribute defer processing of the rest of the document until the appcache loads?
No. On the very first load the cache gets built in the background, using the same files that where just downloaded, provided they have proper cache settings. E.g. If you have foo.css with long cache headers in your HTML page and the manifest, the browser will:
Load and render the page.
Look at the manifest.
Load foo.css from browser cache to appcache.
BUT: Appcache will however result in a FOUC (brief white page on reload), even if online and the page/app was made well enough so far to show smooth reloads.
With AppCache, the browser loads the document and its associated resources directly from the cache, without accessing the network, so this should load just as fast if not faster.