6 ms·
It's worth balancing this against other research showing that users often don't like the experience provided by progressive image rendering: http://www.webperf
by philbo 10y ago
It's worth balancing this against other research showing that users often don't like the experience provided by progressive image rendering:
http://www.webperformancetoday.com/2014/09/17/progressive-image-rendering-good-evil/ http://www.webperformancetoday.com/2014/09/17/progressive-im...
- inian 10y agoThis is the only research that claims progressive images aren't a good user experience though. I can't confirm with electrodes attached to my brain but personally I like progressive images better than baseline and they are smaller too!
- philbo 10y agoTrue. As ever, it makes sense to A/B test these things with your userbase. Their behaviour is more important to your own sites than any research or personal preference.
- danielrhodes 10y agoCan't you just reason that images coming through earlier is a better experience than not? Do you really need to AB test this?
- Normal_gaussian 10y agoYou can. You can also be wrong. If the value coming through your site is great enough that marginal improvements (on the order of 1%) are worth time investment (compared to other available improvement avenues) then this is something you should A/B test.
- trav4225 10y agoHah, I'm surprised at the replies here. I guess I'm in the minority opinion (I don't like progressive loading of anything; just prepare the page, then show it to me :-).
- rebuilder 10y agoSample size of one, but on mobile, my number one pet peeve (apart from popover ads and autoplay videos!) is layouts that change as the page loads. Progressive encoding with multiplexing should help make sure newly loaded images don't make article text jump around as I try to read it. Then again, maybe this is a laziness issue since it seems to me defining a layout independent of actual image content is something that you could do in the 90's.
- rimantas 10y agoSpecifying image dimensions is enought to prevent any jumps.
- eknkc 10y agoOn mobile, we mostly do percentages on images due to varying display sizes. Gets ridiculous when you want to specify the dimension, because you can't. We need to specify aspect ratios and css does not provide that. Went with a padding-top + absolute position in wrapper hack at the end. That jumpiness is part the tooling problem.
- kuon 10y agoI know it's a hack, but what is wrong with it? I've always been using that and it works. I haven't looked in details into the new srcset and size attributes of image, but won't that help also?
- woof 10y ago<picture> with multiple srcset makes it possible to serve images that are displayed at 100% width, filling their (DOM) container. Check out http://scottjehl.github.io/picturefill/ http://scottjehl.github.io/picturefill/
- hinkley 10y agoThis is why I use vh, vw for proportional images at mobile breakpoints. You still have to know the aspect ratio of the original image of course, but it does help.
- rockostrich 10y agoOne piece of research that measures vitals instead of just asking the users which one they liked more isn't very convincing. It could even be A/B tested by measuring how long people stay on the page or bounce rate above the fold.
- SmkyMt 10y agoSample size: three (and counting). It's an awful problem, mobile or laptop/desktop: My greatest gripe is that I may think page is fully loaded, click to highlight text and - boom! I'm sent of to some page of video or advertising through a link that abruptly displaces the target I aimed at.