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.
Related
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.
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.
I found out that some websites use css tag like style.css?ver=1. What is this?
What is purpose of ?ver=1?
How do I do it in code?
To avoid caching of CSS.
If the website updates their CSS they update the ver to a higher number, therefore browser is forced to get a new file and not use cached previous version.
Otherwise a browser may get a new HTML code and old CSS and some elements of the website may look broken.
Adding '?ver=1' makes the HTTP request look like a GET query with parameters, and well-behaved browsers (and proxies) will refuse to cache parameterized queries. Of course well-behaved browsers (and proxies) should also pay attention to the 'Cache-control: no-cache', 'Expires', 'Last-Modified', and 'ETag' response headers (all of which were added to HTTP to specify correct caching behavior).
The '?ver=1' method is an expensive way to force behavior when the site developer doesn't know how (or is too lazy) to implement the correct response headers. In particular, it means that every page request is going to force requesting that CSS file, even though, in practice, CSS files change rarely, if at all.
My recommendation? Don't do it.
The purpose of the ?ver=1 is to parameterize the css file, so when they publish a new style.css file they up the version and it forces the client to download the new file, instead of pulling from the cached version.
If you are developing a web application in HTML and CSS or any other technology, and you are using some external CSS or JS files, you might notice one thing that in some cases if you made any changes to your existing .css or .js files then the browsers are not reflecting the changes immediately.
What happens in that case is that the browser do not download a fresh copy of the latest version of the .css and .js files, instead it uses those files stored in your local cache. As a result the changes you made recently are not visible to you.
<link rel="stylesheet" href="style.css?v=1.1">
The above case when you load the web page the browser will treat "style.css" as a different file along with "?v=1.1". Hence the browser is forced to download a fresh copy if the stylesheet or the script file.
I think that ?ver=1 is for the version no. of the web app. Every time a new build is created, the app can update the ver to the new version. This is so that the browser will load the new CSS file and not use the cached one (both use different file names).
You can refer to this site: http://www.knowlegezone.com/36/article/Technology/Software/JavaScript/CSS-Caching-Hack----javascript-as-well
IMO a better way to do this would be to include a hash generated off of the file size or a checksum based on the file contents or last-modified date. That way you don't have to update some version number and just let the number be driven off of the file's changing properties.
I was browsing the html of my favorite site...ahem...and I saw this in the markup:
<link href="/Content/all.min.css?d=20090107" rel="stylesheet" type="text/css" />
what does "?d=20090107" do? I'm assuming it's a date of some kind, but I'm not sure why it's in the path to the file. Any ideas?
That is there to add some uniqueness to the filename, so that when they change the CSS file, they can change the extra bit to be totally sure that every client will reload the CSS rather than use a cached version.
The webserver will ignore the parameter and serve /Content/all.min.css normally
Note: While it's possible the CSS is dynamically generated, this is a common idiom for ensuring a reload, and given the parameter is a date, it seems quite likely.
Edit: Podcast 38 mentioned this...
We’ve been using the Expires or
Cache-Control Header since we
launched. This saves the browser
round-trips when getting infrequently
changing items, such as images,
javascript, or css. The downside is
that, when you do actually change
these files, you have to remember to
change the filenames. A part of our
build process now “tags” these files
with a version number so we no longer
have to remember to do this manually.
It's to "clear the cache" every time the style is updated. I would speculate that whoever is responsible for those styles increments it every time there is a change. It's because the browser sees a different URL in the style field, so it will grab the latest version, even though it's technically in the same place on the server.
As helpfully pointed out in the comments, css files often have their expiry set well into the future, this method is a nice sidestep to cache related headers.
Quite a useful trick.
It is to make the browser think it is a new file every-time to it refreshes its cache.
Very useful when your stylesheets change regularly...