My code to load JavaScript file is:
<script src="/path/to/app.js?1350550684711"></script>
where 1350550684711 is just a server-side generated timestamp. This practice of cache busting is quite popular (link 1, link 2).
In Chrome and Firefox this mechanism works, and in theory it should work for all browsers, since a different HTTP resource is being requested every time.
Still reports are coming in of users using cached versions of the JS file; specifically those on Apple Safari. Any idea?
That could mean that the affected Apple Safaris reuse a cached version of the html page that contains the <script elements, and thus naturally they would not get a new timestamp from the server.
I'm speculating here, but that could be because they interpret the HTTP cache related headers differently, potentially due to differing default settings, offline browsing mode or whatever.
Check which cache settings apply to that html file.
Related
We have an ASP MVC 5 applications. We use bundles with optimization enabled by default. But we have heard several times from users, that they get errors, that we think are caused by old versions of user scripts. Their browsers somehow take scripts from cache, despite the fact, that we have edited that script files and bundles should be updated. The worst part of the problem is that we can't imitate or recreate this problem. We don't know how. We already have tried to make test-changes to scripts like adding some "console.log('test')" lines in order to see, if the browser takes the cached version, but everything was ok, the hash in the end of <script src="....?v='hash'"> changed and the browser took the newest version from first time. I should mention, that our site is a single page application. Don't know, maybe its somehow related with the problem.
Have you faced this kind of problem?
There's not enough information here to give a definitive answer. The bundler detects changes in files and will regenerate the bundle along with the link to that bundle, which will include an updated query string param. Since the query string is part of the URI, it's considered a totally different resource at this point, and the browser should fetch it again, because there is technically no cache available. The only logical reason this would not occur is if the HTML with the link to the bundle is not being updated. This can happen if you're using OutputCache or otherwise caching the HTML document. It can also happen if the client's browser is aggressively caching the HTML document. Unfortunately, there's not much you can do about that, as the client browser ultimately has control over what is or is not cached and for how long.
That said, given that this is a single page app, it's very possible that it's also including a cache manifest. This manifest will very often include the HTML file itself, and the browser will not refetch any file in the manifest unless the manifest itself is updated.
Hey I'm working on a site that loads CSS and images that are generated server-side. Some times the images and CSS that is loaded in shows up as the incorrect template but with the correct images.
Since this template is created on the server and not on the actual page I was thinking that the web server that hosts the actual page may have a cached version of that page and may sometimes ignore the CSS and images that are generated from the main server.
In short:
Do webservers sometimes keep cached versions of page Styling?
I there an easy way to make it get the live version always?
Also this happens very infrequently and at random. It seems very hard to replicate. But I have seen it happen a few times.
Any other Ideas?
For the first answer, yes they do but only if setup that way. There is the CDN or varnish. These system are used for website with huge loads where content must be cached locally or on other server, allowing the user to visualize the cached content and not the one generated by the webserver at the moment the user requested.
Exclude this for your case then ;)
I always use chrome or firebug on firefox to debug a website.
Press F12 while in the page you want to check and, on chrome, go to "Network" tab and pin "Disable Cache".
This is incredibly handy if you refresh your page quite often and want the content not cached.
For the question itself, I don't think I/we can help you without seeing the code. But try my suggestion with F12 before.
There are two kinds of caches to think about. One of them is server cache. If you use server cache, then whenever CSS was modified, you need to empty the CSS cache if you have such a cache. If not, then you need to empty the cache, which might be painful.
As about browser cache, if you add a new parameter to your css file, then it will be loaded even if it was cached in the browser of a given user, therefore it is recommendable to add a parameter to your css file where you include it. This parameter should be either a version or a timestamp, or something uniquelly distinguishable from earlier versions. That value should be stored and you need to refresh (preferably) automatically whenever the CSS changes. The exact steps are up to you, since they differ greatly in different environments.
While tuning my web app, I noticed that certain of my images are never loading from cache, even though they're completely static:
This particular file always loads from the server, but it should be cached. The only thing somewhat special about the file, AFAICT, is that it's sourced via a CSS class, which specifies the file via a background-image style. I'm not specifying any tricky headers or anything; it's just a regular jpg file.
There's a lot online about preventing caching, but I can't find anything about making it work when it doesn't seem to be.
Do you have caching software on your web server? If yes is it enabled? Since some can be disabled such as UnixyVarnish what is mainly found in cPanel. Images do get cached by default. Regardless of how its displayed. And your browser should automatically cache websites you visit, unless you have disabled it.
In the head section of the sample html file from the html5boilerplate project, I notice this:
<link rel="stylesheet" href="css/style.css?v=2">
Note the v=2 request variables. I also notice that this is never done for javascript files.
What is the actual function of doing this ?
The ?v=2 might be to prevent reading from cache by the browser. It's used when loading dynamic content from a static file, like so:
changingListOfStuff.txt?randomUselessPropertyToTrickBrowser=123456789
This forces the browser to use this exact file, not a cached version of changingListOfStuff.txt previously downloaded and stored by the browser. Caching speeds up loading time, but might provide an older version of the file if it changes rapidly.
Read more about caching here: http://en.wikipedia.org/wiki/Web_cache
this is just telling the version of the url. This is done to make a fresh request to the server.In case of css as we know to achieve performance some headers are modified so that next time css is served by the browser history.But every time a css is modifed specifically in case of version releases. Browser should make new requests that would happen only when the url changes. So v=2 probaly means a new version is in and the url should freshly fetch the content from css.
This is called cache busting...you can read it here too
http://manikandanc.blogspot.com/2005/11/cache-busting-with-javascript.html
this will avoid client to get the version from browser. When you change the javascript or css , the end client who already visited your website may get javascript from his cache.
You can increment the version no whenever you deploy the files to the production , so that it will get the latest file
I'm using TypeKit to provide fonts for a site I'm developing. When the page is loading it loads slow (more than a second). Turns out that this is because it's downloading the fonts on every requests. It's beyond me that a service such as this doesn't have etags configured to get clients to cache the fonts...but I digress. Until TypeKit fixes this I host the CSS locally temporarily.
Anyone had this issue with TypeKit? How did you work around it? Perhaps I'm wrong?
According to a posting on their getsatisfaction.com account, they have at least some caching in place:
One thing to note is that although the fonts are served with an Expires header, they're also served with an Etag. The browser is required to make a request after 5 minutes, but will normally use the Etag to generate a 304 (Not Modified) response - meaning, the fonts aren't actually downloaded again.
can you check what happens using Firebug?