CC'ing zero@ to include them in the conversation
On Mon, Jun 9, 2014 at 5:01 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:
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.
Yuri, you mentioned that we we're seeing a 2x decrease in payload
traffic as a result of this change.
When you profile against a sample of our traffic data does this
increase/decrease/stay the same?
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.
While thats great for end users it doesn't help the carrier as it
requires the user to opt into the experience. Our carrier partners
have to pay the bill irregardless of wether someone turns images on or
off. In fact a zero rated customer will have even less incentive to
turn off images if their network is fast enough and the data is free.
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...
Zero team, what is our target device matrix these days and how robust
is its Javascript support?
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?
This historically has been due to upstream caches not respecting
purges and our ops team wanting to keep TTL's as low as possible. We
can take it up to the ops list if we want to know more
--tomasz