4 ms·

If you no longer support IE7, I think it's time to switch to data uris inlined in your stylesheets. It's easier to maintain, you don't have to care about image

• jaffathecake 14y ago
  Sprites often perform better than data uris. With data uris, you're putting the image data in your css file. This creates two performance differences to images. Firstly, the user will download the image data even if it isn't used on the page, an external image is only downloaded if it's element is present & visible. Secondly & more importantly, browsers completely block rendering while CSS downloads (with the exception of Opera, which unblocks after about 3 seconds), CSS does not render progressively. A 10k CSS file with 60k of imagery will load slower than a 70k CSS file due to HTTP overhead, although it'll be perceived faster as the user sees things happening after 10k rather than looking at a blank screen until the full 70k has downloaded. Small numbers, but noticeable on flakey wi-fi and mobile connections. In terms of image size, when you base64 encode an image you're using 8 bits of data to represent 6. Gzip deals with a lot of this, but it's still an extra ~10% per image. That's compared to separate images, with a sprite image you get further benefits by sharing a PNG palette and compression across all sprites. Neither sprites or data uris are the "correct solution" in all situations, it should be considered on a case by case basis. Sprite Cow itself uses both techniques, the toolbar icons are in a sprite, some smaller tiling assets are data uris.
  • giulianob 14y ago
    Also I'd imagine the client may download the image multiple times if it's used in multiple CSS rules. Caching can probably also be hindered since mobile devices have limits on the size of JS/CSS they will cache and stuffing images in CSS can create large files.
    • bryne 14y ago
      Gzip will take care of the duplication bloat issue. In general, this is a process best curated manually, with a maximum on converted file sizes and hand-picking images that are "must-haves" for the initial page load.
  • arcos 14y ago
    "Firstly, the user will download the image data even if it isn't used on the page, an external image is only downloaded if it's element is present & visible." If you are strategic and smart about when you include certain CSS rules, this is less of a problem. The images in these files should be user interface chrome shared by the majority of your app/site. Other inline images should be split across section-based CSS files (if your site is not a single page JS app). "Secondly & more importantly, browsers completely block rendering while CSS downloads (with the exception of Opera, which unblocks after about 3 seconds), CSS does not render progressively." Except with at 500k sprite file (very common) your user waits for UI elements to pop-in that depend on it. So yes it doesn't block, but the UI can look strange. You end up with a bunch of blank spots or incomplete backgrounds while this sucker loads. Also if you dynamically add elements to the page that make requests for uncached sprite images (because you are being smart and don't want a 500k sprite file) you have to wait for those UI elements to load in their images. With data-uris the image data is already there, ready to use. "Neither sprites or data uris are the "correct solution" in all situations, it should be considered on a case by case basis." Agreed, but I will typically bias myself toward data uris to avoid the extra network request(s) and the pain-in-the-ass maintenance of sprite files (especially when shared across a team). Really, what we should be doing is using fewer images in our UIs.
  • NikhilVerma 14y ago
    But if you separate the two CSS files. One only containing image sprite data uri's which is loaded AFTER the site's content you would not get such delays.