Following up on this a couple of years later as I think I previously misunderstood something, however, I still think there is still an easy win here for performance.
Previously I thought the avatars were being stored locally (Discourse server itself) and was wondering why they weren’t served directly from the SSO external avatar URL instead of hitting Discourse. However, after some poking, I see now that external avatars coming from SSO are already uploaded to the object storage (e.g. S3) and in the required multiple sizes.
So, if I understand correctly, currently Discourse is proxying avatars from the object storage to the client. However, this behavior seems specific to when using SSO external avatars since avatars here in meta are coming directly from the (CDN’ed) object storage. But when using SSO with external URLs, the avatar URLs are in the form
https://discourse-host/user_avatar/discourse-host/{username}/{size}/{uploadid}_{version}.png
where it hits rails for every avatar displayed (before being cached by the client).
And if I understand the code, there’s even a setting to allow a redirect instead of proxying it, but at that point it already hit rails and the redirect only adds up time to the load time for the client.
Wouldn’t it be faster to just link avatars to the object storage (potentially serving it from a CDN) while freeing some rails resources at the same time? /cc @Falco