I want to put images of the 1024x768 as backgrounds and load quickly using css. I could use
background(url....)
in the CSS, but will that solve the issue, of downloading images quickl?
Thanks
Jean
If you have to use this technique, then remember to compress and cache the image, this will speed it up somewhat, but try and be creative with alternative solutions.
For example can the background repeat on the x-axis? If it can you'll be able to create a 1px wide version that you can repeat across the page.
Try searching for this. It helps cutting off a few KB of data. PNG Gauntlet is also a free software for PNG compression that also cuts Gama correction that causes problems with IE6 and IE7.
Body background images are usually saved with lower quality, thus reducing size.
If your backgrounds are changeable, preload them. It is done by putting divs of zero height at the beginning of the page, and assigning background-image style to each. The images are loaded at the beginning, so when the background of the body gets changed the user doesn't notice the lag.
Google started to count the load time already, so classic preloading causes problems with SEO. Loading with JS, after the page fully loads is an option, or even assigning styles with JS after certain actions are made is also a solution.
remember you can't change the user dsl speed. so css background would be good. Maybe start with take a higher JPEG compression to minimize the file
(btw. i hate (full size) background images at websites with my dsl light)
Related
Is there a way, without javascript, to load a small image for a background before the real image is downloaded? Without javascript because I know how to do it with it.
I can't test if the following CSS3 would work because it works too quick:
body {
background-image:url('hugefile.jpg'), url('tinypreload.jpg');
}
If the tinypreload.jpg is only, say 20k, and the hugefile.jpg is 300k -- would this accomplish the task? I assume that both downloads would start at the same time instead of being consecutive.
Update
Timing the results using Firefox's profiling revealed that it's not practical / not worth it to load a smaller background first. Main reason is the connection time. For tiny pictures it's the same time to connect as it is to download the content. For images where this becomes worth it -- the file size is not recommended for mobile.
If you still want to achieve this effect - combine all your "necessary" images into 1 file and display them as cropped background with correct offset. Load your high-res images through javascript, and update the content afterward.
You could exploit css load order and overrides to achieve this result.
Try loading the small image from your main css file and then put a <style></style> tag at the bottom of the html page. The inline style will override the main style but will load last because of it's position in the code.
The difference would be milliseconds though, so it may be too quick. It's also hacky and would result in invalid, but working code. Worth a shot though.
If you're trying to fix a mobile problem then have a look at this article on context specific images as that might be a more effective way to go.
This article on CSS3 multiple backgrounds may also help, as you may be able to exploit the stacking order to achieve the result you're after
It would be useful to know what problem you are trying to solve beyond load order, as it's hard to give advice on this one.
As I said in my comment you can use the 'net' tab in firebug for firefox (called timeline in chrome) to see the actual load order on your page - you can even filter it (on firefox) for CSS only or images only - this will enable you to test.
The typical rule of thumb when it comes to using CSS sprites for images is that you should only do it for smaller images (like icons) and that actual image content should always be represented through <img> elements. My question is: why? Aren't the advantages of spriting worthwhile for content images as well?
One reason I have read is to enable the use of alt text, to be more syntactically correct and accessible to screen-readers. However, when that is a concern, couldn't you just as easily use a single tiny transparent image with all the syntactical sugar atop a sprite that presents the real visual content?
You could, but:
Content images don’t tend to be re-used as much as UI-type images like icons. Imagine a newspaper site: if every content image they used in every story was part of a sprite, that sprite would very quickly get huge, and would be downloaded even by users who only looked at one story.
Website content is generally expected to be maintained by people who don’t know CSS. It’s a bit unreasonable to expect content editors to edit a master sprite image file, re-save out to a JPG, and pop in some CSS just to put an image on a page.
If you sprite a lot of large image files, the sprite file will get really large. It might take an unacceptably long time to download when the user first visits the page, or it might use up too much bandwidth on users who only end up seeing one of the images within the sprite.
Obviously, those are generalisations — in a specific situation, it might make perfect sense to sprite larger/more content-y images.
On using an <img> tag with a tiny transparent image file for sprites, you can do that for any sprite images — it’s often useful for clipping and positioning the sprite image beyond what background-position allows.
One additional reason I can think of, is search-engines; if you have an image with a descriptive alt-tag or a figure element with a figcaption, search engines will be able to find, classify and show it.
Sprites are usually usefull for static contents (images that are common on many pages).
Content pictures often appears in only one page, so you can't add it to your sprite file.
If you want to have real-time sprite generation, making custom sprite file with all your pictures, I think the generation cost is far more expensive than the duplicated HTTP calls it saves.
Sprites are here to save HTTP requests, but you should not waste server-side computation time to make it, nor put expensive and unusefull pictures in your sprite file.
Sprites should be used for common icons across the whole website and not for page specific content. When you use sprites for big images you get a lot of white space that is wasted.
According to http://blog.vlad1.com/2009/06/22/to-sprite-or-not-to-sprite/ this is also a problem:
Another (but much less important) downside is that if a sprite-using
page is zoomed using the full-page zoom feature that’s present in many
browsers, the browser may need to do extra work to get the correct
behaviour at the edges of these images — basically, to avoid adjacent
images in the sprite from “leaking in.” This isn’t a problem for
small images, but can be a performance hit for bigger ones.
From the research I've continued to do on this, another potential issue is memory consumption. Despite the fact that sprites may be compressed enough to download quickly, the footprint they fill in the client machine's memory is after the browser has rendered them, meaning it can be quite large, even for sprites with fairly small file sizes.
I haven't seen a definitive answer on whether or not this memory footprint is any larger than what one would see when loading the same number of images without sprites. I will be testing that in the coming weeks for the project that prompted this question, so I will return and update this answer once I have a conclusion.
Sprites are used to reduce the amount of requests to a server. The impact of lots of small requests is slowing the server more than one bigger request. But if the image of sprites, I like to call it sprite-map, is too large, it will also slow down the performance. The other thing of importance is like you sad the possibility for each single picture to give some name, to manage and to index by search engine.
I have a colourful background image that is 2000px x 1500px and because of the details I am saving it as a jpeg that renders at 1.1 MB. I am using the CSS background property to render the image. So being relatively new to web dev and working with a client/designer that's not open to a change of design at this point in the process, what should I do to help this image load blazingly fast. I don't know if it makes a difference but the site is using Joomla 1.5.9. This is something I've always wanted to understand but have had trouble uncovering solutions for... I hope someone can help!!
Thanks everyone!
There's no way to make images magically load faster. Sometimes, though, splitting an image in smaller images allows for surprising size gains; so if it's not out of question for your CSS layout (it typically is, though), you could try this.
Another possibility for you would be to use progressive JPEG images. They are encoded in such a way that enables browsers to display a progressively more precise image as it loads. This means that at first, the image appears blurry (or incomplete) but with full-dimensions, then it progressively gets sharper and better. It's well-suited for images meant to load slowly (or at least, images acknowledged to load slowly).
The best thing that you can do is try to shrink the file size to as small as possible. Let this be using some type of optimizer, smush.it for example. If you created the background image try saving it as progressive first, it loads a lower res version first then finishes loading. But the best thing is to try to shrink the size of the image width and height by finding a repeating pattern and cropping just that portion out and using it. Most about.me images are no larger than 100kb in size that are above 1200px wide.
you could immediatley call the image in the head by using
<script>
(new Image()).src = "IMAGE PATH";
</script>
and make sure you compress the image as much as you can with different programs, or if you have photoshop cs5 you can save it for a web device to strip out all of the extra junk, you can try yahoo's smush.it
http://www.smushit.com/ysmush.it/
or you could delay the loading of the site entirely for a few seconds, until you can be sure that the image is loading, you could try something like hiding all of the elements and fading them in upon a setTimeout something like
*CSS
body{
opacity:0;
}
*jQuery
setTimeout(function(){$('body').animate({opacity:'1'},300)},5000);
although that may not be all that practical.
Would loading the background image after the rest of the page has loaded work for you? At least this way visitors will be able to use the rest of your site until the 1.1MB has loaded.
Something along the lines of setting the style attribute of the <body> to be background: url(image.jpg) within an onload function?
Delivering the image over a CDN will likely speed things up; the better ones are usually optimized to deliver the proper TCP packet size/MTU to the wide variety of clients out there and have generally done a lot of work in the details of delivering things quickly. Slow connections like cellphones will still hate you for it, but getting things like packet size right can make the most of the bandwidth that is available.
I want to know when not to use CSS sprites. CSS sprites works great, but are there any occasions when they create a lot of headaches?
Like all things, there are times when it is useful, and there are times when it is harmful.
Many developers like to use CSS sprites because it saves on request time -- the browser makes one request, downloads the image, and all the various sprites are now automatically cached and blazing fast.
So how can it hurt?
Because download size != memory size.
That PNG or GIF that's only 10kb might actually be much, much greater in size once the browser loads it in memory. The issue is that while something like GIF will compress solid areas of color, the browser expands it out to a bitmap, where all images of equal dimensions use equal memory.
And it loads a new bitmap every time you use that image somewhere.
So everything in moderation.
See: http://blog.mozilla.com/webdev/2009/06/22/use-sprites-wisely/ for more info.
Maintainability of your site will suffer from using them. Only combine images that belong to the same logical unit and are unlikely to be updated separately. Keep images that are likely to change separate to begin with.
CSS sprites works bad for <input type="text"> where the user can enter more than fits in the box, as the background then scrolls in some versions of IE.
They also works bad if you want to repeat the pattern.
They can cause headache for your users if they want to download a particular image. First they won't get the "Save image as" option. If they figure out to use "View background image" they'll get a huge image with lots of other images on there too.
This is why sprites are best saved for "utility" (i.e. buttons) or design images.
We had a tough time when we wanted to position the image dynamically.
background-image: url(../images/a.gif);
background-repeat: no-repeat;
background-position: left bottom;
This is tricky (if not impossible) to do using a sprite.
Sprites should never be used when the size of images are very different.
Because in that case the size of sprite is quite huge.
Recently I converted 3.5MB pictures to a sprite, and size shooted up to 17MB!
Using larger pic might be a headache...
When pics are combined in smaller size, and neighbouring pics are just 1 or 2 px between each other, then CSS sprites can be a good solution.
In our case, http://www.nbhuntop.com, we just use it for menu components including: Home, About, Products. And all the pics are in gif format, and no one will download these pics at all.
Is the only benefit of using css image sprites that there is less http requests?
Or is there other benefits?
Also is there an easy way of detiming which area of a sprite to show?
Like you said, one of the main advantage is to reduce the number of requests to the server, improving the response time (especially if you're loading a large amount of small images). But this is not the only reasons people use sprites.
If you don't use sprites for a "mouse over" display, the user will see the image disappear for a second... and it looks really bad. This is because if you change the image instead of just moving the sprite around it will load a new image and the loading time can be visible to the end user.
.bad{
background:url(abc.jpg);
}
.bad:hover{
background:url(abcHover.jpg);
}
.good{
background:url(abc.jpg) 0px 0px;
}
.good:hover{
background-position:15px 0px;
}
Another advantage of sprites is that you can keep all your images in one location and in some cases it makes more sense (for menus and so on).
To determine which area of a sprite to show, just use photoshop or any other image editing software.
The primary benefit is your pages load faster, mainly because of reduced HTTP requests.
You could generate your sprite using a tool.
Disclaimer - I wrote this tool.
It is much easier to get image placement (especially next to text) the same cross-browser. You can adjust images up/down/left/right with out using vertical-align and padding.
I find it easier to keep track of all the images if they are in a single file. Especially since I usually have a transparent png images and and then use gif images for ie6. I save my png sprite map as a gif and add one line with background-image in my ie6 css and my images are switched.
I use photoshop or gimp to get approximate locations in the sprite map and then use firefox to fine-tune the placement.
Yes, there is another benefit. Every image file has his own headers, describing image type, colors etc. So when you combine images to a single sprite, you win some kb.
But as you said before, mostly you win by reducing HTTP requests count.
In terms of determining the area to show, I will typically place my elements on pixels that are multiples of 100. So if there's a sprite with a bunch of 64x64 pixel icons, I'll typically have them at (0, 100), (0, 200), (0, 300), etc.
This way, I don't have to type in an exact measurement (or any other developer for that matter) and save keystrokes when setting all my background-position properties.