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

[Noam Rosenthal]

On Sun, Nov 10, 2019 at 9:41 PM Maciej Stachowiak <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.


> On Nov 10, 2019, at 1:16 AM, Noam Rosenthal <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
>
> 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
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> 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/55938d7f/attachment.htm>