Javascript versioning to avoid caching, difference in these practices? - javascript

If I decide to use last_modified_time of a javascript or css file, and use the unix timestamp of it as a key in the name to bust cache when file is modified.
What is the difference between following two practices ?
filename is : my_script.js and timestamp is : 1321951817
1/ File gets included as :
<script type="text/javascript" src="http://example.com/js/my_script.js?v=1321951817"></script>
Hence,the query string parameter creates a new cache everytime the v is changed.
2/ File gets included as :
<script type="text/javascript" src="http://example.com/js/my_script.1321951817.js"></script>
The filename changes with every modification, a rewrite rule removes the timestamp and points the requested url to my_script.js
3/ UPDATE: ONE MORE METHOD BASED ON ANSWERS BELOW : File is renamed and get included as :
<script type="text/javascript" src="http://example.com/js/my_script.1321951817.js"></script>
The filename is changed and NO REWRITE RULE is used.
Question : Are these two techniques inherently the same, or are there any advantages/disadvantages of using query string parameters instead of direct file name.

Using an updated querystring is a bad solution. See what Steve souders has so say about it: http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
The ideal method is to rename the file itself.
Some people prefer using the time stamp of the last modification date, which i think is a problem.
In modern web development you really need to optimize your page as much as possible, which means combining css and javascript into single files which are minfied.
That means that you introduce a build step into your process, and that the last modification time of your file always will be at your last build. If you set that as your file name, you essentially bust the users cache all the time, and some times you dont need to.
I recommend renaming the files to an md5 sum of their content. That way you can do new builds all the time, but the file name only changes if the content changes. This makes your file name an identifier of the content. Using this you can set a far future expires header on all your static content and simply stop worrying about it any more.
I can recommend using a build system for this, since this workflow gets boring fast.
My company open sourced one a while ago that does this among a lot of other things that optimize your web page: https://github.com/One-com/assetgraph-builder
There are many other build tools that do the same. Take a look around and find the one that best suits your development setup.

You are saying it yourself: in the second example you are using a rewrite rule which checks with regex every page you are loading.
The first one just fooling the browser to think it's a different file. So the first one is the way to go.

Related

Why the names of some css, js files have random numbers in them?

Some websites seem to have file names such as 'assets/app-02b4523sev8fsd56e.js'. I have noticed that these numbers do not change though, so I thought it has something to do with security but I am not sure. Is there any reason behind this?
This is normally to break caches stored by the browser so that the latest version of a file is loaded. Every time a file is changed this value will normally be changed also. This can be done manually by changing the filename and/or the paths in other files referencing this file, or this can be done programatically in some way. You may also see this done like the following and it may also contain a timestamp rather than a hash like the above:
assets/scripts.js?v=20150611190618
This is often referred to as a 'cache-buster' amongst other names.

Why do developers append a query string in JavaScript files' stylesheet links? [duplicate]

This question already has answers here:
Why pass parameters to CSS and JavaScript link files like src="../cnt.js?ver=4.0"?
(9 answers)
Cache manifest and query strings
(3 answers)
Closed 8 years ago.
I have seen this in many sites:
<script src="/file.js?query=string"></script>
<link rel="stylesheet" type="text/css" href="//cdn.sstatic.net/stackoverflow/all.css?v=86c1a91ea87b">
<link rel="apple-touch-icon image_src" href="//cdn.sstatic.net/stackoverflow/img/apple-touch-icon.png?v=fd7230a85918">
Why are developers passing a query string for these scripts and stylesheets, etc.?
Update: I agree this is duplicate But can you tell me how to 'search' to get those original questions?
This is used for invalidating caches.
Check out this brief (albeit old) explanation: http://css-tricks.com/update-on-css-caching/
When the query string is updated, it forces the client's browser to download an updated copy of the stylesheet or script.
One thing that can be used for is to force the browser to re-pull scripts or stylesheets, by changing the query string. That way, in case the file ever changes, and the site wants to force any users to pull the new one instead of using a cached copy, they just change the query string.
For example:
<script src="//whatever.com/something.js"></script>
If you have this on your page, then a browser will pull it down once, then probably cache it for awhile, so every time your page loads, they'll use the cached copy unless they have a reason to try to re-pull (like F5-refreshing the page).
If you use a random query string, then once you change your query string in your markup, the browser has to go pull a new one, since the browser thinks it's a new file (regardless of whether or not it actually is). And the content server will ignore the query string parameters on static files, so it doesn't care what you put:
<script src="//whatever.com/something.js?v=12345"></script>
The browser will grab the file again, whether it needs it or not.
<script src="//whatever.com/something.js?v=98765"></script>
Now it will do it again.
The developers of a web application which are in evolving stage and get changed often encounter the issue that their JavaScript code or CSS changes do not start working until you clear the cache of browser. In case of a live application, you cannot ask users to clear the cache, so to ensure that changes start working developers append the query string to CSS or JavaScript files.
The reason to do this is because browsers cache the GET calls, so multiple calls to JavaScript, that is,
<script src="//example.com/myscript.js"></script>
will not always get the new copy so to overcome this query-string helps:
<script src="//example.com/myscript.js?v=62345"></script>
Any random unique data as query string tells the browser that it is a different call from the previous one, so it always get the new copy. Stack Overflow is also using this technique.
That caching is helpful in cases when your files never get changed or rarely change like a jQuery file that is the reason it is recommended to use a CDN for these files as it already get cached by some other website.
One possibility besides attempting to prevent the CSS from being cached is that those sites are generating their files server-side. The original question, before it was edited to change its meaning, was asking about "scripts and style sheets etc". Because I saw the script element first, which doesn't have a value appended to it that looks like a hash value, my answer would be that it's possible that they are trying to roll all of their scripts into a single file to cut down on HTTP requests, which will speed up their site. That is a recommended best practice for speeding up your site by Yahoo.
After pulling together the appropriate files, the server can then save them to a file as a cached version and avoid fetching everything dynamically again unless the individual pieces are updated.
If I was using PHP:
$page = $_GET['query'];
switch($page)
{
case 'homepage':
/* There would be some code here, checking to see if there's
* a cached version that could be served up, before doing the
* extra work of rolling the scripts together */
foreach($scripts as $script)
$combined_script_file .= $script;
echo $combined_script_file;
...
break;
case 'blog':
...
}
There are plenty of different use cases for server-side processing of files. This is just one.

