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.
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.
My site have a big css sprite image.
Site: http://www.protohaber.com/demo
Sprite Image: http://www.protohaber.com/demo/templates/v1/images/proto_sprite.png
My site is works slow (e.g. page scrolling slow, etc..) at browser in some computers (low cpu computers)
Maybe you should try to use PNG Gauntlet to optimize the image.
Another Solution could be to split the Sprite into two or even more.
I think the principal reason for this is because the image is too big (almost 1.5 Megabytes), So just imagine how much the cpu have to calculate to move the background from one side to another. I think you sprite has a lot of resources which doesn't belong to it (like some images (the girl, caution alert, etc). Also you are mixing a lot of color at the same sprite which make the images bigger because has more colors to render.
I think one option is break apart the sprite into separate one which will make the file smaller (the slow processors can handle, render and move better small images), remove the images like (the girl, caution alert, etc) and make them jpg file which will make the file also smaller.
the idea of sprites is reduce the request to the server but if this reduce the performance of you application is best idea to make a couple of more request and have a better performance for the final user.
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.
"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.
I'm making a sprite and its reaching about 4000px in height. Is there a general size for maximum sprite height that is used within the graphics design community?
Browsers will have to decompress (and keep in memory) the whole image even if you only use very few sprites in it, and even if most of the image is blank/white.
For a desktop client you've only missed an occasion to be a good citizen by using too much memory (and browser are already sucking a lot of memory).
For some mobile client (eg. IPhone for files over 25k after degzipping), it can be more problematic, the image won't be cached at all, thus it may be better to have 2 files <25k and two HTTP request than one >25k file and a single request never cached.
Last problem, PNG compression is line-based, there is less overhead in having wide images than tall ones (though too wide could be theoretically bad in some case, since you can have only one prediction filter type per line).
Oh and also, with too much spriting, you may end with way too much different colors in the same image, and miss the opportunity for decent paletted image. Testing all combinations of this is tedious, but if you can, grouping your sprites by main colors of gradients is a good heuristic (since gradients/blur needs many different colors).
I don't think the focus should be on how big the sprite is physically (width x height) but rather how big the sprite file size is and ask yourself the question if it would be worth splitting the sprite into multiple sprites.
Quite often we split our sprites based on color so have sprites that are predominantly blue or red or yellow. That way we get smoother gradients and overall image quality while keeping image file sizes down