Thanks for this. This is very surprising... cc'in design and mobile list. Maybe we should rethink using css sprites for our icons?
On Mon, Sep 23, 2013 at 2:57 PM, Ori Livneh ori@wikimedia.org wrote:
http://www.mobify.com/blog/data-uris-are-slow-on-mobile/
Ori Livneh ori@wikimedia.org
Per comments on the article, I wouldn't read much into it -- the benchmark is pretty flawed. It doesn't measure anything representative of typical usage.
And of course, the whole reason to use inline styles is to avoid round-trips on non-cached cold start, which he explicitly didn't attempt to measure.
-- brion
On Mon, Sep 23, 2013 at 3:09 PM, Jon Robson jrobson@wikimedia.org wrote:
Thanks for this. This is very surprising... cc'in design and mobile list. Maybe we should rethink using css sprites for our icons?
On Mon, Sep 23, 2013 at 2:57 PM, Ori Livneh ori@wikimedia.org wrote:
http://www.mobify.com/blog/data-uris-are-slow-on-mobile/
Ori Livneh ori@wikimedia.org
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Mon, Sep 23, 2013 at 3:11 PM, Brion Vibber bvibber@wikimedia.org wrote:
Per comments on the article, I wouldn't read much into it -- the benchmark is pretty flawed. It doesn't measure anything representative of typical usage.
And of course, the whole reason to use inline styles is to avoid round-trips on non-cached cold start, which he explicitly didn't attempt to measure.
Yes, you're right. I skimmed the headline and got excited, but this is not a useful report.
On 09/23/2013 06:11 PM, Brion Vibber wrote:
Per comments on the article, I wouldn't read much into it -- the benchmark is pretty flawed. It doesn't measure anything representative of typical usage.
Yeah. They inexplicably *only* used a single size, a 17.8kB PNG (18227 bytes). If you're not sure why that's a problem, check the size of some of the images MW embeds. Examples from a quick grep:
resources/jquery/images/jquery.arrowSteps.head-ltr.png - 303 bytes resources/jquery.tipsy/images/tipsy.png - 133 bytes resources/jquery.ui/themes/vector/images/ui-icons_ffffff_256x240.png - 3702 bytes resources/mediawiki.action/images/green-checkmark.png - 681 bytes
Why does it matter? The main reason to avoid requests for every single image is to minimize the time, latency, and bandwidth (bytes) used for HTTP request and responses. The smaller the image, the bigger the fraction (header size / image size) is, thus the more wasted header time.
What he said about a 814 byte fixed header is also simply wrong. Some of our data URIs are less than 814 bytes *total*. E.g. data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAAkCAAAAABtHw/QAAAAGElEQVQIW2P4wMTA9B8Fo5IIGl0EQQIxAEzaGCA3rKnhAAAAAElFTkSuQmCC is a real example from jquery.ui.dialog.
We should keep this issue in mind (there is a penalty, particularly for large images), but that article draws a skewed picture.
Matt
Yup very flawed but interesting never the less. Putting into the back of the memory bank. Thanks for sharing Ori and thanks Brion for pointing out the flaws that I also skimmed over :)
On Mon, Sep 23, 2013 at 5:26 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 09/23/2013 06:11 PM, Brion Vibber wrote:
Per comments on the article, I wouldn't read much into it -- the benchmark is pretty flawed. It doesn't measure anything representative of typical usage.
Yeah. They inexplicably *only* used a single size, a 17.8kB PNG (18227 bytes). If you're not sure why that's a problem, check the size of some of the images MW embeds. Examples from a quick grep:
resources/jquery/images/jquery.arrowSteps.head-ltr.png - 303 bytes resources/jquery.tipsy/images/tipsy.png - 133 bytes resources/jquery.ui/themes/vector/images/ui-icons_ffffff_256x240.png - 3702 bytes resources/mediawiki.action/images/green-checkmark.png - 681 bytes
Why does it matter? The main reason to avoid requests for every single image is to minimize the time, latency, and bandwidth (bytes) used for HTTP request and responses. The smaller the image, the bigger the fraction (header size / image size) is, thus the more wasted header time.
What he said about a 814 byte fixed header is also simply wrong. Some of our data URIs are less than 814 bytes *total*. E.g. data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAAkCAAAAABtHw/QAAAAGElEQVQIW2P4wMTA9B8Fo5IIGl0EQQIxAEzaGCA3rKnhAAAAAElFTkSuQmCC is a real example from jquery.ui.dialog.
We should keep this issue in mind (there is a penalty, particularly for large images), but that article draws a skewed picture.
Matt
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Another thing that seems to be ignored here is how well gzip performs when embedding multiple images in a single stylesheet. When we implemented this feature we were skeptical about possible side-effects of say, embedding the same image multiple times, or embedding images that might not end up being used. Our tests showed that gzip was so aggressive at combining common image headers and in some cases color pallets or actual pixel data, that we would have to have a pretty extreme situation for these sorts of things to actually cause performance issues.
- Trevor
On Wed, Sep 25, 2013 at 10:53 PM, Jon Robson jdlrobson@gmail.com wrote:
Yup very flawed but interesting never the less. Putting into the back of the memory bank. Thanks for sharing Ori and thanks Brion for pointing out the flaws that I also skimmed over :)
On Mon, Sep 23, 2013 at 5:26 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 09/23/2013 06:11 PM, Brion Vibber wrote:
Per comments on the article, I wouldn't read much into it -- the benchmark is pretty flawed. It doesn't measure anything representative of typical usage.
Yeah. They inexplicably *only* used a single size, a 17.8kB PNG (18227 bytes). If you're not sure why that's a problem, check the size of some
of
the images MW embeds. Examples from a quick grep:
resources/jquery/images/jquery.arrowSteps.head-ltr.png - 303 bytes resources/jquery.tipsy/images/tipsy.png - 133 bytes resources/jquery.ui/themes/vector/images/ui-icons_ffffff_256x240.png -
3702
bytes resources/mediawiki.action/images/green-checkmark.png - 681 bytes
Why does it matter? The main reason to avoid requests for every single image is to minimize the time, latency, and bandwidth (bytes) used for
HTTP
request and responses. The smaller the image, the bigger the fraction (header size / image size) is, thus the more wasted header time.
What he said about a 814 byte fixed header is also simply wrong. Some of our data URIs are less than 814 bytes *total*. E.g.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAAkCAAAAABtHw/QAAAAGElEQVQIW2P4wMTA9B8Fo5IIGl0EQQIxAEzaGCA3rKnhAAAAAElFTkSuQmCC
is a real example from jquery.ui.dialog.
We should keep this issue in mind (there is a penalty, particularly for large images), but that article draws a skewed picture.
Matt
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Jon Robson http://jonrobson.me.uk @rakugojon
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design