On Sun, Nov 10, 2019 at 9:41 PM Maciej Stachowiak <[email protected]> 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 <[email protected]> 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 > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev > > >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
