1. Font Icons

This is the best solution but at the same time the most difficult to implement because our icons are custom.

Why use font icons?

  • Scale easily
  • Change color easily
  • Include shadows easily
  • Have good browser support in general
  • Can be styled on the fly (by making changes on :hover, etc.)
  • Can do anything image icons can do (change opacity, rotate, etc.)
  • Have smaller file sizes since they contain fewer characters than full typeface.

I would suggest instead use our custom icons for the headers etc (static-pages), use similar ones from font-awesome (part of bootstrap and we are already using them on athena-client for the info i).

If there is not enough icons in font awesome, we can create our own custom fonts with only the icons we need, and download them from the different webs of font icons there is in the internet (pretty awesome and optimized).

We can use this app for that: https://icomoon.io/app/#/select

Summarizing:

  • Pros: Fastest, best quality resizing (based on vectors), only one http request.
  • Cons: Difficult to customize with our own icons (there is apps to create icon fonts but I think is not something easy and fast).

Side documentation: https://www.youtube.com/watch?v=Md5LNfZ356A // How to use custom icon-fonts

2. SVG images

Very similar to the previous one (based on vectors), but the compatibility cross-browser is not that good. http://caniuse.com/#search=svg

  • Pros: scalable, 0 http requests/
  • Cons: Designers have to be able to generate them, not compatible with ie8, bigger dom elements.

Side documentation: http://css-tricks.com/using-svg/

3. Data-uri (base-64 encode)

Images encoded on Base-64 and linked on the css.

-Pros: Combining multiple image loading requests into one request of CSS file; easy updates of generated file.

  • Cons: The biggest con is the missing support in IE6/7, and the incomplete support in IE8 (data: URIs must not be larger than 32 kilobytes there).

base64 encoding makes file sizes roughly 25% larger than their original binary representations, which means more data down the wire (this might be exceptionally painful on mobile networks);

Retina -> if we create 2 CSS Sprites (for retina and common) browser will download those one that it will use. In Base64 way we will have to encode all graphics and there will be 2 files that will upload automatically in both ways - while using retina device or common.

They scale as images (bad).

Side documentation: http://en.wikipedia.org/wiki/Data_URI_scheme#Advantages

How to convert images to base64: http://webcodertools.com/imagetobase64converter

base64 vs Sprites: http://tjrus.com/blog/base64-vs-css-sprites-battle-for-performance

4. Sprites

We can have 2 sprites (1 for retina and 1 for regular displays) and compress them at maximum. With css mediaqueries we can serve one or the other depending on the display pixel density.

  • Pros: Easy to generate the sprite, only one http request (worst case scenario 2), easy to manage from css.
  • Cons: Don't scale as well as fonts, cant change the image color via css and all the problems related with bitmap images.

Side documentation: http://egorkhmelev.github.io/retina/

http://css-tricks.com/snippets/css/retina-display-media-query/

http://www.sitepoint.com/css-techniques-for-retina-displays/

http://www.andreasnorman.com/how-to-easily-create-image-sprites-for-retina-displays/


1,431 0 1