I had looked at doing this on my own but ended up stumbling across a performance report that showed no decrease in site load time, and in some certain cases they actually saw an increase.

I look forward to seeing some before and after performance reports once this module is released.

CommentFileSizeAuthor
#7 Embeded.pdf74.99 KBphilbar
#7 Not Embedded.pdf75.77 KBphilbar

Comments

Flying Drupalist’s picture

Flying Drupalist commented

subscribe

a_c_m’s picture

a_c_m commented

subscribe.

bryancasler’s picture

bryancasler commented

I dug around and found a performance benchmark I was referencing. In fact I think that this was the one that made me consider the tradeoff too much work. With your module however I may have to reconsider, especially once the report backs start coming in.

http://www.ravelrumba.com/blog/data-uris-for-css-images-more-tests-more-...

jcarnett’s picture

jcarnett commented

Thanks for the link. I like his alternate approach of loading the data URIs in a separate CSS file rather than adding them to the original CSS -- I'll have to try adding support for that. That approach would make it easier to include data for an image only once as well. The current implementation will include it each time it's referenced in the CSS.

The main objective of this module is to minimize round trip times and request overhead.

Round trips are almost unnoticeable on fast, low-latency connections but they become a major factor as soon as latency starts to increase ("the major contributing factor to latency," according to Google). You can really see the difference it makes in the international load times in the article.

Request overhead is less significant, but it's still interesting when it comes to data URIs. Because data URIs are base64 encoded they actually increase the total page weight, which will increase load times unless the overhead avoided by cutting out extra round trips is greater than the additional weight from the encoding. In my experience this tends to work out well because typical site designs have lots of small background images for things like bullets, gradients, etc and usually support gzip compression (which is lost on all those extra request/response headers).

I don't have any concrete benchmarks for you at the moment, but I'll work on putting some together.

bryancasler’s picture

bryancasler commented

This sounds great, and when my current site is out of development I will give your module a try and post benchmarks. This would probably be around 1+ months from now. I really like the idea of breaking up the CSS files, so +1 for that, except I assume it would have be generated after the css files are already aggregated.

philbar’s picture

philbar commented

Anyone know how to test this?

I'm working on performance issues for my site right now. YSlow and Google Page Speed both suggest making less HTTP request. My site went from 26 image HTTP requests to 9 image requests.

philbar’s picture

philbar commented
StatusFileSize
new Not Embedded.pdf75.77 KB
new Embeded.pdf74.99 KB

My results for the following page:
http://dev.bioworldusa.com/content/bioworld-company-profile

See attached documents for Yslow report.

CSS Image URLs
Original: 27
Embedded: 0

Total Page Size Reduction
Original: 129.3K
Embedded: 106.3K
17.79% Reduction

Load Times Uncached
Original: 5.776 sec
Embedded: 5.2 sec
9.97% Reduction

Load Times Cached with Boost
Original: 2.209 sec
Embedded: 1.811 sec
18.02% Reduction

Load Times Cached with Boost and browser cache
Original: 2.489 sec
Embedded: 1.684 sec
32.34% Reduction

philbar’s picture

philbar commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.