I'm trying to create a gallery for a mobile site where I have different stylesheets for different sized devices. Within these stylesheets I have several classes which simply set a background url property to each image I want in the gallery.
Only one of these will be displayed at a time. And I will be cycling through the classes using Javascript to display them in a slideshow type presentation.
I am wondering is this method more bandwidth efficient than having all the images as individual img tags within the DOM? By setting these url properties do they get downloaded to the user's browser when they first load the site or are they only downloaded when the class gets set on a div in the DOM?
Simply I am trying to avoid having to download all the different images to the user's device at once. If you know any alternate methods which are better for this sort of thing I am also interested.
You are right, When you set the image backround, the image will only be downloaded if it is used, By this I mean, used as a style on some dom element.
Alternatively, you could 'change' the background-image css property using javascript. This way, you don't even have the image url in your CSS.
If bandwidth is your biggest concern, I would urge you to have a look at the inspector in webkit browsers like Chrome or safari, or with firebug on Firefox to see the 'network' tab, there you have a clear overview of what is loaded, how ( what order ) and how to optimize things. You can also make some stupid mistakes clear like downloading multiple times the same library from different locations and so.
If you just declare the class in css it shouldn't download anything before it is set. however it is a round question and the answer could take a lot of different shapes.
So I would say that yes it is a good way to do it, and it should be more bandwidth efficient (if you don't know that all the images will be loaded eventually anyhow, since you will typically have asynchronous image-loading either way it shouldn't matter much. I guess that if you only load one image initially the other images (i.e. the mentioned img tags) will not interfere making the load a bit more smooth?).
I find it to be a cleaner solution at least if you aren't sure which images will be viewed (which is likely to believe) to use your css-approach. also it's easier to maintain and provide a better design.
That you will be using javascript indicate that you are also doing the client side. And that give you control to choose what to do which is great :)
One alternative could be to have a local cache of the images as well, but that really depends on the problem at hand, if you will have different images and no real possibility to know in advance which images you will need (and perhaps not even how many of them?) then I think that the cleanest way is the way you purpose.
i.e. set up (or dynamically create) css-classes for images and handle all the logic in javascript.
Related
If I have to show one image many times on my HTML page, which is better from the point of view of site performance, many image tags with the same src URL, or many elements with the same background image defined in CSS? The first way, the browser should cache the image the first time it requests it, but there are still many requests to deal with. The second way, it seems to me there is just one request, when the CSS is parsed. Am I right in thinking that is more efficient?
Even in the case of CSS, the multiple background-image rules would still involve the browser making one web request & then caching the image. Exactly the same mechanics would be in place. The fact that the images are referenced in CSS rather than in HTML doesn't allow the browser to magically 'know' it already has the image without even checking the cache.
The primary difference between your two scenarios is that if you reference all the images in CSS, the CSS itself could be cached, which would represent a minor performance improvement, and your HTML files will be smaller. The improvement may or may not be substantial - it depends on many other factors such as how many image references we're actually talking about, whether your HTML files themselves are cacheable, how many page-views your users make on average, and so on.
All said, the CSS background-image is likely to be marginally better, but not for the reason you state. Whether you're talking HTML or CSS, you're still looking at one request followed by a bunch of cache-hits.
Suppose I am using a DIV element for which I can either add a background image or can replicate the same style creating a CSS3 gradient. Now, for Phonegap applications (where all the image files reside in the device itself), which option is better to go for.
I am asking this because I saw somewhere that the gradients takes some computation time where using image may create a loading time issue. But for Phonegap apps, the image load time issue may not be there. So, maybe just using the image be a better option here?
According to an article on the Webkit Wiki, images perform better:
Sometimes it's tempting to use webkit's drawing features, like -webkit-gradient, when it's not actually necessary - maintaining images and dealing with Photoshop and drawing tools can be a hassle. However, using CSS for those tasks moves that hassle from the designer's computer to the target's CPU. Gradients, shadows, and other decorations in CSS should be used only when necessary (e.g. when the shape is dynamic based on the content) - otherwise, static images are always faster. On very low-end platforms, it's even advised to use static images for some of the text if possible.
Source: https://trac.webkit.org/wiki/QtWebKitGraphics#Usestaticimages
Of course, you have to balance that CPU time with the extra time it would take to load the image from the server. Also, for Internet Explorer, filters are extremely slow, especially if you have many on one page.
Here's the thing: I have a Google Map with a lot of markers in it.
The problem is that the map loads, stays empty for a little while and only then markers are displayed. The markers are customized PNGs.
My idea is to "preload" them (not sure it's the right word) so they appear almost at the same time as the map.
What I did so far is to add the same images I use on my map, outside of the map, earlier in the page in display:none;
I'm not sure but it seems like the time between the map and the images are displayed has been reduced.
Is it the best way to do it, and is it a good practice?
You could use "sprites" i.e. a collection of separate images on 1 single png. This bears the advantage of requiring only 1 load i.e. less separate loads. Google GWT pushes this technique a lot (i.e. Image bundles).
The value of this technique increases with the number of discrete images that require loading: the more separate images, the longer it takes to load them.
Don't use display:none for preloading. Because an element set to display:none doesn't render any of its physical attributes, the browser doesn't bother downloading it until it's made visible.
An alternative is to use visibility:hidden, but you run the risk of running into a user agent that does pretty much the same thing. visibility:hidden requires that the browser compute the box model for the image, which requires that image is loaded (to get the dimensions). I don't believe this works in IE6, though.
The last technique (and my favorite) is to create a div directly before your </body> tag. Position it absolute with left: -99999999px; top: -99999999px. The browser is forced to render the images (and consequently load them) and there's no messy Javascript to deal with.
Now, to integrate this with your issue, put the code for your Google map after your "preload div". Your browser will be forced to load the images before it runs the code to create the map. This should solve your problem.
Hope this helps!
From what I recall of most modern browsers, images are always loaded once (given the src of the image is the same). I guess you mean loading them before the maps load.
In my opinion in does not really matter that much. Markers should be relatively light compared to the map image itself and I can't really use them without the map anyway.
If you think it improve you user experience then I think it is a good practice, but I'd try to get them on a more cleaner way, probably an ajax call early in the page load?
Take a look at Ajax In Action: Preloading Images
We have an HTML page which displays a bunch of pretty bars using divs and repeating backgrounds. We are in the process of making a report out of this that can be printed nicely, but this may take some time because we don't have a reporting framework in place. As an interm solution we'd like to make the HTML version printable. The background of the divs are the only problem, and they don't print because of the default setting (which can't be enabled because the workstations are locked down).
I have found a work around for printing background images, but this doesn't work when the background needs to be repeated.
Are there any other work arounds which might be able to help? I have also been trying to insert an image inside the dive and stretch it, but this is throwing off all the other relative positions and is proving to be very difficult to fix. I am still looking into this however.
I have used this ActiveX Component in situations where controlling the printer output was absolutely neccessary (think printing stickers etc).
The function you'd want is : printBackground
However this doesn't come with their free license but perhaps the cost of that license outweigh the other work arounds implementation time.
Drawback: IE only.
If you can educate your users, there is an option in the print dialog box of IE and Firefox that is labeled something like 'Include Background Images' or 'Print Background Images'
This will include repeating background images.
I couldn't load the link, and I may not be understanding the problem correctly, but...
This is more of a work-around than a solution, but would you be able to make a single image that just appears to be repeated? Or at least, is repeated (for variable browser and screen sizes), but is large enough to be 'proper' for printing (which is a much more standard size)?
The easiest way I can think of achieving this is to have different stylesheet for printing that uses standardised images that fit the containers printed on paper.
The display stylesheet would continue to use the repeated images which wouldn't hinder performance as the full images loaded in the print stylesheet would only be loaded when the page is sent to the printer.
...at least, that's what the HTML spec says should happen. Whether this is actually the case, I can't be 100% sure.
The discussion on this answer to the question "How can I use Google's new imageless button?" Has prompted this question.
Google seems to think that going imageless is good for some reason, but from the comments cited, I fail to see the advantage. Is it worth it to send dozens of lines of HTML and who knows how much CSS to render these imageless buttons, rather than simply load another image, especially when techniques like CSS sprites are available?
When would this technique be preferred? The other question asks how it can be done, but I want to know why it should be done.
Localization (it's easier to translate text than images)
Skinning/themeing (it's easier to change the look and feel with single CSS than recreate multiple images)
Accessibility (screen readers can read properly, text scaling works properly)
Performance (the CSS is shared and so is loaded once from the server)
Functionality (it's easier to expand the button with new UX elements like dropdown arrow when you don't have to change the whole picture)
Btw, the "imageless" button might as well contain an image inside the visual template. This approach is quite similar to XAML's approach to templating and styling the visual tree.
I think in this specific case I can only see the advantage that the buttons can be programatically generated. If you don't know what your button will say it's probably easy to make this way than generating it using somekind of image library generator.
Also changing one CSS can make you change the look-and-feel of all buttons at once. Using image buttons you'll need to update everyone and each of images.
Isn't this done because the height of the button may vary (for example the text size)?
The page load is smoother as no images have to be loaded and will appear later than the rest
The button text is also readable in the case somebody cannot read/view images, yet you have the graphical look. (building a graphical button with images in the traditional way around real text is as complicated HTML as this method)
As they mentioned in their blog, these buttons are skinnable without creating and storing custom images.
Basically, you get all the advantages of plain text buttons over custom imaging, while still having a nice, skinnable graphical look.