homepage Welcome to WebmasterWorld Guest from 54.205.122.62
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor 2014
Home / Forums Index / Code, Content, and Presentation / CSS
Forum Library, Charter, Moderators: not2easy

CSS Forum

    
CSS + Data URIs = Fewer HTTP Requests
page loading speed tip
SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 12:52 am on Nov 26, 2009 (gmt 0)

This won't be too technical, I'm hoping some of you more technical people will come in to my rescue should I fail to explain something properly!

We all know, that Page Speed is a hot topic right now, and that one of the best things you can do times is to reduce the number of HTTP requests to the server [developer.yahoo.com], Yahoo's #1 rule.

One of the most well known area that CSS can help in this is for people to join their background images together to form CSS Sprites [css-tricks.com]. This works well for those icons and smaller type images, it also works well for multi state image rollovers for menus.

There is another, possibly better, way which will reduce the number of requests dramatically, perhaps even to 1 depending on if you need the images cached for tracking or not. The technique works with both inline and background images, although it gets a bit technical and benefits from some programming knowledge if you want to cover all your inline images, however I'm just going to hope fully explain how to get them in your CSS.

Check out this page [tanfa.co.uk] with Y!Slow or your favourite HTTP request indicator.

10 images on the page = 1 x HTTP request and that 1 is for the page itself

5 of the images are CSS backgrounds and 5 are inline. They are ALL there courtesy of the Data URI Scheme [en.wikipedia.org]

What's that?
Well that's where I'll need help, but it basically takes data, in this case an image, and encodes it into a long text string of seemingly random characters, that the browsers will convert back into the actual data VIA the URI.

the URI format is something like this:
<img src="data:image/jpeg;base64,/9j/4AAQ....">
  • data = name of the scheme
  • image/jpeg = content type
  • base64 = the type of encoding used to encode the data
  • ,/9j/4AAQ.. = the encoded data string

There are online converters out there Example [dopiaza.org] or you can code your own if you're able to whip up a PHP page, code is also available online.

The encoded string itself can get very long, typically it can be up to a third bigger than the image itself, but then the text files can be compressed, usually taking the amalgamated file size back to around the size they were + what the images started at (so still optimise the images first!) So the file sizes may not in theory change, but your pages should load a lot faster due to less requests to the server.

Caching
I've come across very little regarding this and would love to know more as I do not yet fully understand it with regards using this technique. As far as I can tell the data URIs themselves are not cached, but the CSS files and/or the text file can be, so although the images themselves may perceptively appear to be slower, or more likely they will all "pop in" together the page content should render a lot quicker. Anyway I think that's the jist.. please do correct me if I'm wrong on that.

OK to the CSS!
It's simple for most browsers. In the above example where I show part of an inline image Data URI, you simply use that same URI as if it were your background image URL. Because of the lengths of the strings it would of course be advantageous to only have one background image assigned to multiple selectors, if they are to be used many times, instead of repeating the rule.

e.g.
h1, h2 {
background: #fff url(
data:image/png;base64,
iVBORw0KGgoAAAANSUhEUgAAAG0AAAA4CAMAAAG3Yra2AAAAwFBMVEUSEhJtb26Pj8np4L1MSk
CSrnKytq3W3bfs02/Cgmn07dPByq28fmKrs4qYonswLy3M3NeEfVvSs5bSzLOnhW7c3df79uqw
..snipped..
AAAAAElFTkSuQmCC) no-repeat 0% 0%;

You would use the background colour, repeat and position as normal.

BUT!
It would be a perfect world if all browsers supported this format, but, you probably knew that was coming right.. and you can probably even guess what's coming next.. IE7 and below don't like it! Apparently this has held back wider scale adoption, However there is a way, Microsoft have their own MHTML format [en.wikipedia.org], I'm not going there either, just gonna try to explain how to use it in this context.

