Image Redirect Caching with Seed

[benkaiser]

Is there a particular reason redirects are instructed to not cache + use a 302 redirect (instead of 301), even when calling with a specific seed url?

I am calling endpoints such as:

https://picsum.photos/seed/7890/400/200

Which will always give me the exact same image. So why instruct the browser to not cache? Seems like it increases the load on the service, and provides a poorer experience for users having to load the image every time it is rendered on the page (despite not changing).

This is a very low priority request, just curious to the background. Absolutely love the work here and this service is absolutely invaluable!

[DMarby]

Hi @benkaiser!

Thank you for reaching out. The reason why all redirects from picsum.photos are 302s and have non-cache directives, is that the resulting image URL we redirect to is not guaranteed to be static, even though they generally are, and we do serve the same image for all /seed responses.

When an image request comes in to picsum.photos, our API service validates the request, and builds the redirect to our image processing service (fastly.picsum.photos). Images are then processed/served by our image processing service as needed, backed by a CDN, but these URLs may change over time. This gives us the freedom to re-architect the backend without service interruption.

This does mean that a client always pays the cost of having to make the request that results in the actual redirect, but the images served by the image service on fastly.picsum.photos (post redirect) does set cache headers, so the actual image should be getting cached appropriately (given the mostly static URL). If this is not the case, please let me know, and I'm happy to look over the cache headers et-al.

[benkaiser]

Thanks for the detailed info @DMarby !

So if that's the case, I should avoid storing the picum.photos url and instead store the redirected url and then always render the image tag with that if I want to give the user the smoothest most-cachable experience?
Just sounds like that may run into issues eventually if, like you say, the URLs might not be static forever.

Is there a middle ground option where we could have some kind of TTL on the redirect of a week or something, rather than using no-cache (specifically for seed URLs)?

[DMarby]

In general, you should only be storing the picsum.photos URLs, as they're the only public API we guarantee will not change. The redirect URLs are implementation detail that may change, and as such, you shouldn't be relying on them (or storing them).
This will mean that there's always at least one request being made per image, but given that it's only a redirect, this is relatively cheap.

There is likely a viable middle-ground with shorter-lived TTLs for seed URLs, yeah!
It would complicate the api service a bit to implement, so not likely to do so in the near-term, but will leave this issue open to track as a potential future improvement.

[benkaiser]

Sounds good. In the meantime I'll look into caching the redirects/image caching with service worker to try to improve client performance.

[calebjacob]

Hey @DMarby, thanks so much for building this. The seed endpoint is perfect for what my team needs, but I've noticed a pretty lengthy response time for the initial request before the redirect occurs.

Here's an example URL I'm using: https://picsum.photos/seed/campaign-fiesta/1000/1000

I see an average ~750ms response time before the redirect to the CDN. It can sometimes get above 1 second I've seen. It's long enough that it feels a bit jarring every time you reload the image. It'd probably be fine if it was closer to 250ms.

What you said here definitely makes sense:

In general, you should only be storing the picsum.photos URLs, as they're the only public API we guarantee will not change. The redirect URLs are implementation detail that may change, and as such, you shouldn't be relying on them (or storing them).

And this sounds like a good solution:

There is likely a viable middle-ground with shorter-lived TTLs for seed URLs, yeah!