Do not require the browser to load images that are much larger than the size used to show them


Issue: When searching for people on Synapse (!PeopleSearch, I believe that the browser is loading the original user profile image (avatar) for each user, which is today 200 x 200 pixels. Note that some users have much larger images, for example Mike Kellen has a 1278 x 720 avatar. In a list, the user avatar is only shown as a 60x60 image (see figure). This example extends to all images on Synapse. A page could load much faster if Synapse provides images in a size equal or similar to the size of the displayed image. Using larger images also lead to a waste of data usage, in particular when accessing Synapse from smartphone and/or subscriptions that do not provide unlimited data usage.

Suggested solutions: There are at least two strategies:
1. When an image is uploaded, generate automatically downsized versions of the image. For example, we could support “small” (20% of the original size), “medium” (50%) and “large/original” (100%) sizes. The issue with this strategy is that we are paying to store extra images that may not be used.

2. A preferred strategy would be to put in place an “image handler service” that allows to query an image as well as parameters that describe a series of transformations of the image (e.g. resize, color transformation, rotation, etc.). When the service receives a request, it would check if this request has been requested/processed “recently”. If yes, the resulting image is retrieved from cache and returned. If not, the image is processed on the fly, returned to the user and cached. Using AWS object storage expiration time, for example, cached images be destroyed after a given time period. This way, we only pay to store the original image if nobody requests the image. For the first user to request an image, it could take slightly longer to return the image because it is computed on the fly. If the image is frequently accessed, subsequent users would have the image returned faster since it is retrieved from cache.

If you are interested in this solution 2, I have an improved version of that is deployed as an AWS stack. The configuration is relatively straight forward and only requires to provide an AWS bucket that includes the original images.






Thomas Schaffter




Thomas Schaffter

Development Area


Release Version History


Affects versions