Apparently IE7 Vista (or all Vista?) will only accept these strings if presented via a text/plain file so for all IE we can make up a simple plain text file containing all the data images and refer to that from our CSS file just as if it were an image. (If it weren't for Vista you could embed this information straight into your ie.css)

Here's the format that the text file must take, line spaces (not linebreaks) and double quotes are important.

/*
Content-Type: multipart/related; boundary="NEXT_IMAGE"

--NEXT_IMAGE
Content-Location:h1logo
Content-Transfer-Encoding:base64

iVBORw0KGgoAAAANSUhEUgAAAG0AAAA4CAMAAAG3Y
ra2AAAAwFBMVEUSEhJtb26Pj8np4L1MSkCSrnKytq3
W3bfs02/Cgmn07dPByq28fmKrs4qYonswLy3M3NeE
...snipped again.....
AEo/siV9WDw17+c/HPW/nH5F98ljJ1eS8NXAAAAAEC

Content-Type: multipart/related; boundary="NEXT_IMAGE"

--NEXT_IMAGE
Content-Location:h2logo
Content-Transfer-Encoding:base64

string in here......

*/


My Bold..
the first bolded words "NEXT_IMAGE" can be any string you like, as long as you use it constantly, it's your image 'files' separator

The second bolded part "h1logo" will be different for each image, it's the identifier you will use to get them from this file.

The URI string in both cases, the normal CSS and this text file, can have whitespace (linebreaks) in it for readability, but I'd suggest not to bother as the idea is to minimise the whitespace in all files too and who wants to read them :)

OK so put all your image strings into a that file too and give them all an identifier, then save the file as anything you like. e.g. ie7css.txt. To use it, the file must reside on a server and be referred to via an absolute URL. (localhost will do for testing)

Then in your ie.css file (via a conditional fed to <IE8) you add the CSS like this, remember you only need the background-image this time as IE<8 will still pick up the positioning and other properties from the main .css file, cascade works as normal.

h1 {background-image: url(mhtml:http://localhost/data-uri/ie7css.txt!h1logo);}
h2 {background-image: url(mhtml:http://localhost/data-uri/ie7css.txt!h2logo);}

I've referred to two images here, but only one in the first file, this is just for example to show the identifiers at work if you are using different images.

It's still the same familiar CSS format it's just the URL which is slightly different, and should be obvious;
mhtml:
http://your/absolute/path/to/savedfile.txt
!
image identifier from the text file

We're already used to making a separate file for IE so this to me anyway doesn't seem that cumbersome, in fact the IE text file would almost be like a database of your images, and overall this format is a lot easier to manage than a complex sprite.

I hear tell it's handy for image thumbnails, like in galleries, and I am going to try a test on one or two of the zen garden sites to see if the background image heavy sites will benefit lots, and I've got an image gallery to build for a site so if I can't see any negatives I might give it a whirl on there.

Anyway, do let me know if you use it already, how it's going, any pitfalls, thoughts and additions are extremely welcome in this case as I would hate to be misinforming.

edit reason: updated broken link

[edited by: SuzyUK at 3:23 pm (utc) on Dec. 6, 2009]

 

swa66

WebmasterWorld Senior Member swa66 us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 4:24 am on Nov 26, 2009 (gmt 0)

Very interesting!

Since you have to feed legacy IE versions something else: why not give them the normal images and leave the performance improvement for those with a modern browser (they need to have some incentive to eventually upgrade ...)

To create base64 encoded date: I'd suggest to use openssl:
To encode:
$ openssl base64 -e <image.png >image.png.base64
To decode:
$ openssl base64 -d <image.png.base64 >image.png

I'm sure it can be done in perl etc just as well.

jameshopkins

5+ Year Member



 
Msg#: 4031959 posted 1:16 pm on Nov 26, 2009 (gmt 0)

Some things to remember before using Data URIs widely. base64 encoding incurs some client processing overhead, and it also uses more bytes than a comparative binary image, although the size can be reduced if the data is optimized correctly - another option would be for the HTTP server to compress the response using HTTP's Content-Encoding header, although the effects are fairly negligible.

As you correctly point out, Data URIs aren't cached like their binary counterparts, so the data will be re-loaded everytime the cache is cleared when their containing document is re-downloaded.

It's worth noting that IE8 only supports Data URIs incorporating up to 32,768 characters (32kb). The application of Data URIs in IE8 is also restricted to, the INPUT element ('type=image' only), the deprecated LINK attribute, the OBJECT element (images only, the IMG element, and "CSS declarations that accept a URL" ('background', 'background-image', etc).

Alcoholico

5+ Year Member



 
Msg#: 4031959 posted 6:23 pm on Nov 26, 2009 (gmt 0)

Simply awesome, for years I've wanted to use the Data URI Scheme, never been able to, due to the lack of IE support, IMHO at this point as important as CSS3 or HTML5 support (or more), off to give it a new try. Thank you.

SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 7:55 pm on Nov 26, 2009 (gmt 0)

Swa, you lost me with that code! where, how, when, why would you use it?

>>Legacy Versions,
Yes you could do that - but then you'd still have to upload images to the server then, and this method, if you encode first, also has the advantage of cleaning out some server disk space, or reducing some Server Side processing which may be an advantage for some sites, and not just their IE users? I'm almost wishing that other browsers did it the same way as MS :o then only one separate "database" would be needed and would keep the css cleaner.. ouch did I say that :)

I agree anything that encourages faster upgrades is nice, in practice it's not gonna get them all to 8 overnight is it, and this one's not just for them.

The main advantage of this that I see from the CSS side is a 'set and forget' file with very minimal server side processing. If it's for inline images though, which are being encoded server side (PHP, Perl etc..). Then yes sure why not feed them the slower ones, why go the bother of extra IE coding if the image is already there :)

@james thanks, I missed the IE8 size limit on the Data URI's - so am I right in thinking that if the average increase from the original image data you might convert is @33%, Original images should be no more than 20Kb, possibly slightly less. What about if using compression should the 32KB limit be the before or after compression? (I mean hopefully most background design images should never even be close to that limit but it would be good to know)

Also can anyone out there give a step by step, or pointers to how/if to set future expiry date for these files?

Seb7

5+ Year Member



 
Msg#: 4031959 posted 8:19 pm on Nov 26, 2009 (gmt 0)

nice post, didnt know you could embed an image like that.

I think 95% of websites can easily speed up their pages by first doing some simple tasks like removing the excessive spaces, tabs and line breaks.

And I never understood the multiple style files and javascript files. Maybe one global, one local to the page at the most.

The main offenders seems to be the applications that the HTML was created from (which is why all my websites have been created in notepad! - fully optimised and no technical or design restrictions.).

swa66

WebmasterWorld Senior Member swa66 us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 8:26 pm on Nov 26, 2009 (gmt 0)

Swa, you lost me with that code! where, how, when, why would you use it?

Sorry 'bout that: I should have been more clear.

It were (unix) command lines to create base64 encoded files (which you can then include in the CSS itself) from a regular image (or back if you want to see it ;) ).

Using the IE trickery: I see little advantage over a CSS sprite (except where sprites would be rather unhandy) It'll still get that extra hit, and has the drawback of the overhead of the base64 encoding. Seems to me it's the worst possible choice.

[edited by: swa66 at 9:47 pm (utc) on Nov. 26, 2009]

Alcoholico

5+ Year Member



 
Msg#: 4031959 posted 8:43 pm on Nov 26, 2009 (gmt 0)

There are drawbacks, for instance, this should not be done with a reusable image (not css), as for expiry dates, it may be done via custom headers; smthing like (php):

$browser_cache = 60*60; #seconds
header('Expires: '.gmdate('D, d M Y H:i:s', time() + abs($browser_cache)) . ' GMT');
header('Cache-Control: max-age='.abs($browser_cache).', must-revalidate');

Of course, that'd be for the entire document, not just the embedded images.
I have just tested and noticed that the total bytes transfered increase after compressing by about 30%, nonetheless it's just one server hit, it'd be interesting to test it on a production high traffic server to see how server load behaves.

jameshopkins

5+ Year Member



 
Msg#: 4031959 posted 9:32 pm on Nov 26, 2009 (gmt 0)

so am I right in thinking that if the average increase from the original image data you might convert is @33%

Around that figure, yes.

What about if using compression should the 32KB limit be the before or after compression?

I assume the documentation relates to the final, compressed size.

Also can anyone out there give a step by step, or pointers to how/if to set future expiry date for these files?

As I mentioned in my original post, the data within the URI can't itself be cached, however, the document containing the Data URI can. I'm unsure why you'd want to explicitly set a cache expiry in the first place?

And I never understood the multiple style files and javascript files. Maybe one global, one local to the page at the most.

Extremely inefficient from a development and maintenance point of view.

g1smd

WebmasterWorld Senior Member g1smd us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 11:19 pm on Nov 26, 2009 (gmt 0)

Embedding the data at the top of the HTML page will surely delay the textual HTML content showing up by some extra time?

That is, when a page has separate HTML and image files, the text may be rendered on screen before the images have finished loading.

SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 11:26 pm on Nov 26, 2009 (gmt 0)

intersting Alcoholico, thanks for sharing!

Spell it out for me @james.. I'm aware that you cannot cache the Data URI's themselves, but from what I understand the benefits of using them with CSS is that the CSS file itself is cached, would the extra text file also be automatically cached or would it require some headers added?

This "CSS caching" would obviously not apply to inline images where the choice for their replacement will be two pronged and very much site dependant

Quote from Yahoo's best practices ref: HTTP requests
Inline images: use the data: URL scheme to embed the image data in the actual page. This can increase the size of your HTML document. Combining inline images into your (cached) stylesheets is a way to reduce HTTP requests and avoid increasing the size of your pages. Inline images are not yet supported across all major browsers.

That quote is centered on inline images, from what I read into that it's that individuals would need to weigh up their costs of the amount over the wire for an increased size single HTML Page HTTP request - versus each individual image HTTP request. Because in this case the inline image data would be in the HTML page (btw the very first example page I linked to is all in the page, so it's not even relying on a CSS cache, although that wasn't the point of the demo page, it was the how rather the why ;))

Some pretty charts to illustrate [yuiblog.com] why Yahoo place so much importance on HTTP requests.

But (my bold) they are even suggesting moving the inline images into the CSS, for even better results. They are saying that the Data URI's in the cached stylesheet will give a better performance, simply because it reduces the number of HTTP requests regardless of the increase in its (the CSS) filesize. So 1 large CSS file is better than (n) of on page image HTTP requests?

I'm sure there's a happy medium somewhere in all this, some testing is in order :)

vincevincevince

WebmasterWorld Senior Member vincevincevince us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 4:06 am on Nov 27, 2009 (gmt 0)

Great post;

My own solution is to parse the CSS and indeed HTML files with PHP before releasing them, replacing the data URIs with server calls (basically to a script which does a base64_decode and spits back the same data), just for incompatible browsers.

This avoids having to maintain two versions, but obviously has a speed implication of its own.

Seb7

5+ Year Member



 
Msg#: 4031959 posted 12:16 pm on Nov 27, 2009 (gmt 0)

flushing your page just before any heavy server side script can also make a big difference to page loading times:
eg.
<?php flush(); ?>
<% response.flush %>

SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 12:23 pm on Nov 27, 2009 (gmt 0)

Initial tests are very interesting!

though on a small scale with CSS Zen garden design so not exactly media heavy, I'm just testing the CSS background theory.

I'll finish up today a put all results I have here, but meantime;

First go over. i.e. no change to the page, 18 background images not "sprited" or optimised (though they're not bad)
the most startling result is that after I replaced the 18 background images with DATA URIs the CSS file became 104.3K from the initial 6.8K

HOWEVER even @ 104K over 7K it loads quicker! This does seem to confirm the information that one big stylesheet is better than multiple small ones. The response time for the entire page is reducing from around 2.6-2.8s to 1.5s
Total page weight has increased from 112.3K to 117.6K

Yahoos page "score" has gone from 74(C) to 95(A) on a non-gzipped server (though I'm going to run tests on gzip too)

The score is affected in more ways than just the HTTP requests too, i.e. the CDN grading from F to A, Expires headers from F to B , Entity tags from F to B.

@g1smd, the data is still external and CSS backgrounds as far as I know always load last even when external, so the page content still does render instantly

pageoneresults

WebmasterWorld Senior Member pageoneresults us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 4:36 pm on Nov 27, 2009 (gmt 0)

Check out this page with Y!Slow or your favourite HTTP request indicator.

I did! 167,498 UTF-8 characters in the source.

I thought we were doing just fine with the various basic methods being used. That stuff above went right over this fella's head. Seriously. Has design become that high tech? Do I need to start learning ALL of that? Help a guy out here, that's a lot of information to assimilate.

I think 95% of websites can easily speed up their pages by first doing some simple tasks like removing the excessive spaces, tabs and line breaks.

Ain't that the truth! Before ANYONE touches the above, you should first address the basics.

This won't be too technical...

Speak for yourselves! :)

ChanandlerBong

5+ Year Member



 
Msg#: 4031959 posted 4:57 pm on Nov 27, 2009 (gmt 0)

wow, we've got back to 1998, but this time, you need 6 tech manuals open by your desk to understand it all.

K.I.S.S never stopped being correct.

SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 5:49 pm on Nov 27, 2009 (gmt 0)

Ok, here's what I have, Gzipping doesn't make too much of a performace enhancement speed wise, but earns the Google and Yahoo tools' gold stars

I'm not gonna list the gzip facts and figues as the response times, perceived response, and grades did not differ

Perceived response is my own

Haven't listed all the image response times, but they range from 473ms to 1500ms. Intersting points I noted, the smaller images had the slowest response times, they appear to choke to response time and that's were the overall time delay appears to be. That would appear to suggest the usefulness of spriteing the smaller images, however although I only sprited the smaller one, see what you think about the results. The sprite itself was/would be a maintenance bugbear, it took me longer to set up and calculate the CSS positioning, that the Data URI replacements took.

1. Original Page, just moved to my server to get same benchmark
Score 74
Grade C
CDN: F
Expires Headers: F
Gzip: C
Etags: F

HTTP Requests: 20
HTML: 13.3K
CSS: 6.8K
Images: 92.2K
Total Weight: 112.3K

(response times)
HTML: 889ms
CSS: 553ms
Images: 2.59s

Total Time: 4.1s
after caching: 2.8s

Perceived Response, content instant, Flash of background until images came in, after caching, all instant

2. Same page with CSS amended accordingly, using a Sprite for some of the images
Score 76
Grade C
CDN: F
Expires Headers: F
Gzip: C
Etags: F

HTTP Requests: 12
HTML: 13.3K
CSS: 6.7K
Images: 66.0K
Total Weight: 86.1K

(response times)
HTML: 722ms
CSS: 800ms
Images: 1.95s

Total Time: 3.53s
after caching: 2.2s

Perceived Response, content instant, Flash of background until images came in, after caching, all instant

3. Same as #1 page with CSS images replaced with Data URIs
Score 95
Grade A
CDN: A
Expires Headers: B
Gzip: C
Etags: B

HTTP Requests: 2
HTML: 13.3K
CSS: 104.3K
Images: 0K
Total Weight: 117.6K

(response times)
HTML: 618ms
CSS: 900ms
Images: 0

Total Time: 1.54s
after caching: 1.2s

Perceived Response, content & background instant, no flicker/flash.

all tests ran 3 times earlier today and then 3 times later in the day, average taken.

Gzipping really didn't affect response times that much and where it did so, the data content fared better. It only really served to get the Gzip grade up to an A from the C that's showing.

what do you think?

SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 5:52 pm on Nov 27, 2009 (gmt 0)

p1r, this isn't a design thing ;) but a Page Speed Tip (see title) apparently page speed is becoming important to all, even SEO's so this is just an exercise to see how interesting it could be if designers and developers speak to each other no?

pageoneresults

WebmasterWorld Senior Member pageoneresults us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 6:16 pm on Nov 27, 2009 (gmt 0)

p1r, this isn't a design thing wink but a Page Speed Tip.

Oh, I'm following along. But, we're in the CSS Forum, for me, that's design. :)

I'm reading, searching. Reading, searching. There's a bit of information to take in. I just don't see where this would be applicable for most of us. I like the idea of discussing it but what I see above would require someone highly specialized in their skillset. I mean, those look like surgical procedures up there. Whatever happened to optimizing an image in Fireworks, uploading it and serving it just as it is? I'm not understanding the micro breakdown and technical implementation to achieve that extra byte or two of savings. I could see Google or any other top visited property doing this or something similar, but the rest of us?

I'm still confused about the first example. When I view the source of that page, the first thing "I" would think is well, I don't know. I'd be confused. I am confused. ;)

swa66

WebmasterWorld Senior Member swa66 us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 6:58 pm on Nov 27, 2009 (gmt 0)

Think it's important to see where this comes from:

embedding an image inside the html has a big problem in that it makes it impossible to cache the image for use on other pages (it's part of the prior html, not an image with it's own URL anymore)

External CSS is cached between pages. Having the option of embedding background images inside the CSS is far more interesting.

CSS has a competing strategy to do the opposite of what slicing images used to to. CSS sprites is a way to merge images together (even if they are unrelated) into one image and then use CSS backgrounds and position the one image where you need it.

It's interesting to see this embedded technique is apparently efficient in (some?) browsers and as such an option to get a faster site.

I feel like it wold be most beneficial for small images where sprites can't be used easily (e.g. as repeating backgrounds to get gradients and the like).

Time to experiment a bit ...

SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 7:33 pm on Nov 27, 2009 (gmt 0)

lol P1r, get out of the dark ages would you! :)

CSS isn't all about design you know, it's a skillset as you say and it offers more than one way to put a page together, there are like any of the programming language or markup languages, efficient and not so efficient ways to apply it.

As for optimising images, agreed a good first step and should also be done before attempting to encode them too for best results any way. The images I started were already optimised as best they could be/

Sprites:
I was really surprised that the Sprite version didn't perform at least half way in between the other two.. all logic told me that joining all the small images should free up the bottleneck at the server, it did but not as much as I thought. & Also a bit of an eye opener.. It only took one image (a header jpg) (24K) to cause a download flicker on both the image version.

The large image would be a design "thing", but it's a fact the interweb has got much more media heavy and I don't think that's going anywhere, so this is just another useful tool in the box perhaps?

SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 8:23 pm on Nov 27, 2009 (gmt 0)

.. sorry for replying again, I missed a bit you wrote, my multitasking isn't up to par tonight ;) loving the ideas coming out in this thread

I'm not understanding the micro breakdown and technical implementation to achieve that extra byte or two of savings.

That's the surprising thing about all this, it doesn't save bytes, it actually increases them, however the server side apparently is able to handle it better, thus decreasing clients page load time. It's about taking a look outside your box IMHO (I did)

>>confused by source code
that example has the CSS inline as well, I presume just for demonstration purposes, but imagine for the paranoid among you who don't want your source or CSS file pinched.. fill it with those Data URI thingies and who'll want to read it ;)

It really is no more than replacing your regular background image URL with a pasted URI string, (and either using the MHTML method or the original images for IE<8 in an IE conditional CSS file) not exactly rocket science, though it does look a bit scary, it's just copy/pasting - but P1R, if'n your reading & reading I imagine you'll be able to share much more with us than I could take in from the more technical side..

Swa, looking forward to results of your experiments too my tests were really basic, I went at them from a user POV, of both CSS and viewing web pages. are you going to test them v sprites too? I can't quite believe the results and would like some confirmation - either way it's almost another way developers can help separate design from content?

I think these DATA URI's have and are mainly used in applications, I've used them previous in custom stylesheets, but didn't think about in the real world, it's all good fun!

[edited by: SuzyUK at 12:11 am (utc) on Nov. 28, 2009]

httpwebwitch

WebmasterWorld Administrator httpwebwitch us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 8:50 pm on Nov 27, 2009 (gmt 0)

I like this immensely for its kewl factor.

I'm concerned about not employing browser caching for images reused on many pages - I'd likely still use an external JPG/GIF/PNG file for those. Sprites still rock for multipurpose interface elements.

I'd totally use this technique for images that are only used on one page, like "leaf node" pages and product detail pages.

I look forward to the decade when all browsers support this. I hope it happens within my lifetime.

SuzyUK

WebmasterWorld Senior Member suzyuk us a WebmasterWorld Top Contributor of All Time 10+ Year Member



 
Msg#: 4031959 posted 11:04 pm on Nov 27, 2009 (gmt 0)

I'm concerned about not employing browser caching for images reused on many pages - I'd likely still use an external JPG/GIF/PNG file for those. Sprites still rock for multipurpose interface elements.

if I may ask, why do you need them inline images cached? (especially if they're just a pretty below the fold, or on an internal page) To me as long as you have the dimensions of them in the HTML (HTML 101), then they will not impede your page content load, and they will appear.. if it's alt text (attribute!) you're after, a transparency gif over a background image will have the same effect as well as making it that little bit more difficult for your image to be pinched (not impossible), as well as being able to take advantage of CSS Caching - CSS classes are your friend if you're talking about re-usability, is it just that the actual image gives you something "physical or tangible"? rather than thinking about it "data" sense?

.. as for the "in my lifetime", it's here, it's possible, if you don't use it to your advantage, someone else will use it to theirs ;) (I'm a CSS'er I know that phrase only too well! hehe)

As for Sprites, I know my results would make me wary of proclaiming them to be the be all and end all without a little look beyond the theory.* In most cases absolutely YES, it's better than their "diced" counterparts, and at the very least it shows someone has even been paying attention, however the truth is that while it certainly won't harm, it just might not be the best solution for your needs.

*Disclaimer: I have and will continue to do so, because it's the least designers can do to show they understand! and the demos are very persuasive.., and yes it works to an extent

for instance in the example I tested, I'm not sure I would have sang the sprites praises, yes it helped, but it wasn't optimal and was no where near definite enough to prove, either way (the theory does sound good though!). but then I guess I'm not Yahoo! G or Amazon hehe!

poppyrich

5+ Year Member



 
Msg#: 4031959 posted 4:40 pm on Dec 1, 2009 (gmt 0)

@swa66, suzy, and all:

embedding an image inside the html has a big problem in that it makes it impossible to cache the image for use on other pages (it's part of the prior html, not an image with it's own URL anymore)

That's a big problem only if you are counting on a primed cache being available to speed things up as the visitor moves from page to page.
But the advantage is that the image is a part of the page.
No separate file(s). Time consuming HTTP requests are kept to a minimum. The happier medium is to put the data URI's in the stylesheet file that gets cached. But I'm really not sure if it's any more efficent than sprites.
httpwebwitch said:

I'd totally use this technique for images that are only used on one page, like "leaf node" pages and product detail pages.

And so would I, absolutely. One single HTML file to deal with. Simple.

Another situation might be on a home page where the content is changing constantly and therefore you can assume a mostly empty cache relevant to that page.
It's all really subject to site-by-site analysis.

Steve Souders (YSlow) is the guy to read about all this. Two books out about all kinds of optimization stuff. And a lot of it is online, too. Mr. Optimimization.
[stevesouders.com...]

CSS isn't all about design you know, it's a skillset as you say and it offers more than one way to put a page together, there are like any of the programming language or markup languages, efficient and not so efficient ways to apply it.

Darn right.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / CSS
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved