Skip to main content
Clarified the part about privacy
Source Link
Trich
  • 616
  • 3
  • 4

TL;DR answer: I don't think that exists in the way you mentioned similar to webp and, if it's possible, it would be with messy/unsupported workarounds. It may even trigger some ad blockers / antivirus. Unlike with webp, which is just a test of browser capability and not user-specific at all. I don't really know, but privacy laws are changing fast and don't seem to be based in reality anyway. I only imagine this being a problem because it would be done with some kind of weird workaround. It would be fine if a standard/official method existed. "Why are you asking what's in my cache? How dare you?!? I feel violated!"

Long answer:

Are these the image dimensions you're using or just examples? Both are very small and the benefits may not be worth it for a few reasons.

The main reason I can think of: if you use something like Cloudflare, using big.jpg in both cases will make it more likely that the image is available at "the edge" (Cloudflare data center closest to the user). It will download very quickly because of proximity and there will be no communication at all with your origin server, which is great.

With image variants, it's more likely that one or the other isn't available from Cloudflare at any given moment, because it has fallen out of the cache for whatever reason (usually because it hasn't been accessed recently and/or simply not popular enough in that geographical location). In that case, it will have to be retrieved from your origin server, causing a delay and using your origin's resources. You and the user are both disadvantaged when this happens, and the PageSpeed Insights score will be lower for tests that get served images from your origin.

Using variants also adds complexity/weight to whatever you're doing. More code, more files, more "decisions" to be made by the various systems between you and your users. This part is probably not a big deal in your case, but like I said, the benefits may not be worth it for these dimensions.

I would suggest looking at using the srcset attribute but as far as I know even the smallest device used to view the website would request the 300x300 variant most/all of the time.

Finally, you would need to find out how likely it is that a user goes from big.html > small.html and vice versa to know whether you would get much benefit / disadvantage from the configs you mentioned. (And I'm fairly sure PageSpeed Insights never accounts for this - it doesn't have a browser cache so it will request whatever image fits for the mobile/desktop tests).

TL;DR answer: I don't think that exists in the way you mentioned similar to webp and, if it's possible, it would be with messy/unsupported workarounds. It may even trigger some ad blockers / antivirus. Unlike with webp, which is just a test of browser capability and not user-specific at all. I don't really know, but privacy laws are changing fast and don't seem to be based in reality anyway. "Why are you asking what's in my cache? How dare you?!? I feel violated!"

Long answer:

Are these the image dimensions you're using or just examples? Both are very small and the benefits may not be worth it for a few reasons.

The main reason I can think of: if you use something like Cloudflare, using big.jpg in both cases will make it more likely that the image is available at "the edge" (Cloudflare data center closest to the user). It will download very quickly because of proximity and there will be no communication at all with your origin server, which is great.

With image variants, it's more likely that one or the other isn't available from Cloudflare at any given moment, because it has fallen out of the cache for whatever reason (usually because it hasn't been accessed recently and/or simply not popular enough in that geographical location). In that case, it will have to be retrieved from your origin server, causing a delay and using your origin's resources. You and the user are both disadvantaged when this happens, and the PageSpeed Insights score will be lower for tests that get served images from your origin.

Using variants also adds complexity/weight to whatever you're doing. More code, more files, more "decisions" to be made by the various systems between you and your users. This part is probably not a big deal in your case, but like I said, the benefits may not be worth it for these dimensions.

I would suggest looking at using the srcset attribute but as far as I know even the smallest device used to view the website would request the 300x300 variant most/all of the time.

Finally, you would need to find out how likely it is that a user goes from big.html > small.html and vice versa to know whether you would get much benefit / disadvantage from the configs you mentioned. (And I'm fairly sure PageSpeed Insights never accounts for this - it doesn't have a browser cache so it will request whatever image fits for the mobile/desktop tests).

TL;DR answer: I don't think that exists in the way you mentioned similar to webp and, if it's possible, it would be with messy/unsupported workarounds. It may even trigger some ad blockers / antivirus. Unlike with webp, which is just a test of browser capability and not user-specific at all. I don't really know, but privacy laws are changing fast and don't seem to be based in reality anyway. I only imagine this being a problem because it would be done with some kind of weird workaround. It would be fine if a standard/official method existed. "Why are you asking what's in my cache? How dare you?!? I feel violated!"

Long answer:

Are these the image dimensions you're using or just examples? Both are very small and the benefits may not be worth it for a few reasons.

The main reason I can think of: if you use something like Cloudflare, using big.jpg in both cases will make it more likely that the image is available at "the edge" (Cloudflare data center closest to the user). It will download very quickly because of proximity and there will be no communication at all with your origin server, which is great.

With image variants, it's more likely that one or the other isn't available from Cloudflare at any given moment, because it has fallen out of the cache for whatever reason (usually because it hasn't been accessed recently and/or simply not popular enough in that geographical location). In that case, it will have to be retrieved from your origin server, causing a delay and using your origin's resources. You and the user are both disadvantaged when this happens, and the PageSpeed Insights score will be lower for tests that get served images from your origin.

Using variants also adds complexity/weight to whatever you're doing. More code, more files, more "decisions" to be made by the various systems between you and your users. This part is probably not a big deal in your case, but like I said, the benefits may not be worth it for these dimensions.

I would suggest looking at using the srcset attribute but as far as I know even the smallest device used to view the website would request the 300x300 variant most/all of the time.

Finally, you would need to find out how likely it is that a user goes from big.html > small.html and vice versa to know whether you would get much benefit / disadvantage from the configs you mentioned. (And I'm fairly sure PageSpeed Insights never accounts for this - it doesn't have a browser cache so it will request whatever image fits for the mobile/desktop tests).

Source Link
Trich
  • 616
  • 3
  • 4

TL;DR answer: I don't think that exists in the way you mentioned similar to webp and, if it's possible, it would be with messy/unsupported workarounds. It may even trigger some ad blockers / antivirus. Unlike with webp, which is just a test of browser capability and not user-specific at all. I don't really know, but privacy laws are changing fast and don't seem to be based in reality anyway. "Why are you asking what's in my cache? How dare you?!? I feel violated!"

Long answer:

Are these the image dimensions you're using or just examples? Both are very small and the benefits may not be worth it for a few reasons.

The main reason I can think of: if you use something like Cloudflare, using big.jpg in both cases will make it more likely that the image is available at "the edge" (Cloudflare data center closest to the user). It will download very quickly because of proximity and there will be no communication at all with your origin server, which is great.

With image variants, it's more likely that one or the other isn't available from Cloudflare at any given moment, because it has fallen out of the cache for whatever reason (usually because it hasn't been accessed recently and/or simply not popular enough in that geographical location). In that case, it will have to be retrieved from your origin server, causing a delay and using your origin's resources. You and the user are both disadvantaged when this happens, and the PageSpeed Insights score will be lower for tests that get served images from your origin.

Using variants also adds complexity/weight to whatever you're doing. More code, more files, more "decisions" to be made by the various systems between you and your users. This part is probably not a big deal in your case, but like I said, the benefits may not be worth it for these dimensions.

I would suggest looking at using the srcset attribute but as far as I know even the smallest device used to view the website would request the 300x300 variant most/all of the time.

Finally, you would need to find out how likely it is that a user goes from big.html > small.html and vice versa to know whether you would get much benefit / disadvantage from the configs you mentioned. (And I'm fairly sure PageSpeed Insights never accounts for this - it doesn't have a browser cache so it will request whatever image fits for the mobile/desktop tests).