1) I'm confused about the purpose of setting header expiry dates
for caching css and js files (like how it's done in the
Boilerplate .htaccess file).
I thought web browsers automatically cache css and js files.
What's the point of setting header expiry dates?
2) Is there a way to NOT use versioning of css and js files and
still have them automatically update when I upload them to a server.
I tried setting a lower expiry date ("access plus 1 week" and "access
plus 0 seconds") and the browser was still displaying the old cached copy
when I uploaded updated css and js files. I'm not 100% sure I did this
correctly, though.
Thanks :)
1) Some browsers don't cache things that do not have an expiration date.
2) Try appending a get variable to the end of your URL string to new versions of your website to ignore previous versions cache. The idea is to transform your urlstring into something like www.example.com/?v=1 and then when you change that to www.example.com/?v=2 the browser does not recognize this url so it doesn't use any cached files. When a user goes back to www.example.com/?v=2 it will access the cached files for v2 of your website
Related
I have custom build JS library (which is swiper.js). Can I check if the browser has its CDN version in the cache before downloading it? Normally it's 130KB but my desired version (contain few fewer functions) is just 70KB so I don't want to add those extra KBs to get it from CDN if the user has not already cached it. Is this possible?
Just for clarity, you decide via your markup(html) as to what file the browser should download. So in the case of checking if there's a previous version of a file that you want to refresh, you can simply add a parameter at the end of the file to make the URL unique such that the browser doesn't use one that's prevously downloaded.
Here's an example link:
swipser.js?version=<version or date saved>
So each time a browser see this, it will not download unless the parameter has changed, or perhaps the user has cleared their cache
I'm deploying a whole new website redesign onto an existing domain. I will be manually replacing all files with the new files at 12:00AM, but how do I ensure users don't get a cached version of the old website (thereby breaking everything)?
Also, how do I change the sitemap so that the old one on google gets replaced?
There are several ways to bust a cache.
The easiest way is to add an expiration header to files of that type. This can be done in an Apache configuration like so:
<FilesMatch "\.(gif|jpg|js|css)$">
ExpiresActive On
ExpiresDefault "access plus 10 years"
</FilesMatch>
You could also use a new query string value in the URL for each resource.
Another option is an updated version number within the filename that is routed to the update file.
You'll need to wait for Google's web crawler to index the changes. It's not something you'll have control over.
There are couple of ways , you can either use tools like webpack or plugins from gulp , grunt which will add a hash to the generated file name ,
So file name will be like this
someabc.RandomAlphanumeric.js
where RandomAlphanumeric randomly generated hash
If you are not using any build tool you can nema the file like
<script type="text/javascript" src="/folder/js/someFile.js?v1"></script>
Note the use of ? .Usually a time stamp is attached with the file name
If you are redeploying an entire site I doubt you want to add ?v1 to every file. And since your files are already cached I don't think that would be very effective anyway. I would look at the server level for an option. Most hosts have an option to disable or refresh your cache. That is your best bet!
I have developed some websites using custom PHP and YII2. Whenever I have modified any JS or CSS file, it doesn't give any effect on my web pages. To apply the newest version of my code, I have to press ctrl+f5 to refresh it.
I have already gone through the several answers, but no effect.
I have checked the below links:
Force browser to refresh css, javascript, etc
How can I force clients to refresh JavaScript files?
Please help me to solve this.
You can achieve this by setting AssetManager::$appendTimestamp to true. In your web config:
'assetManager' => [
'appendTimestamp' => true,
]
Whether to append a timestamp to the URL of every published asset. When this is true, the URL of a published asset may look like /path/to/asset?v=timestamp, where timestamp is the last modification time of the published asset file. You normally would want to set this property to true when you have enabled HTTP caching for assets, because it allows you to bust caching when the assets are updated.
I have an old version of a JS file cached on users' browsers, with expiration set to 10 years (since then, I have learned how to set expires headers correctly on my web server). I have made updates to the JS file, and I want my users to benefit from them.
Is there any way my web server can force users' browsers to clear the cache for this one file, short of serving a differently named JS file?
In the future, if expires headers are not set correctly (paranoia), can my JS file automatically expire itself and force a reload after, say, a day has passed since it was cached?
EDIT: Ideally I want to solve this problem without changing HTML markup on the page that hosts the script.
In short... no.
You can add something to the end of the source address of the script tag. Browsers will treat this as a different file to the one they have currently cached.
<script src="/js/something.js?version=2"></script>
Not sure about your other options.
In HTML5 you can use Application Cache, that way you can control when the cache should expire
You need to add the path to the manifest
<!DOCTYPE HTML><html manifest="demo.appcache">
In your demo.appcache file you can just place each file that you want to cache
CACHE MANIFEST
# 2013-01-01 v1.0.0
/myjsfile.js
When you want the browser to download a new file you can update the manifest
CACHE MANIFEST
# 2013-02-01 v1.0.1
/myjsfile.js
Just be sure to modify the cache manifest with the publish date or the version (or something else) that way when the browser sees that the manifest has change it will download all files in it.
If the manifest is not change, the browser will not update the local file, even if that file was modify on the server.
For further information please take a look at HTML5 Application Cache
You could add a dummy parameter to your URLs
<script src='oldscriptname.js?foo=bar'></script>
[e: f; b]
The main problem is that if you set up the expiration with a simple "Expires" header, then the browsers that have the file cached won't even bother to contact you for it. Even if there were a way for the script to whack the browser in the head and clear the cache, your old script doesn't do that, so you have no way to get that functionality out to the clients.
You can force to reload an cacheated document with on javascript:
window.location.reload(true);
The true command indicate the browser must to reload the page without cache.
I've been learning JavaScript recently, and I've seen a number of examples (Facebook.com, the Readability bookmarklet) that use Math.rand() for appending to links.
What problem does this solve? An example parameter from the Readability bookmarklet:
_readability_script.src='http://lab.arc90.com/....script.js?x='+(Math.random());
Are there collisions or something in JavaScript that this is sorting out?
As Rubens says, it's typically a trick employed to prevent caching. Browsers typically cache JavaScript and CSS very aggressively, which can save you bandwidth, but can also cause deployment problems when changing your scripts.
The idea is that browsers will consider the resource located at http://www.example.com/something.js?foo different from http://www.example.com/something.js?bar, and so won't use their local cache to retrieve the resource.
Probably a more common pattern is to append an incrementing value which can be altered whenever the resource needs to change. In this way, you benefit by having repeat requests served by the client-side cache, but when deploying a new version, you can force the browser to fetch the new version.
Personally, I like to append the last-modified time of the file as as a Unix timestamp, so I don't have to go hunting around and bumping version numbers whenever I change the file.
Main point is to avoid browser caching those resources.
This will ensure that the script is unique and will not cached as a static resource since the querystring changes each time.
This is because Internet Explorer likes to cache everything, including requests issued via JavaScript code.
Another way to do this, without random numbers in the URL, is to add Cache-Control headers to the directories with the items you don't want cached:
# .htaccess
Header set Cache-Control "no-cache"
Header set Pragma "no-cache"
Most browsers respect Cache-Control but IE (including 7, haven't tested 8) only acknowledge the Pragma header.
Depending on how the browser chooses to interpret the caching hints of a resource you might not get the desired effect if you just asked the browser to change the url to a url it has previously used. (most mouse-over image buttons rely on the fact that the browser will reuse the cached resource for speed)
When you want to make sure that the browser gets a fresh copy of the resource (like a dynamic stock ticker image or the like) you force the browser to always think the content is newby appending either the date/time or a every-incresing number or random gargabe).
There is a tool called squid that can cache web pages. Using a random number will guarantee that request will not be ached by an intermediate like this. Even with Header set Cache-Control "no-cache" you may still need to add a random number to get through something like "squid".