When "Expires" and "Cache-Control" headers are not specified, but a "Last-Modified" header is specified, browsers have to guess at how long they should keep the document in cache. Some browsers do use algorithms that let the page remain in cache for a day or more.
Google caching best practices guide states:
Last-Modified is a "weak" caching header in ...
If there is no Cache-Control header and no Expires header, but there is a Last-Modified header (which most web servers send by default for static assets), most browsers will use heuristic freshness to determine how long to cache that asset for.
The typical calculation for this (which is the one suggested by RFC 7234) is:
(current time - last modified time) / ...
You have two approaches to this problem.
The clean way is to set the headers returned for GET data.txt preventing the browser (or proxy) from storing the response in cache.
Using apache, this can usually be done by adding a few lines in a .htaccess file.
If this data.txt is a static file, this is the only way you could control the headers.
It might be as simple as missing one keyword that is causing your issue.
## EXPIRES CACHING ##
ExpiresByType image/jpg "access plus 1 day"
ExpiresByType image/jpeg "access plus 1 day"
ExpiresByType image/gif "access plus 1 day"
ExpiresByType image/png "access plus 1 day"
ExpiresByType text/css "access plus 1 ...
24 hours is too little to suffice as cache control :) In theory, images never change without their name also changing, so you can set that easily to a year (or a month if you feel more comfortable with that).
If you replace an image with a new image, it has a new name. picture-of-cat-on-18th-birthday.jpg will not suddenly be an other image with the same ...
no-cache is not as strong as no-store. Chrome's documentation indicates that no-cache indicates a re-usable document, while no-store indicates that it should not be re-used.
Based on this information, your Cache-Control header should simply be:
The extra values in it may be letting Chrome pick and choose which it would like to ...
I see that the previous answer says that 24 hours is not enough. But looking into Google document: https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching#defining-optimal-cache-control-policy it says that the images be cached for 1 day for optimal caching.
Caching images for short time makes sense, because in ...
It is not a good idea to let Googlebot crawl URLs that can be constructed with combinations of parameters. When you allow your categories to be filtered, my advice is to only allow Googlebot to crawl pages with a single filter applied, even if you allow users to view multiple filters at the same time.
To implement this, you need to change your URLs:
I understand you want to use Cache-Control private/no-store because you don't want the CDN to cache an outdated version of those files. However, not caching these files (i.e. all requests go back to your origin) might make your server vulnerable to a DDOS attack.
Leverage the CDN for what it does best. Unless these files change several times in the hour, I ...
What is it?
The Vary HTTP response header tells user agents (clients) that the server's response can vary if the client changes any of the mentioned request headers.
This means that if the browser sends a different value in the Accept-Encoding request header, the server might send a different response.
(It should be noted that the ...
No. The browser will send the same information on a refresh as if the user had just come to that page, with the same referrer information. Hence the problem of double-POSTing if someone refreshes the destination page for a form.
What you could do is have a refresh button on the page (as Google Ads used to have before they removed it), which you could use to ...
Browsers do send additional headers, but behavior different. This info in link a bit outdated: stackoverflow question
Looks like Cache-control:no-cache is the best solution, to check for Ctrl+F5, but better to check not the only one header.
Just checked on Firefox Ubuntu, F5 gives nothing, but Ctrl+F5 request contain this
There is no ideal length. It all depends on how often this content changes for you (and the files usually cached should not change often). I'm not in front my the code for my personal website but that content rarely changes so I have it set to be a week or two IIRC. If your content changes on a daily basis then a 24 hour expiration seems appropriate.
That's not correct.
If you would like to extend CloudFlare's CDN to cache more than static content by default, you can use Page Rules to extend the caching capabilities to cache more content. Page Rules can be accessed by going to the settings for the domain that you want to create a Page Rule for.
If you want to cache everything on, say, https://www....
The expires header is related to the page, not fragments of it.
Lets go over the basics.
You send HTML to the browser, all of it or a stream, doesn't matter for the example.
The browser receives it and starts parsing it. At the same time, once it starts parsing, all the other linked files are called, like images, css, js, etc. Some parallel connections ...
FilesMatch takes a filename and matches against the file system, not the URL. The underlying file is still called "myscript.js", so this pattern should be something like: \.(js|css)$
(Aside... your example request appears to be for common.js - which wouldn't have matched your pattern anyway - shouldn't this be ...
is expired past it's cache control header time, how long do browsers
keep the content around to make use of 304 responses?
While browsers may keep the content stored on disk in a temporary or cache directory beyond the expiry date/time, the browser will consider it out-of-date (not 'fresh'...
When new content is launched, it may not be absolutely critical that users see it right away. In that case you could relax your cache controls and allow your content to be cached for an hour or two and not require that the user re-validates. Actually with "must-revalidate", I don't see any point in not allowing your pages to be cached forever.
Turning off browser caching can be important for:
Security (so that pages can't be found in browser cache)
Accurate site stats (so that you can count each visit to a page)
I've worked with big sites that get lots of search engine referrals and don't allow page caching. It is very possible to have great rankings even without allowing browser caching.
The right way would be to change the Apache configuration (via htaccess or conf file) with the expire headers with very low caching time. Double check if you have access to .htaccess file if not Apache conf file.
However, if you absolutely can't alter .htaccess or Apache conf, there may be a trick to achieve it. Most developers use this trick to renew the ...
The Expires header is the simplest. If you're using Apache you can set this by mime type using mod_expires. In your .htaccess:
ExpiresByType text/css "access plus 1 day"
ExpiresByType image/png "access plus 1 day"
By "type" I assume you mean mime-type, in which case you should look at mod_expires and the ExpiresByType directive - this is undoubtedly the easiest/modern way to set the appropriate Expires and Cache-Control (max-age directive) HTTP response headers.
It goes something like:
Nothing you do on your end can really affect the crawl rate Google uses. You have the ability to slow down crawls through webmaster tools but there is no way to speed it up through webmaster tools or through your site. Your headers look fine and appear to be much the same as many sites out there. If Google has slowed down after having a long time of frequent ...
You seem to be asking two different questions here.
The best way to handle caching of static assets is to set the max-age/expires date far in the future, but have the URL to the asset automatically change whenever the asset itself is updated. That way you're taking full advantage of the browser cache, but the browser will always grab a fresh copy when you ...
I agree with Stephen that "cache busting" is the way to go.
Is there anything else that could be done server side such as setting a new apache rule
You can use the apache rewrite module (make sure mod_rewrite is installed) to map a URL name starting with something common and map it to an actual file.
For example, you can use a rule like this in your ....
Have you looked at limiting Google's bot threshold?
If Google is making too many requests per second to your site and
slowing down your server, you can limit how fast Google crawls your
The one caveat is you cannot limit to a specific folder/directory. Per Google:
You cannot change the crawl rate for sites that are not at the ...
You cannot change the headers for requests you're not responding to. In this case, the browser will make a request to Google asking for fonts. The browser will receive a response from Google(not you) with headers(cache, encoding, etc) and body(actual resource).
Don't forget these tools point you in the right direction but are not always aware of the whole ...