[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Content-DPR: Image resolution optimization at CDN/transport layer
From: Noam Rosenthal <noam () webkit ! org>
Date: 2019-11-10 20:05:20
Message-ID: CAGttnEV3JFDmeuooNQpmqwuauP3Aq3iCcpDJBonKaoyNRQmT-A () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sun, Nov 10, 2019 at 9:41 PM Maciej Stachowiak <mjs@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@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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Sun, Nov 10, 2019 at 9:41 PM Maciej Stachowiak <<a \
href="mailto:mjs@apple.com">mjs@apple.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: \
break-word;"><div><br></div>Is this header useful without the DPR \
client-hint?<br></div></blockquote><div>Absolutely. </div><div>A server/CDN can \
decide to serve an image with a particular content-dpr without knowing the \
client's actual DPR.</div><div><br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: \
break-word;"><div><br><blockquote type="cite"><div>On Nov 10, 2019, at 1:16 AM, Noam \
Rosenthal <<a href="mailto:noam@webkit.org" \
target="_blank">noam@webkit.org</a>> wrote:</div><br><div><div \
dir="ltr">Hola<br><div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">I \
would like to open a discussion that has started a few years back and has never \
reached a consensus: <a href="https://bugs.webkit.org/show_bug.cgi?id=145380" \
target="_blank"><span \
style="font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal; \
line-height:normal;font-family:Times;font-kerning:none;color:rgb(0,0,233)">https://bugs.webkit.org/show_bug.cgi?id=145380</span></a></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Times;color:rgb(0,0,233);min-height:18px"><span \
style="text-decoration-line:underline;font-kerning:none"></span><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">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.</div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">The \
feature is already up and running in chrome since version 67, and is used by some \
CDNs.</div><div style="margin:0px;font-variant-numeric:normal;font-variant-east-asian: \
normal;font-stretch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">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. <br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">—</div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">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.</div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">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.</div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">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.</div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">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 (<a \
href="https://bugs.webkit.org/show_bug.cgi?id=145380#c7" target="_blank"><span \
style="font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal; \
line-height:normal;font-family:Times;font-kerning:none;color:rgb(0,0,233)">https://bugs.webkit.org/show_bug.cgi?id=145380#c7</span></a><span \
style="font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal; \
line-height:normal;font-family:Times;text-decoration-line:underline;font-kerning:none;color:rgb(0,0,233)">)</span>.</div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">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.<span> </span></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">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).</div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">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.<span> Less battery and data used for downloading big images at certain \
situations, for example.</span></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">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 :)</div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stre \
tch:normal;line-height:normal;font-family:Helvetica;min-height:17px"><br></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Helvetica">Additional \
info:</div><div style="margin:0px;font-variant-numeric:normal;font-variant-east-asian: \
normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,233)"><span \
style="text-decoration-line:underline;font-kerning:none"><a \
href="https://github.com/eeeps/content-dpr-explainer" \
target="_blank">https://github.com/eeeps/content-dpr-explainer</a></span></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,233)"><span \
style="text-decoration-line:underline;font-kerning:none"><a \
href="https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67" \
target="_blank">https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67</a></span></div><div \
style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Times;color:rgb(0,0,233)"><span \
style="text-decoration-line:underline;font-kerning:none"><a \
href="https://www.chromestatus.com/metrics/feature/timeline/popularity/906" \
target="_blank">https://www.chromestatus.com/metrics/feature/timeline/popularity/906</a></span></div></div></div>
_______________________________________________<br>webkit-dev mailing list<br><a \
href="mailto:webkit-dev@lists.webkit.org" \
target="_blank">webkit-dev@lists.webkit.org</a><br><a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" \
target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br></div></blockquote></div><br></div></blockquote></div></div>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic