[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:       Maciej Stachowiak <mjs () apple ! com>
Date:       2019-11-10 19:41:05
Message-ID: 477F0DAF-6959-4C94-86DE-CA0DE85E2B0C () apple ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Is this header useful without the DPR client-hint?

> 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 \
> <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


[Attachment #5 (unknown)]

<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><div class=""><br class=""></div>Is this \
header useful without the DPR client-hint?<br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On Nov 10, 2019, at 1:16 AM, Noam Rosenthal &lt;<a \
href="mailto:noam@webkit.org" class="">noam@webkit.org</a>&gt; wrote:</div><br \
class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hola<br \
class=""><div class=""><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;" class=""><br class=""></div><div \
style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; \
font-stretch: normal; line-height: normal; font-family: Helvetica;" class="">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" class=""><span \
class="gmail-s1" style="font-variant-numeric:normal;font-variant-east-asian:normal;fon \
t-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-stretch: normal; line-height: normal; font-family: Times; color: rgb(0, 0, 233); \
min-height: 18px;" class=""><span class="gmail-s2" \
style="text-decoration-line:underline;font-kerning:none"></span><br \
class=""></div><div style="margin: 0px; font-variant-numeric: normal; \
font-variant-east-asian: normal; font-stretch: normal; line-height: normal; \
font-family: Helvetica;" class="">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-stretch: normal; line-height: normal; \
font-family: Helvetica; min-height: 17px;" class=""><br class=""></div><div \
style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; \
font-stretch: normal; line-height: normal; font-family: Helvetica;" class="">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;" class=""><br class=""></div><div \
style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; \
font-stretch: normal; line-height: normal; font-family: Helvetica;" class="">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.&nbsp;<br class=""></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;" class=""><br class=""></div><div \
style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; \
font-stretch: normal; line-height: normal; font-family: Helvetica;" \
class="">—</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;" class=""><br class=""></div><div \
style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; \
font-stretch: normal; line-height: normal; font-family: Helvetica;" class="">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-stretch: normal; \
line-height: normal; font-family: Helvetica; min-height: 17px;" class=""><br \
class=""></div><div style="margin: 0px; font-variant-numeric: normal; \
font-variant-east-asian: normal; font-stretch: normal; line-height: normal; \
font-family: Helvetica;" class="">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-stretch: normal; line-height: normal; \
font-family: Helvetica; min-height: 17px;" class=""><br class=""></div><div \
style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; \
font-stretch: normal; line-height: normal; font-family: Helvetica;" class="">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-stretch: normal; \
line-height: normal; font-family: Helvetica; min-height: 17px;" class=""><br \
class=""></div><div style="margin: 0px; font-variant-numeric: normal; \
font-variant-east-asian: normal; font-stretch: normal; line-height: normal; \
font-family: Helvetica;" class="">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" \
class=""><span class="gmail-s3" \
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 \
class="gmail-s3" style="font-variant-numeric:normal;font-variant-east-asian:normal;fon \
t-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;" class="">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 \
class="gmail-Apple-converted-space">&nbsp;</span></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;" class=""><br \
class=""></div><div style="margin: 0px; font-variant-numeric: normal; \
font-variant-east-asian: normal; font-stretch: normal; line-height: normal; \
font-family: Helvetica;" class="">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-stretch: normal; line-height: normal; \
font-family: Helvetica; min-height: 17px;" class=""><br class=""></div><div \
style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; \
font-stretch: normal; line-height: normal; font-family: Helvetica;" class="">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 class="gmail-Apple-converted-space">&nbsp;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-stretch: normal; line-height: normal; font-family: Helvetica; min-height: 17px;" \
class=""><br class=""></div><div style="margin: 0px; font-variant-numeric: normal; \
font-variant-east-asian: normal; font-stretch: normal; line-height: normal; \
font-family: Helvetica;" class="">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-stretch: normal; line-height: normal; \
font-family: Helvetica; min-height: 17px;" class=""><br class=""></div><div \
style="margin: 0px; font-variant-numeric: normal; font-variant-east-asian: normal; \
font-stretch: normal; line-height: normal; font-family: Helvetica;" \
class="">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);" class=""><span class="gmail-s2" \
style="text-decoration-line:underline;font-kerning:none"><a \
href="https://github.com/eeeps/content-dpr-explainer" \
class="">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);" class=""><span class="gmail-s2" \
style="text-decoration-line:underline;font-kerning:none"><a \
href="https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67" \
class="">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);" class=""><span class="gmail-s2" \
style="text-decoration-line:underline;font-kerning:none"><a \
href="https://www.chromestatus.com/metrics/feature/timeline/popularity/906" style="" \
class="">https://www.chromestatus.com/metrics/feature/timeline/popularity/906</a></span></div></div></div>
 _______________________________________________<br class="">webkit-dev mailing \
list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" \
class="">webkit-dev@lists.webkit.org</a><br \
class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br \
class=""></div></blockquote></div><br class=""></body></html>



_______________________________________________
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