-
Notifications
You must be signed in to change notification settings - Fork 31
Preloading for HiDPI images (image srcset 2x) #31
Comments
I don't think "fixed URL" is an issue here. If you're using CSS image-set or media queries then you already have different URLs for various resolutions. Also, the preload spec does indicate that the "right time to load the resource" is when there is a matching media query... So, you could do |
I couldn't find any mention of a media attribute for the preload link. That's essentially what I was requesting here. I must've looked over that, it's right there in the spec. Thanks! I assume it would support something like |
I agree that a
Potentially, we could also harness Client-Hints for that purpose, if Accept-CH is sent as a header. That (similarly to One problem with responsive resource preloading as a |
Personally, I don't think we want to introduce the srcset complexity at this point.. a) You can unroll srcset into multiple declarations with different media queries I'm inclined to close this, any objections? |
The problem with using Client-Hints would be a better option, if we're just talking about the HiDPI scenario. |
@yoavweiss I'm not aware of any browsers that have taken advantage of the srcset/image-set downgrade.. yet, at least. FWIW, this may be a reasonable v2 feature, but for now I'd prefer to keep things simple. |
I agree we haven't done anything with the "downgrade" possibilities yet, but am also afraid that enabling I think that we should enable the current case using |
Agreed. You can use preload + Client Hints to get the desired behavior.
FWIW, I don't think we should. Put the ~srcset use case aside (solved via DPR), and consider the typical stylesheet example where media queries are often critical -- e.g. load this stylesheet for this breakpoint, and that one if insert-other-MQ-here. We need media support to enable many use cases around preloading critical assets (JS, CSS). |
@Krinkle @yoavweiss I don't believe there are spec-related issues here. Can we close this? We can continue implementation discussions elsewhere (e.g. crbug). |
closing, please feel free to reopen if there is more to discuss here. |
@igrigorik It appears there may be a missing component here that wasn't considered. Where in CSS, multiple media queries naturally cascade/de-duplicate, preload does not. .mw-logo {
background-image: url(/static/wikipedia.png);
background-size: 135px auto;
}
@media (min-resolution:1.5dppx),(min-resolution:144dpi) {
.mw-logo {
background-image:url(/static/wikipedia-1.5x.png);
}
}
@media (min-resolution:2dppx),(min-resolution:192dpi) {
.mw-logo {
background-image:url(/static/wikipedia-2x.png);
}
} The closest we've come up with is the following, which seems rather.. suboptimal.
Would there be a better way that doesn't involve |
Was able to improve it slightly by using the Although the middle image still has to use
(example code in PHP, https://gerrit.wikimedia.org/r/215061) |
Glad you got it to work 👍 There are definitely limitations to |
For the record, this has been restarted at #120. |
Currently prefetch and preload are insufficient to e.g. preload a website's logo or header graphic due to it being limited to a fixed url.
For example, Wikipedia specifies their logo in a stylesheet (with a high-res variant specified via media query). Right now the logo isn't fetched until after the browser has loaded the stylesheet and parsed the relevant page HTML that the rules apply to.
If it were an
<img>
tag it could use srcset and be seen by the look-ahead pre-parser (assuming the pre-parser supports srcset). Though that limits how the image can be used (due to limitations in CSS), and is still seen fairly late due to how Wikipedia body HTML is ordered (content is before nav sidebar). And using an image is impractical as it would require purging edge caches in order to effectively change the logo (as opposed to changing a stylesheet).A preload instruction is relatively easy to add with an HTTP header.
The text was updated successfully, but these errors were encountered: