I have been looking at a HTML 5 boilerplate template (from http://html5boilerplate.com/) and noticed the use of "?v=1" in URLs when referring to CSS and JavaScript files.
What does appending "?v=1" to CSS and JavaScript URLs in link and script tags do?
Not all JavaScript URLs have the "?v=1" (example from the sample below: js/modernizr-1.5.min.js). Is there a reason why this is the case?
Sample from their index.html:
<!-- CSS : implied media="all" -->
<link rel="stylesheet" href="css/style.css?v=1">
<!-- For the less-enabled mobile browsers like Opera Mini -->
<link rel="stylesheet" media="handheld" href="css/handheld.css?v=1">
<!-- All JavaScript at the bottom, except for Modernizr which enables HTML5 elements & feature detects -->
<script src="js/modernizr-1.5.min.js"></script>
<!------ Some lines removed ------>
<script src="js/plugins.js?v=1"></script>
<script src="js/script.js?v=1"></script>
<!--[if lt IE 7 ]>
<script src="js/dd_belatedpng.js?v=1"></script>
<![endif]-->
<!-- yui profiler and profileviewer - remove for production -->
<script src="js/profiling/yahoo-profiling.min.js?v=1"></script>
<script src="js/profiling/config.js?v=1"></script>
<!-- end profiling code -->
These are usually to make sure that the browser gets a new version when the site gets updated with a new version, e.g. as part of our build process we'd have something like this:
/Resources/Combined.css?v=x.x.x.buildnumber
Since this changes with every new code push, the client's forced to grab a new version, just because of the querystring. Look at this page (at the time of this answer) for example:
<link ... href="http://sstatic.net/stackoverflow/all.css?v=c298c7f8233d">
I think instead of a revision number the SO team went with a file hash, which is an even better approach, even with a new release, the browsers only forced to grab a new version when the file actually changes.
Both of these approaches allow you to set the cache header to something ridiculously long, say 20 years...yet when it changes, you don't have to worry about that cache header, the browser sees a different querystring and treats it as a different, new file.
This makes sure you are getting the latest version from of the css or js file from the server.
And later you can append "?v=2" if you have a newer version and "?v=3", "?v=4" and so on.
Note that you can use any querystring, 'v' is not a must for example:
"?blah=1" will work as well.
And
"?xyz=1002" will work.
And this is a common technique because browsers are now caching js and css files better and longer.
The hash solution is nice but not really human readable when you want to know what version of file is sitting in your local web folder. The solution is to date/time stamp your version so you can easily compare it against your server file.
For example, if your .js or .css file is dated 2011-02-08 15:55:30 (last modification) then the version should equal to .js?v=20110208155530
Should be easy to read properties of any file in any language. In ASP.Net it's really easy...
".js?v=" + File.GetLastWriteTime(HttpContext.Current.Request.PhysicalApplicationPath + filename).ToString("yyMMddHHHmmss");
Of coz get it nicely refactored into properties/functions first and off you go. No more excuses.
Good luck, Art.
In order to answer you questions;
"?v=1" this is written only beacuse to download a fresh copy of the css and js files instead of using from the cache of the browser.
If you mention this query string parameter at the end of your stylesheet or the js file then it forces the browser to download a new file, Due to which the recent changes in the .css and .js files are made effetive in your browser.
If you dont use this versioning then you may need to clear the cache of refresh the page in order to view the recent changes in those files.
Here is an article that explains this thing How and Why to make versioning of CSS and JS files
Javascript files are often cached by the browser for a lot longer than you might expect.
This can often result in unexpected behaviour when you release a new version of your JS file.
Therefore, it is common practice to add a QueryString parameter to the URL for the javascript file. That way, the browser caches the Javascript file with v=1. When you release a new version of your javascript file you change the url's to v=2 and the browser will be forced to download a new copy.
During development / testing of new releases, the cache can be a problem because the browser, the server and even sometimes the 3G telco (if you do mobile deployment) will cache the static content (e.g. JS, CSS, HTML, img). You can overcome this by appending version number, random number or timestamp to the URL e.g: JSP: <script src="js/excel.js?time=<%=new java.util.Date()%>"></script>
In case you're running pure HTML (instead of server pages JSP, ASP, PHP) the server won't help you. In browser, links are loaded before the JS runs, therefore you have to remove the links and load them with JS.
// front end cache bust
var cacheBust = ['js/StrUtil.js', 'js/protos.common.js', 'js/conf.js', 'bootstrap_ECP/js/init.js'];
for (i=0; i < cacheBust.length; i++){
var el = document.createElement('script');
el.src = cacheBust[i]+"?v=" + Math.random();
document.getElementsByTagName('head')[0].appendChild(el);
}
As you can read before, the ?v=1 ensures that your browser gets the version 1 of the file. When you have a new version, you just have to append a different version number and the browser will forget about the old version and loads the new one.
There is a gulp plugin which takes care of version your files during the build phase, so you don't have to do it manually. It's handy and you can easily integrate it in you build process. Here's the link: gulp-annotate
As mentioned by others, this is used for front end cache busting. To implement this, I have personally find grunt-cache-bust npm package useful.
Related
I know that a common practice is to set an expire time far in the future for css, javascript and image files and then make sure that all browsers fetches the latest content as soon the files changes by appending a querystring (or changing filename) like this
From this <link rel="stylesheet" type="text/css" href="base.css">:
to this:
<link rel="stylesheet" type="text/css" href="base.css?v=1234">
or:
<link rel="stylesheet" type="text/css" href="base_1234.css">
But what about images referenced in a css file?
// Inside base.css
background: url(/img/logo.png)
// Is this necessary(?):
background: url(/img/logo.png?v=1234)
Or will /img/logo.png be reloaded when base.css changes filename to base.css?v=1234 or base_1234.css automatically?
And also, what about images in src for img-tags?
The browser is making these requests after determining an absolute path, so if you are 'cache busting' your static assets in this way, you do need to do it for each file individually, no matter where it's called. You can, however, make it easer on yourself by making it a variable on the backend.
You can append the string as a variable that you only have to update in one place on your backend, probably in conjunction with a CSS pre-processor like LESS or SASS to get all your images.
Or use relative paths to your advantage by adding the version to the base url (site.com/folder/styles.css => site.com/v123/folder/styles.css). This can be added to an existing static asset base url variable in your app, then on the server you can just use a UrlRewrite to strip out the version. This way all the images relatively referred to from your CSS automatically get the version too, having the same 'cache busting' effect.
You could be extra clever and set the variable automatically as part of your build process as the last commit hash from you version control system - which will also make future debugging easier.
From my experience the cache busting of the css is not recursive. So the querystring at the end of the image referenced in css is required to bust the cache.
To be sure all images are fresh you may want to also cache bust with the querystring version (img.png?v=1234).
Chrome seems to be the worse of the browser-bunch for not updating it's cache (perhaps due to the new predictive caching methods it's using) and the way to do this is indeed with a querystring.
This website takes it one step further and uses the simple JavaScript Date().getTime(); method (with or without jQuery) that is attached to all img tags.
Another solution is to write a javascript code so that the browser does not pick up image
from the cache and loads it everytime.
The benefit of the above is that individual image-file renaming, for the sake of the querystring, is not needed as the JavaScript handles this in one pass.
While it does use a single line of JavaScript to accomplish this, it's not as high-maintenance as tracking down every img element in a large CSS file, which can take time and add to the file size.
When I make a page, link it to a CSS file, and open it in a browser, it works fine.
But if a make a change and refresh the page again between very short time periods, the change is not reflected. But after sometime, when i refresh the page again, the changes appear.
So, somehow the browser keeps the CSS file cached and expires it after sometime. How to make the browser cache no CSS or HTML file.
It would be better if i can block it on a particular domain.
I'm on Ubuntu, using Chrome and Firefox, trying to prevent browsers from caching CSS files on 'localhost'... How to do it...
Thanks...
Something as simple as this should work:
<link rel="stylesheet" src="/css/screen.css?v={CURRENT_TIMESTAMP}">
Just replace {CURRENT_TIMESTAMP} with the actual timestamp in your server side code. This makes the browser think it's a new file because of the query string and it will be downloaded again. You could also use the actual modification time of the file (filemtime('/path/to/css/screen.css') if you're using PHP) which should prevent unnecessary downloads.
You can open Developer Tools by pressing Ctrl+Shift+J and then you'll find a cog icon in bottom right. When you click on it you should see an option to disable caching.
It would help to know how the website is hosted, as you can configure this in most web servers.
Also, it's a good idea to introduce a cache busting mechanism which would modify the links to the CSS files in question when you change the CSS files' contents. Browsers would then reload the CSS file because the HTML refers to a different URL.
A good example of a cache busting mechanism is the ruby on rails 3.1 asset pipeline which also minifies files and gzips them if the browser supports them:
Rails 3 - Asset Pipeline -- What does it mean to me?
http://2beards.net/2011/11/the-rails-3-asset-pipeline-in-about-5-minutes/
The seemingly-inelegant but rock solid approach is to give the asset a new name, when the content changes. This solves the problem for all your users, not just you:
<link rel="stylesheet" src="/css/screen_034.css">
<link rel="stylesheet" src="/css/screen_035.css">
<link rel="stylesheet" src="/css/screen_036.css">
Or maybe (but it's more of a pain to change in an IDE, and sometimes causes unrelated problems with caching):
<link rel="stylesheet" src="/css/screen.css?pretend_version_number=034">
Nothing else works quite as well in large scale production environments, where millions of copies of an older css file may be sitting in various intermediate or browser caches. Some clients ignore cache control headers, and you don't really want caching subverted anyway, at least not in production.
In development you can press Ctrl+Shift+J (Chrome) and turn off caching.
I noticed some websites put the version numbers (especially) in the CSS file path. For example:
<link rel="stylesheet" type="text/css" href="style.css?v=12345678" />
What is the main purpose to put the version number? If the purpose is to remember when the CSS file was updated last time, shouldn't the version number added as a comment inside the CSS file?
From HTML5 ★ Boilerplate Docs:
What is ?v=1" '?v=1' is the JavaScript/CSS Version Control with
Cachebusting
Why do you need to cache JavaScript CSS? Web page designs are getting
richer and richer, which means more scripts and stylesheets in the
page. A first-time visitor to your page may have to make several HTTP
requests, but by using the Expires header you make those components
cacheable. This avoids unnecessary HTTP requests on subsequent page
views. Expires headers are most often used with images, but they
should be used on all components including scripts, stylesheets etc.
How does HTML5 Boilerplate handle JavaScript CSS cache? HTML5
Boilerplate comes with server configuration files: .htacess,
web.config and nginx.conf. These files tell the server to add
JavaScript CSS cache control.
When do you need to use version control with cachebusting?
Traditionally, if you use a far future Expires header you have to
change the component's filename whenever the component changes.
How to use cachebusting? If you update your JavaScript or CSS, just
update the "?v=1" to "?v=2", "?v=3" ... This will trick the browser
think you are trying to load a new file, therefore, solve the cache
problem.
It's there to make sure that you have the current version. If you change your website and leave the name as before, browser may not notice the change and use old CSS from its cache. If you add version, the browser will download the new stylesheet.
If you set caches to expire far in the future adding ?v=2 will let the server know this is a new file but you won't need to give it a unique name (saving you a global search and replace)
HTM5 boilerplate also includes it in their project.
Check this video also: HTML5 Boilerplate Walkthrough.
One of the reason could be to bypass file caching. Same name CSS files can be cached by the servers and may result in bad display if new version has has layout changes.
This is to optimise browser-caching. You can set the header for CSS files to never expire so the browser will always get it from its cache.
But if you do this, you'll get problems when changing the CSS file because some browsers might not notice the change. By adding/changing the version-parameter it's "another" request and so it won't be taken from the cache (but after the new version is cached, it's taken from there in the future to save bandwidth/number of requests until the version changes again).
A detailed explanation can be found at html5boilerplate.com.
My knowledge is pretty much out of date regarding websites, but the variable stored in the 'href' argument is received by the browser through HTTP. Using the usual tricks in URL-rewriting you could actually have an arbitrary script that produces CSS-output when called. That output can differ, depending on the argument.
In some sourcecodes i see this:
<link rel="stylesheet" href="/css/style.css?201007071609" type="text/css" />
Now is my question: why do people print 201007071609 behind style.css?
This forces the browser to not load the css from cache and rather take the latest version from the server
see related article
Another trick developers do is to add a random string or a timestamp to force refresh the css page.
That's a way to make sure that clients don't cache older versions of the same file. If the URL is different, the client will retrieve the file from the server instead of from cache. So, for example, if a new version of the site was published, that would be a way to make sure visitors see the right CSS.
This forces the browser to retrieve a fresh copy of the file, rather than loading a cached version. This is important when your html has changed and requires an up to date css file to prevent it from displaying incorrectly.
the font of the content of my facebook app keeps getting italicized even when i've removed the italics from the css file. if i make minor changes in the css file and upload it to the server, the firebug shows the unedited previous css file and hence, the app keeps showing unformatted content. what exactly is going wrong here?
i made a new css file and copied the contents of the previous css exactly as it was, and i linked it in all the files which require css. but when i upload these files to the server, facebook canvas doesn't show any css at all. i replaced the css filename with the previous one, and it works. why is this?
Actually it looks like facebook is currently experiencing some weird problems with styling. It doesn't cache any new styles, only displays what was previously cached (from yesterday). If you provide a new stylesheet url it will not be able to pull it up (like that url doesn't exist).
During normal conditions what others already suggested should work.
Facebook does like to cache things. Persistently. I don't know why the new file wouldn't have worked, by I can recommend 'spoofing' your css filename with a spurious querystring variable, and incrementing it each time you make an update.
eg
href="my_css_file.css?x=1"
Sounds like the browser is caching your CSS file, which is why even Firebug sees the older version.
There are numerous ways you can prevent the browser from caching your CSS file during development (once in production mode, you probably want it to remain in the cache). The most common technique used by web frameworks like Ruby on Rails is to append a random query string to the URL, like so:
<link rel="stylesheet" type="text/css" href="style.css?96234987" />
...but the trick is that it should be different every time, so the browser thinks it's a different file.
Here are links to a simple trick for PHP, a JSP example, and other possible methods.
According to Include files on facebook developer wiki:
Stylesheet includes are cached automatically by Facebook. Just include a tag like:
<link rel="stylesheet" type="text/css" media="screen"
href="http://yourapp.com/stylesheets/style.css?v=1.0" />
Increment the version number upon each change to your style sheet, as specified above.