Let me start off by stating that I realize the arguments against doing CSS Sprites for large images. I even asked a question about why that could be considered a bad idea (and added an answer of my own). Now that we've had that talk...
I'm going to be making a large CSS Sprite-map. For the process of making this sprite-map, it behooves me to know what (if any) limit exists for the height and/or width of a sprite image in order for browsers to properly process it.
The ultimate reason behind this question is a debate over whether to lay out the sprite images in a grid or in a single row/column. For example: is it necessary or beneficial to do 4000 x 3000 instead of 400 x 30000?
Edit: The sticking point here isn't about what size images can be, but rather what size browsers can process for sprites. Given the lack of detail thus far, I'm moving forward with generating the single-large-column sprite. I'll post details of my experiences as an answer once that is complete.
Sometimes it's more of a matter of download time. Since browsers can use multiple connections to download files, a huge image can take longer to download than a few smaller ones.
If your image is so big that it's slowing down page load maybe it's time to consider several smaller sprite images.
Direct-X 9 has a size limit if 4096 pixels, so any Internet Explorer filters applied to these elements will crop them at 4096 pixels.
See: IE display transparency bug on height > 4096px?
In practice, this seems to work with no problems in Firefox 5+, Chrome, and IE7+ for a sprite image of 400x16560.
The potential issues of IE's directx rendering engine failing on images over 4096px do not create problems in IE7 or beyond; we have no method or need to test IE6 for our current project.
The one place that we experienced problems with really large spritemaps is on mobile platforms. Android devices handle them reasonably well, but iOS devices break down pretty badly, and in a strange way: They shrink the image down to fit within the dimensions they accept. So our CSS works perfectly for a small spritemap, but with no changes except increasing the physical dimensions of the spritemap image, the sprited images begin to show four times as much of the spritemap in the same html entity, with exactly the same CSS.
There is a limit in version 1.0 that is upgraded in v1.1 But still there is a limit for dimensions:
In accord with version 1.1, the scope of the 31-bit limit on chunk
lengths and image dimensions has been extended to apply to all
four-byte unsigned integers. The value -231 is not allowed in signed
integers.
Source
A funny limit is IE6.0 fails to display PNG images of 4097 or 4098 bytes in size!
But these limits are very huge in compare to what we're using in web pages.
Related
I'm really confused with this one as it seems impossible to do.
When running my site through GTMetrix I pass great but with Google page speed insights it's insisting my images can be optimized more for instance:
Compressing and resizing mysite.com/…ets/img/homepage/my_image.jpg could save 78.5KiB (94% reduction).
The image in question is 65KiB so how Google thinks I can shave another 78.5 off it I don't know.
I'm using jquery unveil and using the retina function on it too could that be the problem?
Also I've tried downloading the images Google provides as their compressed version but these images have had their dimensions changed so would look terrible if I put them at their intended size.
Really confused, any help would be appreciated.
Thanks
There are few things you need to distinguish before proceeding with optimizing images for Google Page Speed.
Images are optimized for different platforms (Desktop and Mobile)
Images are optimized for physical size.
Reports for images can be "Compressing and resizing" and "Compressing" only. Compressing means u need to do a compression part, on other hand compressing and resizing means you need to use appropriately sized image for appropriate platform.
Depending on the report you are looking at (desktop or mobile), your item "Compressing and resizing mysite.com/…ets/img/homepage/my_image.jpg could save 78.5KiB (94% reduction)." needs to be less in dimensions and compressed or just less in dimensions. Margin for resizing an image with CSS is around 20% so if you got 100x100px image you can resize it to around 120x120px with CSS without getting report on that item (that is if you also optimized it physically also). To check this in Chrome, inspect image and check "Natural" size in element selector.
You can deal with this on few ways:
Media Query (note that you have to use background image in this case)
Srssets
JS
Depending on the image compression package that you use, you might get different compression results. I've noticed that sometimes Google's Page Speed is able to optimise an image further than I have been able to (and other times not!)
Do you have a live URL for your web page? Or even the image? It helps to be able to see it live and compare!
I am looking to make a website dynamically scale its assets (png/jpg) and output the appropriate css for three sets of resolutions: 540p, 720p, 1080p
Currently we have assets created for each resolution, so thats 3 sets maintained manually, ideally I want a Jenkins/hudson job to create the assets (by scaling from the highest resolution asset set, maybe use imagemagick commandline) and then generate CSS to make the resolution layout possible.
This is clearly not an old or unique problem, I am wondering what is the best approach to take for this?
The webpage is intended for low computing power embedded devices, which have limited capability, albeit HTML5 supporting. The solution has to be a server side creation of assets and CSS scaling as we cannot rely on the devices to be able to cope with much scaling.
Look forward to your thoughts and replies.
Cheers in advance.
Not a real solution, but rather a work-around which is working well and is easier to maintain:
Replace PNGs with SGVs. Take the highest resolution version and use something like http://vectormagic.com.
For JPGs take the highest resolution version, but compress it heavily and use something like ImageOptim. This works well for:
Browsers are nowadays very good at resizing higher resolution images to smaller ones.
Since the pixel density is so high if you are using the full size, the compression (artifacts) will be much less visible. And if your browser is scaling down, artifacts will be less visible because of the smoothing your browser applies.
File sizes will be bigger, but not much, since you can use a higher compression and it's getting more efficient with the image's size.
Reference: http://www.fngtps.com/2012/reasonable-ways-to-use-high-resolution-images-on-retina-displays/
I have recently begun using image sprites and they are definately great for reducing http requests. Is there a point where it becomes bad practice?
Im thinking particularly where a lot of extra markup has to be added to support them. For example, using them for list bullet points, I have to add two or three extra spans to get everything alligned etc.
Theres also the annoying point that you cant use repeating images, so therfore there is always the toss up between one large image as part of sprite or a tiny 1 pixel image used for repeating downloaded on its own.
Im really looking for an opinion on the two situations outlined here + any other general considerations/guidelines for using sprites.
They can often cause performance issues on mobile devices. I'm not 100% certain why (never really dived into the problem), but I'm assuming it's because the mobile webkit is loading a new copy of a relatively large image into memory for every instance of it on the page. Since mobile devices often have very small amounts of RAM, it can quickly cause the page to slow down.
I've run into this issue before when having about 300 "icon" sprites on a page at one time, each pulling from a sprite image that contained about 50 different icons. Going back to "normal" methods of one icon per image (or 2-3 for hover states) solved performance issues on this particular page.
Also, many browsers (mobile and otherwise) will often not 100% respect the clipping of sprites when you slightly resize the page content (e.g. using "Zoom In/Out" on the browser itself). You'll often see little pieces of the sprite next to the one you want to use.
As for your bullet example, you shouldn't ever need more than one extra div/span. You would set a margin-left on the li and position your "bullet div" in the empty space it creates.
That being said, I use sprites all the time because they're convenient, just be aware of a few issues with them. Generally, I have sprites.png, sprites_h.png and sprites_v.png for horizontally and vertically repeating pieces.
Write two simple test pages, use sprites on one, and not on the other. Use a tool like http://www.webpagetest.org/ to measure the performance in a few different browsers. Once you have data, you can make decisions.
I would divide sprites by related elements, like navigation and content-related sprites, so you can benefit from sprites and keep a logical order in your code. Don't forget that readable and understandable code should be a priority (particularly with CSS, it can get very messy) unless you're working on a Google-scale project.
It's often stated that when tiling the background of a web page with background-image, that performance is better with an image of larger dimensions due to it needing to be tiled less frequently. For a while I've been making them 8x8 px, or multiples of 8.
But does anyone have links to data that prove this is the case across a range of browsers, taking in rendering times, or CPU load at various points of page rendering?
I'd imagine it matters very little in these modern browsers you listed in your comment:
IE 8/9, and latest versions of
Firefox/Safari/Chome/Opera
However, I have heard of a bug in IE8 when it comes to an image of exactly the size 1px * 1px:
Internet Explorer 8 doesn't perform
the repeat of a 1x1 pixel
semi-transparent background image
correctly when any other element on
the page is using the "-ms-filter"
drective for the alpha transparency:
-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";
See: http://nemesisdesign.net/blog/coding/ie8-1x1px-semi-transparent-background-bug/
and the demo: http://static.nemesisdesign.net/demos/ie9-1x1px-semi-transparent-background/
So, 8x8 seems like a good enough size to use. I'd be surprised if anyone on the Internets has cared enough about this to rigorously benchmark it.
I did find this, which discusses the subject:
http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html
Make sure to also read the comments.
To sum it up, I'm going to quote myself from months ago:
I'd imagine it matters very little in [the] modern browsers [IE 8/9, and latest versions of Firefox/Safari/Chome/Opera] you listed
in your comment.
In some email clients the image won't repeat unless the background image is at least 25X25 so I've settled on that as my default size.
I don't think there is an "optimum size," but the general opinion is that larger dimensions are better than small: see this question, and this one too.
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