I'd rather we didn't serve poor quality images
to all our users. This is a
poorer user experience in my opinion. if I understand correctly this change
was more to encourage more providers to join zero by providing an incentive
of Zero users using less data. I'm still not convinced there is a huge
benefit to the user themselves when you consider gzipping etc. Have you
benchmarked and documented how this change effects load time? Pulling in
Ori and Aaron since they should have expertise in this area.
A lot of browsers these days allow you to turn off images altogether and I
think if a user you'd rather do this then receive poorer quality images. To
me it's a binary switch - no images or images... On retina displays we
actually go the opposite direction and pull in better quality images. I
would hazard a guess that the issue here is the number of http requests
rather than the size of the images.
I think if we wanted to invest any time in this sort of thing we should
explore deferring the load of images until they are visible (we dabbled
with this when we explore lazy loading sections) [1]. It would be
interesting to rewrite any image after the first heading to be a link to
the image and pull it in via JavaScript when it is scrolled into view. I
think this would give us more bang for our buck...
On a side notice I notice all images on mobile are missing a cache
expiration - is that intended? Also have we considered adding a header
Cache-Control: public to them?
[1]
Thanks Yuri,
CC'ing Multimedia team
Maryana, this could be something interesting for the Mobile Web team
to look at to optimize image delivery.
Have you guys done any perf work around images?
--tomasz
On Thu, Jun 5, 2014 at 4:10 PM, Yuri Astrakhan <yastrakhan(a)wikimedia.org>
wrote:
The reduced quality images is now live in
production. To see it for
yourself, compare original with low quality images (253KB => 99.9KB, 60%
reduction).
The quality reduction is triggered by adding "qlow-" in front of the
file
name's pixel size.
Continuing our previous discussion, now we need to figure out how to
best
use this feature. As covered before, there are
two main approaches:
* JavaScript rewrite - dynamically change <img> tag based on
network/device/user preference conditions. Issues may include multiple
downloads of the same image (if the browser starts the download before
JS
runs), parser cache fragmentation.
* Varnish-based rewrite - varnish decides which image to server under
the
same URL. This approach requires Varnish to know
everything needed to
make a
decision.
Zero plans to go the first route, but if we make it mobile, or ever site
wide, all the better.
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org