Is this header useful without the DPR client-hint? > On Nov 10, 2019, at 1:16 AM, Noam Rosenthal <n...@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@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
