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

Sun Nov 10 14:13:27 PST 2019

> On Nov 10, 2019, at 12:05 PM, Noam Rosenthal <noam at webkit.org> wrote:
> 
> 
> 
> On Sun, Nov 10, 2019 at 9:41 PM Maciej Stachowiak <mjs at apple.com <mailto:mjs at apple.com>> wrote:
> 
> Is this header useful without the DPR client-hint?
> Absolutely. 
> A server/CDN can decide to serve an image with a particular content-dpr without knowing the client's actual DPR.

A few more questions (apologies if there are basic things that would be explained by a spec somewhere).

- Is there a specification for Content-DPR? All I could find in bugzila and elsewhere is links to <https://httpwg.org/http-extensions/client-hints.html <https://httpwg.org/http-extensions/client-hints.html>>, which does not mention Content-DPR at all).
- Can you give us some examples of how the CDN would make the decision of what density of image to serve without knowing the client’s DPR via  client-hints? 
- Is this presuming situations where the CDN serves the images but not the markup or CSS (which presumably could be rewritten to account for DPR)?
- What happens if Content-DPR is provided, but the markup or CSS has conflicting explicit info? For example, <img srcset=“image-2x.jpg 2x, image.jpg 1x”>, and image-2x.jpg is served with a Content-DPR header of 3x. Or the analogous thing with CSS.
- Does Content-DPR have any effect on images where an explicit size is provided, either in markup or in CSS? (I’m assuming no.)

Cheers,
Maciej

> 
> 
>> On Nov 10, 2019, at 1:16 AM, Noam Rosenthal <noam at webkit.org <mailto:noam at webkit.org>> wrote:
>> 
>> 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 <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 <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://github.com/eeeps/content-dpr-explainer>
>> https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67 <https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67>
>> https://www.chromestatus.com/metrics/feature/timeline/popularity/906 <https://www.chromestatus.com/metrics/feature/timeline/popularity/906>_______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
>> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20191110/d62cca49/attachment.htm>