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
Related
I'm generating dynamic CSS URLs for cache-busting. I.e. they're in the format styles-thisisthecontenthash123.css.
I also want to use HTTP Link headers to load the files slightly faster. I.e. have the header Link: <styles-thisisthecontenthash123.css>; rel=stylesheet
I'm pretty sure it's possible to do this in Fastly using VCL, but I'm not familiar enough with the ecosystem to figure it out. The CSS URL is in index.html, which is cached. I'm thinking I can open index.html and maybe use regex to parse out the CSS URL. How would I do this?
If I'm understanding your question correctly, you want to include a link header for all requests for index.html. You can do that with Fastly, but if the URL for the CSS file is changing you're not going to be able to pull that info out with VCL (you can't inspect the response body).
You could use edge dictionaries and whenever your CSS filename changes, update the reference via the API.
Thing is, if you're going to make an API call whenever the file changes, might as well just keep the filename consistent (styles.css) and whenever you publish a new version send a cache invalidation (purge). Fastly will clear the cache in ~150ms, so you then all you have to do is add the header which is can be done in the Fastly web portal with a condition.
I've been using S3 to host static websites and I've made changes to the HTML & CSS files and have seen those changes reflected in the past. For some reason I go to do the exact same thing I've done before, change the style of one of my sites, and no change would take place. In-fact after deleting all previous files, the old build was still rendering. I had no version control on that particular bucket.
Content-type is set to 'text/css'. My file structure is normal with index.html being in the root. My normal steps of creating or updating new or existing sites has not changed, but S3 has for some reason.
When I click on the index.html file and go to the public url link, it reflects all my changes.
My only fix is to add the full url to the style link.
<link href="https://s3.amazonaws.com/{bucket-name}/css/style.css">
Does anyone know why this is happening or how to fix it other than adding the http link? If not, I hope my solution helps others for this weird S3 issue. Normally you can just upload your files to a bucket, set the policy and finally enable hosting after stating the root html file.
It might be due to your browser caching, where it's loading locally stored assets (CSS stylesheet) from a previous time you've visited the URL rather than fetching the new resources in an attempt to speed up load times. There are settings you can change in your browser to determine how long your browser will hold onto cached resources before fetching new ones.
By setting the stylesheet link directly to the s3 bucket URL, it will cause it to fetch the new stylesheet every time the page is loaded, which leads me to believe that caching is the issue here.
Try clearing your cache and see if it solves the problem.
Here is a deeper explanation of the concept with respect to browsers, and a list of commands to perform a cache refresh depending on what browser/OS you have!
I think it's the CSS folder's doesn't allow you to access the files inside. If you make the folder public, it will work.
Select all your files and folders, go to actions tab and then select make public to allow objects to access one another.
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.
So I'm having this really weird bug with my new server where the CSS won't update in the browser. Refreshing and clearing the cache doesn't work. I then opened up FileZilla to see if the updated CSS file is actually being uploaded to server using FTP, which it is, and then when I drag a copy of the css file to my desktop, the css file magically updates. The PHP file updates just fine.
Here's how I include the css: <link rel="stylesheet" type="text/css" href="css/stylesheet.css">
I have no idea what is happening and how to fix this so any help would be greatly appreciated!
You could have any number of issues, but I'd like to point out a cool tip when using Chrome.
On your page, with the developer tools open if you press and hold the reload button you get a great option to clear the cache and hard reload!
This is very handy to make sure you have the "freshest" copy while developing.
Update:
As for your scenario (after reading updates) it sounds like an HTTP header issue with your CSS file.
Check what HTTP headers are being sent with your CSS file response. If you are not specifying a cache header it will likely try to cache for you. Set an expires header (in the past) when in development, but far in the future when in production. In the Network tab of your developer tools (most browsers) you should be able to see these headers, or you can use a too like Fiddler that will let you deeply inspect your network traffic.
Alternatively if you can't easily tweak the HTTP Headers, then set a far expires header, but ensure the path to the file changes whenever you make a code change. Options include:
adding a time() stamp (always changes (yeah!) but doesn't cache (boo))
add the version control # to the file URL (works great, but you need to manage the updates properly within your tooling)
something fancier that creates a generated "fake" path to the file that auto changes on any modification to the file... but also loads the URL as expected, and sets the cache to "forever" (max 365 days according to the HTTP specs)
You may try queries to force the browser to load fresh CSS when it loads. To do this
<link rel="stylesheet" type="text/css" href="css-file-name.css?v=1.1">
If you are comfortable with php you may try below code to force the browser to load most updated CSS to load. To do this
<link rel="stylesheet" type="text/css" href="http://example.com/style.css?d=<?php echo time(); ?>" />
This will ensure browsers always load fresh CSS with last modified time stamp.
Hope this help you.
I do not really understand how Google Code handles file versioning.
I am building a jQuery plugin that anyone can access. Like so:
<script type="text/javascript" src="http://jquery-old-browser-warning.googlecode.com/files/jquery.browser-warning.js"></script>
This script accesses other files on the same project (via ajax).
The problem is, that when I upload a new file, it just seems like there aren't any changed to it. Google recommends that new files should have new names.
But then I would have to change the filenames that the script loads.
But then I would have to change the script file as well, and that would break everybodys implementation (with the script-tag above)
Is there a way to force a file to change when uploading with the same filename?
PS: If I go directly to the project page's file list. Then I do get the file with the updated content. But as I said, not when getting it through ajax.
The cheapest trick in the book to prevent caching is adding some random content to a GET parameter:
www.example.com/resources/resource.js?random=1234567
You can for example use the current timestamp for this.
This, however, causes any and every access to re-fetch the content, and invalidates any client-side caching mechanism as well. I would use this only as a last resort. If Google are that stringent about caching, I'd rather develop a workflow that allows for easy renaming of files.
I don't know your workflow, but maybe you can work with versioned directories?
Like so:
www.example.com/50/resources/resource.js
www.example.com/51/resources/resource.js
that would keep whatever caching the client employs intact, but whenever there's a change from your end, the browser would reload the content.
I think Its just a cache on the browsers, So when you request file from ajax, just add random parameters or version number.
For example, Stackoverflow add version parameter to static contents like
http://sstatic.net/so/all.css?v=6638
Are you talking about uploading files to the "Downloads" area? Those should have distinct filenames, for example they should be versioned. If you're uploading the script code, that should be submitted by the version control system you're using, and should most definitely keep the same name across revisions.
Edit: your code snippet didn't show up on my page, misunderstood what you're trying. Don't imagine Google would be happy with you referencing the SVN repository every time some client page is loaded :)