[webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer

[Noam Rosenthal]

Hola


I would like to open a discussion that has started a few years back and has
never reached a consensus: https://bugs.webkit.org/show_bug.cgi?id=145380


In a nutshell: content-dpr is a response-only header for images, that
allows servers at transient layers (CDNs/proxies) to optimize images by
changing their resolution, allowing the user agents to compensate for the
change in intrinsic size caused by the resolution change - thus making the
resolution change transparent to users. It's the header that makes the
resolution-encoding transparent.


The feature is already up and running in chrome since version 67, and is
used by some CDNs.


Since there was lack of consensus in the bug discussion, I wanted to make
the case for it here, and see if opinions about the subject can be voiced
before we reach a decision/consensus. I tried to find a good balance
between being detailed and being concise.


—


Players in CDN, proxy and other transient parts of the internet world have
innovated a lot in the past few years. There are lots of interesting
companies and competition there. One of the areas of this innovation is in
optimizing images in a transparent way at transient layers (proxy/CDN).
This makes a lot of sense considering how much of internet traffic is taken
by image download.


What the research at the CDN companies found, was that modifying resolution
at the transient layer can have a tremendous effect on
performance/user-experience balance, for example by serving
lower-resolution versions of the images when network traffic is costly/slow
(the exact formula for that is part of where the CDN can innovate). More
details on that innovation in the links below.


The thing is, that modifying image resolution at the CDN/proxy is not
inherently transparent, due to one reason - layout is affected by the
image’s intrinsic size, and changing the image’s resolution inadvertently
changes the image’s intrinsic size. To make this transparent, the user
agent has to be involved, to compensate for this optimization when reading
the image’s intrinsic size.


The main case against this feature was that image resolution is a feature
that should be handled at the markup layer and not at the transport layer (
https://bugs.webkit.org/show_bug.cgi?id=145380#c7).

I would argue that http-headers are not a transport layer (TCP/UDP etc.),
but rather part of an application-layer protocol that is designed, in part,
to pass information to the transient layers such as CDNs, and that
resolution compression is a (new, image-specific) equivalent of
transfer-encoding.


Also, as a response to the view that this should be part of markup, I would
argue that those transparent decisions by the servers should not concern
web authors at all. It’s an optimization decision to be handled by the
servers, with the user agent doing nothing about it but allow that decision
to be transparent in terms of layout (the same way gzip and cache-control
are transparent).


What is offered here is a win-win in terms of delivering images, and would
allow webkit-browser users to enjoy some of the innovations in the image
delivery world without modifying their HTML content and without concern of
breaking their layouts. Less battery and data used for downloading big
images at certain situations, for example.


I hope this provides enough background without being too tedious. I would
be happy to shed more light on whatever is missing in this longish essay :)


Additional info:

https://github.com/eeeps/content-dpr-explainer

https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67

https://www.chromestatus.com/metrics/feature/timeline/popularity/906
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20191110/0f65deb8/attachment.htm>