search

igrigorik / http-client-hints

401 stars 24 forks source link

Handling of multiple `<img>` tags with the same resource #36

Closed yoavweiss closed 9 years ago

yoavweiss commented 9 years ago

What happens when CH is on, and we have an HTML that contains two separate <img> tags, one that contains an image that's the full width of the viewport, and another that's a thumbnail of the same image? (assuming both have sizes/width, or both start to download post-layout)

In the srcset case, the browser can be smart enough to avoid the download of the thumbnail if a higher quality resource is already in cache.

Since for CH the browser side caching is Vary based, I'm not sure that the same can be done for CH, but I wonder if we can do something to avoid this sub-optimal behavior, without adding key support in the browser.

igrigorik commented 9 years ago

In the srcset case, the browser can be smart enough to avoid the download of the thumbnail if a higher quality resource is already in cache.

Same applies for CH: if you have a "DPR:2" asset there is no need to download a "DPR:1".

One way to achieve that is for the origin to specify a Key: DPR;r=[1.0:] (or similar) and have the UA apply the relevant logic (i.e. this variant is good for DPR 1.0+). Alternatively, you could probably also automate parts of that within the UA: if you fetched a Vary: DPR asset and its Content-DPR value > DPR value of the one you're requesting now.. reuse it. Similar logic for RW?

yoavweiss commented 9 years ago

The logic is clear, but the fact that we'd have to special case it in the browser implementation is iffy at best. I guess that key support can't come fast enough...

igrigorik commented 9 years ago

How is this anymore "iffy" than the magic behind srcset? Seems like its the exact same case.

yoavweiss commented 9 years ago

Vary already has well defined (and implemented) semantics, which we'd have to override in some cases here: "If Vary is on DPR/RW and cached DPR/RW is larger than current ones, then get the resource out of the cache even though you're not really supposed to".

The magic (AKA "proprietary selection logic" :) ) behind srcset is not defined anywhere, but the location in which this logic is applied is, so IMO it's way cleaner.

igrigorik commented 9 years ago

Fair enough. I guess a "proper" implementation would effectively implement Key support... E.g. if the origin does not provide Key policy then the UA could automatically inject one: Key: DPR;r=[1.0:<value of Content-DPR>], and the rest would be taken care of.. the browser would initiate the request and get a cache hit.

yoavweiss commented 9 years ago

Yup, key is key.

igrigorik commented 9 years ago

/me nudges @mnot about Key... any updates? Can we carve out some stable parts of the spec?