I have been using a central CSS file to build my site and have added to and modified it over time. I use cloudflare which caches CSS files every few hours, so to avoid this I change the number on the end of the file name each time and update it in my header template. This worked fine for months on two different servers.
But just recently it has decided not to allow this. If I change the CSS's file name and reference link, the CSS will not load. If I set it back to what it was before (site_main61.css) then it works just fine. I've even tried using different characters than increment numbers at the end and still end up with the same result.
This started happening out of the blue; no changes had been made to the server. Could this be a problem with Cloudflare? Something else?
I can provide more details if needed, but I can't think of anything that would be relevant right now.
The problem is not related to forgetting to update the link in html. I've tested this countless times to be sure.
You can add a query string the to end of the file name. It will be cached as a separate file, but it will be the same filename. It's basically a forced recache for the file. Just go to the link in the HTML and add something like this:
<link href="path/to/file/site_main61.css?version=1" ... />
This will work with most caching systems and you no longer have to change the file name.
Related
This is probably a dumb question, but I'm worried :
I have published a website on a server, then made some changes to a css file.
As the css file was already cached by my browser, it didn't display the changes.
deleting the cash allowed to display the changes.
Now my worry is that if some users have previously been to the website, and it is cached by their browser, if I make a change they wouldn't be able to see it.
How do you guys prevent this ? Do you just change the file names ?
Sorry for my noobness,
Thanks.
There are a number of solutions floating around the web, but as far as I can tell they all boil down to changing the CSS filenames whenever their content changes. That way you steer clear of user caches and server caches serving old content.
Variants:
Instead of changing the name of the file itself, create a symbolic link with a new name to the old file whenever content changes.
Instead of changing the name of the file, change the way it is referenced by the page. Replacing myfile.css?v=1 by myfile.css?v=2 circumvents people's caches.
Write code that automatically changes the name or the link name or the way the file is referenced
Use a framework that does one of the above.
And: remember that the same problem applies to any content that might be cached, like JS files.
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...
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...