"Simple" question.
Is it better to use large spritesheets for site elements than using multiple images?
I mean,do the additional CSS image manipulation (background positioning a large image and cropping it) compensate for the fewer HTTP image requests?
The number of concurrent HTTP/1 connections to a host is limited to about 6. Assuming a latency of 100ms, the about 60 images in the posted sprite would take at least a whole second to download (probably more, since HTTP requests and answers need to be generated and parsed).
Since the size of the sprite image is about the same as the individual sprites and image processing is blazingly fast (I'd estimate well below <100 ms for all 60 images together), using sprites saves amazon about 900ms of load time, a noticeable impact - and that's in theory, without accounting for the huge overhead of having to serve 60x the number of requests they would have to otherwise.
In summary, use sprites for logos and small images over HTTP/1.
HTTP/2 is designed so that workarounds are no longer needed. Most importantly, multiple requests can be served concurrently over the same TCP connection. Additionally, header compression is designed to compress redundant headers such as User-Agent or Accept.
It is generally better to use sprites that many small images.
Every image creates additional http request and that needs time. Especially with HTTP 1.0 every new request need to wait for previous response.
As for very big pictures - it mostly depends on ratio of time needed to transfer one image of a set to the overhead in time coming from HTTP protocol. If the overhead is not big and you feel that such big images can slow down your app - you can use multiple images, if it's relevant - use css sprites.
Yes, for any reasonable image size, it will be faster.
Drawing part of a larger image is not slower than drawing a whole smaller image. It's not like the browser is drawing the whole image and removing parts that are not showing, it's only drawing the part of the image that is showing. It's just copying pixels from memory, and it matters very little if the pixels are close together in memory or spread apart in a larger image.
A larger image takes longer to load that a small image, so smaller images would start showing up faster, but the large image loads a lot faster than all the small images together. Even if you have to wait somewhat longer before the images start showing up, all images show up at once instead of popping up one at a time.
Sure, it is better. The browser will make only request for the file, compared to many request to more files.
Use sprites for many little images that tend to repeat in your design(icons for ex). For large photos it's not a good idea, in case of a photo gallery.
Related
I've read a lot about the benefits of using sprites in css for icons and logos, but this seems to be largely used for lossless formats such as gif and png. I'm wondering if the benefits are still there with jpegs and images? I want to build a header from a number of smaller pictures that may be displayed in different orders. Will combining them into a single jpg still have the speed benefits of the normal use cases for sprites?
It might depending how big those jpegs are. Usually images are combined to reduce http calls back to the server. If they are small in size then combine them, if not then leave them separate and call which ever ones you need.
The main benefit of using the sprites for multiple images is that it provides a smaller amount of header information being sent. Therefore having larger pictures inside of the sprite would have less of an overall impact on the whole project, there would be a small increase but the adaptability of the system is reduced using sprites. If the picture is going to be changed at any point i would keep it outside of the sprite.
You can reap the same benefits in terms of reduced round-trips, etc. but:
The level of compression is likely to suffer; JPEG is tuned to reduce the size of single images, and does poorly with abrupt transitions (as in a collage, which your meta-image would basically be)
For the same reason, it's possible that the edges of your sprite images will be less sharp than they are now, as they're being lossily compressed (and so slightly combined) along with adjacent image data.
Does anyone have any experience/information on how browsers handle really big images. We're using a series of large jpeg's to imitate video (don't ask why) and are wondering if there are any problems with combining them all into one large jpeg and using background positioning to advance the frames. If our images were small then this approach would probably be worth the effort due to fewer http requests and greater jpeg compression, but as the images are large (about 30kb each) and numerous (700 frames) it'd be good to knwo if there are any known issues with throwing such large images at a browsers.
30Kb is not that large, but you may have problems with outputting the amount of images you want to a browser if the images are on a remote server because the images may not refresh quickly enough.
JPEG has a maximum image size of 65535x65535 so you may have to arrange your frames in a square rather than a simple film strip, and you may still run out of space.
I have a web page that i'm working on and it has only one image on it that was meant for design. It is about 200k bytes. When you go to another page, depending on the page, its the same image just a different color.
Should i be loading these background images as one big sprite and positioning them correctly or loading them separately?
When A page loads it is only doing 1 http request for that one image of ~200k bytes. If i make a sprite with(it will be at least 5) all the images on it, it will for sure increase the size of that one http request.
So the only benefit then is a caching/storage benefit? Are there any other benefits or is it a bad idea? What are you thoughts?
If combining them makes it 400kb, it may be better to leave them separate - otherwise none of your icons will appear until the browser has downloaded your image.
I would try combined and as 2 requests, and measure performance.
In what scenarios CSS sprites would be good to use and when not? Is it time saver or only server request saver?
I think bandwidth use will be same because image is same like ong big image but it's in a parts?
When and where use of css sprite is a time saving(in work) option ?
For navigation it's good for rollover pre-loading effect but not good for images disabled people?
What are other good usage which can save our time once and in future (if changes comes in design) both?
Edit: Sprites is only for css background so should we use images in background as much as possible to save sever request, is it good idea?
Update:
To implement takes more time then regular method and mostly client do not much worry about some slowness like http request. My question is can we save time in site making process and future maintenance of website using css sprite. or regular method is enough.
In nutshell my question is: “can CSS sprites save our designer and xhtml css coder time (I'm not talking about server request)?”
It reduces the number of HTTP requests which will enhance site performance.
CSS Sprites are the preferred method
for reducing the number of image
requests. Combine your background
images into a single image and use the
CSS background-image and
background-position properties to
display the desired image segment.
In Minimize HTTP Requests
CSS sprites are a time saver because it is a server request saver, as server requests are notably time-consuming. Using CSS sprites usually decreases your webpages' load/render time dramatically. There are times when they cannot be used, such as with background images repeating in two dimensions, but when you can use them, it's almost always worth the effort.
Of course you shouldn't sprite groups of images that are very big, especially if they're not very likely to be shown. Don't sprite an entire photo gallery into one big image, for instance =)
Other measures which amount to pretty much the same thing would be minifying, compressing and combining your scripts and styles into only one js file and one css file.
EDIT
With regards to your clarification, i'd say no, CSS sprites will always mean more work, never less, compared to just using the separate images as they are. I still wholeheartedly endorse their use, tho =)
CSS sprites are best used for elements that have a fixed width and height. Otherwise, you need large empty spaces in your sprite image, which can (depending on file type) increase the size a bit.
Due to the way different file formats compress images, sometimes a CSS sprite image will have a noticeably smaller file size than the total file size of separate images. That’s a nice bonus.
As mentioned, sprites reduce the HTTP request overhead, which can help load time. I’ve never seen any numbers on the magnitude of this effect.
Sprites will add a bit of time for your CSS developers. It shouldn’t affect your designers. But bear in mind that your developers code the site up once; the benefits of sprites apply every time someone looks at the site.
It will only reduce the number of requests but that will benefit both the server and the client. The server will not need to handle as many requests. The client, because it is limited in the number of parallel requests that it can make, will render faster as many of it's previous "requests" for the image will be served from its cache, allowing it to make the requests that it does need more expediently.
Using sprites reduces the number of requests and thus also the network overhead. Loading a few sprite image is faster and uses less bandwidth even if the image data is the same (or even a bit more) than the individual images.
It needs a bit more work and some planning to combine the individual images into sprite collection images, so the development time is somewhat longer. The difference is less if you have it in the plan to start with rather than combining the separate images afterwards.
Any scenario where you have several same size background images that replace each other (or complement each other) is ideal for sprites.
As long as you have something like a dynamic photoshop PSD file in the back, then the designer's maintenance won't be an issue. But if it is a static file like PNG/GIF, then maintenance will take more time as you cannot control the individual images separately anymore.
Overall, sprites is a great idea. Use it for fixed width & height images that are less likely to be updated frequently.
Sprites are always good to use. They help speed up the loading of web pages and prevent the blinking effect on navigation hovering.
I want to know like converting an image (gif or jpeg) to png8 using yslow smushit will increase the speed of the site performance? Will that work in ie6?
It depends on the image. PNG is suited to images with blocks of color, whereas jpeg is good for photo type images. Smushit will shave off any extraneous bytes, reducing the filesize, but if you have many small images in separate files, then you should consider spriting them in order to reduce the number of connections required to load your page.
Reducing the filesize will help, but reducing the number of files helps the most (typically).
It will make it quicker to download. PNG (AFAIK) will always be a smaller file size than GIF because it uses a better compression algorithm. Although some programs like Photoshop add a little overhead with meta data. It's also lossless, meaning you won't lose any of the image's quality.
It will work in IE6 because it supports PNG8. PNGs with 24 bit alpha transparency are not supported in IE6. There is a hack, but it's not optimal, though it is better than nothing.
There are a lot of factors involved here:
the size in pixels of the image
the size in (mega)bytes of the image
the speed at which the image can be sent to the user. This is a combination of the speed of your server and the speed of the user's connection.
the time it takes the browser to read the image and convert it to a bitmap for display
the speed of the user's computer/graphics card combination.
I'm not sure that converting images to png is going to make that big a difference to your site's performance unless you know that the bottleneck is due to the size (in bytes) of your images. If the users have a slow connection then this isn't really going to help.
Your question is very vague. I'll try answering anyway.
First of all, performance has two ends: The viewer of your site and the machine(s) where it runs on. The viewer will definitely benefit from smaller (in regard to filesize) images since it allows the page to load faster. For the server, the difference is usually not important, unless you are close to peak bandwidth of the connection.
For (non-animated) GIF images a conversion to PNG8 should be painless and beneficial, as PNG compresses much better. Also Internet Explorer 6 doesn't exhibit problems displaying PNG images with a 1 bit alpha channel (which is essentially what GIF has, too). When using an 8 bit alpha channel IE6 will have display artifacts.
Converting JPEG images to PNG will almost certainly increase the file size and won't improve image quality, so I'd advise against it.