I'm trying to understand why this resource is being cached even though there is no cache-control header returned in the response.
How is it possible that this resource is being cached?
This is addressed in Section 4.2.2 of RFC 7234:
Since origin servers do not always provide explicit expiration times,
a cache MAY assign a heuristic expiration time when an explicit time
is not specified, employing algorithms that use other header field
values (such as the Last-Modified time) to estimate a plausible
expiration time.
And, indeed, browsers do this.
Related
I am somewhat new to web development and have noticed an issue, Browsers seem to not respect the Cache-Control header, I have it set to no-cache, no-store, must-revalidate but yet many of my clients have a cache to begin with (which no-store should prevent according to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#no-store) and the cache is used rather than revalidating with the server leading to broken pages when I change a JS script referenced in a page, only after I tell them to refresh without cache does the browser then fetch the new file but for the browsers to be compliant with the HTTP protocol and spec, don't they need to respect the no-store policy or are none of the major browsers properly compliant with the HTTP protocol/spec and why haven't they been fixed so we don't need workaround solutions like query strings appended to files or using the file's hash or last modification date?
You initially served the resource without cache headers. In that case, the specification allows the client to choose the cache time itself:
Since origin servers do not always provide explicit expiration times,
a cache MAY assign a heuristic expiration time when an explicit time
is not specified, employing algorithms that use other header field
values (such as the Last-Modified time) to estimate a plausible
expiration time.
Different browsers will use different algorithms, but in any case it probably won't be very long. Your problem might have already resolved itself.
As for query strings, I think your confusion comes from conflating at least three distinct issues. One is the HTTP protocol mechanism for communicating cache policies. That is covered in RFC 7234 and mainly involves the proper use of the Cache-Control response header.
A separate issue is what cache strategy to use. That is, which resources should be cached and for how long? There are different ways to approach this, my suggestion would be to follow the best practices discussed here.
Finally, there's how to fix your mistake if you communicated the wrong cache policy and now need an already-cached resource to be ignored or invalidated. In that case, if possible, you could just use a different resource (i.e. change the name). Adding query strings is sometimes suggested here, but it's not a great solution since the standard does not forbid clients from caching resources with query strings.
Getting back to your question, you can temporarily fix your mistake (missing Cache-Control headers) by changing the name of the linked resource, or just by waiting a short time for the heuristic expiration time to pass. Longer term, you should decide how you want your different resources to be cached, and then use Cache-Control to communicate that intent to the browser.
Hello all please help with the analysis of my page.
Question 1
Why since everything is load from cache. Load time is 690ms?
question 2
what will be the reason to use --> private, max-age=60000
(public), max-age=60000 VS. private, max-age=60000
https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching?hl=en
First, load time isn't just defined by the time it takes to get assets from the network. Painting and parsing can take a lot of time, as can the parsing of Javascript. In your case, DOMContentLoaded is only fired after 491 milliseconds, so that's already part of the answer.
As to your second question, the answer really is in the link you provided:
If the response is marked as “public” then it can be cached, even if it has HTTP authentication associated with it, and even when the response status code isn’t normally cacheable. Most of the time, “public” isn’t necessary, because explicit caching information (like “max-age”) indicates that the response is cacheable anyway.
By contrast, “private” responses can be cached by the browser but are typically intended for a single user and hence are not allowed to be cached by any intermediate cache - e.g. an HTML page with private user information can be cached by that user’s browser, but not by a CDN.
I have updated my website with some new content.
I talked to some people to view the content on their computers,
but it seems like they cant's see the content unless they delete their browser cache. Is there a way to handle this by my side, so all new things show up automatically on every browser?
There is no way to accomplish this without cleaning the cache.
Although, you can delete cache easily by pressing CTRL+SHIFT+R (atleast on firefox).
You cannot remote-wipe someone's cache. This time your only options are to wait, or tell your users to clear their cache, or instruct them to vigorously press refresh a few times, which will cause most browsers to refresh the page.
For future reference, there are two types of caching: expiration based caches and ETag caches.
If you set an explicit expiration date on your HTTP response, the client will not check back at all until that expiration date has passed. This greatly reduces network traffic, at the tradeoff of possibly having outdated content out there. Choose your expiration dates wisely for the best tradeoff.
The alternative is ETags, in which case the server sends an ETag token, and the client will inquire with "send me new content unless this token is still valid". This only reduces network traffic somewhat, but you're guaranteed to always have the latest content out there.
You need to balance your caching strategy in practice. First decide if you need caching at all, then decide how much you need and what tradeoff you're willing to make. For a high-traffic site even a cache of a few minutes can be worthwhile, while the issue of outdated content will be minuscule in this scenario.
You cannot erase a remove user's browser cache from Server/Client-side code.
Going forward, best you could do is tell the browsers not to cache at all in future, or to cache for a specified time (less than next expected update)
Cache-Control : no-cache
Cache-Control : max-age=315600
ETag sounds like it could serve the purpose (though I've never used).
The server generates and returns an arbitrary token which is typically
a hash or some other fingerprint of the contents of the file. The
client does not need to know how the fingerprint is generated, it only
needs to send it to the server on the next request: if the fingerprint
is still the same then the resource has not changed and we can skip
the download.
I want to set cache expiration for my html page after may be 10days
<META HTTP-EQUIV="expires" CONTENT="Thu, 12 Apr 2012 08:21:57 GMT">
So my question is
What happens after 10days? yes the cache will get expire but do I have to set the expiration date again ?
I there a way to set the day length in number for eg: 10
Am confused here please give me some reference.
Please help...
The tag has limited effect. In particular, it does not affect proxies, since they work on HTTP headers and do not parse HTML documents.
After the expiry time, browsers are expected to treat the copy of the page in their caches as stale and not use it but request for the page from the server (if online), at least conditionally (send if modified since such-and-such). This means that after any new request for the page, the copy received should not be cached at all. So yes, you should set a new expiry date, unless you really want to prevent caching.
The Expires header or its meta simulation needs to have a specific time mentioned. There are other ways to affect caches, see http://www.mnot.net/cache_docs/
You need to use some kind of server-side scripting language (like PHP or ASP or JSP) to set that date dynamically. This is only a 'hint' and browsers may or may not even listen to it.
That is a hint telling browsers that they should keep the HTML in cache until the specified date. That means that, if the browser complies, then whenever it sees the same URL, it will not make a request to retrieve it, but rather it would take the HTML from its cache and show that instead.
Therefore you can safely generate a new time for each request, since the browser that's caching the page won't make the request anyway, and the browsers making the new requests will get an updated hint.
Note though that no one's forcing the browsers to comply, they may simply ignore the hint and make the request anyway.
I'ld like to present always the latest website content to the user but also have it fast loaded. By researching I came across postings people suggesting to use the cache for speeding up loading.
So what do I need to add to my website to "overwrite" the cache after 3 days to display the latest content?
The Cache-Control header is used in HTTP 1.1 to control the behavior of caches. The max-age directive is used to specify (in seconds) the maximum age of the content before it becomes stale (i.e., the content will not change for some period of time). So if you know that your content will not change for 3 days, you want your server to add the following HTTP header:
Cache-Control: max-age=259200
(259200 = 60s x 60m x 24h x 3d)
To do that in PHP, add this line to your output:
header('Cache-Control: max-age=259200');
Read here for more info on the header function:
http://php.net/manual/en/function.header.php
There is more than one way to do this - but you need to consider exactly what you need to cache and what you don't. The biggest speed increases will likely come from making sure your assets (css, images, javascript) are cached, rather than the html itself. You then need to look at various factors (how often do these assets change, how will you force a user to download a new version of the file of you do change it?).
Often as part of a sites release process, new files (updated files) are given a new filename to force the users browser to redownload the file, but this is only one approach.
You should take a look at apache mod_expire, and the ability to set expiry times for assets using the .htaccess file.
http://www.google.com/?q=apache+cache+control+htaccess#q=apache+cache+control+htaccess
As mentioned Expires and Cache-Control Headers are usually the best way to incorporate information about information lifetime.
Because clients are not very reliable on interpreting these informations proxies with caching capabilities like squid, varnish or such solutions are preferred by most people. You also need to consider if you want to cache only static content (like images, stylesheets, ..) or dynamically generated content as well.
As per the YSlow recommendations you could configure your web server to add an Expires or a Cache-Control HTTP header to the response which will result in user agents caching the response for the specified duration.