[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 22:13:27
Message-ID: E36002D1-2EE4-4997-AC3D-CCB34C3A039D () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Nov 10, 2019, at 12:05 PM, Noam Rosenthal <noam@webkit.org> wrote:
>
>
>
> On Sun, Nov 10, 2019 at 9:41 PM Maciej Stachowiak <mjs@apple.com \
> <mailto: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.
A few more questions (apologies if there are basic things that would be explained by \
a spec somewhere).
- Is there a specification for Content-DPR? All I could find in bugzila and elsewhere \
is links to <https://httpwg.org/http-extensions/client-hints.html \
<https://httpwg.org/http-extensions/client-hints.html>>, which does not mention \
Content-DPR at all).
- Can you give us some examples of how the CDN would make the decision of what \
density of image to serve without knowing the client's DPR via \
client-hints?
- Is this presuming situations where the CDN serves the images but not the markup or \
CSS (which presumably could be rewritten to account for DPR)?
- What happens if Content-DPR is provided, but the markup or CSS has conflicting \
explicit info? For example, <img srcset="image-2x.jpg 2x, image.jpg 1x">, and \
image-2x.jpg is served with a Content-DPR header of 3x. Or the analogous thing with \
CSS.
- Does Content-DPR have any effect on images where an explicit size is provided, \
either in markup or in CSS? (I'm assuming no.)
Cheers,
Maciej
>
>
> > On Nov 10, 2019, at 1:16 AM, Noam Rosenthal <noam@webkit.org \
> > <mailto: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 <mailto:webkit-dev@lists.webkit.org>
> > https://lists.webkit.org/mailman/listinfo/webkit-dev \
> > <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=""><br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On Nov 10, 2019, at 12:05 PM, Noam Rosenthal \
<<a href="mailto:noam@webkit.org" class="">noam@webkit.org</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div \
dir="ltr" class=""><br class=""></div><br class=""><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" class="">mjs@apple.com</a>> wrote:<br \
class=""></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;" class=""><div class=""><br class=""></div>Is this \
header useful without the DPR client-hint?<br class=""></div></blockquote><div \
class="">Absolutely. </div><div class="">A server/CDN can decide to serve an \
image with a particular content-dpr without knowing the client's actual \
DPR.</div></div></div></div></blockquote><div><br class=""></div><div>A few more \
questions (apologies if there are basic things that would be explained by a spec \
somewhere).</div><div><br class=""></div><div>- Is there a specification for \
Content-DPR? All I could find in bugzila and elsewhere is links to <<a \
href="https://httpwg.org/http-extensions/client-hints.html" \
class="">https://httpwg.org/http-extensions/client-hints.html</a>>, which does not \
mention Content-DPR at all).</div><div>- Can you give us some examples of how the CDN \
would make the decision of what density of image to serve without knowing the \
client's DPR via client-hints? </div><div>- Is this presuming situations \
where the CDN serves the images but not the markup or CSS (which presumably could be \
rewritten to account for DPR)?</div><div>- What happens if Content-DPR is provided, \
but the markup or CSS has conflicting explicit info? For example, <img \
srcset="image-2x.jpg 2x, image.jpg 1x">, and image-2x.jpg is served with a \
Content-DPR header of 3x. Or the analogous thing with CSS.</div><div>- Does \
Content-DPR have any effect on images where an explicit size is provided, either in \
markup or in CSS? (I'm assuming no.)</div><div><br \
class=""></div><div>Cheers,</div><div>Maciej</div><div><br class=""></div><br \
class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div \
class="gmail_quote"><div class=""><br class=""></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;" \
class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On \
Nov 10, 2019, at 1:16 AM, Noam Rosenthal <<a href="mailto:noam@webkit.org" \
target="_blank" class="">noam@webkit.org</a>> wrote:</div><br class=""><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" \
target="_blank" class=""><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)" \
class="">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" \
class=""><span style="text-decoration-line:underline;font-kerning:none" \
class=""></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. <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" target="_blank" \
class=""><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)" \
class="">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)" \
class="">)</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=""> </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=""> 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 style="text-decoration-line:underline;font-kerning:none" class=""><a \
href="https://github.com/eeeps/content-dpr-explainer" target="_blank" \
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 style="text-decoration-line:underline;font-kerning:none" class=""><a \
href="https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67" \
target="_blank" 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 style="text-decoration-line:underline;font-kerning:none" class=""><a \
href="https://www.chromestatus.com/metrics/feature/timeline/popularity/906" \
target="_blank" 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" target="_blank" \
class="">webkit-dev@lists.webkit.org</a><br class=""><a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank" \
class="">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br \
class=""></div></blockquote></div><br class=""></div></blockquote></div></div> \
</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