4

Let's say I have one page big.html that uses

<img alt="big image" src="big.jpg" width="300" height="300" />

where big.jpg is indeed an image of 300 by 300 pixels. And on a different page small.html I want to use the same image in half its size. This could be achieved in two ways:

  1. <img alt="small image" src="big.jpg" width="150" height="150" />
  2. <img alt="small image" src="small.jpg" width="150" height="150" />, where small.jpg is a precomputed scaled-down version of 150 by 150 pixels.

The advantage if variant 1 is: If the user recently visited big.html, they presumably already have big.jpg in cache and hence no additional image download is needed for small.html. The disadvantage is: If the image is not yet cached, page small.html is unnecessarily slow because it loads a much bigger image than needed (and accordingly, tools such as PageSpeed Insights complain). Then again, this loss is compensated in case they later visit big.html and do not need to download the big version again.

Conversely, the disadvantage of variant 2 is that the small image needs to be downloaded even if a just as useful larger version is already available, and its advantage is that a small image is faster when the cached big image is not available. Then again, visiting big.hmtl later will need to download big.jpg instead of reusing something from cache. (And in addition, it might be possible to optimize the precomputed scaled-down version further, beyond a mere automated out-of-the-box scaling)

Q: Is it possible to get the best of both worlds in something similar to the negotiation of media types ("If you understand webp, download this small *.webp file; otherwise, download the original *.jpg file"), i.e. something like "If you have A.jpg in your cache, use it; otherwise download B.jpg"?

2
  • You could potentially determine if the user has visited big.html in the current session and serve big.jpg if they have (assuming it has been cached) and small.jpg otherwise. However, this would seem to add a lot more complexity for very little gain.
    – MrWhite
    Jan 31 at 0:53
  • 1
    developers.google.com/web/ilt/pwa/… lets you fully override how the browser handles the cache
    – lights0123
    Jan 31 at 1:18
6

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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.