I often get designs from our artists which contain large complicated images that can be turned into a background-color, some tiling, and overlaid smaller images. The problem is, doing this often takes quite a while and adds complexity to the html structure. How should I decide wether it is worth doing?

For example, the following is a button / mouseover:

Button MouseOver

All the buttons in an atlas take up a whopping 232kb*.

I can get this down to 40kb by using a background color and overlaying the following:

  • top gradient (horizontal)
  • bottom gradient (vertical)
  • text
  • photo
  • outline
  • glow for mouse over

But then instead of 1 html element the button would take up several. In addition, I would have to spend several more hours to cut everything out and do the html/css.

So, as a new web developer, are there any guidelines for when to split images up vs just using the whole thing? Based on size/difference, time taken, and additional DOM complexity added?

In this specific case, at least extracting the glow seems like an obvious decision, as it only adds one element and halves the number of images.

*I'm fairly new to web development from non-web programming and may be wrong, but 200+ kb seems massive for just some of the art assets.

3 Answers 3


I would ask the designer to work with you to rethink the button in terms of code rather than exportable graphics. It is absolutely worth the effort to make the button graphics lighter (in size). To your point, there is a lot more that will load on the page: the remainder of the graphics, CSS, HTML, javascript, and who knows what else. Why waste space because of a careless design process.

The gradients and background color could all be done in CSS, making the button lighter on load and easier to update. It also means you have one style that can be applied (with tweaks as necessary) across a range of buttons without consistency concerns.

At the most you have two graphics:

  1. The type and white line art (with a CSS color overlay on the latter prior to hover)
  2. The photographic trash can

You could slim that down by using live type for the labels.

  • Yeah, I meant splitting out css'able stuff as well, not just using images. So in regards to dom complexity, you are saying replacing an <img> tag with something like this jsfiddle.net/NrEXK is worth it, right? (markup only to show example complexity)
    – carpat
    Commented Feb 6, 2013 at 22:39
  • Also note that Fireworks will create the CSS for you and export it to a separate style sheet or copy it to clipboard. Commented Feb 12, 2013 at 2:37
  • @carpat Sorry, a little slow getting back to this one. You're HTML seems overly complex to me but at first glance it looks like it would still be faster than what you're designer submitted. I would trim it down to the trashcan and line art in one graphic. Then, as another poster noted, just use pseudo classes to handle the rest. You should be able to achieve the effect with a single gradient (multiple stops) that changes on hover. The type should be done with webfonts. Commented Feb 12, 2013 at 5:16
  • Just as a side note: CSS based gradients and box-shadows take quite a long time (in milliseconds :) to render. It's best to use them sparingly, not at all, and/or promote the elements in question to the GPU layer.
    – Dom
    Commented Apr 21, 2015 at 10:11
  • 1
    Gradients can be slow but typically no where near as slow as the server latency when calling images. I'd just limit them because the rarely add value (^_-) Commented Apr 21, 2015 at 15:50

Not sure I understand the issue.

... 23.6k using "high" jpg settings.


and using Sliding doors CSS......

jsFiddle demo

23k is certainly acceptable. It could probably be reduced further.

I realize that 10 buttons this size may total the 200k you mention. But without knowing the entire layout and site purpose it's difficult to determine if that's aceptable. For example, larger image downloads are more acceptable on e-commerce or entertainment-based sites.

  • 1
    Larger image downloads on my ecomm projects are less acceptable than any content site I've tackled. The trouble being peak traffic: You want to keep those servers happily chugging along accepting orders, not serving images. Of course, you also want to watch how many times you're talking to the server to request individual images. That's where base-64 embedded icons can really rock in your CSS. Commented Feb 6, 2013 at 0:32
  • it should be noted that base-64 encoding is about 1.33 times larger than the original binary data. (You are correct about lots of server requests for small files are slower than one large file because of request overhead.)
    – horatio
    Commented Feb 6, 2013 at 18:28
  • 2
    CSS sprites help eliminate the issue for many small http requests.
    – Scott
    Commented Feb 6, 2013 at 21:56

I think the example code in the jsfiddle above is overly complex in the HTML. Much of the effects that you're looking for can be achieved with class-based css on one element. This approach would allow you to use one (semantic) element and style it appropriately...

from what i can see, you could use one or maybe 2 elements with added css and css pseudo elements to acheieve almost the exact same thing.

see example i quickly created: http://codepen.io/peterSalvato/pen/kDvra

this is as close as i can get while at work w/o an image editor to create transparent images to place in the design. once you have transparent images to add to the button in place of the text (you'd place them in the css:pseudoElements where it says 'content'... here is some reading on pseudo elements: http://www.w3schools.com/css/css_pseudo_elements.asp

one added benefit of this approach is it allows the text in your button to be HTML text. This is good for both SEO and accessibility (screen readers and such)...

hope this helps.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.