How to attach large amounts of data with tampermonkey script?

My script adds some annotations to each page on a site, and it needs a few MBs of static JSON data to know what kind of annotations to put where.
Right now I'm including it with just var data = { ... } as part of the script but that's really awkward to maintain and edit.
Are there any better ways to do it?
I can only think of two choices:
Keep it embedded in your script, but to keep maintainable(few megabytes means your editor might not like it much), you put it in another file. And add a compilation step to your workflow to concatenate it. Since you are adding a compilation you can also uglify your script so it might be slightly faster to download for the first time.
Get it dynamically using jsonp. Put it on your webserver, amazon s3 or even better, a CDN. Make sure it will be server cachable and gzipped so it won't slow down the client network by getting downloaded on every page! This solution will work better if you want to update your data regularly, but not your script(I think tampermonkey doesn't support auto updates).
My bet would would definetly be to use special storage functions provided by tampermonkey: GM_getValue, GM_setValue, GM_deleteValue. You can store your objects there as long as needed.
Just download the data from your server once at the first run. If its just for your own use - you can even simply insert all the data directly to a variable from console or use temporary textarea, and have script save that value by GM_setValue.
This way you can even optimize the speed of your script by having unrelated objects stored in different GM variables.

What does 'x' mean as the last letter in `src` attribute

In some projects I noticed that javascripts included into HTML like this:
<script type="text/javascript" src="./js/score.js?x"></script>
What's mean last 'x' symbol?
It is a query string which may be used to pass variables to the script.
It will help to overcome cache problems as well.
If I had to guess, I would say the X is being used as a querystring fragment. Unless the server is depending on the fragment being there, it could possibly be used as a cache buster.
Essentially, by changing that X to a Y we could make the browser fetch a fresh copy. This is useful if you need to make sure users get a new copy of a file.
Of course, without talking to the author we are just guessing. Perhaps the server needs it there to properly build the file in the first place. Or maybe the javascript itself is using it.
It is not a symbol. It is a piece of query string like on web scripts it would be something like test.php?reload=true
Such techniques might be helpful to overcome the caching problem as mentioned by SLaks on the comments.
You can pass parameters to your javascript.
It can be used to initiliaze variable or be used somewhere.
Take a look at this link http://feather.elektrum.org/book/src.html

Help me to understand <script src="some.js?param1=one;param2=two" />

I observed chunks like below sometimes on web pages. So i am curious to know what this really does? or why its written in such a way?
<script src="somefile.js?param1=one&param2=two" />
i can only make out following few intentions behind it
Its not page URL (i mean .aspx/.php/.jsp etc.) so its not hacking kind of code where user can add code like this to pass data without getting users attention as its tag which does not render on UI OR implementing old type of AJAX alternative
This kind of URL param are useful if user do not wish the JS file (any other resource like image) to get cached. This can be quick way to manage caching
But i am unable to figure out following
Looks like page URL parameters but are these parameters anyway readable in JavaScript file and have some additional utility?
Do these parameters have any extra role to play here ?
What are the other possible practical scenarios where code like this can be/is used?
So please provide some inputs related with the same
Thanks,
Running Non-JS Code within .js Extensions
In cases like this, that source .js file might (given proper server-configurations) actually have PHP/.NET code within it, which can read those appended values.
As you said, Avoiding Cache...
Additionally, people will at times append a random string at the end of their referenced elements to avoid loading cached data.
The URL having '.js' means nothing. It could still be handled by a server-side script like an ASP or PHP.
Either the javascript file is not static (it is generated by the server based on the parameters in its querystring)
OR
In the JavaScript file itself, you can have it check its own querystring parameters (not just that of the page, but that of the javascript source url).
OR
(This doesn't exactly match your scenario, but) you can also add parameters at the end of image and script urls as a way of versioning. The version with the url="somescript.js?V=3" will be cached by the user until the page then changes and the url is not="somescript.js?V=4". The file will be replaced by the version on the server no matter what the browser setting may be.
My guess (without looking at this specific case) is that the javascript file is reading its own querystring. I have done this, and its very helpful.
Looks like page URL parameters but are these parameters anyway readable in JavaScript file and have some additional utility?
Yes you can read them in JavaScript, Scriptaculous uses that approach for loading modules, eg:
<script type="text/javascript" src="scriptaculous.js?load=effects,dragdrop">
</script>
Do these parameters have any extra role to play here ?
What are the other possible practical scenarios where code like this can be/is used?
That can be also used for server-side script joining and minifying, of course using some url rewriting technique to have the .js extension, and as you say, it's a common technique to add timestamp parameters to break the browser cache.
It can be used for three different reasons:
1) To generate the JavaScript file in the server depending on the parameters;
2) To avoid caching;
3) To pass parameters to JavaScript itself
An example of this in practice would be a server side handler for somefile.js that uses the parameters (names of other scripts) to determine which scripts are actually required and combine/minify them, returning them as a single somefile.js script file.

Categories

Resources