If you specify same image in different CSS selectors, will it be downloaded separately or later url's will use the first one?
.a {
background: url('image1.png');
}
...
.b {
background: url('image1.png');
}
Actually in all the browsers, we have browser cache. Once it is loaded it will not be loaded again. If the file size and names are same, there is no way it is going to be loaded again. You can track that using firebug or developertools.
Try it — when looking into caching issues, a tool like Firebug for
Firefox or the Developer Tools within Chrome are very beneficial. If
you open the 'Net' panel in either and reload a page, you will see
what HTTP status code was sent for each item. 304 (Not modified) means
that the item was retrieved locally from the cache.
As dthorpe says above, cache headers are important here. As well as
making sure that 'no-cache' hasn't been set, if you have access to
your server configuration you should be pro-active — if you know a
resource isn't going to change you should make sure to set either an
'Expires' header (which tells browsers a date after which the cached
copy should be considered stale) or a 'Cache-Control: max-age' header
(which gives a number of days/hours rather than a set date).
You can set different time-scales for different mime-types/folders
too, which allows you to get clients data to refresh HTML content
often, but images and stylesheets rarely.
Here's a nice intro video/article by Google that's worth checking out.
Highlighted are the proper answers from this stackoverfow question. It will be interesting for you if you try to know about how web browsers work.
Related
I want to do something hackish in order to have responsive images generated automatically with js & php. I would like to do this with my css background-image: url(#/path/to/image.jpg), so that I can specify various image paths that javascript can grab but which won't actually result in separate HTTP requests.
The browser interprets the above code as http://example.com/cssfolder/#/path/to/image.jpg. Which means it is just pointing to the css folder. In my brief tests, if there is an index file in the folder the Chrome console will complain "Resource interpreted as Image but transferred with MIME type text/html" but if there is no index it will give a 404 message.
So that feels kind of bad, but it doesn't seem to affect the browsing experience. I guess developers may not like this method since it pollutes the console with errors, but is there an objective reason to avoid this? Are there some browsers that would actually mess up the page, bearing in mind that a real background image would be immediately supplied with javascript?
We've reached the end of our tether here trying to overcome a nasty and intermittent FOUC in Firefox 3.5.x+ for a new release we're working on.
We've tried:
Disabling Javascript in FF
Using Quirks mode rendering by removing the DOCTYPE
Moving from #import for additional CSS to <link>
Switching concatenation on and off
Removing CSS files from the concat, one at a time
Switching the local cache off in Firefox
etc
Our previous release never exhibited any FOUC issues, so it's something we've done to this release. Changes we've made so far include:
Using Base64 encoded images over Data URIs for all decorative imagery, served via CSS.
Separating 'framework'-related CSS files from page-specific CSS and bundling them as two separate CSS files
To recreate the problem... use Firefox 3.5.x or 3.6.x, then:
Head on over to: http://my.publisher-subdomain.env.yola.net/
Login with username: 'stack#yola.com' and password: 'stackoverflow'
Once logged-in, you should be at http://my.publisher-subdomain.env.yola.net/sites/
Click the Account link in the main nav.
The Account page should load, and you should see a FOUC. If the FOUC does not occur, clear your cache and reload the page.
Your help would be greatly appreciated! :)
UPDATE:
The dev environment is still exhibiting the FOUC, but only if FireFox is running low on memory or has a lot of extensions installed. Latency and rendering speed definitely affect the visibility of this FOUC.
Although this is a very old question, I found it when I was searching for a solution to the same problem. So, I wanted to post the solution for future reference. I just needed to move the reference to my CSS files above the references to external Javascript that needed to be in my header.
I can be wrong, but this could be a concurrent connections issue. According to my Firebug's "Net" tab
the HTML page simply takes a lot of time to load - maybe also because it is on a development server? - and the style sheet gets loaded after the HTML page.
I can't claim to entirely understand what's happening here, but I would try putting the style sheet onto a different domain as a first measure. That should make Firefox establish a connection straight away.
It would probably also be a good idea to go back to normal images instead of data: URIs - that would reduce the size of the style sheet, and data: URIs won't work at all in IE < 8.
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...
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.
.button {
background: url(../Images/button.png);
}
Problem: for performance reason all static content has expiration headers and is cached by browser. When image changes user must refresh cache (Ctrl+F5 in IE). I want images to be cached, but when necessary they must be automatically reloaded.
Question: is next approach 'valid'?
.button {
background: url(../Images/button.png?v=1234);
}
where v=1234 is version of my site. I do not know whether it is 100% valid to write such things in CSS and I do want browsers to still cache images if version is the same. Do all modern browsers correctly cache data with URL parameters part?
Thanks.
That looks like a good approach to me, it'll work fine in CSS in modern browsers - the browser will look at the address of the image (including the ?v=1234), see that it's not cached, and send a fresh request.
This is discussed in rule 3 of High Performance Web Sites: "Add an Expires or a Cache-Control Header". One of the approaches recommended is to version the files rather than the site.
From the accompanying blog:
Keep in mind, if you use a far future Expires header you have to change the component's filename whenever the component changes. At Yahoo! we often make this step part of the build process: a version number is embedded in the component's filename, for example, yahoo_2.0.6.js.